3 ms·
The bytecode isn't set in stone at all. Java 7 added InvokeDynamic, to name one bytecode. Jazelle is basically being phased out in favor of the much-more-gener
by bri3d 15y ago
The bytecode isn't set in stone at all. Java 7 added InvokeDynamic, to name one bytecode.
Jazelle is basically being phased out in favor of the much-more-generic ThumbEE, which isn't onerously licensed and entirely undocumented and hence has a chance of actually being used. New ARM CPUs "support" Jazelle by effectively ignoring it.
It'd of course take a major-version Java release to add unsigned type bytecodes if they chose to go that route (rather than the current approach, which seems to be providing a dangerous and half-baked set of methods on Integer instead). But it certainly isn't impossible by any means.
- jbri 15y agoInterestingly, you don't need to add a "full set" of bytecodes for unsigned arithmetic support - just four (udiv, ludiv, urem, lurem). All the other arithmetic operations are bit-identical with the existing signed versions. It's also worth noting that existing Jazelle implementations don't do everything in hardware, they already call into a software piece to handle any opcodes they come across that they don't interpret natively. So improving those to handle new opcodes is just a software upgrade, same as anything else.
- zbowling 15y agoThe biggest issue with adding those op code is the lack of space for every op code to support between every type IIRC. every new type exponentially increases the number of operations. Being that we can only 255 op code in Java, it causes a bit of a problem. In CIL/MSIL in .NET, they used a multibyte technique with flag bits IIRC. (Don't quote me but I'm recalling designs I seen 8 years ago here).