Deutsche Version dieser Seite

Coding for Implementation

In addition to "normal" Bytecodes there are extended Bytecodes. That is why the instructions have to be newly encoded as opcodes. Therefore groups of instructions are built up: Kontrollfluß, Stack, Laden, Speichern, arithmetisch, logisch, If, Cmp und erweitert. Those are nine groups which can be coded in four bits. Aiming at an 8-bit-opcode four more bits are left for encoding 16 instructions belonging to each group out of 16 at maximum. Resulting is a maximum total count of 256 opcode instructions the pipeline can execute.

The prototype contains only nine instruction groups, each with only a few opcodes. There should be enough free opcodes to finish the pipeline and being able to use it in a microcontroller, then. In addition it is possible to define dedicated instructions for use in special environments and applications.

Analysis of the Bytecode shows that there are some groups of instructions which can be implemented in one opcode, because they only are variants of one more powerful instruction with different options or operands. All in all opcode count ends up at about 100 instruction that must be executable in hardware for correct interpretation of Java-Bytecode.

Only a part of those executable hardware instructions is to be implemented in this work. Table 4.2 shows those 26 opcodes which represent 53 Bytecodes. Because there is still a lack of space on the FPGA the instruction have been prioritized. Important Bytecodes for program flow and execution shall be implemented from the beginning so that more complex instructions can be built up out of those. In consequence no full compatibility to "normal" Java programs can be reached, but an interface for writing test programs exists on a lower level.

Theoretically the coding of Bytecode itself could be used as opcode as long as there were no extended Bytecodes and all Bytecodes had the same length. Since those constraints are not met new opcode has to be developped.

The results are printed in table 4.2. Priority stage 5 means "must be implemented", stage 1 stands for "may be implemented if there are still enough ressources after everything else is done".

Tabelle 4.2: Implemented opcodes

td ALIGN=CENTER>IF td ALIGN=CENTER>directly

Mnemonic	Bytecode	Opcode	Priority	Group	implemented as
nop	0x00h	0000 0000	5	Kontrollfluß	directly
push	0x01h..0x08h	0100 0000	5	Stack	directly
loadv	0x15h	0001 0000	5	Load	directly
	0x19h..0x1Ch
	0x2Ah..0x2Dh
storev	0x36h	0010 0000	5	Store	directly
	0x3Ah..0x3Eh
	0x4Bh..0x4Eh
loado	0x59h	0001 0001		Load	directly
add	0x60h	0011 0000	5	arithmetisch	directly
sub	0x64h	0011 0001	4	arithmetisch	directly
mul	0x68h	0011 0100	2	arithmetisch	directly
div	0x6Ch	0011 0101	1	arithmetisch	directly
neg	0x74h	1100 0000	4	logisch	directly
shl	0x78h	1100 0001	5	logisch	directly
shr	0x7Ah	0011 0010	5	arithmetisch	directly
and	0x7Eh	1100 0011	5	logisch	directly
or	0x80h	1100 0100	4	logisch	directly
xor	0x82h	1100 0101	4	logisch	directly
iinc	0x84h	0011 0010	3	arithmetisch	directly
ifeq	0x99h	0101 0000	5	IF	directly
iflt	0x9Bh	0101 1001	4
braeq	0x9Fh	1010 0000	5	CMP	directly
bralt	0xA1h	1010 1001	4	CMP	directly
load_w	0xFFx04h	0001 0010	5	Load	directly
store_w	0xFFx24h	0010 0010	5	Store	directly
r_pc	0xFFx40h	1111 0000	4	Test	directly
r_optop	0xFFx43h	1111 0001	4	Test	directly
aload	0x2Eh	0001 1000	3	Load	Mikrocode
astore	0x4Fh	0010 1000	3	Store	Microcode
r_global0	0xFFx5Ah	1111 0010	z	erweitert	directly
r_global1	0xFFx5Bh	0100 0011	z	erweitert	directly
w_pc	0xFFx60h	1111 1000	z	erweitert	directly
w_optop	0xFFx63h	1111 1001	z	erweitert	directly
w_global0	0xFFx7Ah	1111 1010	z	erweitert	directly
w_global1	0xFFx7Bh	1111 1011	z	erweitert	directly

For implementation of microcoded instruction more extended Bytecodes have to be executed: Access to the global register GLOBAL0 and GLOBAL1 is necessary. Other extended Bytecodes are implemented for better testing opportunities. That is why they all are marked as "additional" (z) for priority in table 4.2.

The two instructions implemented as microcodes execute array accesses in external memory. The needed data like reference address and index are loaded from stack. The opcode sequences are shown in tabel 4.3. EXEOp16 is an operand provided for the execution unit.

Table 4.3: Microcode sequences

/tr>

Opcode	Address	Opcode sequence (mnem.)	Bytecode sequence	Opcode sequence	EXEOp16
aload	0000 0001	push 2	0000 0101	0100 0000	2
		shl	0111 1000	1100 0001	-
		push 4	0000 0111	0100 0000	4
		add	0110 0000	0011 000	-
		add	0110 0000	0011 0000	-
		load_word	1111 1111 0000 0100	0001 0010	-
astore	0000 0010	write_global0	1111 1111 0101 1010	1111 1010	-
		push 2	0000 0101	0100 0000	2
		shl	0111 1000	1100 0001	-
		push 4	0000 0111	0100 0000	4
		add	0110 0000	0011 0000	-
		add	0110 0000	0011 0000	-
		write_global1	1111 1111 0101 1011	1111 1011	-
		read_global0	1111 1111 0111 1010	1111 0010	-
		read_global1	1111 1111 0111 1011	1111 0011	-
		store_word	1111 1111 0010 0100	0010 0010	-

2000-04-27