Creating JVM language [PART 14] - Handling other primitive types

Sources

New supported types

So far Enkel supported integers and Strings only.
It is time to include all the other primitive types.
This step was also necessary to prepare a compiler
for upcoming object oriented features coming soon (so far creating objects
other than String is not possible).

Many versions of the same instruction - let’s generalize this.

There are many bytecode instructions that only differ from each other by type.
Let’s take a look at the return instruction as an example:

return - returns from a method

ireturn - returns integer value (pops it off the stack) from a method

freturn - returns float value

dreturn - returns double value

lreturn - returns long value

areturn - returns reference value

It might be tempting to just add cases for each type in each section that emits bytecode instruction.
It would however result in awful ifology - we don’t want that.
Instead I decided to make an TypeSpecificOpcodes enum that stores all the opcodes for each type respectively and is reachable by Type enum:

publicenumTypeSpecificOpcodes{INT(ILOAD,ISTORE,IRETURN,IADD,ISUB,IMUL,IDIV),//values (-127,127) - one byte.LONG(LLOAD,LSTORE,LRETURN,LADD,LSUB,LMUL,LDIV),FLOAT(FLOAD,FSTORE,FRETURN,FADD,FSUB,FMUL,FDIV),DOUBLE(DLOAD,DSTORE,DRETURN,DADD,DSUB,DMUL,DDIV),VOID(ALOAD,ASTORE,RETURN,0,0,0,0),OBJECT(ALOAD,ASTORE,ARETURN,0,0,0,0);TypeSpecificOpcodes(intload,intstore,intret,intadd,intsub,intmul,intdiv){//assign each parameter to the field}//getters