Why is the Java bytecode instruction set not orthogonal?

Question

Section 2.11.1 of the JVM 8 Specification includes the words:

In other words, the instruction set is intentionally not orthogonal.

From my perspective, that implies that the Java bytecode instruction set is full of dirty hacks. I understand that the designers were restricted to only one byte to represent opcodes, but then they consumed 8 opcodes for aload and astore, not to mention individual opcodes for iload, fload, dload, etc. The only reason I can think of for making the instruction set nonorthogonal is to optimize it for memory-constrained systems**; it seems these design decisions make it more difficult to write optimizers, not to mention limit the instruction set.

Surely I am missing something. Why did the Java designers do it this way?

**When I say "memory-constrained", what I'm referring to is the size of the bytecode itself. Presumably the reason they have aload_0 is because it saves a byte over aload 0, and it is used a ton.

Answer 1

Surely I am missing something. Why did the Java designers do it this way?

Java grew out of Oak, which was originally intended to be used in "smart appliances". It was first developed in 1991. So we're talking about old-school embedded systems, highly resource-constrained by early 90s standards.

Today, when "embedded system" can mean a minimalist but full-featured computer that costs $9, it seems a bit mind-boggling to architect a system that way, but almost 25 years ago, saving a byte here and a byte there on an embedded system was still a big deal.