From: user5857@newsgrouper.org.invalid
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow.
--------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}×{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}×{Size}.
Integer and floating point compare instructions only compare
bits of the specified {Size}.
Conversions between integer and floating point are now also
governed by {Size} so one can directly convert FP64 directly
into {unSigned}×{Int16}--more fully supporting strongly typed
languages.
--------------------------------------------------------------
Integer instructions are now::
{Signed and unSigned}×{Byte, HalfWord, Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
Although I am oscillating whether to support FP8 or FP128.
With this rearrangement of bit in the instruction formats, I
was able to get all Constant and routing control bits in the
same place and format in all {1, 2, and 3}-Operand instructions
uniformly. This simplifies the Decoder, but more
importantly; the Operand delivery (and/or reception) mechanism.
I was also able to compress the 7 extended operation formats
into a single extended operation format. The instruction
format now looks like:
inst<31:26> Major OpCode
inst<20:16> {Rd, Cnd field}
inst<25:21> {SRC1, Rbase}
inst<15:10> {SH width, else, {I,d,Sign,Size}}
inst< 9: 6> {Minor OpCode, SRC3}
inst< 4: 0> {offset,SRC2,Rindex,1-OP×}
So there is 1 uniformly positioned field of Minor OpCodes,
and one uniformly interpreted field of Operand Modifiers.
Operand Modifiers applies routing registers and inserting
of constants to XOP Instructions.
--------------------------------------------------------------
So, what does this buy the Instruction Set ??
A) All integer calculations are performed at the size and
type of the result as required by the high level language::
{Signed and unSigned}×{Byte, HalfWord, Word, DoubleWord}.
This, gets rid of all smash instructions across all data
types. {smash == {sext, zext, ((x<<2^n)>>2^n), ...}
B) I actually gained 1 more extended OpCode for future expansion.
C) assembler/disassembler was simplified
D) and while I did not add any new 'instructions' I made those
already present more uniform and supporting of the requirements
of higher level languages (like ADA) and more suitable to the
stricter typing LLVM provides over GCC.
In some ways I 'doubled' the instruction count while not adding
a single instruction {spelling or field-pattern} to ISA.
--------------------------------------------------------------
The elimination of 'smashes' shrinks the instruction count of
GNUPLOT by 4%--maybe a bit more once we sort out all of the
compiler patterns it needs to recognize.
--------------------------------------------------------------
I wonder if crow tastes good in shepard's pie ?!?
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
