It's not just architecture that determines what kind of code you want your compiler to emit.
It is possible, even likely, that the compiler's strategy for a TV plugged into AC power is going to be very different from the compilation for a mobile device with a small battery. And within the worlds of small battery mobile and AC-power or big-battery (e.g. car) devices there will be parameters like heap size, CPU speed, etc. that will vary how the compiler emits code for that device.
Expecting a bytecode designed to be interpreted to be the ideal intermediate representation is a little "bonkers" but it may be good enough that it's not a serious problem, either.
DEX is not a bytecode as such (more of a halfwordcode if you will) and it was designed with the idea of being both efficiently interpretable (look at lua's snappy performance with their wordcode format) but also a more reasonable IR for a JIT or AOT backend.
> also a more reasonable IR for a JIT or AOT backend.
It might have turned out that way but I see no evidence that DEX was designed that way from the start. The claims about DEX performance when Android first came out were that it was twice as fast as interpreted Java bytecode and half the size.
The Dalvik JIT compiler is a nifty design, but there is no evidence DEX was designed to make it easier or better. The JIT compiler was added years after Android shipped.
One can make the general claim that there is no big impediment to producing optimal compiled code from any reasonable bytecode. But I have yet to see anything indicating DEX was designed for compilation or confers any advantages on any compiler design.
It's not just architecture that determines what kind of code you want your compiler to emit.
It is possible, even likely, that the compiler's strategy for a TV plugged into AC power is going to be very different from the compilation for a mobile device with a small battery. And within the worlds of small battery mobile and AC-power or big-battery (e.g. car) devices there will be parameters like heap size, CPU speed, etc. that will vary how the compiler emits code for that device.
Expecting a bytecode designed to be interpreted to be the ideal intermediate representation is a little "bonkers" but it may be good enough that it's not a serious problem, either.