2 ms·
This isn't quite right - we don't in general really care whether we're allocating optimally (for example, if we have 16 registers we don't care if we can potent
by CHY872 12y ago
This isn't quite right - we don't in general really care whether we're allocating optimally (for example, if we have 16 registers we don't care if we can potentially allocate to 10), and heuristic based approaches are practically very useful (and cheap).
In terms of compiler writing, if you wanted to write any optimisations you'd probably want to manipulate 3-address code internally, if only because the data flow based analyses would be made easier (and then you would emit stack code in the last step).
This might be a reason why the JVM designers decided to use a stack machine, but I doubt it's an important one - they'd easily be able to get ahold of a few decent compiler writers if they needed to.
- wlievens 12y agoI don't doubt the JVM designers have good compiler writers. I rather think that they wanted the bytecode to be accessible to write for other compiler writers, such as the team that implemented JSP servlets a century ago, but also perhaps with a future vision for the alternative JVM languages.
- sehugg 12y agoDon't forget bytecode verification which is easier with just a stack rather than a stack + registers. Java was not originally envisioned to become the default server side + JIT technology it eventually became, it was meant for embedded apps which meant small simple bytecode.