We so need an updated browser!

We have been living without JIT since the beginning of time, so let's not waste time on that to begin with. I think I heard someone (Fab?) was working on the JIT engine at some point..?

Another bounty which is still on hold is JIT JS for Oddysey. There was some progress at some stage ... but bounty was never completed.

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.

One question: Is it the JS JIT that has endian issues, or the plain interpreter?

We have been living without JIT since the beginning of time, so let's not waste time on that to begin with. I think I heard someone (Fab?) was working on the JIT engine at some point..?

You seem to be mixing up the JIT bigfoot was working on with the interpreter in JavaScriptCore.

If the community is too outnumbered to keep web browsers up to date to the level of the rest of the world. Maybe it's time to give up !?

Is it possible to build/test JavaScriptCore only or are bugs exposed only in the actual use?

Overpriced hardware, dead CPU => no new blood => less of all us => of course need to give up :) I mean, that everything expected. Its big big surprise that we all still here, and have even what we have :) Our hope in terms of webbrowsers, is that someone still will support big-endian machines, and we can reuse that code. Because making browser by 1-2-3 ppls today are unreal.

Any idea how hard adding WebGL support would be? I assume that the Webkit code already has it; just the AmigaOS-specific parts would have to be done.

Also, is the plugin API working in the AmigaOS version?