English version of this page
Next:Synthese  Up:Entwurf  Previous:Prioritätenmanager  Inhalt


Kodierung für die Implementierung

Die zu kodierenden Befehle werden in die Gruppen Kontrollfluß, Stack, Laden, Speichern, arithmetisch, logisch, If, Cmp und erweitert unterteilt. Dies sind neun Gruppen, die sich in vier Bit kodieren lassen. Für die Kodierung der Befehle innerhalb einer Gruppe stehen weitere vier Bits zur Verfügung, wenn man als Ziel der Kodierung einen 8-Bit-Opcode vorsieht. Es sind somit 16 verschiedene Befehle in maximal 16 Befehlsgruppen möglich, woraus sich eine maximale Anzahl von 256 Instruktionen ergibt.

In der prototypischen Implementierung werden nur neun Befehlsgruppen mit jeweils wenigen enthaltenen Instruktionen verwendet, so daß für eine spätere Fortführung des Entwurfs zu einem Mikrocontroller mit vollständigem Befehlssatz ausreichend Freiheitsgrade zur Verfügung stehen sollten. Zusätzlich wäre es möglich, anwendungsspezifische Befehle (beispielsweise einer Echtzeit-JVM) ebenfalls in Hardware anzulegen.

Dies gilt insbesondere, da rund 250 verschiedene Bytecode-Befehle existieren. Bei näherem Hinschauen stellt man jedoch fest, daß es sich bei kleinen Gruppen von Instruktionen häufig um Varianten eines Befehls mit unterschiedlichen Optionen bzw. variiertem Operanden handelt, die also mit einer einzigen, festverdrahteten Instruktion implementiert werden können. Bezieht man diese Tatsache in die Betrachtungen mit ein, so kommt man auf rund 100 Hardware-Befehle, die für die korrekte Interpretation von Java-Bytecode in einer Java Virtual Machine zur Verfügung gestellt werden müssen.

Von diesen tatsächlich in Hardware zu implementierenden Instruktionen sollen die in Tabelle 4.2 aufgeführten 26 Befehle im Prototypen verwirklicht werden, welche 53 Bytecodeinstruktionen entsprechen. Auch diese Umsetzung wird unter der Randbedingung vorgenommen, daß relativ wenig Platz auf dem FPGA zur Verfügung steht. Insofern wurde eine Priorisierung vorgenommen, damit die für die Ausführung eines Programms wichtigsten Befehle auch von Anfang an implementiert sind. Auf diese Weise wird zwar vorerst keine vollständige Kompatibilität des Prototypen mit "normalen" Java-Programmen erreicht, es ist damit aber eine Schnittstelle für Test-Programme verfügbar.

Die Kodierung der Befehle im Bytecode könnte grundsätzlich auch als Code für die Implementierung verwendet werden, allerdings wäre durch die Gruppenbildung bestimmter Befehle eine Überarbeitung notwendig.

In Tabelle 4.2 ist für jeden Opcode eine Priorität angegeben, mit der dieser Befehl im Prototypen implementiert werden soll. Die Kodierung wurde wie folgt vorgenommen (in absteigender Reihenfolge): von 5 (muß in jedem Falle implementiert sein) über 4, 3 und 2 bis 1 (sollte noch implementiert werden, falls alle anderen Befehle aus Tabelle 4.2 schon enthalten sind und es die Ressourcen erlauben).

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

Um die mikrocodierten Befehle umsetzen zu können, sind zusätzlich Befehle für Zugriffe auf die globalen (Hilfs-)Register GLOBAL0 und GLOBAL1 erforderlich. Diese sind in Tabelle 4.2 mit einem z als Priorität gekennzeichnet. Für eine weitere Vereinfachung der Tests werden ebenfalls die beiden Befehle zur direkten Veränderung des Befehlszeigers und des Zeigers über den obersten Eintrag auf dem Stack hinzugenommen.

Tabelle 4.3 enthält die Befehlsfolgen für die beiden mikrocodierten Befehle des Prototypen. Es handelt sich dabei um Array-Zugriffe im externen Speicher. Die benötigte Referenzadresse für den Anfang des Feldes und der Index für den zu bearbeitenden Eintrag müssen für eine korrekte Verarbeitung vorher auf den Stack geschrieben worden sein.

Tabelle 4.3: Übersicht Mikrocodes im Prototypen
Befehl Adresse Befehlsfolge Bytecodefolge Opcodefolge 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 -



Next:Synthese  Up:Entwurf  Previous:Prioritätenmanager  Inhalt
Robert Zulauf

2000-04-27