This is the mail archive of the guile@sourceware.cygnus.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: 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. :-)]

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