MLton inline assembler etc.?

[Anoq of the Sun]

Hello Matthew!


Matthew Fluet wrote:
> 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.

OK - I see the problems, I didn't think very much about
this when I wrote it :)

The only things I would need would be something like write pixel,
reading from / writing to memory, doing ugly typecasts and
maybe using special graphics hardware and setting the right
registers for that.

> 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.

Well, if there's some way that I can add primitives like those
myself - then I guess that will be adequate :)

Thanks for the info! :)


Cheers
-- 
http://www.HardcoreProcessing.com