Re: [ANN] LuaJIT-2.0.0-beta6

[Mike Pall <mikelu-1102@...>]

David Given wrote:
> On 11/02/11 16:05, Mike Pall wrote:
> > About the PPC/e500 port of the LuaJIT interpreter: please note
> > this will _not_ run on other PPC-based machines (e.g. game
> > consoles).
> 
> Is this because it uses the e500v2's non-standard FPU? If so, what would
> be involved in porting it to use the standard PowerPC FPU? Not that I
> want to do it, I'm just curious about the LuaJIT architecture for
> handling this sort of thing.

The LuaJIT interpreter is written in assembler, so you'd have to
use a completely different instruction set.

A specific difficulty in this case is that the e500 architecture
doesn't have FPRs! All of the GPRs got an extra 'upper half',
which can be used with a special set of vector-style instructions.
These are not real 64 bit registers, as it doesn't have any 64 bit
integer operations. But it has vector-ops for 2x int or 2x float
or 1x double vectors. This is very different from the design used
by the standard PPC FPU.

> (I would naively assume that most FPUs these days just implement the
> standard IEEE operations, so that they differ only in what the opcodes
> look like --- a mul ought to look like a mul regardless of CPU
> architecture. I don't know whether this actually works in real life.)

In theory yes, but in practice the operation itself doesn't matter
that much (fmul vs. efdmul). The difficulty here are the type
checks, cross-register moves, scheduling the loads and so on. You
should know that GCC generates rather mediocre code for PPC and
really awful code for the e500. And I have to do it by hand ...

In fact I'm using vector ops for the type checks on e500. :-)
And I make extensive use of the isel op, which is missing on most
other PPC CPUs. Thankfully FreeScale publishes really good CPU
docs, so I've hand-scheduled the whole code for optimal use of the
execution units. This makes it a bit tough to port to the regular
PPC CPU/FPU combo.

--Mike