Awesome. I did something similar on the old Raspberry Pi Zeros which had the right chip for it. It was a Linux kernel module with with a bit implemented in ARM assembly. All it executed was an add, I always meant to go back and reverse more functionality of the instruction set.
Back in the mid 2000s I tried to reverse engineer some of it. Got to executing a few instructions. Found that ARMv5TEJ cores did not natively execute very many Java instructions. It was sad. I had say hoped that later cores got better.
I never understood why ARM hid jazzelle docs away. It made no sense. It is probably why Jazzelle died.
ARM wanted to deprecate Jazzelle as fast as possible. Even during its development, it became clear that Java bytecode is never going to be quick, and that it's better to just JIT/AOT it.
It's a bit of a bizarre design; the JVM's execution model is not sufficiently different from any standard procedural execution semantics to justify special hardware support. It makes more sense to use a normal JIT/AOT compiler that's modular over the target ISA.
There's that one ARM instruction specifically for JavaScript float-to-i32 casts, but at least that's relatively narrowly scoped.
To be clear, the behavior in question is Intel behavior that snuck its way into the JavaScript spec; ARM just doesn't wanna use the word "Intel" in public documentation. For similar reasons there's a few other places where there's an "alternate" execution mode that exists solely to emulate x86.
There was a narrow window where CPUs were big enough to have circuitry for JVM fast bytecode execution, but too small for strong JIT compilation. ARM deprecated Jazelle as soon as that window passed.
Awesome. I did something similar on the old Raspberry Pi Zeros which had the right chip for it. It was a Linux kernel module with with a bit implemented in ARM assembly. All it executed was an add, I always meant to go back and reverse more functionality of the instruction set.
Back in the mid 2000s I tried to reverse engineer some of it. Got to executing a few instructions. Found that ARMv5TEJ cores did not natively execute very many Java instructions. It was sad. I had say hoped that later cores got better.
I never understood why ARM hid jazzelle docs away. It made no sense. It is probably why Jazzelle died.
ARM wanted to deprecate Jazzelle as fast as possible. Even during its development, it became clear that Java bytecode is never going to be quick, and that it's better to just JIT/AOT it.
I was working there at the time and even internally Jazelle documentation was hidden. Very odd for what it is.
It's a bit of a bizarre design; the JVM's execution model is not sufficiently different from any standard procedural execution semantics to justify special hardware support. It makes more sense to use a normal JIT/AOT compiler that's modular over the target ISA.
There's that one ARM instruction specifically for JavaScript float-to-i32 casts, but at least that's relatively narrowly scoped.
>JavaScript float-to-i32 casts
To be clear, the behavior in question is Intel behavior that snuck its way into the JavaScript spec; ARM just doesn't wanna use the word "Intel" in public documentation. For similar reasons there's a few other places where there's an "alternate" execution mode that exists solely to emulate x86.
There was a narrow window where CPUs were big enough to have circuitry for JVM fast bytecode execution, but too small for strong JIT compilation. ARM deprecated Jazelle as soon as that window passed.
Funny, I pulled up HN while I go through modding a Wii I got from hard rubbish.