From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: A vm for native code in guile
Date: Wed, 1 Aug 2012 22:59:28 +0200 [thread overview]
Message-ID: <CAGua6m0iMtWB4e2w7Xn6HnJfKib-+5WpDJjRTKV4id_FkS5UNw@mail.gmail.com> (raw)
In-Reply-To: <87obnxreq5.fsf@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]
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.
* 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
[-- Attachment #2: Type: text/html, Size: 2587 bytes --]
next prev parent reply other threads:[~2012-08-01 20:59 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 [this message]
2013-01-14 2:51 ` Nala Ginrut
[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=CAGua6m0iMtWB4e2w7Xn6HnJfKib-+5WpDJjRTKV4id_FkS5UNw@mail.gmail.com \
--to=stefan.itampe@gmail.com \
--cc=guile-devel@gnu.org \
--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).