[racket] assembly language

> 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 <bloch at adelphi.edu>
To: Hugh Aguilar <hughaguilar96 at 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
sbloch at adelphi.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121001/7c0878f0/attachment-0001.html>