Re: Extensible vm ops?

[Stefan Israelsson Tampe]

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 <address@hidden> 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"