MorphOS Developer
Posts: 510 from 2003/4/11
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.
So what's the status of all this? I found and fixed probably 99% of all of the above issues. Yet at least two issues remain that are rather tricky to track down, and those two (or more) issues cause most large websites to fail, because one of the pieces of Javascript tha triggers one of the remaining issue is a Javascript framework that's used by just about everyone.
So, as Pampers mentioned, I still want to finish this, but with the amount of time I ended up spending on fixing endian issues in the JIT engine, I overshot my initial time estimate by at least a factor of 5, and I had to focus on other things to get an income. Thus, I'm still (obviously very slowly) working on this, but I (also obviously) no longer expect to get paid for this work, and thus if anyone wants their money back or wants to assign their money to another project, then of course it is no problem.
I rarely log in to MorphZone which means that I often miss private messages sent on here. If you wish to contact me, please email me at [username]@asgaard.morphos-team.net, where [username] is my username here on MorphZone.
