4 ms·
My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to
by fch42 3y ago
My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to develop a JVM on top of it, you'd pay ARM for docs, professional services, and unit licenses. And second, that once things got to the ARM11 series cores, software JITs beat the cr* out of Jazelle. I don't remember any early Android device ever used it.
ARM is quite capable in vapourware generation. 64bit ARM was press-released (https://www.zdnet.com/article/arm-to-unleash-64-bit-jaguar-for-handhelds/ https://www.zdnet.com/article/arm-to-unleash-64-bit-jaguar-f...) a decade before ARMv8 / aarch64 became a thing.
(I'd love to learn more)
- jaywee 3y agoSun wanted to do the same thing in late 90ties - picoJAVA (embedded), microJava and UltraJava (VLIW workstations). Relegated to the dustbin of history.
- miki123211 3y agoJava Card still survives, though. I find Java Card pretty puzzling. You go from high-level interpreted languages on powerful servers, to Java and C++ on less powerful devices (like old phones for example), to almost exclusively C on Microcontrollers, and then back to Java again on cards. If. it makes sense to write Java code for a device small enough to draw power from radio waves, why aren't we doing that on microcontrollers?
- cpgxiii 3y agoThe Java Card environment is quite limited, though, due to resource limitations. There have been several more-or-less successful attempts at running higher-level languages on microcontrollers, e.g. .Net Micro Framework and CircuitPython. In all of these cases, though, you tend to struggle with all the native device behavior being described/intended by the vendor for use with C or C++ and the BSP for the higher level environment being an afterthought.
- funcDropShadow 3y agoJavaCard is used in smartcards e.g. for banking cards. There you want to have more language guarantees to avoid losing money.
- sillywalk 3y agoFYI UltraJava was renamed to MAJC[0] which IIRC was only used in Sun's XVR graphics cards. More from Ars (1999) https://archive.arstechnica.com/cpu/4q99/majc/majc-1.html https://archive.arstechnica.com/cpu/4q99/majc/majc-1.html [0] https://en.wikipedia.org/wiki/MAJC https://en.wikipedia.org/wiki/MAJC
- RicoElectrico 3y ago> I don't remember any early Android device ever used it. It couldn't have, as Dalvik VM is distinct from JVM.
- fch42 3y agoIt executes Java Bytecode. Whether Dalvik VM was/is a "Java" VM is hardly relevant there (not the least because "Java" is so much more than Java Bytecode, and Jazelle does nothing to help with anything on top of the latter).
- RicoElectrico 3y agoApparently it's not even Java bytecode. Would make sense, after all Dalvik is register-based. https://stackoverflow.com/a/36335740 https://stackoverflow.com/a/36335740
- pjmlp 3y agoIt certainly doesn't. https://source.android.com/docs/core/runtime/dalvik-bytecode https://source.android.com/docs/core/runtime/dalvik-bytecode
- bitwize 3y agoJava bytecode is transpiled to Dalvik's own bytecode as a build step. Dalvik itself doesn't run Java bytecode. This is one of the reasons why Oracle sued Google: clearly Google was trying to appropriate Java with some clever IP law dodges with this Dalvik business.
- lxgr 3y agoHuh, I always took their rationale for having the .class -> .dex compilation step at face value (i.e. space efficiency due to shared string literals etc.), but this actually makes more sense, given that J2ME seemingly was fine without it on much more lightweight hardware.
- Vogtinator 3y agoThere is a bit of info including example code on https://hackspire.org/index.php/Jazelle https://hackspire.org/index.php/Jazelle
- fidotron 3y agoThe performance of Dalvik was far below J2ME on Nokia and Sony Ericsson feature phones for a very long time, and Android relied on pushing a lot to C libraries to compensate.
- zozbot234 3y agoThere was a successor ThumbEE ("Execution Environment") that was comprehensively documented. But it didn't get much attention either and later chips removed it.
- happosai 3y agoIIRC jazelle left it to the implementers which bytecodes to handle in HW and what to trap to SW. Since SW JIT beat the Jazelle implementtions, by the arm11 times, the cpu implementers would just leave everything for the SW traps... So while the original raspberry pi was arm1176j and J meant Jazelle support, it was all already hollowed out.