From: user5857@newsgrouper.org.invalid
Robert Finch posted:
> On 2025-10-02 10:50 p.m., MitchAlsup wrote:
> >
> > 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.
> >
> For my arch, I decided to support FP128 thinking that FP8 could be
> implemented with lookup tables, given that eight bit floats tend to vary
> in composition. Of course, I like more precision.
> Could it be a build option? Or a bit in a control register to flip
> between FP8 and 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×}
> >
> Only four bits for SRC3?
No, there are 5-bits--inst<9:5>--woops.
>
> > 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)
|
