usage message

[Matthew Fluet]

> As to exposing the C back end, how easy is it  to  add  `primitives'  to  the
> assembler  back  end?  I suppose that there could be people out there who use
> that.

Do you mean foreign function calls?  Or new primops?  The former works
just like it did in the C backend, using _ffi syntax.  Adding a brand new
primop is somewhat more involved.  I suspect that anyone who was adding
new primitives to the C backend could really get by with making them ffi
calls.  The primary drawback is that many of the MLton primitives were
pre-processor macros, so gcc had a little more freedom to optimize.  For
example, remember the rotates that were mentioned with regards to
Rijndael.  Suppose someone wanted to add the primitive

rol: word * Word.word -> word

With the C backend, they would probably just add a Word32_rol primitive
and then add 
#define Word32_rol(x,y) ((x)>>(32-(y)) | ((x)<<(y)))
to ccodegen.h

With the native backend, they would be forced to write a C function and
then pay the function call overhead, which they were probably hoping to
avoid.  This particular example isn't very hard to add to the native
backend, since there is a rol instruction.  Someone should be able to just
walk along mimicing everything that happends to Word32_lshift.  Probably
the most complicated primop right now is Thread_switchTo.  If someone can
follow that and write the primitive they want in assembly, they should be
able to add it.  But I don't claim it will always be a piece of cake.

> The only serious disadvantage with not being able to restart a
>     mlton -stop g ...
> is if some one is  actually  modifying  the  assembler  code  generated  (for
> instance  by  adding/changing some primitive or something).  It is a bit of a
> shame to not do it, but I don't see it as a major problem.

I agree that there isn't really a major problem with it.