[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A vm for native code in guile
From: |
Nala Ginrut |
Subject: |
Re: A vm for native code in guile |
Date: |
Mon, 14 Jan 2013 10:51:46 +0800 |
On Wed, 2012-08-01 at 22:59 +0200, Stefan Israelsson Tampe wrote:
> Hi,
>
> The byte-code -> native-code compiler is does serve my needs pretty well
> now. It should really
> soon be possible to add code that will auto compile bytecode versions to
> native versions. The compiler is not perfect and some instructions is
> missing. But it can go from VM->NATIVE->VM and so on so whenever there is
> missing instruction the compiler can bail out to vm code. What's left is
> to be able to go from VM to Native returning multiple values and in all
> call positions.
>
> To note
>
> * the code is for x86-64, linux.
>
> * Windows have another calling convention => the assembler has to be recoded
> => we need compilers for all interesting combinations of operating
> systems and native targets
>
> * Using the C-stack is nice because the native push and pop instructions
> can be used as well as
> brk-ings makes for automatic stack growth? also calling out c functions
> can be fast. On the
> other hand stack traces is defunct with this code and I'm uncertain how
> the prompting will
> cope with this feature. It's probably better to use a separate stack for
> the native code and model
> it like the wip-rtl stack. On the other hand it has been convenient to
> use it as a stack to save
> variables before calling out to helper c-functions, but these helper
> functions usually is on the slow
> path and the savings can be done using helper registers that is local to
> the vm a little bit slower
> but doable. Not sure what path to take here.
>
> * Writing assembler is really tough. Because debugging is really difficult.
>
IMO, we don't have to write assembler again, since GNU Binutils does.
The only necessary work is to map bytecode->asm, and add a AOT option
with a script into 'guild' for calling Binutils.
We may borrow some work from GCC. I don't know if it's easy, but GCC
uses Lisp-like thing to handle machine-description. Though it could be
interesting, it's a lot of work todo. Then it could support many
platforms rather than x86.
> * To ease things I compiled C code and examined the assembler => fragile
> and difficult to port the
> code. The final version needs to put more effort into probing for
> constants used in the generated
> assembler.
>
> * x86 code is pretty different because of the low number of registers and
> invariant registers over c-call's
>
> * prompt and aborts are tricky instructions!
>
> Example:
> as an example reducing a list of 1000 elements with a function that is
> basically + a 4x increase in performance when compiling to native code
> could be seen. This are typical figures for what one can expect to improve
> in speed. A smarter usage of registers and less poping and pushing (RTL)
> could mean that we can increase the speedup from stable-2.0 even further.
>
>
> I will next week start working on the RTL branch porting the current setup
> but use the rtl stack in stead of the native C stack.
>
> Regards
> /Stefan
- Re: A vm for native code in guile,
Nala Ginrut <=