[MLton] power pc "port"

[Filip Pizlo]

> > The only downside is that in addition to every arithmetic operation
> > on 8-bit and 16-bit words requiring a function call,
> 
> No.  Most of the arithops are defined in c-chunk.h as static inlines
> that will be optimized away.  Only a few (like quot, rem) require
> function calls, and that is necessary to keep gcc's optimizer from
> doing things that the SML spec doesn't allow.

Ah.  Didn't catch that.  In that case I agree with your current solution.

> > each one of those operations will now require one or more sign
> > extension and/or masking operations.  Of course, the cost of these
> > operations may be minuscule in comparison to the cost of the
> > function calls. :-)
> 
> You only have to do the sign extension if the value isn't already sign
> extended.  I would think in most cases with a sequence of (signed)
> arithops, gcc's optimizer would simply keep the value sign extended in
> a register, but maybe gcc doesn't do as good a job as I would expect.

Yes, of course.  I was just assuming that that the other word ops were
functions that took unsigned args - in which case there would be a lot of
spurious sign extension and masking.

> Maybe, but I'm not convinced.  The codegen or some earlier pass will
> certainly need to decide at various points how 8 and 16 bit values are
> to be represented in a 32-bit register.  It can choose to keep them
> sign extended or masked, depending on what's appropriate.  A naive
> approach would be to keep all words masked, and then to sign extend
> before each arithop and mask after.  But there are better approaches.
> Have a look at "Widening Integer Arithmetic" for a framework to think
> about this issue.
> 
> 	http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html
> 
> My guess is that their dynamic programming approach may not even be
> necessary (although I'd like to see it) and that some simple
> heuristics would do an acceptable job.  Kevin Redwine reads this list
> -- perhaps he is interested in helping out with this issue?  In any
> case, these heuristics could be expressed in the codegen or as an
> optimization on the Ssa IL that eliminates all occurrences of Word8
> and Word16.  My preference would be the Ssa IL, since then the
> optimization could be used on other platforms.

Sounds interesting.  I'll have a look.

--
Filip Pizlo
http://bocks.psych.purdue.edu/
pizlo@purdue.edu