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 <[email protected]> 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" > >
