guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]