> Since Forth's design is so tied to its implementation, that could actually
> break some working programs.
A lot has changed since 1983 when you were into Forth. I'm 40 pounds heavier,
for one thing. On a more positive note, Forthers have gotten smarter --- we no
longer standardize the implementation, but only what it does. Forth programs
are no longer supposed to know about what kind of threading scheme is being
used under the hood. All of that stuff is abstracted out now.
> I think the main goal of JIT is the ability to distribute compiled code in a
> machine-independent way.
That is an interesting idea. I thought of the possibility of doing this in
Forth with a threaded implementation (no JIT though). It could be done, but I
doubt anybody would want it. Sun knew from the get-go that they would have
thousands of Java users and a dozen platforms, so it made sense for them. I
wrote a Forth development system in the past; only one application has ever
been written for it (the motion-control program for a laser etcher). This is a
big success by Forth standards --- 1 paying customer is infinitely more that 0,
which is what most compiler-writers have. Within this context, moving programs
sans source-code between platforms is not an issue. :-)
I don't think that JIT is anything I'd want for my Forth. Thanks for explaining
it though --- I'm always interested in learning about what is going on in the
real world.
From: Stephen Bloch <bl...@adelphi.edu>
To: Hugh Aguilar <hughaguila...@yahoo.com>
Sent: Thursday, September 27, 2012 4:03 AM
Subject: Re: [racket] assembly language
I want to generate machine-code functions. This involves assembling at run-time
(for the forth system, which is compile-time for the Forth application program).
Since Forth's design is so tied to its implementation, that could actually
break some working programs. But never mind...
I don't really understand JIT. I suppose the idea is to save memory by
compiling the program as threaded code (which is much smaller than
machine-code), but to convert this into machine-code "just in time" for it to
run.
No, JIT has only been being done for 10-15 years or so, as far as I know, and
RAM has been cheap and abundant for all of that time. I think the main goal of
JIT is the ability to distribute compiled code in a machine-independent way.
I suppose this involves pasting together the code from all of those
sub-functions in the threaded stream to create a sequence of machine-code. It
seems like this conversion would take so much time that it would outweigh any
speed advantage of running machine-code rather than threaded code.
That's what I thought when I first heard about it. I'm no JIT expert, but I
think it's actually used in practice mostly when the interpreter detects a loop
or something else that would benefit substantially from it.
Stephen Bloch
sbl...@adelphi.edu
____________________
Racket Users list:
http://lists.racket-lang.org/users
