Yokemate of Keyboards
Posts: 2057 from 2003/6/4
Quote:bigfoot schrieb:
Quote:
pampers wrote:
I was talking with bigfoot and he came back to developing it but he cannot promise any time frame. I'd say bigfoot will speak for himself in this topic soon.
I'm not sure there's really that much to say. When I took the bounty, I made an estimate for how much time it would take to complete the JIT implementation for PPC32. In fact, I finished that task a bit faster than I had originally estimated. What I didn't realise was just how broken Webkit was internally, and how much of a problem it would pose.
The problem is that the JIT engine internally expects a little endian memory layout. This is different from other endian problems in that the JIT engine itself isn't what isn't endian safe, it's the code that the JIT engine generates that isn't.
Webkit's Javascript engine internally treats
all Javascript values as 64 bit floating point values. This not only includes actual floating point values, but also integers, strings, objects and so on. This means that every value that the JIT-generated code uses is a 64 bit value, even on 32 bit architectures. How this works is that there are certain bit encodings of floating point values that are illegal, and which will never be the result of a normal floating point arithmetic operation. These encodings are then used to indicate if a value is actually something else than a floating point value.
Now, the problem is that we're on a 32 bit CPU, so the integer part of the CPU, which is what is used for doing these tests, and for passing data around, can only load 32 bits at a time. The JIT engine then generates code that expects the upper 32 bits of the 64 bit floating point value to be located at
address + 4. This assumption is made roughly every 20-30 lines over tens of thousands of lines of code. Furthermore, it expects 64 bit values to be passed and returned in 2 32 bit registers, which is perfectly normal, but it of course expects the order of this register pair to be swapped, while at the same time expecting 32 bit return values to reside in the register that also holds the lower 32 bits of a 64 bit return value. This assumption is made for every single interaction between JIT-generated Javascript code and the compiled Odyssey binary. Every time your Javascript code calls for example
Math.Floor(), this assumption is made in the JIT-generated code.
I am rather clueless on low level programming - but what about using the 128 Bit registers of Altivec/VMX. Would be an Altivec/VMX only JIT then, but there are only very few non Altivec/VMX machines with MorphOS support (IIRC Peg1+e few PegII and Efika).
--
http://via.bckrs.de
Whenever you're sad just remember the world is 4.543 billion years old and you somehow managed to exist at the same time as David Bowie.
...and Matthias , my friend - RIP