[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile-vm 0.3
From: |
Rob Browning |
Subject: |
Re: guile-vm 0.3 |
Date: |
09 Apr 2001 12:59:14 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
Marius Vollmer <address@hidden> writes:
> Hmm, might be worth a try. For what it's worth, you should be able to
> use Lightning already to construct calls to C code:
Interesting.
> Anyway, I'm not sure if run-time generation of wrappers is an
> advantage. We are wrapping libraries that are batch-compiled, so
> why not wrap them with another batch-compiled library?
I'm not sure it is an advantage, but I thought it was worth
discussing. One potential win is space/code-density. In g-wrap, we
wrap about 313 functions, and the wrapper .o file alone turns out to
be 768K. Now perhaps I can shrink that by being smarter about what is
put in the wrappers, but off the top of my head, I don't think it'll
shrink much. With an on-line (or in-line) system, you only wrap the
things you need, where you need them (depending on how it's
implemented).
(One other thing I found interesting was that libfcall supports C side
closures. Not sure if it'd be useful for anything for us, though...)
> I think you want to have a real compiler for this, that does real
> type inference. In the midst of fixnum arithmetic and pair walking
> optimizations it could also do some subr optimizations. In fact,
> the compiler could maybe do the complete wrapping...
Right. That's what I was getting at. Mostly I was thinking of where
we want to go in the long run. Do we want to continue with an
off-line wrapper-processor and supplemental libwrapfoo.so files, or do
we want an on-line approach (is there any convincing benefit to
it?)...
> I am quite confident that once we can demonstrate a compiler for, say,
> the i386 platform, it will not be long before it gets ported to other
> popular architectures
:>
> [ Still, it _is_ great fun to work on a native compiler and, given GNU
> Lightning, it is not really difficult, either. I now have a
> prototype that efficiently compiles tail-calls and inner-function,
> argument passing gotos. It does no register allocation yet, tho,
> but that will come soon.
That's quite nice :>
--
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930
- Re: guile-vm 0.3, (continued)
- Re: guile-vm 0.3, Rob Browning, 2001/04/03
- Re: guile-vm 0.3, Evan Prodromou, 2001/04/04
- Re: guile-vm 0.3, Ariel Rios, 2001/04/05
- Re: guile-vm 0.3, Rob Browning, 2001/04/05
- Re: guile-vm 0.3, Marius Vollmer, 2001/04/05
- Re: guile-vm 0.3, Ariel Rios, 2001/04/05
- Re: guile-vm 0.3, Marius Vollmer, 2001/04/05
- Re: guile-vm 0.3, Miroslav Silovic, 2001/04/06
- Re: guile-vm 0.3, Rob Browning, 2001/04/09
- Re: guile-vm 0.3, Marius Vollmer, 2001/04/09
- Re: guile-vm 0.3,
Rob Browning <=
- Re: guile-vm 0.3, Rob Browning, 2001/04/05
- Re: guile-vm 0.3, Ariel Rios, 2001/04/05
- Re: guile-vm 0.3, Rob Browning, 2001/04/06
- Re: guile-vm 0.3, Marius Vollmer, 2001/04/09
- Re: guile-vm 0.3, Evan Prodromou, 2001/04/09
- Re: guile-vm 0.3, Marius Vollmer, 2001/04/09
- Re: guile-vm 0.3, Rob Browning, 2001/04/09
- Re: guile-vm 0.3, Marius Vollmer, 2001/04/09
- Re: guile-vm 0.3, Rob Browning, 2001/04/09
- Re: guile-vm 0.3, Keisuke Nishida, 2001/04/11