MLton inline assembler etc.?

[Matthew Fluet]

Anoq,

Since I've been primarily responsible for the native backend of the MLton
compiler, I'll give my view on adding inline assembly to MLton.

> #define HcP_WritePixel(address, r, g, b) ...
>    // Doing some bit-shifting and an assignment to the address.
> 
> I guess the reason this is efficient to do is that
> MLton generates C-code from the ML source and
> that the C-compiler can optimize all the code
> at the same time.
> 
> Now, if the next version of MLton generates
> native assembler, then this advantage might
> disappear. 

You're right about this advantage disappearing.  With the native backend,
it will not be possible to include a definition like:

val f = _ffi "HcP_WritePixel" : word * int * int * int -> unit;

because this will result in a C-style function call to HcP_WritePixel,
which won't have a function definition if it is only defined as a macro.
You could certainly turn HcP_WritePixel into a true C function, compile
it, and add the object file to the MLton command line to be linked in
with the object file from MLton.  But, now you pay the price of a function
call for the bit-shifting and memory put.

> So I'm thinking that it might
> be a good idea to support inline assember...
> 
> Maybe something like:
> 
> val f = _primAsm "word inreg ADDRESS \n
>                   int inreg R \n
>                   int inreg G \n
>                   int inreg B \n
>                   ... (Do the RGB shifting here)
>                   MOV ADDRESS,RESULT":
>                     word * int * int * int -> unit;
> 
> And also with some kind of support for
> returning a value (outreg?). Maybe
> a different syntax, but anyways...
> 
> I guess the only thing required to do it
> would be to instruct the register allocator
> about the ML function's input and output variables
> and to allow for creating temporary
> registers which are guaranteed to be unique.

Conceptually, this isn't too bad.  Some issues are pragmatic: reading
and parsing the assembly, etc.  Some issues are design related: allowing
jumps and/or calls in inline assembly, allowing labels in inline assembly,
etc.

The big issues are dealing with all the possible instructions and
effects that the programmer might use in the inline assembly.  Take a look
at the gcc man pages and all the modifiers that go with inline assembly.

The other issue is that there is a pseudo-x86 IL which operates on
abstract memory locations (rather than registers), which is optimized
before register allocation.  This would mean translating assembly
addressing modes into the abstract memory locations.  Not necessarily
hard, but not trivial.

I think the bottom line is that the idea is nice, but there are a lot of
practical issues that would need to be overcome.  

> I know that all which would be needed to
> do graphics would be a peek and poke
> function (which we talked about earlier) -
> but having full support for inline assembler
> would also allow for all the nasty typecasts
> in efficient ways (and the RGB bit-shifting...).

Peek and poke are really easy to provide as primitives.  In fact, for any
reasonable ammount of assembly, it would probably be easiest to add new
primitives and add the appropriate pseudo-x86 assembly to translate the
new primitives.

So, sorry to say, the short answer is that MLton won't likely support
inline assembly anytime soon.

-Matthew