This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile-vm-0.2


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> The best (in the sense of producing efficient code) compiler I'm aware
> of is ftp://ftp.nj.nec.com/pub/qobi/stalin-0.8.tar.gz.  (You'll find
> the actual compiler in the file "stalin.sc".)

One thing that's been on my list of things to think-about/try for a
while is to add a simple way (either via g-wrap or a direct addition
to guile) to allow you to (mostly) transparently call stalin compiled
code from guile for cases where the the computation was much more
expensive than the data input/output, and cases where object/pointer
equivalence is irrelevant.

As a first cheap hack, once you'd defined the functions that should be
handled by stalin in some way, I was thinking I'd just automatically
generate code for stalin that contained these function definitions
along with a simple reader.  The reader would listen on the server
application's standard input for function call requests, then call the
functions when asked and spew the results to standard output.  All the
communications across the boundary would be handled as plain text
scheme forms.  I'd also need to autogenerate the infrastructure on the
guile side that would handle launching the stalin executable (if
necessary), sending the function call request, and then "read"ing the
results.

For cases where you're dealing with RNRS code, where the operation is
compute bound relative to the arg/result IO, and where you don't need
language features that stalin won't handle (like eval), it seems like
this could be a big win, and later, if Jeffery Siskind's amenable, it
might be possible to augment stalin to generate a library as the
result of its compilation rather than a standalone executable.  If so,
it might be possible to dynamically load that library and call the RPC
parser directly rather than across a pipe.

However, I've also been wondering if there are really that many
applications where this would actually be useful...

Anyone?

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]