> John will comment, I'm sure, but there's also
> run-time efficiency reasons. If you only ever
> call a particular core opcode with static parameters,
> you can generate a special instance of the opcode
> with the parameters "rolled into" the opcode code.
Yes, with each release, sfront's opcode implementations
(core and to a degree user-defined) become more like
"module generators" and less like straight code. Constancy
is one of several properties the generators use -- rate,
implied integer or float, use of optional parameters,
all come into play. An extreme feature, currently in the
development version and due out in a week or two, traces
all table arguments back to their source, through multiple
levels of opcode calls if needed -- this will also be used
to rate-optimize tablemap indexing.
Apart from these issues, though, there are a few other
reasons why sfront isn't the right vehicle for a DLL for
opcodes:
-- The data structures the opcodes manupulate look a lot
more like Fortran than C++, on purpose -- sfront depends
on having a good optimizing C compiler detect things like
arrays being indexed by a constant, and a lot of the data
strcuture choices in sfront are geared to exposing static
optimization opportunities.
-- In an interpeted system, you'll really want to use the
techniques Giorgio and collaborators have developed for
blocking -- these techniques will probably make it into
sfront eventually in some form, but sfront currently is
looking in different directions for speedups -- directions
that leverage compilation.
Basically, if you're looking to embed sfront-related
technology into a system, I'd recommend embedding sfront
itself, if it fits the product (a C compiler is available,
the latency of C compilation is OK, the GPL is compatible
with your licensing, ect). If it doesn't fit, I'd recommend
either leverging an existing commercial or free interpeter,
or rolling your own ...
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:50 EDT