ML game and more MLTon hacking :)

[Stephen Weeks]

> I have finally released the ML game
> on my webpage that was compiled for
> Windows with MLTon:
> http://www.HardcoreProcessing.com/Entertainment/Index.html
> 
> It's the one called The Unlimited Game.

Neat.  I'll get one of my friends who knows Danish to translate the
instructions so I can play.

> signature ASSEM =
>   sig
>     type temp
>     type const = Word.word (* warning: assuming adressing = datawidth *)
> 
>     val zeroTemp : temp (* Like register 0 on MIPS... *)
>     val newTemp : unit -> temp
>     val valueOf : temp -> const (* To be able to read a register value into ML *)
>                                 (* Storing to a register can be done with addi *)
> 
>     val add : temp * temp * temp -> unit     (* t1 <- t2 + t3 *)
>     val mul : temp * temp * temp -> unit     (* t1 <- t2 * t3 *)
>     val sub : temp * temp * temp -> unit     (* t1 <- t2 - t3 *)
>     val div : temp * temp * temp -> unit     (* t1 <- t2 / t3 *)
>     val addi : temp * temp * const -> unit   (* t1 <- t2 + c *)
>     val subi : temp * temp * const -> unit   (* t1 <- t2 - c *)
>     
>     (* Here M[] is the entire memory *)
>     val load : temp * temp * const -> unit   (* t1 <- M[t2 + c] *)
>     val store : temp * temp * const -> unit  (* M[t2 + c] <- t1 *)
>   end
>
> As you can see this is similar to the MIPS intruction set -
> except with an infinite number of registers (temps).
> There are no labels or jumps though, and they could be
> added but I don't think I'll need it... Also there's
> the valueOf function to be able to read a register
> value into ML.

I don't understand why you need the temp type at all.  Why won't
normal ML variables of type const or const ref do?  Then you don't
need any of the add, ..., subi operations.  Further, then you could
define a peek and poke via the the FFI mechanism.  Something like:

val peek = _PRIM "PEEK": word -> word;
val poke = _PRIM "POKE": word * word -> unit;

#define PEEK(w) *(uint*)w
#define POKE(w1,w2) *(uint*)w1 = w2

> So it would be like a suitable low level intermediate
> language in a compiler. What I would like the compiler
> to do is to have this structure as a "builtin"
> structure where it knows that it should not
> translate these function calls before reaching
> a low level intermediate language during translation
> - where a simple one to one mapping could problably
> be used.

Currently, functions defined by FFI mechanism are left alone
completely by the compiler and generated as C.

> So the question - how difficult would it be to implement
> this in MLTon? :) It could be implemented inefficiently
> by using the FFI - but one thing I'm doing now is
> to try to just scale a bitmap image - and calling a
> foreign C function just to move a machine word for
> each pixel is _very_ slow.

Mayber C statements are fast enough?

> If you are interested in implementing such a structure
> in the compiler, please let me know. Otherwise if you
> can tell me sort of what would need to be done to implement
> it I would be very happy :)

Let me know what, if anything, is unacceptable about the peek/poke
approach.  If it won't work, we'll figure out something else.

> As a last couple of notes - it seems that I'll be hired
> to do a "real" 3D game, built on the Unreal engine. I would
> like to write the non-3d parts in ML (most likely using MLTon).
> And the game should run on Linux and Win32 x86 - which is
> no problem :)  But also on Mac and Playstation 2... so I
> will problably want to port MLTon to these platforms.
> However it will be a while before the project starts for
> real, so these ports will not start in a very near future.

Cool.  Other work on MLton is slow, but ongoing.  I have a an internal 
version with a new basis library that is more complete and less buggy,
and also has some better support for signals and threads.  There is
also a student who will be writing an x86 native backend this summer.