Discussion:
[Larceny-users] Generating interoperable closures
David Rush
2010-06-04 18:06:34 UTC
Permalink
Hello all -

I'm looking at doing quite a bit of language protoyping with what are
basically Schemely semantics, and I was wondering just how difficult it is
to generate my own closures that will play correctly with the rest of the
Larceny run-time. Actually, I'm wondering even more if there is a secret
documentation cache somewhere with hints on the interactions between the
compiler and the run-time, because i don't really recall seeing much on that
beyond what is in the ABI/FFI documents.

Basically I'd like to be able to take advantage of the Larceny back-end
optimizations and run-time while putting up a new surface language. Does
anyone have any suggestions on where to start looking, even?

david
--
GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
w***@ccs.neu.edu
2010-06-04 21:18:10 UTC
Permalink
Post by David Rush
I'm looking at doing quite a bit of language protoyping with what are
basically Schemely semantics, and I was wondering just how difficult it is
to generate my own closures that will play correctly with the rest of the
Larceny run-time.
The easiest way to do that, by far, is to translate the relevant
parts of your prototype language into Scheme and run that through
Larceny's standard compiler or interpreter(s).

The second easiest way is to translate into Larceny's so-called
"MacScheme machine language" and run that through Larceny's standard
assembler(s). The hooks are exposed only in twobit.heap, which is
no longer being shipped with binary distributions so you'll have to
build it yourself.

The hardest way, by far, is to generate the machine code and data
structures yourself without using any of Larceny's infrastructure.
Post by David Rush
Actually, I'm wondering even more if there is a secret
documentation cache somewhere with hints on the interactions between the
compiler and the run-time, because i don't really recall seeing much on that
beyond what is in the ABI/FFI documents.
The representations are different in the four different varieties
of Larceny (Larceny/IA32, Larceny/Sparc, Petit Larceny, and Common
Larceny). The representations for the first three varieties are
similar, but not identical because of byte ordering and similar
details.
Post by David Rush
Basically I'd like to be able to take advantage of the Larceny back-end
optimizations and run-time while putting up a new surface language. Does
anyone have any suggestions on where to start looking, even?
Where you'd start looking depends on the approach you choose. Here
are some random pointers, in no particular order:

Larceny User Manual, section 10.4 (documents make-procedure etc).

Larceny Note #2: Data Representations (slightly obsolete)
http://larceny.ccs.neu.edu/doc/LarcenyNotes/note2-repr.html

Larceny Note #6: Larceny on the SPARC
http://larceny.ccs.neu.edu/doc/LarcenyNotes/note6-sparc.html

Larceny Note #13: MacScheme Machine Instruction Set
http://larceny.ccs.neu.edu/doc/LarcenyNotes/note13-malcode.html

Examples of handed-coded MacScheme machine code
https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/src/Lib/Common/malcode.mal
https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/src/Lib/Common/arith.mal

Assemblers:
https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/src/Asm

IA32 assembly code and conventions:
https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/src/Rts/globals-nasm.cfg
https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/include/Shared/i386-machine.ah
https://trac.ccs.neu.edu/trac/larceny/browser/trunk/larceny_src/src/Rts/Shared/i386-millicode.asm

Will

Loading...