How to devise instruction set of a stack based machine?

Question

Stack based virtual machines like CLR and JVM has different set of instructions. Is there any theory behind devising the instruction set while creating a virtual machine? e.g. there are JVM instruction sets to load constants from 0-5 onto the stack

iconst_0
iconst_1
iconst_2
iconst_3
iconst_4
iconst_5

whereas in CLR there are instruction set to load number from 0 to 8 onto the stack as follows

ldc.i4.0
ldc.i4.1
ldc.i4.2
ldc.i4.3
ldc.i4.4
ldc.i4.5
ldc.i4.6
ldc.i4.7
ldc.i4.8

why there is no ldc.i4.9 and if ldc.i4 is there why we need the above opcodes? And there are others like these.

I am eager to know what is the reason behind this difference between opcodes of different VMs? Is there any specific theory to devise these opcodes or it is totally driven by the characteristics of the VM itself or depends on the high-level language constructs?

Answer 1

Often instruction sets are devised by examining the code generated for similar machines to see which instructions occur most often. The designers will also write compilers (or at least a back-end for GCC) using their proposed instructions to see how efficient (both in terms of code density and execution speed) the resulting code is. I'm sure the designers of the CLR took a good hard look at the JVM to see how it could be improved, just as the designers of the JVM got insight from earlier VMs (p-system, Forth, Smalltalk).

General ISA design theory says that the most commonly-used opcodes should be the shortest, since this will lead to the best code density (and also the best performance, since shorter instructions tend to be simpler to decode). Devising the actual encoding scheme (opcode+operand(s)+data type(s)+addressing mode(s)) is entirely up to the ISA architect and is one of those "black art" skills that involves lots of experience.

Answer 2

The only book I know which consider issues in instruction set (ISA) design is Gerry Blaauw and Fred Brooks, most other books on CA just provide a classification and don't go very far.

For you problem at hand, you have to trade-off with the density of code. An ldc.i4 is enough to provide the functionality, but every case it is used, it would take says 1 byte of instruction and 4 bytes of constant. Providing a few special purpose ldc.i4.xx using only 1 byte of instruction help in increasing the density of the code. But obviously you can only have 256 one byte instructions, so you have to use them wisely.

And additional factor for VM (this factor is less true for hardware implementation) is that such special instruction will not only take less place in the instruction stream (with benefit on the cache pressure and thus on the speed), these instructions will be executed more rapidly than their equivalent.