Re: Extensible vm ops?

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

Hi,

I have now implemented most of the rtl oops and in the phase where i am
testing the ops so that all generate assembler .e.g. generate not run, I
will run them later.

I have a few problems usng the rtl codebase, namely I don't know how to
tell the
program where the rtl bytecode ends, I would expect wingo to clear this up
in a few weeks
and for now I can manualy tune this for the compilation to native code.

For the question of having a possibility to extend the byte-code or native
instruction generation
I would like to implement something like SBCL and CMUCL's VOP, e.g. a
virtual instructions
that can be translated to machine code. I think that we can copy that
interface.

Anyway one important feature of these virtual instructions are that they
will need to specify the
register usage in order for guile at a later stage be able to store data in
cpu registers. Thinking about this
one thing that make things harder is that in many instructions we have fast
paths for e.g. fixnums and
a backup plan using a C function call. Now that means that we loose the
control over registers which may be clobbered by the C-function. One way to
solve this is to jump to common code for dispatching to C call's e.g. we
have a few call stubs where a set of registers are pushed ontop of the
stack before the call and then pushed back at the end of the call. This can
work but it will make the slow path slower.
I would still vote for such a feature if and when we will be able to make
reasonable efficient use of cpu registers across instructions.

Regards
Stefan


On Thu, Aug 9, 2012 at 9:07 AM, Tristan Colgate <tcolgate@gmail.com> wrote:

> Hi All,
>
>   Is it possible, or practical, to support addition of VM ops to the
> VM dynamically?
>
>   The only use case I am really thinking of is for adding SIMD based
> functions for operations on uniform numeric vectors. I realise I could
> just take all the funky maths and add it in a C extension, but then
> I'm calling out to C, have an extra function call and all that
> entails.
>
>   Providing a bunch of hard coded SIMD based vector ops might well be
> good enough, but I thought a more general solution might be sexier.
> I've no idea how such a thing might look though.
>
> --
> Tristan Colgate-McFarlane
> ----
>   "You can get all your daily vitamins from 52 pints of guiness, and a
> glass of milk"
>
>

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]