This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: librep's indirect threaded bytecode interpretter
Michael Livshin writes:
> Per Bothner <per@bothner.com> writes:
>
> > A more Scheme-centric, more compact bytecode may be more efficient
> > on a *simple* interpreter - but it really depends more on how smart
> > the compiler is that generates the bytecode, and how clever the
> > interpeter (augmented by a just-in-time compiler) is.
>
> at this point I have only one but very general question:
>
> as everybody knows, among the flagship GNU products there are the GNU
> Compiler Collection and the GNU Binutils.
>
> was there ever any research done aimed at making these things suitable
> for an interactive native-compiling language environment? it seems
> such a shame that so much backend and porting work is done for all
> those icky batch languages like C, C++, Java, Chill, Pascal, etc,
> while all the Lisp, Scheme, Prolog & ML systems out there are
> basically out in the cold when it comes to native compilation.
How about as a starter having a toolkit that each of these languages use?
[by "these" I'm refering to "Lisp, Scheme, ..." you mention.]
The toolkit would derive the necessary info about each particular target cpu
from a machine description of the cpu. Binutils would also derive
a large part of its data/code from the same machine description (ideally
ditto for GCC at least to some minimal extent). [Simulators for each cpu
could also be derived from the same machine description but that's off topic.]
Hence doing a GNU toolchain port to a cpu would to a large extent simply
involve writing the machine description, and having done so a lot more
applications would benefit.
Ideally what we'd have is an "application independent machine description".
Each application would machine generate the relevant code/data it needs
(or use existing general purpose machine generated code/data also
derived from the machine description).
[One might even write most of the framework in Guile (by framework
I mean code that slurps in the machine description and code that
machine generates code/data for each respective application).
Then the toolkit would use Guile, and Guile would use the toolkit. :-)]