From: Nala Ginrut <nalaginrut@gmail.com>
To: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
Cc: Andy Wingo <wingo@pobox.com>, guile-devel <guile-devel@gnu.org>
Subject: Re: A vm for native code in guile
Date: Mon, 14 Jan 2013 10:51:46 +0800 [thread overview]
Message-ID: <1358131906.23443.129.camel@Renee-desktop.suse> (raw)
In-Reply-To: <CAGua6m0iMtWB4e2w7Xn6HnJfKib-+5WpDJjRTKV4id_FkS5UNw@mail.gmail.com>
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
next prev parent reply other threads:[~2013-01-14 2:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 7:53 A vm for native code in guile Stefan Israelsson Tampe
2012-07-02 22:16 ` Andy Wingo
2012-07-03 14:24 ` Stefan Israelsson Tampe
2012-07-07 20:12 ` Stefan Israelsson Tampe
2012-08-01 20:59 ` Stefan Israelsson Tampe
2013-01-14 2:51 ` Nala Ginrut [this message]
[not found] ` <CAGua6m0x-W4kdWCSoonjn-+xY=RvSjvniN=wQH53h+MzEQPpbw@mail.gmail.com>
2013-01-14 9:10 ` Nala Ginrut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1358131906.23443.129.camel@Renee-desktop.suse \
--to=nalaginrut@gmail.com \
--cc=guile-devel@gnu.org \
--cc=stefan.itampe@gmail.com \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).