native code and ZINC machine

native code and ZINC machine

[Aaron Bohannon]

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.  [NB: My question is not about 
trying to write code that is dependent on the order of arguments.]

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.

I have googled for papers and discussions, and poked around the obvious 
websites looking for answers, but I must have missed something.  Any 
pointers in the right direction would be appreciated.

Aaron Bohannon

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

[Xavier Leroy]

> 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

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

[David Brown]

On Sat, Nov 06, 2004 at 10:37:48AM +0100, Xavier Leroy wrote:

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

Just out of curiosity, what model does the native compiler use when
evaluating functions of unknown arity (List.map for example).

Dave

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

[Diego Olivier Fernandez Pons]

    Bonjour,

Xavier Leroy a écrit :

[...]

> However, following the principle of least surprise, it tries to
> enforce the same evaluation order as the bytecode compiler, that is,
> right-to-left.

J'aurai tendance à penser qu'avoir des compilateurs qui évaluent leurs
arguments dans des sens différents est plus une force qu'une
faiblesse. Cela permet de détecter des bogues (car il est raisonnable
d'estimer que tout code va être testé sur les deux compilateurs).

J'ai trouvé une fois dans mon code un bogue car j'évaluait mentalement
de gauche à droite et le compilateur de droite à gauche. Ce jour j'ai
compris l'utilité d'évaluer dans un ordre que je trouvais auparavant
"anti-intuitif".


        Diego Olivier