On 2021-05-08, BGB wrote:
> On 5/7/2021 3:40 PM, MitchAlsup wrote:
>> On Friday, May 7, 2021 at 3:20:56 PM UTC-5, BGB wrote:
>>> On 5/7/2021 8:15 AM, Stefan Monnier wrote:
>>>>> It is possible that it could be generalized, but then the ISA would
>>>>> be less
>>>>> RISC style then it is already...
>>>>>
>>>>> Then again, I did see recently that someone had listed my ISA
>>>>> somewhere, but
>>>>> then classified it as a CISC; I don't entirely agree, but alas...
>>>>>
>>>>> Then again, many peoples' definitions of "RISC" exclude largish
>>>>> instruction-sets with variable-length instruction encodings, so alas.
>>>>>
>>>>> But, taken at face value, then one would also need to exclude
>>>>> Thumb2 and
>>>>> similar from the RISC category.
>>>>
>>>> I think it's better not to worry about how other people label your ISA.
>>>>
>>>> The manichean RISC-vs-CISC labeling is stupid anyway: the design space
>>>> has many more than 2 spots.
>>>>
>>>> Also I think the "classic RISC" is the result of specific conditions at
>>>> that point in time which resulted in a particular sweet spot in the
>>>> design space.
>>>>
>>>> But design constraints are quite different now, so applying the same
>>>> "quantitative approach" that lead to MIPS/SPARC/... will now result in
>>>> something quite different. One could argue that such new ISAs
>>>> could be called RISC-2020 ;-)
>>>>
>>> Yeah.
>>>
>>> Classic RISC:
>>> Fixed size instructions
>>> Typically only a single addressing mode (Reg, Disp)
>>> Typically only supporting aligned memory access
>>> Aims for fixed 1 instruction per cycle
>> <
>> Mc 88K had
>> fixed sized instructions
>> [Rbase+IMM16] and [Rbase+Rindex<<scale] address modes
>> Aligned memory has been show to be defective
>> aimed at 1ipc but we did engineer a 6-wide OoO version
>>
>> My 66000
>> has fixed sized instruction specifiers with 1 or 2 constants.
>> [Rbase+IMM16] and [Rbase+Rindex<<scale] and
>> [Rbase+Rindex<<scale+disp[32,64] address modes
>> Misaligned memory model
>> Aimed at low burden for LBIO implementations and low burden for GBOoO
>> implementations
>> Inherently parallel
>> Never needs a NoOp
>
>
> BJX2 allows misaligned access, and also does not need NOPs.
>
> Misaligned access may degrade performance in some cases though, doesn't
> work with certain instructions, ...
>
> If one triggers an interlock on a memory load or similar, there will be
> a partial pipeline stall, and it will behave as-if a NOP were present.
> Triggering an interlock on various other instructions may also trigger
> this behavior.
>
> Interlocks currently are in 2nd place (behind cache misses) for wasting
> clock-cycles (improving the efficiency of memory has, in effect, also
> increased the proportion of clock-cycles wasted on pipeline interlock
> stalls).
>
> I had more recently added logic to my C compiler's "wexifier" to shuffle
> instructions around to try to reduce interlock penalties. At the moment,
> it is disabled by default as the wexifier seems to be buggy in some
> as-of-yet undetermined way (seems to be producing bundles which don't
> work correctly on the FPGA implementation, but I can't seem to isolate
> the behavior well enough to determine the cause).
>
>
> BJX2:
>   Rb + Imm<<Sc
>   Rb + Ri<<Sc
>

MRISC32:
Rb + Imm
Rb + Ri<<Sc

> Rb: R2..R15, R18..R31
> Ri: R0, R2..R14, R18..R31
>
> R0/R1: Used to encode special-cases
> R15 (SP): Only usable as a base register
> R16/R17: Reserved (for the possibility of more special cases)
>
> Sc: Typically hard-wired based on the element type
>
> Base registers encoded via special cases:
>   PC, GBR, TBR
> Index registers encoded via special cases:
>   R0, Sc=0 (Allows access to misaligned struct members)
>
> However, since pretty much all this is handled in the decoder, I don't
> really feel it classifies as distinct address modes (and, as far as the
> AGU is concerned (Rb+Ri<<Sc) is the only mode).
>
> Generally, (Rb) and (Rb,0) are treated as equivalent.
>
>
>
> Given the lack of autoincrement modes or similar, both PC and PC&(~3)
> addressing, ... BJX2 in practice actually has fewer distinct addressing
> modes than SuperH.
>
> The SuperH ISA also had a few edge cases where multiple memory accesses
> would be performed by a single instruction (and other violations of
> Load/Store), but was generally classified as a RISC.
>
>
> One thing BJX2 does have, that many RISC's lack, is a LEA instruction.
> LEA Generally takes the form of assuming the Zero-Extended Store doesn't
> make sense, so these cases are interpreted as a LEA.
>
> This was mostly because LEA helps in various edge cases, such as for:
>   Composing function pointers;
>   Long-distance branches;
>   Compound addressing within structures;
>     Eg: Accessing an element within an array within a structure.
>   ...
>

MRISC32 also has LEA (called "LDEA" - LoaD Effective Address). It
essentially uses the output from the AGU as the result (bypassing
the load-from-memory stage), and has a few different use cases.

Apart from preloading memory addresses into registers, it can be used
for simple arithmetic on the form A + B << N (where N is 0, 1, 2 or 3),
which can be used for implementing x * 3 and x * 5, for instance.

Another very useful use case is to load vector registers with a
"stride". In vector mode the AGU will generate addresses on the
form:

(1) addr[k] = Rb + Im * k (Immediate form stride)
(2) addr[k] = Rb + (Ri << Sc) * k (Register form stride)
(3) addr[k] = Rb + Vi[k] << Sc (Gather/scatter)

Forms (1) and (2) construct addresses with a constant offset
between each address (I call these "stride based" load/store).

The LDEA instruction can thus be used for loading a series of
numbers into a vector register, e.g. like this:

LDEA V1, Z, #1 ; V1 = {0, 1, 2, 3, 4, 5, ...}

LDI S1, #7
LDEA V1, S1, #3 ; V1 = {7, 10, 13, 16, 19, ...}

This is a common operation in vectorized code, and on classic SIMD
ISA:s you usually load a predefined constant (e.g. from memory) in this
case.

Since the MRISC32 ISA allows each implementation to define the vector
register size, using predefined vector constants is not a good solution
since the vector register size is not known at compile time.

/Marcus

On 5/8/2021 12:19 PM, John Levine wrote:
> According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>>> The huge advantage is that it takes care of scaling automatically so
>>> the programmer doesn't have to worry about it in every operation.
>
>> While all of that is true, there were other alternatives. COBOL
>> supported, and still does, automatic scaling of fixed point numbers. I
>> don't know if other languages support this.
>
> COBOL gives you fixed scaling, e.g. PIC 9999V999 has four digits before
> the implicit decimal point and three after. When you do arithmetic
> it'll align the decimal point, but you don't get automatic scaling
> unless you tell the compiler that the data is COMP-1 or COMP-2 so
> it uses the internal floating point representation.

Again, true, of course. I guess I thought the "automatic scaling" is
included in the "dynamic" part of "dynamic range" that Marcus mentioned
earlier. But of course YMMV.

> Scaling crisis of the day:
>
> The NASDAQ stock exchange's computers represent prices as 32 bit
> unsigned integers, with units being 1/100 of a cent or 1/10000 of a
> dollar. Since the largest 32 bit integer is 4294967295 the highest
> price it can represnt is $429,496.7295. The price of Berkshire
> Hathaway reached $437,131 this week. Oops. They say they'll have a
> fix later this month.

Wow! Interesting. I wonder what the fix will be?

> The next highest price is about $5000, and Berkshire's CEO Warren
> Buffett has said for decades that he'll never split the shares like
> everyone else does.

Thanks, John. I didn't know that.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

> Yes that makes sense. Specifically for FP8, the increased dynamic range
> is by far the most important trait. I've even seen examples of using
> 1:5:2 in DNN:s (deep neural networks) where dynamic range is often more
> important than precision.

Indeed 1:5:2 is arguably more useful than 1:4:3.

Stefan

Stefan Monnier [2021-05-09 14:35:28] wrote:
>> Yes that makes sense. Specifically for FP8, the increased dynamic range
>> is by far the most important trait. I've even seen examples of using
>> 1:5:2 in DNN:s (deep neural networks) where dynamic range is often more
>> important than precision.
> Indeed 1:5:2 is arguably more useful than 1:4:3.

An alternative of course is to use a log-base representation. So your
8bit data is split 1:7 between a sign and an exponent, with no mantissa
at all and then you choose your dynamic range by picking the base.
Multiplication is easy but addition is takes more effort.

But if those FP8 are only used for transport and always converted to
FP16 or FP32 before actual computations, then the ease of
addition/multiplication is irrelevant and the only worry is how to
convert to/from that (and converting from FP8 is easy since it's small
enough to use a lookup table).

Stefan

On Sunday, May 9, 2021 at 1:21:44 PM UTC-5, Stephen Fuld wrote:
> On 5/8/2021 12:19 PM, John Levine wrote:
> > According to Stephen Fuld <sf...@alumni.cmu.edu.invalid>:
> >>> The huge advantage is that it takes care of scaling automatically so
> >>> the programmer doesn't have to worry about it in every operation.
> >
> >> While all of that is true, there were other alternatives. COBOL
> >> supported, and still does, automatic scaling of fixed point numbers. I
> >> don't know if other languages support this.
> >
> > COBOL gives you fixed scaling, e.g. PIC 9999V999 has four digits before
> > the implicit decimal point and three after. When you do arithmetic
> > it'll align the decimal point, but you don't get automatic scaling
> > unless you tell the compiler that the data is COMP-1 or COMP-2 so
> > it uses the internal floating point representation.
> Again, true, of course. I guess I thought the "automatic scaling" is
> included in the "dynamic" part of "dynamic range" that Marcus mentioned
> earlier. But of course YMMV.
> > Scaling crisis of the day:
> >
> > The NASDAQ stock exchange's computers represent prices as 32 bit
> > unsigned integers, with units being 1/100 of a cent or 1/10000 of a
> > dollar. Since the largest 32 bit integer is 4294967295 the highest
> > price it can represnt is $429,496.7295. The price of Berkshire
> > Hathaway reached $437,131 this week. Oops. They say they'll have a
> > fix later this month.
<
> Wow! Interesting. I wonder what the fix will be?
<
The only way to get BH to split their stock would be the thread of delisting.
<
> > The next highest price is about $5000, and Berkshire's CEO Warren
> > Buffett has said for decades that he'll never split the shares like
> > everyone else does.
<
Unless someone forces his hand.
<
> Thanks, John. I didn't know that.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Sunday, May 9, 2021 at 1:20:57 PM UTC-5, Anton Ertl wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >On 5/8/2021 8:31 AM, John Levine wrote:
> >> When people were designing early computers in the 1940s, they knew
> >> about floating point but didn't include it because they thought that
> >> the programer could easily keep track of the scale so the extra
> >> hardware complexity wasn't worth it. This was true if the programmer
> >> was John von Neumann, not so true otherwise, so FP hardware showed up
> >> on the 704 in the early 1950s.
> >
> >While all of that is true, there were other alternatives. COBOL
> >supported, and still does, automatic scaling of fixed point numbers. I
> >don't know if other languages support this.
> >
> >Of course, the time period you were discussing was before high level
> >languages, and writing the code in assembler was probably "a bridge too
> >far" for most programmers at the time.
<
> Not really sure what you mean with the latter. In the early 1950s,
> writing programs included steps that most of us don't know about these
> days, such as layout of instructions on the rotating memory for
> performance, where each instruction included the address of the next
> one. What we see as machine code since the 1960s does not have to
> deal with these complications, assembly language is even higher level,
> Fortran I higher level yet.
<
Before that we had "patch pannels" where the program was expressed in WIREs
>
> As for fixed vs. floating point, I guess that is a cross-cutting
> concern. Sure you can argue that, if you spend a lot of time on
> low-level steps such as coding layout, spending some time on range
> analysis is minor change, so fixed point is acceptable.
>
> OTOH, if you have a nice numerical routine for a certain fixed-point
> number range and notice that you need the same computation, but for a
> different numeric range, do you want to repeat all the low-level work?
> Ok, maybe you can change just a few immediate values and leave the
> code as-is otherwise, but if the code includes optimizations based on
> the knowledge of the values, that's not possible. In such a scenario,
> floating point offers advantages, just as it does now.
<
My how lazy we have become ! Even with high quality FP, numerical
analysis is still mandatory--except that it is seldom performed !?!
>
> What held back floating point for a long time was the slowness and/or
> high cost of FP hardware, but at least in general-purpose computers
> that's a thing of the past.
<
Since mid 1980s
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Sunday, May 9, 2021 at 1:21:34 PM UTC-5, Marcus wrote:
> On 2021-05-08, Stefan Monnier wrote:
> >>>>> Good to know - I didn't think of that. I mostly went with the
> >>>>> configuration that made the most sense: The main advantage (IMO) of
> >>>>> floating-point numbers compared to fixed point numbers is the increased
> >>>>> dynamic range,
> >>>> Isn't that the *only* reason to do floating point?
> >>> I can think of a few more advantages, such as the normalized
> >>> representation that simplifies the implementation of many algorithms ...
> >> The huge advantage is that it takes care of scaling automatically so
> >> the programmer doesn't have to worry about it in every operation.
> >
> > While this is mostly true in general, the comments above where made in
> > the context of an 8bit floating point format, where the exponent's range
> > is sufficiently limited that it is still something the programmer very
> > much has to worry about.
> >
> Yes that makes sense. Specifically for FP8, the increased dynamic range
> is by far the most important trait. I've even seen examples of using
> 1:5:2 in DNN:s (deep neural networks) where dynamic range is often more
> important than precision.
<
Useful precision is often 1-bit (yes or no)
>
> >
> > Stefan
> >
>
> /Marcus

On Sunday, May 9, 2021 at 1:21:42 PM UTC-5, Marcus wrote:
> On 2021-05-08, BGB wrote:
> > On 5/7/2021 3:40 PM, MitchAlsup wrote:
> >> On Friday, May 7, 2021 at 3:20:56 PM UTC-5, BGB wrote:
> >>> On 5/7/2021 8:15 AM, Stefan Monnier wrote:
> >>>>> It is possible that it could be generalized, but then the ISA would
> >>>>> be less
> >>>>> RISC style then it is already...
> >>>>>
> >>>>> Then again, I did see recently that someone had listed my ISA
> >>>>> somewhere, but
> >>>>> then classified it as a CISC; I don't entirely agree, but alas...
> >>>>>
> >>>>> Then again, many peoples' definitions of "RISC" exclude largish
> >>>>> instruction-sets with variable-length instruction encodings, so alas.
> >>>>>
> >>>>> But, taken at face value, then one would also need to exclude
> >>>>> Thumb2 and
> >>>>> similar from the RISC category.
> >>>>
> >>>> I think it's better not to worry about how other people label your ISA.
> >>>>
> >>>> The manichean RISC-vs-CISC labeling is stupid anyway: the design space
> >>>> has many more than 2 spots.
> >>>>
> >>>> Also I think the "classic RISC" is the result of specific conditions at
> >>>> that point in time which resulted in a particular sweet spot in the
> >>>> design space.
> >>>>
> >>>> But design constraints are quite different now, so applying the same
> >>>> "quantitative approach" that lead to MIPS/SPARC/... will now result in
> >>>> something quite different. One could argue that such new ISAs
> >>>> could be called RISC-2020 ;-)
> >>>>
> >>> Yeah.
> >>>
> >>> Classic RISC:
> >>> Fixed size instructions
> >>> Typically only a single addressing mode (Reg, Disp)
> >>> Typically only supporting aligned memory access
> >>> Aims for fixed 1 instruction per cycle
> >> <
> >> Mc 88K had
> >> fixed sized instructions
> >> [Rbase+IMM16] and [Rbase+Rindex<<scale] address modes
> >> Aligned memory has been show to be defective
> >> aimed at 1ipc but we did engineer a 6-wide OoO version
> >>
> >> My 66000
> >> has fixed sized instruction specifiers with 1 or 2 constants.
> >> [Rbase+IMM16] and [Rbase+Rindex<<scale] and
> >> [Rbase+Rindex<<scale+disp[32,64] address modes
> >> Misaligned memory model
> >> Aimed at low burden for LBIO implementations and low burden for GBOoO
> >> implementations
> >> Inherently parallel
> >> Never needs a NoOp
> >
> >
> > BJX2 allows misaligned access, and also does not need NOPs.
> >
> > Misaligned access may degrade performance in some cases though, doesn't
> > work with certain instructions, ...
> >
> > If one triggers an interlock on a memory load or similar, there will be
> > a partial pipeline stall, and it will behave as-if a NOP were present.
> > Triggering an interlock on various other instructions may also trigger
> > this behavior.
> >
> > Interlocks currently are in 2nd place (behind cache misses) for wasting
> > clock-cycles (improving the efficiency of memory has, in effect, also
> > increased the proportion of clock-cycles wasted on pipeline interlock
> > stalls).
> >
> > I had more recently added logic to my C compiler's "wexifier" to shuffle
> > instructions around to try to reduce interlock penalties. At the moment,
> > it is disabled by default as the wexifier seems to be buggy in some
> > as-of-yet undetermined way (seems to be producing bundles which don't
> > work correctly on the FPGA implementation, but I can't seem to isolate
> > the behavior well enough to determine the cause).
> >
> >
> > BJX2:
> > Rb + Imm<<Sc
> > Rb + Ri<<Sc
> >
> MRISC32:
> Rb + Imm
> Rb + Ri<<Sc
>
> > Rb: R2..R15, R18..R31
> > Ri: R0, R2..R14, R18..R31
> >
> > R0/R1: Used to encode special-cases
> > R15 (SP): Only usable as a base register
> > R16/R17: Reserved (for the possibility of more special cases)
> >
> > Sc: Typically hard-wired based on the element type
> >
> > Base registers encoded via special cases:
> > PC, GBR, TBR
> > Index registers encoded via special cases:
> > R0, Sc=0 (Allows access to misaligned struct members)
> >
> > However, since pretty much all this is handled in the decoder, I don't
> > really feel it classifies as distinct address modes (and, as far as the
> > AGU is concerned (Rb+Ri<<Sc) is the only mode).
> >
> > Generally, (Rb) and (Rb,0) are treated as equivalent.
> >
> >
> >
> > Given the lack of autoincrement modes or similar, both PC and PC&(~3)
> > addressing, ... BJX2 in practice actually has fewer distinct addressing
> > modes than SuperH.
> >
> > The SuperH ISA also had a few edge cases where multiple memory accesses
> > would be performed by a single instruction (and other violations of
> > Load/Store), but was generally classified as a RISC.
> >
> >
> > One thing BJX2 does have, that many RISC's lack, is a LEA instruction.
> > LEA Generally takes the form of assuming the Zero-Extended Store doesn't
> > make sense, so these cases are interpreted as a LEA.
> >
> > This was mostly because LEA helps in various edge cases, such as for:
> > Composing function pointers;
> > Long-distance branches;
<
How many branches are farther than 1/8 GB away with code compiled
from high level languages ??
<
> > Compound addressing within structures;
> > Eg: Accessing an element within an array within a structure.
> > ...
> >
> MRISC32 also has LEA (called "LDEA" - LoaD Effective Address). It
> essentially uses the output from the AGU as the result (bypassing
> the load-from-memory stage), and has a few different use cases.
>
I know one compiler writer that would enunciate "LEA" as 'Lee'-'ah'
>
> Apart from preloading memory addresses into registers, it can be used
> for simple arithmetic on the form A + B << N (where N is 0, 1, 2 or 3),
> which can be used for implementing x * 3 and x * 5, for instance.
>
Better still is to make integer multiply 3-cycles.
>
> Another very useful use case is to load vector registers with a
> "stride". In vector mode the AGU will generate addresses on the
> form:
>
> (1) addr[k] = Rb + Im * k (Immediate form stride)
> (2) addr[k] = Rb + (Ri << Sc) * k (Register form stride)
> (3) addr[k] = Rb + Vi[k] << Sc (Gather/scatter)
>
Both stride and gather forms fall out "for free" in VVM. {So, I am
agreeing with you that LEA is a valuable instruction.}
>
> Forms (1) and (2) construct addresses with a constant offset
> between each address (I call these "stride based" load/store).
<
Don't forget the stride-0 form in GPUs where every thread wants to
bang on the auto-update memory reference location.
>
> The LDEA instruction can thus be used for loading a series of
> numbers into a vector register, e.g. like this:
>
> LDEA V1, Z, #1 ; V1 = {0, 1, 2, 3, 4, 5, ...}
>
> LDI S1, #7
> LDEA V1, S1, #3 ; V1 = {7, 10, 13, 16, 19, ...}
>
> This is a common operation in vectorized code, and on classic SIMD
> ISA:s you usually load a predefined constant (e.g. from memory) in this
> case.
>
> Since the MRISC32 ISA allows each implementation to define the vector
> register size, using predefined vector constants is not a good solution
> since the vector register size is not known at compile time.
>
> /Marcus

On Sunday, May 9, 2021 at 1:45:06 PM UTC-5, Stefan Monnier wrote:
> Stefan Monnier [2021-05-09 14:35:28] wrote:
> >> Yes that makes sense. Specifically for FP8, the increased dynamic range
> >> is by far the most important trait. I've even seen examples of using
> >> 1:5:2 in DNN:s (deep neural networks) where dynamic range is often more
> >> important than precision.
> > Indeed 1:5:2 is arguably more useful than 1:4:3.
> An alternative of course is to use a log-base representation. So your
> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
> at all and then you choose your dynamic range by picking the base.
> Multiplication is easy but addition is takes more effort.
<
Really ?!?!?
Both are implemented with table look ups with concatenated values as the
address.
>
> But if those FP8 are only used for transport and always converted to
> FP16 or FP32 before actual computations, then the ease of
> addition/multiplication is irrelevant and the only worry is how to
> convert to/from that (and converting from FP8 is easy since it's small
> enough to use a lookup table).
>
>
> Stefan

>> Wow! Interesting. I wonder what the fix will be?
> The only way to get BH to split their stock would be the threat of delisting.

They could also threaten to let it wrap around ;-)

Stefan

>> An alternative of course is to use a log-base representation. So your
>> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
>> at all and then you choose your dynamic range by picking the base.
>> Multiplication is easy but addition is takes more effort.
> Really ?!?!?
> Both are implemented with table look ups with concatenated values as the
> address.

Really? A 64k entry table seems rather expensive for such
a functionality. Then again, if the output is FP8, maybe it can be
implemented as just a big mess of auto-generated and+or+not since many
inputs map to the same output.

Stefan

On 5/9/2021 3:59 PM, MitchAlsup wrote:
> On Sunday, May 9, 2021 at 1:21:42 PM UTC-5, Marcus wrote:
>> On 2021-05-08, BGB wrote:
>>> On 5/7/2021 3:40 PM, MitchAlsup wrote:
>>>> On Friday, May 7, 2021 at 3:20:56 PM UTC-5, BGB wrote:
>>>>> On 5/7/2021 8:15 AM, Stefan Monnier wrote:
>>>>>>> It is possible that it could be generalized, but then the ISA would
>>>>>>> be less
>>>>>>> RISC style then it is already...
>>>>>>>
>>>>>>> Then again, I did see recently that someone had listed my ISA
>>>>>>> somewhere, but
>>>>>>> then classified it as a CISC; I don't entirely agree, but alas...
>>>>>>>
>>>>>>> Then again, many peoples' definitions of "RISC" exclude largish
>>>>>>> instruction-sets with variable-length instruction encodings, so alas.
>>>>>>>
>>>>>>> But, taken at face value, then one would also need to exclude
>>>>>>> Thumb2 and
>>>>>>> similar from the RISC category.
>>>>>>
>>>>>> I think it's better not to worry about how other people label your ISA.
>>>>>>
>>>>>> The manichean RISC-vs-CISC labeling is stupid anyway: the design space
>>>>>> has many more than 2 spots.
>>>>>>
>>>>>> Also I think the "classic RISC" is the result of specific conditions at
>>>>>> that point in time which resulted in a particular sweet spot in the
>>>>>> design space.
>>>>>>
>>>>>> But design constraints are quite different now, so applying the same
>>>>>> "quantitative approach" that lead to MIPS/SPARC/... will now result in
>>>>>> something quite different. One could argue that such new ISAs
>>>>>> could be called RISC-2020 ;-)
>>>>>>
>>>>> Yeah.
>>>>>
>>>>> Classic RISC:
>>>>> Fixed size instructions
>>>>> Typically only a single addressing mode (Reg, Disp)
>>>>> Typically only supporting aligned memory access
>>>>> Aims for fixed 1 instruction per cycle
>>>> <
>>>> Mc 88K had
>>>> fixed sized instructions
>>>> [Rbase+IMM16] and [Rbase+Rindex<<scale] address modes
>>>> Aligned memory has been show to be defective
>>>> aimed at 1ipc but we did engineer a 6-wide OoO version
>>>>
>>>> My 66000
>>>> has fixed sized instruction specifiers with 1 or 2 constants.
>>>> [Rbase+IMM16] and [Rbase+Rindex<<scale] and
>>>> [Rbase+Rindex<<scale+disp[32,64] address modes
>>>> Misaligned memory model
>>>> Aimed at low burden for LBIO implementations and low burden for GBOoO
>>>> implementations
>>>> Inherently parallel
>>>> Never needs a NoOp
>>>
>>>
>>> BJX2 allows misaligned access, and also does not need NOPs.
>>>
>>> Misaligned access may degrade performance in some cases though, doesn't
>>> work with certain instructions, ...
>>>
>>> If one triggers an interlock on a memory load or similar, there will be
>>> a partial pipeline stall, and it will behave as-if a NOP were present.
>>> Triggering an interlock on various other instructions may also trigger
>>> this behavior.
>>>
>>> Interlocks currently are in 2nd place (behind cache misses) for wasting
>>> clock-cycles (improving the efficiency of memory has, in effect, also
>>> increased the proportion of clock-cycles wasted on pipeline interlock
>>> stalls).
>>>
>>> I had more recently added logic to my C compiler's "wexifier" to shuffle
>>> instructions around to try to reduce interlock penalties. At the moment,
>>> it is disabled by default as the wexifier seems to be buggy in some
>>> as-of-yet undetermined way (seems to be producing bundles which don't
>>> work correctly on the FPGA implementation, but I can't seem to isolate
>>> the behavior well enough to determine the cause).
>>>
>>>
>>> BJX2:
>>> Rb + Imm<<Sc
>>> Rb + Ri<<Sc
>>>
>> MRISC32:
>> Rb + Imm
>> Rb + Ri<<Sc
>>
>>> Rb: R2..R15, R18..R31
>>> Ri: R0, R2..R14, R18..R31
>>>
>>> R0/R1: Used to encode special-cases
>>> R15 (SP): Only usable as a base register
>>> R16/R17: Reserved (for the possibility of more special cases)
>>>
>>> Sc: Typically hard-wired based on the element type
>>>
>>> Base registers encoded via special cases:
>>> PC, GBR, TBR
>>> Index registers encoded via special cases:
>>> R0, Sc=0 (Allows access to misaligned struct members)
>>>
>>> However, since pretty much all this is handled in the decoder, I don't
>>> really feel it classifies as distinct address modes (and, as far as the
>>> AGU is concerned (Rb+Ri<<Sc) is the only mode).
>>>
>>> Generally, (Rb) and (Rb,0) are treated as equivalent.
>>>
>>>
>>>
>>> Given the lack of autoincrement modes or similar, both PC and PC&(~3)
>>> addressing, ... BJX2 in practice actually has fewer distinct addressing
>>> modes than SuperH.
>>>
>>> The SuperH ISA also had a few edge cases where multiple memory accesses
>>> would be performed by a single instruction (and other violations of
>>> Load/Store), but was generally classified as a RISC.
>>>
>>>
>>> One thing BJX2 does have, that many RISC's lack, is a LEA instruction.
>>> LEA Generally takes the form of assuming the Zero-Extended Store doesn't
>>> make sense, so these cases are interpreted as a LEA.
>>>
>>> This was mostly because LEA helps in various edge cases, such as for:
>>> Composing function pointers;
>>> Long-distance branches;
> <
> How many branches are farther than 1/8 GB away with code compiled
> from high level languages ??
> <

The normal direct branch op in BJX2 has a 20-bit displacement, so can
reach +/- 1MB.

A Jumbo+LEA can do +/- 2GB, so:
LEA.B (PC, Disp33s), R3
JMP R3

But, this is also possible (+/- 32MB):
MOV #Imm25s, R0
BRA R0

In general, these don't really come up at present because, of my test
programs, all of them have < 1MB in the ".text" section.

>>> Compound addressing within structures;
>>> Eg: Accessing an element within an array within a structure.
>>> ...
>>>
>> MRISC32 also has LEA (called "LDEA" - LoaD Effective Address). It
>> essentially uses the output from the AGU as the result (bypassing
>> the load-from-memory stage), and has a few different use cases.
>>
> I know one compiler writer that would enunciate "LEA" as 'Lee'-'ah'

I always thought of it like "Lee".

>>
>> Apart from preloading memory addresses into registers, it can be used
>> for simple arithmetic on the form A + B << N (where N is 0, 1, 2 or 3),
>> which can be used for implementing x * 3 and x * 5, for instance.
>>
> Better still is to make integer multiply 3-cycles.
>>
>> Another very useful use case is to load vector registers with a
>> "stride". In vector mode the AGU will generate addresses on the
>> form:
>>
>> (1) addr[k] = Rb + Im * k (Immediate form stride)
>> (2) addr[k] = Rb + (Ri << Sc) * k (Register form stride)
>> (3) addr[k] = Rb + Vi[k] << Sc (Gather/scatter)
>>
> Both stride and gather forms fall out "for free" in VVM. {So, I am
> agreeing with you that LEA is a valuable instruction.}
>>
>> Forms (1) and (2) construct addresses with a constant offset
>> between each address (I call these "stride based" load/store).
> <
> Don't forget the stride-0 form in GPUs where every thread wants to
> bang on the auto-update memory reference location.
>>
>> The LDEA instruction can thus be used for loading a series of
>> numbers into a vector register, e.g. like this:
>>
>> LDEA V1, Z, #1 ; V1 = {0, 1, 2, 3, 4, 5, ...}
>>
>> LDI S1, #7
>> LDEA V1, S1, #3 ; V1 = {7, 10, 13, 16, 19, ...}
>>
>> This is a common operation in vectorized code, and on classic SIMD
>> ISA:s you usually load a predefined constant (e.g. from memory) in this
>> case.
>>
>> Since the MRISC32 ISA allows each implementation to define the vector
>> register size, using predefined vector constants is not a good solution
>> since the vector register size is not known at compile time.
>>
>> /Marcus

On Sunday, May 9, 2021 at 4:16:17 PM UTC-5, Stefan Monnier wrote:
> >> An alternative of course is to use a log-base representation. So your
> >> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
> >> at all and then you choose your dynamic range by picking the base.
> >> Multiplication is easy but addition is takes more effort.
> > Really ?!?!?
> > Both are implemented with table look ups with concatenated values as the
> > address.
> Really? A 64k entry table seems rather expensive for such
> a functionality. Then again, if the output is FP8, maybe it can be
> implemented as just a big mess of auto-generated and+or+not since many
> inputs map to the same output.
<
IBM 1620 "Can't add, doesn't even try" laid the groundwork where if the
operands are small enough it becomes cheaper to just read out the correct
result than to build the logic to calculate the result.
>
>
> Stefan

On Sunday, May 9, 2021 at 4:34:56 PM UTC-5, BGB wrote:
> On 5/9/2021 3:59 PM, MitchAlsup wrote:

> > <
> > How many branches are farther than 1/8 GB away with code compiled
> > from high level languages ??
> > <
> The normal direct branch op in BJX2 has a 20-bit displacement, so can
> reach +/- 1MB.
>
> A Jumbo+LEA can do +/- 2GB, so:
> LEA.B (PC, Disp33s), R3
> JMP R3
>
> But, this is also possible (+/- 32MB):
> MOV #Imm25s, R0
> BRA R0
>
My 66000 has 16-bit actual word displacement (18-bit byte address) for
conditional branches and 26-bit unconditional branches (and calls) (28-bit
effective range).

But JMP instructions can have 32-bit or 64-bit immediates so you predicate
over the JMP with an inverted condition for the predicate.
>
> In general, these don't really come up at present because, of my test
> programs, all of them have < 1MB in the ".text" section.
<
In practice, few (<1%) are branches of those dimensions.
<
> >>> Compound addressing within structures;
> >>> Eg: Accessing an element within an array within a structure.
> >>> ...
> >>>
> >> MRISC32 also has LEA (called "LDEA" - LoaD Effective Address). It
> >> essentially uses the output from the AGU as the result (bypassing
> >> the load-from-memory stage), and has a few different use cases.
> >>
> > I know one compiler writer that would enunciate "LEA" as 'Lee'-'ah'
> I always thought of it like "Lee".
<
It was funny to hear him say "lee-ah", but he was from Russia so I gave him
a break.
> >>
> >> Apart from preloading memory addresses into registers, it can be used
> >> for simple arithmetic on the form A + B << N (where N is 0, 1, 2 or 3),
> >> which can be used for implementing x * 3 and x * 5, for instance.
> >>
> > Better still is to make integer multiply 3-cycles.
> >>
> >> Another very useful use case is to load vector registers with a
> >> "stride". In vector mode the AGU will generate addresses on the
> >> form:
> >>
> >> (1) addr[k] = Rb + Im * k (Immediate form stride)
> >> (2) addr[k] = Rb + (Ri << Sc) * k (Register form stride)
> >> (3) addr[k] = Rb + Vi[k] << Sc (Gather/scatter)
> >>
> > Both stride and gather forms fall out "for free" in VVM. {So, I am
> > agreeing with you that LEA is a valuable instruction.}
> >>
> >> Forms (1) and (2) construct addresses with a constant offset
> >> between each address (I call these "stride based" load/store).
> > <
> > Don't forget the stride-0 form in GPUs where every thread wants to
> > bang on the auto-update memory reference location.
> >>
> >> The LDEA instruction can thus be used for loading a series of
> >> numbers into a vector register, e.g. like this:
> >>
> >> LDEA V1, Z, #1 ; V1 = {0, 1, 2, 3, 4, 5, ...}
> >>
> >> LDI S1, #7
> >> LDEA V1, S1, #3 ; V1 = {7, 10, 13, 16, 19, ...}
> >>
> >> This is a common operation in vectorized code, and on classic SIMD
> >> ISA:s you usually load a predefined constant (e.g. from memory) in this
> >> case.
> >>
> >> Since the MRISC32 ISA allows each implementation to define the vector
> >> register size, using predefined vector constants is not a good solution
> >> since the vector register size is not known at compile time.
> >>
> >> /Marcus

According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>> Wow! Interesting. I wonder what the fix will be?
>> The only way to get BH to split their stock would be the threat of delisting.

BH is listed on the NYSE which uses a different internal
representation. This is solely the NASDAQ's problem.

Buffett is 90 years old and has named a successor. They also have
class B shares which are worth 1/1500 of a class A share but only have
1/10000 of a class A vote. The obvious thing to do once Buffett is no
longer on the scene is to convert everything to class B so the price
is in the $300 range and all shares have the same vote.

>They could also threaten to let it wrap around ;-)

That had occurred to me.

Several decades ago I recall a somewhat similar issue when BH was the
first listed stock whose price exceeded $10,000. At that point the
problem was stock price tables were printed in newspapers, and the
typesetting software a lot of papers used wasn't expecting five digit
prices. They fixed that somehow, too.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 5/9/2021 4:28 AM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>
>> IMUL (Lane 1)
>> 32*32 -> 64
>
> Do you have two instructions (one for signed and one for unsigned)
> or three (one for the lower half, one for signed high, one for
> unsigned high)? The latter version could save you some ALU
> complexity and some latency in the (probably common) case where
> only a 32*32 multiplication is needed, at the cost of added
> instructions for the 32*32-> 64 bit case.
>

There are actually more cases:
MULS: 32*32->32, Result is sign-extended from low 32 bits
MULU: 32*32->32, Result is zero-extended from low 32 bits
DMULS: 32*32->64, 64-bit signed result
DMULU: 32*32->64, 64-bit unsigned result

The former give the typical behaviors one expects in C, the latter gives
the widened results.

These exist as 3R forms, so:
DMULU R4, R5, R7 // R7 = R4 * R5

Originally, there were also multiply ops which multiplied two inputs and
then stored a pair of results in R0 and R1, more like the original
SuperH multiply ops, but I dropped these for various reasons.

There are cases where DMACS or DMACU instructions could be useful:
DMACU R4, R5, R7 // R7 = R4 * R5 + R7

But, I don't currently have these.

Eg (64-bit signed multiply):
SHADQ R4, -32, R6 | SHADQ R5, -32, R7 //1c
DMULS R4, R7, R16 //1c
DMACS R5, R6, R16 //3c (2c penalty)
SHADQ R16, 32, R2 //3c (2c penalty)
DMACU R4, R5, R2 //1c
RTS

Though, while fewer instructions than the current form, the above
construction would still be pretty bad in terms of interlock penalties.

SHADQ R4, -32, R6 | SHADQ R5, -32, R7 //1c
DMULS R5, R6, R16 //1c
DMULS R4, R7, R17 //1c
DMULU R4, R5, R18 //1c
ADD R16, R17, R19 //2c (1c penalty, DMULS R17)
SHADQ R19, 32, R2 //2c (1c penalty, ADD R19)
ADD R18, R2 //1c
RTS

Both cases would have approximately the same clock-cycle count (assuming
both cases have a 3-cycle latency).

( Where recently, I have gotten around to modifying things such that the
multiplier is now fully pipelined... )

Otherwise, my time recently has mostly been being consumed by debugging...

Then tries and seeing if I can get stuff to pass timing at 75MHz again
(hopefully without wrecking stuff quite as bad this time). This
sub-effort also revealed a few bugs (*), though there are still some
bugs I have yet to resolve...

*: Eg, after boosting the core to 75MHz while leaving the MMIO bus at
50MHz, stuff was breaking in simulation due to the L2 Ringbus <->
MMIO-Bus bridge not waiting for the MMIO-Bus to return to a READY state
before returning back to an idle state.

It was then possible for the response to travel the rings and get back
to the L1, which then allows execution to continue, with the CPU core
then issuing another MMIO request, which then travels along the rings
back to the MMIO bridge, in less time than it took for the 'OK -> READY'
transition to happen on the MMIO bus...

The way the bridge was designed, it would then try to initiate a
request, see that the MMIO-Bus state was 'OK', and use whatever result
was present (losing the request or returning garbage).

This may have been happening at 50MHz as well, and could have possibly
been leading to some of the bugs I had seen.

Or such...

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>As for fixed vs. floating point, I guess that is a cross-cutting
>concern. Sure you can argue that, if you spend a lot of time on
>low-level steps such as coding layout, spending some time on range
>analysis is minor change, so fixed point is acceptable.

We forget how flaky and unreliable those early computers were. They
used orders of magnitude more components than the most complex
electronic systems ever had before. The Williams tubes used in the
early 1950s just barely worked and needed endless tuning and fiddling.
Even once they switched to core, tubes burned out, components went out
of spec, solder joints cracked, and uptime was measured in hours if
you were lucky, minutes if you weren't.

So a compelling reason to leave out floating point was that all the extra
logic made the computer even less reliable. It's impressive that they
risked it on the 704.

I have read that the practical limit on the length
of a FORTRAN program on the 704 was set by fact that the compiler
had to compile it in one run between hardware failures.

>What held back floating point for a long time was the slowness and/or
>high cost of FP hardware, but at least in general-purpose computers
>that's a thing of the past.

On small systems, I suppose. Floating point was standard or at least a
widely provided option on large computers by the early 1960s.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 5/9/2021 9:06 PM, John Levine wrote:
> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>> As for fixed vs. floating point, I guess that is a cross-cutting
>> concern. Sure you can argue that, if you spend a lot of time on
>> low-level steps such as coding layout, spending some time on range
>> analysis is minor change, so fixed point is acceptable.
>
> We forget how flaky and unreliable those early computers were. They
> used orders of magnitude more components than the most complex
> electronic systems ever had before. The Williams tubes used in the
> early 1950s just barely worked and needed endless tuning and fiddling.
> Even once they switched to core, tubes burned out, components went out
> of spec, solder joints cracked, and uptime was measured in hours if
> you were lucky, minutes if you weren't.
>
> So a compelling reason to leave out floating point was that all the extra
> logic made the computer even less reliable. It's impressive that they
> risked it on the 704.
>
> I have read that the practical limit on the length
> of a FORTRAN program on the 704 was set by fact that the compiler
> had to compile it in one run between hardware failures.
>
>> What held back floating point for a long time was the slowness and/or
>> high cost of FP hardware, but at least in general-purpose computers
>> that's a thing of the past.
>
> On small systems, I suppose. Floating point was standard or at least a
> widely provided option on large computers by the early 1960s.
>

Leaving out functionality is not the only solution to flaky hardware.
B6500 system 101 had a MTTF of 8 minutes after Jake Vigil dumped a cup
of coffee into mem mod zero. So when system 102 came up, with MTTF of
four hours, all the software team (all 23 of us for a new OS, five
compilers, and all the ancillaries) went over there. Which meant that
you couldn't get any time on it.

So I stayed on 101. And for me, and only me, it would stay up for half
an hour, which was enough to boot and get a compile through. Why me? I
remain convinced that it was because after every successful compile I
would pat the console D&D lights and thank it.

On 5/9/2021 6:08 PM, MitchAlsup wrote:
> On Sunday, May 9, 2021 at 4:34:56 PM UTC-5, BGB wrote:
>> On 5/9/2021 3:59 PM, MitchAlsup wrote:
>
>>> <
>>> How many branches are farther than 1/8 GB away with code compiled
>>> from high level languages ??
>>> <
>> The normal direct branch op in BJX2 has a 20-bit displacement, so can
>> reach +/- 1MB.
>>
>> A Jumbo+LEA can do +/- 2GB, so:
>> LEA.B (PC, Disp33s), R3
>> JMP R3
>>
>> But, this is also possible (+/- 32MB):
>> MOV #Imm25s, R0
>> BRA R0
>>
> My 66000 has 16-bit actual word displacement (18-bit byte address) for
> conditional branches and 26-bit unconditional branches (and calls) (28-bit
> effective range).
>
> But JMP instructions can have 32-bit or 64-bit immediates so you predicate
> over the JMP with an inverted condition for the predicate.

All these cases are 20 bits in my case.

I had a few times considered eliminating the fixed BT/BF instructions in
favor of using the BRA?T and BRA?F encodings instead (semantically
equivalent), but haven't done so yet (partly inertia, partly I don't
like breaking binary compatibility unless there is a good reason).

Though, the main reason to do this would be to reclaim ~ 21 bits of
encoding space...

>>
>> In general, these don't really come up at present because, of my test
>> programs, all of them have < 1MB in the ".text" section.
> <
> In practice, few (<1%) are branches of those dimensions.
> <

In my current tests programs, it currently rests at 0%, since any larger
branches tend to be indirect calls through a function pointer or similar
(*2).

*2: Though, one of these programs is has ~ 1.2 MB of ".text" on an
x86-64 build (for both native Win64 and WSL), and 760K as BJX2 (in speed
optimized mode).

Similarly, it wont effect any local branches unless by some absurd
chance a *single function* were to exceed 1MB in the ".text" section.

Excluding the possibility of excessively large procedurally generated
"switch()" blocks or similar (eg: 10k+ case labels), this is unlikely.

But, these cases don't break the ISA, merely the limits of the existing
branch encodings. I could, in-theory add wider encodings, but then would
need to deal with them in the pipeline (and making this part any wider
would be a big source of timing hassles).

Well, it is either this, or allow a "jumbo branch" encoding where, say:
Can branch pretty much anywhere in the address space;
Completely ignored by the branch predictor;
Takes ~ 11 or so clock cycles to perform said branch...

In this case, the branch would likely be routed through the ALU (as a
64-bit integer ADD), and then the ADD result is used as a branch
destination.

Where, say, the branch instruction is actually decoded as a hacked
64-bit ADD instruction, and then in EX2 or EX3, some logic is like "Hey,
we just added something to PC!" and invokes the register-indirect branch
mechanism using the ADD result.

But, a lot of this would be mostly because, as-is, there is basically no
good way for the existing PC-relative branch mechanisms to handle a
displacement this large...

Though, it would technically be a bit simpler/cheaper to add a special
case to allow for a Jumbo-encoded "BRA (Abs48)" or similar in this case,
which wouldn't require any new logic on the EX side of things (can jump
anywhere... Just requires using base relocs...).

>>>>> Compound addressing within structures;
>>>>> Eg: Accessing an element within an array within a structure.
>>>>> ...
>>>>>
>>>> MRISC32 also has LEA (called "LDEA" - LoaD Effective Address). It
>>>> essentially uses the output from the AGU as the result (bypassing
>>>> the load-from-memory stage), and has a few different use cases.
>>>>
>>> I know one compiler writer that would enunciate "LEA" as 'Lee'-'ah'
>> I always thought of it like "Lee".
> <
> It was funny to hear him say "lee-ah", but he was from Russia so I gave him
> a break.

OK.

I vary between phonetic mappings, and letter-based mappings.

If I try to say things IRL, sometimes there is a slight delay if my mind
isn't sure how to map a mess of letters and numbers over to a spoken
form. As can be noted, I mostly think in visual images and text with
spoken language more as a 2nd class citizen.

Admittedly, this is also partly why my naming conventions tend to be
based more on patterns or visual aesthetic rather than whether or not
things can be easily spoken.

>>>>
>>>> Apart from preloading memory addresses into registers, it can be used
>>>> for simple arithmetic on the form A + B << N (where N is 0, 1, 2 or 3),
>>>> which can be used for implementing x * 3 and x * 5, for instance.
>>>>
>>> Better still is to make integer multiply 3-cycles.
>>>>
>>>> Another very useful use case is to load vector registers with a
>>>> "stride". In vector mode the AGU will generate addresses on the
>>>> form:
>>>>
>>>> (1) addr[k] = Rb + Im * k (Immediate form stride)
>>>> (2) addr[k] = Rb + (Ri << Sc) * k (Register form stride)
>>>> (3) addr[k] = Rb + Vi[k] << Sc (Gather/scatter)
>>>>
>>> Both stride and gather forms fall out "for free" in VVM. {So, I am
>>> agreeing with you that LEA is a valuable instruction.}
>>>>
>>>> Forms (1) and (2) construct addresses with a constant offset
>>>> between each address (I call these "stride based" load/store).
>>> <
>>> Don't forget the stride-0 form in GPUs where every thread wants to
>>> bang on the auto-update memory reference location.
>>>>
>>>> The LDEA instruction can thus be used for loading a series of
>>>> numbers into a vector register, e.g. like this:
>>>>
>>>> LDEA V1, Z, #1 ; V1 = {0, 1, 2, 3, 4, 5, ...}
>>>>
>>>> LDI S1, #7
>>>> LDEA V1, S1, #3 ; V1 = {7, 10, 13, 16, 19, ...}
>>>>
>>>> This is a common operation in vectorized code, and on classic SIMD
>>>> ISA:s you usually load a predefined constant (e.g. from memory) in this
>>>> case.
>>>>
>>>> Since the MRISC32 ISA allows each implementation to define the vector
>>>> register size, using predefined vector constants is not a good solution
>>>> since the vector register size is not known at compile time.
>>>>
>>>> /Marcus

MitchAlsup wrote:
> On Sunday, May 9, 2021 at 1:45:06 PM UTC-5, Stefan Monnier wrote:
>> Stefan Monnier [2021-05-09 14:35:28] wrote:
>>>> Yes that makes sense. Specifically for FP8, the increased dynamic range
>>>> is by far the most important trait. I've even seen examples of using
>>>> 1:5:2 in DNN:s (deep neural networks) where dynamic range is often more
>>>> important than precision.
>>> Indeed 1:5:2 is arguably more useful than 1:4:3.
>> An alternative of course is to use a log-base representation. So your
>> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
>> at all and then you choose your dynamic range by picking the base.
>> Multiplication is easy but addition is takes more effort.
> <
> Really ?!?!?
> Both are implemented with table look ups with concatenated values as the
> address.

Agreed, in a HW implementation you don't even need a full 64K (8+8
bits), since the sign logic can go on in parallel with the table access.

I.e. 14-bit tables for each operation is sufficient, so that is about 14
KB x 4 = 56 KB of rom space?

If you for some really strange reason want to implement programmable
rounding for those 8x8->8 bit operations, then I would fake it with
8-bit (+ sign) outputs from the lookup tables and use the trailing bit
for rounding up/down/even, but having nearest_or_even built in to the
tables seems more reasonable.

OTOH, for AI training it seems like most implementations are using
higher precision accumulators, i.e. FP16 or FP32?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Sunday, May 9, 2021 at 2:53:04 PM UTC-6, MitchAlsup wrote:

> My how lazy we have become ! Even with high quality FP, numerical
> analysis is still mandatory--except that it is seldom performed !?!

Numerical analysis is indeed necessary even when using floating-point,
but of course that doesn't mean that floating point is never really
needed!

John Savard

MitchAlsup wrote:
> On Sunday, May 9, 2021 at 4:34:56 PM UTC-5, BGB wrote:
>> On 5/9/2021 3:59 PM, MitchAlsup wrote:
>>> I know one compiler writer that would enunciate "LEA" as 'Lee'-'ah'
>> I always thought of it like "Lee".
> <
> It was funny to hear him say "lee-ah", but he was from Russia so I gave him
> a break.

That is funny:

'Lea' is an old female name here in Norway (probably from the
Norwegian-language bible), it is always pronounced as two emphasized
syllables, i.e. close to the 'Lee'-'ah' suggestion above.

I never even considered that it could be pronounced any other way!

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Sunday, May 9, 2021 at 5:03:11 PM UTC-6, MitchAlsup wrote:

> IBM 1620 "Can't add, doesn't even try" laid the groundwork where if the
> operands are small enough it becomes cheaper to just read out the correct
> result than to build the logic to calculate the result.

And that reminds me... of the FOCUS Number System.

Where numbers were represented by logarithms, and addition was done by
looking up log((a+b)/a) as a function of log(b/a).

John Savard

On Sunday, May 9, 2021 at 10:06:15 PM UTC-6, John Levine wrote:

> Even once they switched to core, tubes burned out, components went out
> of spec, solder joints cracked, and uptime was measured in hours if
> you were lucky, minutes if you weren't.

> So a compelling reason to leave out floating point was that all the extra
> logic made the computer even less reliable. It's impressive that they
> risked it on the 704.

> I have read that the practical limit on the length
> of a FORTRAN program on the 704 was set by fact that the compiler
> had to compile it in one run between hardware failures.

That may be. But aside from the 704 using core memory, which didn't
have the pattern sensitivity issues of Williams tubes, a lot of effort
went into making it reliable by IBM. One thing was that the tubes
were run at a lower-than-normal voltage, since they were being used
for digital amplification in a computer with thousands of them, instead
of in a radio with five of them.

John Savard

BGB <cr88192@gmail.com> schrieb:

> Similarly, it wont effect any local branches unless by some absurd
> chance a *single function* were to exceed 1MB in the ".text" section.

> Excluding the possibility of excessively large procedurally generated
> "switch()" blocks or similar (eg: 10k+ case labels), this is unlikely.

One way I have encountered this is automatically generated formulas
from computer algebra sytems like Maple.

Look at https://gcc.gnu.org/bugzilla/attachment.cgi?id=41459 for
an example of such code. It isn't easy on compilers (but it does
not have branches).

> But, these cases don't break the ISA, merely the limits of the existing
> branch encodings. I could, in-theory add wider encodings, but then would
> need to deal with them in the pipeline (and making this part any wider
> would be a big source of timing hassles).

Code should be correct as first consideration, fast as a (distant)
second.

I assume you can jump to a register in your ISA, for function
pointers.

If that is the case, you can reverse the test and optionally branch
over an instruction sequence which loads the target address into
a register via loading the PC and adding the offset to it (as
determined by the assembler) and then jumping to that register.

[...]

> Though, it would technically be a bit simpler/cheaper to add a special
> case to allow for a Jumbo-encoded "BRA (Abs48)" or similar in this case,
> which wouldn't require any new logic on the EX side of things (can jump
> anywhere... Just requires using base relocs...).

That sounds even better. You have the long instructions, why not use
them?