----- Forwarded message from [EMAIL PROTECTED] -----
Date: Fri, 8 Dec 2000 08:55:25 -0800
Subject: Update on C--
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Gentle C-- colleagues
This message is just to update you on the state of play in C--.
Please do send mail to the list if any of you are doing relevant stuff.
Simon
Concurrency framework
~~~~~~~~~~~~~~~~
C-- is meant to support clients that need lightweight concurrency.
Norman and Simon have recently completed a paper giving a first
cut at a design for what support C-- should offer (submitted to PLDI):
Featherweight concurrency in a portable assembler
http://www.cminusminus.org/abstracts/c--con.html
We would be absolutely delighted to get feedback from you about
both the presentation and the content of the paper.
Front ends
~~~~~~~~
We are getting to the stage where we really need compilers that
emit C-- to stress three C-- implementations that exist or nearly exist.
Would any of you be able to help? There are various levels of
stressfulness:
- need core C-- functionality (procedures, global registers)
- need GC support (spans, runtime stack-walking interface)
- need exception support (continuations, more runtime interface)
- need concurrency support (more continuations)
Volunteers please! This doesn't have to be for a "real" compiler or
language. "Toy" ones would be just as good.
Work at Harvard
~~~~~~~~~~~~
Christian and Norman are beavering away on Quick C--. They'll
send round a summary of progress in the next few days.
Fermin Reig's cmmc implementation
~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.dcs.gla.ac.uk/~reig/c--/
Fermin has an implementation of C-- using Lal George's ML Risc
code generator. He writes:
I am in the process of adding support for cut to continuations to
cmmc. This will be in the next version that hopefully will be out
within a week (I've had to make more changes to cmmc than I
anticipated).
Next extension to cmmc: I will implement the GC interface of C--'s RTS
(after Christmas).
Fermin is also writing an OCaml to C-- compiler as a front end. Of
this he says: I have completed the ocaml to C-- translation (all
constructs
of ocaml's IL), and now I am working on the various parts of the ocaml
compiler that call the C-- compiler, linker, etc. This initial version
is without the GC interface (would not run programs that need to do
GC).
Sergei Egorov's TRC implementation of C--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.malgil.com/trc/
Sergei has built an implementation of C-- by compiling C-- to C
and using a trampoline. He writes:
TRC is basically a proof-of-concept implementation that demonstrates
a popular method of compiling tail-recursive procedures to portable C.
I also decided to cover as many features of original C-- spec. as possible
without resorting to assembler or nonportable tricks. C code generated
by TRC is parameterized by several architecture-dependent parameters
contained in cmmrt.h (integer sizes and inline arithmetics); the other
part of platform-dependent code is contained in cmmrt.c (C main, C--
runtime interface and out-of-line arithmetics). It was my intention to
keep the output simple, readable, and ANSI; there are several extra
assumptions that go beyond ANSI C, but I think they are true for most
mainstream architectures:
- - chars have 8 bits
- - integers are stored in 2-complement form
- - integer arithmetics wraps results that cannot be represented
in the given number of bits without overflow errors
- - 64-bit integer type is supported
- - data and code pointers are of the same size (as required by C--)
and can be converted to/from 64-bit integers with no data loss
- - NULL pointer, integer 0s and floating-point 0s are represented
by all-zeroes bit pattern
- - 32-bit and 64-bit IEEE floating point types are supported
Some parts of the original C-- spec were not implemented
for various reasons. Floating-point math is missing because
it is not fully covered by C standard library; I was too lazy
to get all the details right. Other pieces are missing because
they cannot be compiled to portable C; the most notable
omission is foreign returns from regular C-- functions.
I believe that the very concept of foreign return taken out of
context of the foreign function being called is generally unsound:
it only works with traditional (pre-ANSI) C calling convention
where the return code can be generated without statical knowledge
of the layout and size of the callee frame. Most other calling
conventions require at least some knowledge about the original
formal argument types to generate the correct cleanup and restore
code; this is impossible if the original foreign function is not available
to the C-- compiler. This is also the case with jumps from the foreign
function: the correct return code cannot be generated.
The logic of TRC implementation called for small extensions to C--;
my favorite one is init {} and fini {} blocks (see the TRC reference
for details). Also I noticed that the resulting C code would be much
faster if only C-- weren't so flexible in data layout and alignments
(in C-- you can align 64-bit integer on 2-byte boundary; there is
no way to implement this in C static data specifications -- runtime
memcpy is required).
I received very little feedback and I didn't expect much feedback;
TRC itself is, for practical purposes, non-portable. I chose to implement
it in ISO C++; the resulting code is reasonably clear and easy to read,
but I am still waiting for a compiler that can compile it as is (actually,
by bending the code in a dozen places, I managed to compile it with
VC6.0, but GCC with its buggy stringstreams requires too many
workarounds -- I decided to wait for a better release).
--
Instructions: http://www.cminusminus.org/mail.html
Help: [EMAIL PROTECTED]
Unsubscribe: [EMAIL PROTECTED]
