[racket] assembly language

[Hugh Aguilar]

Hello. I'm new to Racket. I tried learning Factor previously but had difficulty understanding the concepts and the terminology, so I decided to try Racket instead --- Racket has a lot of novice-oriented documentation available, plus Scheme has books available also. I may learn Common Lisp simultaneously with Racket, but right now I'm just interested in learning Racket. My impression is that CL is oriented more to writing large programs.

 

I have a question to start off:

 

Is there an x86 assembler available in Racket? If so, does it support the 64-bit x86?

 

I'm writing a program in HLA right now. HLA is limited to 32-bit x86 and I would prefer 64-bit, although I can stick with 32-bit if necessary.

 

[Tony Garnock-Jones]

On 09/24/2012 01:27 AM, Hugh Aguilar wrote:
> Is there an x86 assembler available in Racket? If so, does it support
> the 64-bit x86?

There's Noel Welsh's IA32 assembler
https://github.com/noelwelsh/assembler. I guess it doesn't support
x86_64 yet.

> I'm writing a program in HLA right now. HLA is limited to 32-bit x86 and
> I would prefer 64-bit, although I can stick with 32-bit if necessary.

I don't think there's anything directly analogous to HLA. Noel's work
assembles straight to memory, rather than being an offline assembler. I
suppose with a bit of work (ELF emitter) it could be used instead of gas.

Regards,
Tony
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Hugh Aguilar]

I don't want anything analogous to HLA, NASM, etc. I want an assembler that goes straight to memory.

 

I am writing a Forth system. I want it to be interactive in the usual Forth way. This means assembling a function at run-time and immediately being able to run the assembled function.

 

What I was doing in HLA was writing a lot of functions in HLA assembly. Then, during the run-time of the HLA program, pasting together snippets of those functions to produce new functions. This involves poking values into the code snippets after they are pasted in, for such things as literal values and displacement values and so forth. This is a major hassle. It also has a lot of limitations to what can be done. I'm much better off if I can just assemble the functions at run-time for the Forth system (which is compile-time for the user's Forth program).

 

I would like 64-bit though. My understanding is that there are CL assemblers available that provide 64-bit, and there is Gambit Scheme's assembler that also provides 64-bit. I think Racket may get voted off the island. I'm still interested in Racket for other things though.

[Stephen Bloch]

On Sep 25, 2012, at 7:38 PM, Hugh Aguilar <hughag...@yahoo.com> wrote:

I am writing a Forth system. I want it to be interactive in the usual Forth way. This means assembling a function at run-time and immediately being able to run the assembled function.

 

... I'm much better off if I can just assemble the functions at run-time for the Forth system (which is compile-time for the user's Forth program).

The traditional way to implement a Forth compiler, IIUC,  isn't to generate executable machine code at all, but rather to generate a sequence of word-references that are interpreted as procedure calls by the Forth interpreter (which is in native executable code, but written in advance).

Or are you talking about some kind of JIT compiler?

Stephen Bloch

sbl...@adelphi.edu

who last implemented a Forth system in 1983; I presume things have changed since then!

[Ray Racine]

A couple of years ago or so, time does run like water, Larceny merged in a x86 assembler which 100% scheme.  If I recall the original project was 100% standalone x86 assembler / linker.  

[Alex Shinn]

On Wed, Sep 26, 2012 at 9:58 AM, Ray Racine <ray.r...@gmail.com> wrote:
> A couple of years ago or so, time does run like water, Larceny merged in a
> x86 assembler which 100% scheme. If I recall the original project was 100%
> standalone x86 assembler / linker.

It's Jonathan Kraut's Sassy (http://sassy.sourceforge.net/).
There's a Chicken egg of it available as well.

--
Alex

[Hugh Aguilar]

----- Forwarded Message -----
From: Hugh Aguilar <hughag...@yahoo.com>
To: Stephen Bloch <bl...@adelphi.edu>
Sent: Wednesday, September 26, 2012 8:07 PM
Subject: Re: [racket] assembly language

You are right that a threaded Forth doesn't need to do any assembly --- it just "compiles" pointers to functions (code field addresses) in a thread. This can and has been done with traditional assemblers such as HLA. I'm not interested in that though.

 

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).

 

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. 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. It must work somehow though, as it seems to be done quite a lot (the JVM for example).

 

I'm not planning on JIT (especially as I don't understand it). I just want the compiler to assemble actual text source-code rather than paste together code snippets, which I am finding to be a hassle. This will be done at compile-time for the Forth application --- at run-time the Forth application just runs.

 

 

 

 

From: Stephen Bloch <bl...@adelphi.edu>
To: Hugh Aguilar <hughag...@yahoo.com>
Cc: Tony Garnock-Jones <to...@ccs.neu.edu>; "us...@racket-lang.org" <us...@racket-lang.org>
Sent: Tuesday, September 25, 2012 5:12 PM
Subject: Re: [racket] assembly language

[Hugh Aguilar]

> 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 <hughag...@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