Re: [Caml-list] native code and ZINC machine

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> I was quite surprised, recently, when I found out that the native code 
> compiler implements left-to-right evaulation, as opposed to the 
> right-to-left evaulation of the bytecode.

This isn't quite right.  The native-code compiler is essentially
neutral w.r.t. evaluation order, meaning that it can implement any
given evaluation order without singificant changes or performance
impact.  However, following the principle of least surprise, it tries
to enforce the same evaluation order as the bytecode compiler, that
is, right-to-left.  

There is one mistake in 3.08 (corrected in the main branch) that causes
left-to-right evaluation for arguments to certain inlined functions
(see PR#2910).  If you observe left-to-right evaluation with ocamlopt,
please report it.  It's not really a bug according to the OCaml manual
(which leaves evaluation order undefined), but it's certainly a
"quality of implementation" issue that we'd like to be aware of.

> You see, I am quite familiar with the ZINC machine and the benefits of 
> its design, and I thought that the design could be adapted in some way 
> or another to the native code setting.  I am interested in finding out 
> what factors prevented this, or what made the ZINC machine execution 
> model impractical in the native runtime.  My knowledge of systems is 
> perhaps somewhat weak, so maybe I am overlooking some obvious point.

The ZINC / OCaml VM handling of curried function application (an
instance of the push-enter model) pretty much requires that parameters
are passed on a stack.  For native code generation, it is much more
efficient to pass the first N parameters in processor registers.  This
doesn't fit the ZINC model at all.

- Xavier Leroy