[MLton] Re: A MLton / C-- Experiment

[Norman Ramsey]

Matthew,

This message is a bit long for me to digest, but I'll try to respond
to some high (or low) points ;-)

 >  2) Programs that make use of MLton's thread library cannot be
 >     supported.  Attempting to multiplex the one C-- stack among
 >     multiple ML stacks would lead to disaster.

We have some experimental support for multiple C-- stacks.
But since this support cannot detect stack overflow, it is
emphatically unsuitable for any sort of production use.
(People at Bell Labs seem to be willing to run threads with no safety
net, but I am not.)

 > In any case, I suspect it would be beneficial to the C-- developers to
 > have a source of additional C-- programs and to have some inkling of
 > how C-- fits into a full compiler.

Yes; we'd be thrilled ;-)

 > The good news is that I can successfully compile and run a number of
 > tiny SML programs.  The bad news is that I have been unable to support
 > 64-bit operations to a degree sufficient for running realistic
 > programs; MLton has committed to 64-bit file positions, so any I/O
 > necessarily pulls in a lot of 64-bit ops.

Except for division, we can add 64-bit operations pretty easily.
We've been holding off because we haven't had a user.  What operations
do you want? :-)

 > Fair enough.  The next reasonable option would be to peform the 64-bit
 > addition out of a 32-bit add and a 32-bit add with carry.
 > Unfortunately, there does not appear to be a way to directly
 > extracting the high bits of a C-- local variable.  I could extract the
 > low bits with %lobits, but without %shra at 64-bits, I can't get to
 > the high bits.  

Actually %lobits32(n >> 32) should work---this is what we use
internally in the compiler.  I guess the documentation is not clear on
this point; I'll see what I can do to fix it.

 > Note that without an %addc_overflows operator, I must instead coerce
 > the carry out bit to a boolean.  

OK, that's another one we can add...

 > Unfortunately, C-- doesn't really care for this cast:
 > 
 > Not implemented in qc--: non-binary comparison in conditional guard
 > Fatal error: exception Impossible.Impossible("non-binary comparison in condi
   tional guard")

Ouch!  Bug city.  And the parade of bugs just goes on and on...

 > I am sure that the set of primitive operations is a constant source of
 > discussion.  I'll throw in my 2 cents:
 > 
 >  * Having %neg but not %neg_overflows leads to ...
 >  * Not having %addc_overflows and %subb_overflows leads to...
 >  * %hibits32 would also be helpful
 >  * The only other operations missing from MLton's list of primitives
 >    were trigonometric functions.

We will add the overflow operations soon.
I would prefer to retain %lobits32(n >> 32) rather than introduce the
%hibits operator as a synonym.
Regarding trig functions, I need to know what the IEEE standard says
about this.  Meanwhile, we can probably put something
machine-dependent in.

 > As far as I know, using 64-bit data in the way I am
 > doing at the end of the saga (that is, simply copying 64-bit values to
 > and from memory and local variables, and passing to and from foreign
 > "C--" or foreign "C" functions) is intended to be supported by the
 > current version of qc--.

Yes, we intended this.  We all know what is paved with good intentions :-)

I'm really thrilled you've undertaken this experiment.  At present,
nobody in our group is able to make the compiler priority #1, but
we'll certainly be able to tackle the bugs once the ICFP deadline
passes.


Norman