MitchAlsup wrote:
> On Saturday, June 12, 2021 at 12:12:07 PM UTC-5, Terje Mathisen wrote:
>> EricP wrote:
>>> Terje Mathisen wrote:
>>>> EricP wrote:
>>>>>
>>>>> So toss out auto inc/dec address modes and put in two instructions
>>>>>
>>>>> // pdp-11 asm has dest reg on the right
>>>>> ADDTY #tiny,reg Add Tiny
>>>>> SUBTY #tiny,reg Subtract Tiny
>>>>>
>>>>> where tiny is 1..7 and 0 means 8. Much more generally useful.
>>>>
>>>> I would rather have 0..7 meaning 1..8, since this is trivially
>>>> achieved by always enabling an incoming carry to the address adder.
>>>> Special-casing 0 to mean 8 seems like it would need more gates?
>>>>
>>>> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
>>>>
>>>> Terje
>>>
>>> 1..7, 0 => 8 allows the 3 lower bits to be used directly
>>> and a 3-input NOR-3 gate to drive the 4th bit.
>>>
>>> 0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
>>> an AND-2 and an AND-3 carry lookaheads.
>>>
>>> Its in the decoder and there are other more expensive things there,
>>> so it wouldn't be on the critical path either way.
> <
>> The logic is simple either way, but since we're already going to use the
>> (address) adder, just setting carry_in is effectively free.
> <
> What makes you think the AGEN adder has a carry in ??

I realize that it doesn't need one: The bottom bit can be handled with a
half adder which I'm guessing is at least one gate delay faster, and
that can negate any gain from not having to generate cnt3?

OTOH, if this is dedicated circuit, then it would know to always add the
carry-in, so the bottom half adder would just be slightly different:

s0 = a == b
carry_out = a | b;

Right?

Terje

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

On 6/13/2021 1:03 PM, Terje Mathisen wrote:
> Ivan Godard wrote:
>> On 6/11/2021 11:42 AM, MitchAlsup wrote:
>>> On Friday, June 11, 2021 at 1:28:30 PM UTC-5, Quadibloc wrote:
>>>> On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:
>>>>
>>>>> Opinions may vary, but if you were an assembler programmer back in the
>>>>> days when memory was tight and machines were slow, the fact that
>>>>> condition codes are set with many instructions, was of great
>>>>> benefit.
>>>> Oh, I agree that condition codes are a good thing. I'm not too
>>>> sympathetic
>>>> to architectures like the Alpha and RISC-V which completely dispense
>>>> with
>>>> them.
>>>>
>>>> However, if _every_ operate instruction changes the condition codes,
>>>> you
>>>> have to put the conditional branch right after the operate
>>>> instruction that
>>>> affects it. This creates a dependency, and for branches especially
>>>> that's a
>>>> bad thing.
>>> <
>>> In the days condition codes made sense, the machines were using 4-10
>>> cycles
>>> per instruction, so putting the BC immediately after the Operate
>>> instruction
>>> was dé rigueur.
>>> <
>>> One of the things we learned in the early RISC days was this one
>>> either wanted
>>> no condition codes, or to use a bit to say when the condition codes
>>> were going
>>> to be used--in effect CC write elision. Using that bit is bad for
>>> entropy.
>>>>
>>>> So, the way many RISC instruction sets have done it (the PowerPC taking
>>>> it to a more elaborate level) in a high-performance instruction set,
>>>> I include
>>>> a bit to enable or disable setting the condition codes in
>>>> instructions that can
>>>> set them.
>>>>
>>>> That loses a bit of opcode space, but it doesn't lose the advantages
>>>> you
>>>> mention.
>>> <
>>> I still fail to see where cc gain anything (with proper branch
>>> support), plus
>>> I see many places where a vector of comparand bits is better than a CC
>>> from a CMP instruction (especially with the requirements of IEEE 754).
>>
>> How often is more than one bit subsequently selected from that bit
>> vector? -
>
> Enough?
>
> I.e. branch if a >= b, but only if neither is a nan?
>
> I.e. any kind of compound check.
>
> Terje

And that's the question. True, there could be bits for </=/> and you do
a compound for <= and >=, but that seems pointless to me; you should
have a negate flag (branch direction) in the instruction instead of
compounding. Otherwise, how often are compound checks of real operands
in real code? Yes, FP folding a NaN check is a reasonable use - but how
often is NaN checked for in real code regardless of how you do it?

So if compounds are ignorably rare then the bit vector is just an
encoding idea and should be measured on code density.

Quadibloc <jsavard@ecn.ab.ca> writes:
>In a general register architecture, though, if you lengthen
>all the general registers by one bit, now they're not conformant
>with memory. So load and store multiple don't work well for
>saving state unless they're made wasteful of memory, and
>quite a bit else gets made... inaesthetic at least.

Yes, for saving context on a context switch, you have to preserve the
extra bits somehow, and I explored this in
<2021Mar14.152525@mips.complang.tuwien.ac.at>.

For function calls, I don't think it's worth preserving the carry bits
across them, so just store 64 (not 64) bits, and then load 64 bits
with a load instruction that, e.g., zeros the carry.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Sunday, June 13, 2021 at 1:52:45 PM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Friday, June 11, 2021 at 10:08:38 AM UTC-5, EricP wrote:
> >> More expensive ALU serially dependent on decode means longer Decode stage.
> >> Now since no one would do this to Decode, you wind up doing this
> >> in the real ALU which is at least 2 pipeline stages further on.
> > <
> > {Quote :: Spock from "Wrath of Kahan", 'Captain, he is thinking 2-dimensionally'}
>
> I'm pretty sure you were thinking of the "Wrath of Kahn", but I'm sure
> Kahan could also be quite cross if you mess up your FP unit badly?
<
Finally, someone understood the terminology !! Well done sir !
<
> :-)
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Sunday, June 13, 2021 at 3:33:45 PM UTC-5, Ivan Godard wrote:
> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
> > Ivan Godard wrote:

> > I.e. any kind of compound check.
> >
> > Terje
<
> And that's the question. True, there could be bits for </=/> and you do
> a compound for <= and >=, but that seems pointless to me; you should
> have a negate flag (branch direction) in the instruction instead of
> compounding. Otherwise, how often are compound checks of real operands
> in real code? Yes, FP folding a NaN check is a reasonable use - but how
> often is NaN checked for in real code regardless of how you do it?
<
Well Written FP codes do it all the time::
<
double ATAN2( double y, double x )
{ // IEEE 754-2019 quality ATAN2
// deal with NANs
if( ISNAN( x ) ) return x;
if( ISNAN( y ) ) return y;
// deal with infinities
if( x == +∞ && |y|== +∞ ) return copysign( π/4, y );
if( x == +∞ ) return copysign( 0.0, y );
if( x == -∞ && |y|== +∞ ) return copysign( 3π/4, y );
if( x == -∞ ) return copysign( π, y );
if( |y|== +∞ ) return copysign( π/2, y );
// deal with signed zeros
if( x == 0.0 && y != 0.0 ) return copysign( π/2, y );
if( x >=+0.0 && y == 0.0 ) return copysign( 0.0, y );
if( x <=-0.0 && y == 0.0 ) return copysign( π, y );
// calculate ATAN2 high performance style
if( x > 0.0 )
{
if( y < 0.0 && |y| < |x| ) return - π/2 - ATAN( x / y );
if( y < 0.0 && |y| > |x| ) return + ATAN( y / x );
if( y > 0.0 && |y| < |x| ) return + ATAN( y / x );
if( y > 0.0 && |y| > |x| ) return + π/2 - ATAN( x / y );
}
if( x < 0.0 )
{
if( y < 0.0 && |y| > |x| ) return + π/2 + ATAN( x / y );
if( y < 0.0 && |y| > |x| ) return + π - ATAN( y / x );
if( y > 0.0 && |y| < |x| ) return + π - ATAN( y / x );
if( y > 0.0 && |y| > |x| ) return +3π/2 + ATAN( x / y );
}
<
Not so well written FP codes are (well) no so well written.
<
Also note: only 1 compare is required to perform all of the above checks
in My 66000 ISA.
>
> So if compounds are ignorably rare then the bit vector is just an
> encoding idea and should be measured on code density.

Terje Mathisen wrote:
> MitchAlsup wrote:
>> On Saturday, June 12, 2021 at 12:12:07 PM UTC-5, Terje Mathisen wrote:
>>> EricP wrote:
>>>> Terje Mathisen wrote:
>>>>> EricP wrote:
>>>>>>
>>>>>> So toss out auto inc/dec address modes and put in two instructions
>>>>>>
>>>>>> // pdp-11 asm has dest reg on the right
>>>>>> ADDTY #tiny,reg Add Tiny
>>>>>> SUBTY #tiny,reg Subtract Tiny
>>>>>>
>>>>>> where tiny is 1..7 and 0 means 8. Much more generally useful.
>>>>>
>>>>> I would rather have 0..7 meaning 1..8, since this is trivially
>>>>> achieved by always enabling an incoming carry to the address adder.
>>>>> Special-casing 0 to mean 8 seems like it would need more gates?
>>>>>
>>>>> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
>>>>>
>>>>> Terje
>>>>
>>>> 1..7, 0 => 8 allows the 3 lower bits to be used directly
>>>> and a 3-input NOR-3 gate to drive the 4th bit.
>>>>
>>>> 0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
>>>> an AND-2 and an AND-3 carry lookaheads.
>>>>
>>>> Its in the decoder and there are other more expensive things there,
>>>> so it wouldn't be on the critical path either way.
>> <
>>> The logic is simple either way, but since we're already going to use the
>>> (address) adder, just setting carry_in is effectively free.
>> <
>> What makes you think the AGEN adder has a carry in ??
>
> I realize that it doesn't need one: The bottom bit can be handled with a
> half adder which I'm guessing is at least one gate delay faster, and
> that can negate any gain from not having to generate cnt3?
>
> OTOH, if this is dedicated circuit, then it would know to always add the
> carry-in, so the bottom half adder would just be slightly different:
>
> s0 = a == b
> carry_out = a | b;
>
> Right?
>
> Terje
>

what I was talking about was the encoding of a field in the instruction
which would always be set by the assembler/compiler so there is no reason
for it not to be encoded as simply as possible for the hardware.

For a N-bit field, an N-input NOR gate, which 1..7, 0 => 8 needs,
will always be cheaper than an N-bit incrementer.

That being said, there is lots of opportunity to optimize an incrementer
up the wazoo. It should use parallel carry lookahead (a 4 input NAND tree)
so it approximates log_4(N) delay, give or take a few gates.

In this case we are talking about 3 bits so its no big deal.
But in the fetch-parse units there could be some 52 bit incrementers.
I dont know, maybe an FP rounder might want to increment long bit strings.

An optimized incrementer could be organized into groups of 4 bits.
A 4 input NAND would generate the groups (inverted) carry out.
At the next level a 4 input NOR would generate carry for 16 bits.
Next a 4 input NAND generates (inverted) group carry for 64 bits.
The carry outs could drive MUX's to select raw or incremented values.

On Sunday, June 13, 2021 at 5:52:08 PM UTC-5, EricP wrote:
> Terje Mathisen wrote:
> > MitchAlsup wrote:
> >> On Saturday, June 12, 2021 at 12:12:07 PM UTC-5, Terje Mathisen wrote:
> >>> EricP wrote:
> >>>> Terje Mathisen wrote:
> >>>>> EricP wrote:
> >>>>>>
> >>>>>> So toss out auto inc/dec address modes and put in two instructions
> >>>>>>
> >>>>>> // pdp-11 asm has dest reg on the right
> >>>>>> ADDTY #tiny,reg Add Tiny
> >>>>>> SUBTY #tiny,reg Subtract Tiny
> >>>>>>
> >>>>>> where tiny is 1..7 and 0 means 8. Much more generally useful.
> >>>>>
> >>>>> I would rather have 0..7 meaning 1..8, since this is trivially
> >>>>> achieved by always enabling an incoming carry to the address adder.
> >>>>> Special-casing 0 to mean 8 seems like it would need more gates?
> >>>>>
> >>>>> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
> >>>>>
> >>>>> Terje
> >>>>
> >>>> 1..7, 0 => 8 allows the 3 lower bits to be used directly
> >>>> and a 3-input NOR-3 gate to drive the 4th bit.
> >>>>
> >>>> 0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
> >>>> an AND-2 and an AND-3 carry lookaheads.
> >>>>
> >>>> Its in the decoder and there are other more expensive things there,
> >>>> so it wouldn't be on the critical path either way.
> >> <
> >>> The logic is simple either way, but since we're already going to use the
> >>> (address) adder, just setting carry_in is effectively free.
> >> <
> >> What makes you think the AGEN adder has a carry in ??
> >
> > I realize that it doesn't need one: The bottom bit can be handled with a
> > half adder which I'm guessing is at least one gate delay faster, and
> > that can negate any gain from not having to generate cnt3?
> >
> > OTOH, if this is dedicated circuit, then it would know to always add the
> > carry-in, so the bottom half adder would just be slightly different:
> >
> > s0 = a == b
> > carry_out = a | b;
> >
> > Right?
> >
> > Terje
> >
> what I was talking about was the encoding of a field in the instruction
> which would always be set by the assembler/compiler so there is no reason
> for it not to be encoded as simply as possible for the hardware.
<
For what follows I an using the term "decoder" a a block of logic that asserts
on of 2^n output signals in response to n bit input signal. {There are lots of
other kinds of decoders (greater than, less than) but this one is also known
as the equality decoder.
<
One can simply build the decoder of range(0..7) to assert on domain(1..8)
at zero cost. {we have not had this one in the discussion yet, but it needs
to be}
<
The lesser cost is the AND gate which converts 000 into 1000. Then the
lower 3 bits go into a decoder to assert one of 1..7 the AND gate asserting
8. (the zero output of the decoder is not used and if the synthesizer is any
good, the great gate muncher will remove that logic.}
<
The high cost is to increment the 3-bit field and then run it into a decoder.
>
> For a N-bit field, an N-input NOR gate, which 1..7, 0 => 8 needs,
> will always be cheaper than an N-bit incrementer.
>
> That being said, there is lots of opportunity to optimize an incrementer
> up the wazoo. It should use parallel carry lookahead (a 4 input NAND tree)
> so it approximates log_4(N) delay, give or take a few gates.
>
> In this case we are talking about 3 bits so its no big deal.
> But in the fetch-parse units there could be some 52 bit incrementers.
> I dont know, maybe an FP rounder might want to increment long bit strings.
>
> An optimized incrementer could be organized into groups of 4 bits.
> A 4 input NAND would generate the groups (inverted) carry out.
> At the next level a 4 input NOR would generate carry for 16 bits.
> Next a 4 input NAND generates (inverted) group carry for 64 bits.
> The carry outs could drive MUX's to select raw or incremented values.

On 6/13/2021 1:33 PM, Ivan Godard wrote:
> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
>> Ivan Godard wrote:
>>> On 6/11/2021 11:42 AM, MitchAlsup wrote:
>>>> On Friday, June 11, 2021 at 1:28:30 PM UTC-5, Quadibloc wrote:
>>>>> On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:
>>>>>
>>>>>> Opinions may vary, but if you were an assembler programmer back in
>>>>>> the
>>>>>> days when memory was tight and machines were slow, the fact that
>>>>>> condition codes are set with many instructions, was of great
>>>>>> benefit.
>>>>> Oh, I agree that condition codes are a good thing. I'm not too
>>>>> sympathetic
>>>>> to architectures like the Alpha and RISC-V which completely
>>>>> dispense with
>>>>> them.
>>>>>
>>>>> However, if _every_ operate instruction changes the condition
>>>>> codes, you
>>>>> have to put the conditional branch right after the operate
>>>>> instruction that
>>>>> affects it. This creates a dependency, and for branches especially
>>>>> that's a
>>>>> bad thing.
>>>> <
>>>> In the days condition codes made sense, the machines were using 4-10
>>>> cycles
>>>> per instruction, so putting the BC immediately after the Operate
>>>> instruction
>>>> was dé rigueur.
>>>> <
>>>> One of the things we learned in the early RISC days was this one
>>>> either wanted
>>>> no condition codes, or to use a bit to say when the condition codes
>>>> were going
>>>> to be used--in effect CC write elision. Using that bit is bad for
>>>> entropy.
>>>>>
>>>>> So, the way many RISC instruction sets have done it (the PowerPC
>>>>> taking
>>>>> it to a more elaborate level) in a high-performance instruction
>>>>> set, I include
>>>>> a bit to enable or disable setting the condition codes in
>>>>> instructions that can
>>>>> set them.
>>>>>
>>>>> That loses a bit of opcode space, but it doesn't lose the
>>>>> advantages you
>>>>> mention.
>>>> <
>>>> I still fail to see where cc gain anything (with proper branch
>>>> support), plus
>>>> I see many places where a vector of comparand bits is better than a CC
>>>> from a CMP instruction (especially with the requirements of IEEE 754).
>>>
>>> How often is more than one bit subsequently selected from that bit
>>> vector? -
>>
>> Enough?
>>
>> I.e. branch if a >= b, but only if neither is a nan?
>>
>> I.e. any kind of compound check.
>>
>> Terje
>
> And that's the question. True, there could be bits for </=/> and you do
> a compound for <= and >=, but that seems pointless to me; you should
> have a negate flag (branch direction) in the instruction instead of
> compounding. Otherwise, how often are compound checks of real operands
> in real code? Yes, FP folding a NaN check is a reasonable use - but how
> often is NaN checked for in real code regardless of how you do it?
>
> So if compounds are ignorably rare then the bit vector is just an
> encoding idea and should be measured on code density.

One other point. Mitch's scheme does all those checks with a single op
code for the compare and one (or two if you include the predication) for
for the conditional branch/predicate. So depending upon how the
alternative handles things, you might require fewer op codes. How much
that is worth is, of course, dependent on lots of other factors.

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

MitchAlsup wrote:
> On Saturday, June 12, 2021 at 2:23:09 PM UTC-5, EricP wrote:
>> That removes the IP from the register set and moves all the above mode
>> specifier bits into the opcode, where they can be optimally assigned.
> <
> I am currently playing with the notion where there is a small register file
> (8 entries) which is really fast, and a larger register file (64-256 entries)
> which is 1 cycle access, and then memory which is 3-4 cycles of access
> and supports sizes other than 64-bits. {The first 8 entries of the large
> file is the small 8 register file.}

So, this is a NURA (Non-Uniform Register Access) machine?

I am sure the compiler writes would love it. :-)

(Personally I would be perfectly happy, 8 effective registers are enough
for almost all the inner loop code I have ever written.)

Terje

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

MitchAlsup wrote:
> On Saturday, June 12, 2021 at 7:38:05 PM UTC-5, Quadibloc wrote:
>> On Saturday, June 12, 2021 at 2:50:38 PM UTC-6, MitchAlsup wrote:
>>> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
>>>> MitchAlsup wrote:
>>
>>>>> cnt3 is 1-gate delay.
>>>>> carry-in is 4-gate delays.
>>
>>>> Wow!
>>
>>>> So you are saying that simply forcing carry-in takes 4 extra gate
>>>> delays, on top of routing the three address bits, and also merging them
>>>> with the generated cnt3 bit?
>>
>>> Yes, it is sad that SW people see AND and ADD as the same latency.
>> Just in case there's a misunderstanding here:
>>
>> Setting the "carry-in" signal line to HIGH does not take more than one
>> gate delay.
> <
> With a 3 (or 4)-bit adder the carry in does not change the 4-gates of delay.

Since the 3-bit immediate ("tiny") value was to be added to a 64-bit
register anyway, I guessed that the cost of decrementing the immediate
in the encoding and instead using carry-in to adjust for it at runtime,
could be a win.

Terje

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

On 6/13/2021 6:29 PM, Stephen Fuld wrote:
> On 6/13/2021 1:33 PM, Ivan Godard wrote:
>> On 6/13/2021 1:03 PM, Terje Mathisen wrote:

>> And that's the question. True, there could be bits for </=/> and you
>> do a compound for <= and >=, but that seems pointless to me; you
>> should have a negate flag (branch direction) in the instruction
>> instead of compounding. Otherwise, how often are compound checks of
>> real operands in real code? Yes, FP folding a NaN check is a
>> reasonable use - but how often is NaN checked for in real code
>> regardless of how you do it?
>>
>> So if compounds are ignorably rare then the bit vector is just an
>> encoding idea and should be measured on code density.
>
> One other point.  Mitch's scheme does all those checks with a single op
> code for the compare and one (or two if you include the predication) for
> for the conditional branch/predicate.  So depending upon how the
> alternative handles things, you might require fewer op codes.  How much
> that is worth is, of course, dependent on lots of other factors.
>
>

Yes; it shifts entropy from opcode to bit selector. But it doesn't
reduce the total entropy.

On Sunday, June 13, 2021 at 11:55:42 PM UTC-6, Terje Mathisen wrote:

> So, this is a NURA (Non-Uniform Register Access) machine?

> I am sure the compiler writes would love it. :-)

Uh, oh. This is also where I'm going with Concertina II.

The original Concertina had banks of 8 registers, with a separate
bank of 8 base registers. But there was also a 64-register scratchpad.

Concertina II has banks of 32 registers, to be 'as good as' RISC. But
since Concertina II aims to be 'efficient', some VLIW goodness has been
thrown in, so that theoretically one _might_ be able to get half-decent
performance even out of an implementation that didn't have full OoO.

Not that I _really_ recommend that, but I'm still trying to make it at least
halfway feasible.

The 32 registers already have some strangeness in their organization.

The 16-bit operate instructions, in order to fit in 16 bits, divide those 32
registers into four groups of 8, and the source and destination registers
in such a 16-bit instruction must be from the same group.

And to some extent, the groups have different functions, at least for the
integer registers.

Most instructions which specify an index register can only use registers
1-7 as index registers. A different set of eight registers is used as base
registers.

You can choose between addressing modes with different sizes of
displacement. For each displacement size, a different bank of eight
registers is used for base registers. One reason for this is that if you
reserve, say, 65,536 bytes of memory, and have a pointer to that area,
an addressing mode that only accesses the first 4,096 bytes of it is
really not all that useful.

But it also needs to be noted that it is intended that most of the
integer registers are to be used for integer arithmetic calculations;
so in general, it's expected a program will pick one of those
addressing modes, and stick with it. Possibly with occasional forays
into some other mode, only using one base register for it, because some
needed instruction isn't available in the desired mode.

But I mentioned VLIW.

If the 32 registers in a bank are divided into four groups of eight, this fits
in with programs that are doing several separate calculations at once.
That way, one instruction from each of those calculations can
be put in a group of instructions that, being independent, can
all be executed in parallel.

For that style of programming, though, 32 registers might not be
enough, so I've recently added auxilliary banks of 128 registers.

John Savard

Thomas Koenig wrote:
> James Harris <james.harris.1@gmail.com> schrieb:
>> On 12/06/2021 21:50, MitchAlsup wrote:
>>> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
>>
>> ...
>>
>>>> So you are saying that simply forcing carry-in takes 4 extra gate
>>>> delays, on top of routing the three address bits, and also merging them
>>>> with the generated cnt3 bit?
>>> <
>>> Yes, it is sad that SW people see AND and ADD as the same latency.
>>
>> As what you might call a software person I don't see AND and ADD as
>> needing the same latency and I find it a bit irksome when CPUs require
>> the same time (1 cycle) for each -
>
> You would need an elastic pipeline for this; in this case, you could
> also make your additions somewhat faster in the case where you
> do not need to propagate carries very far (or your multipliers if
> you are, for example, multiplying two 8-bit numbers with a 64-bit
> multiplier).
>
> There are papers on this, but no major architecture has done this to
> date (unless I have missed something, which may well be the case).

These sort of elastic pipelines are pretty much incompatible with
crypto: You need a way to make sure your algorithms will run in constant
time, with zero dependency on the actual keys being used.

I.e. even the classic early-out multipliers would have made it
impossible for me to write a version of DFC (an AES candiate) which was
constant time and less than 10% slower than the maximum-speed
implementation.

Terje

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

MitchAlsup wrote:
> On Sunday, June 13, 2021 at 3:33:45 PM UTC-5, Ivan Godard wrote:
>> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
>>> Ivan Godard wrote:
>
>>> I.e. any kind of compound check.
>>>
>>> Terje
> <
>> And that's the question. True, there could be bits for </=/> and you do
>> a compound for <= and >=, but that seems pointless to me; you should
>> have a negate flag (branch direction) in the instruction instead of
>> compounding. Otherwise, how often are compound checks of real operands
>> in real code? Yes, FP folding a NaN check is a reasonable use - but how
>> often is NaN checked for in real code regardless of how you do it?
> <
> Well Written FP codes do it all the time::
> <
> double ATAN2( double y, double x )
> { // IEEE 754-2019 quality ATAN2
> // deal with NANs
> if( ISNAN( x ) ) return x;
> if( ISNAN( y ) ) return y;
> // deal with infinities
> if( x == +∞ && |y|== +∞ ) return copysign( π/4, y );
> if( x == +∞ ) return copysign( 0.0, y );
> if( x == -∞ && |y|== +∞ ) return copysign( 3π/4, y );
> if( x == -∞ ) return copysign( π, y );
> if( |y|== +∞ ) return copysign( π/2, y );
> // deal with signed zeros
> if( x == 0.0 && y != 0.0 ) return copysign( π/2, y );
> if( x >=+0.0 && y == 0.0 ) return copysign( 0.0, y );
> if( x <=-0.0 && y == 0.0 ) return copysign( π, y );
> // calculate ATAN2 high performance style
> if( x > 0.0 )
> {
> if( y < 0.0 && |y| < |x| ) return - π/2 - ATAN( x / y );
> if( y < 0.0 && |y| > |x| ) return + ATAN( y / x );
> if( y > 0.0 && |y| < |x| ) return + ATAN( y / x );
> if( y > 0.0 && |y| > |x| ) return + π/2 - ATAN( x / y );
> }
> if( x < 0.0 )
> {
> if( y < 0.0 && |y| > |x| ) return + π/2 + ATAN( x / y );
> if( y < 0.0 && |y| > |x| ) return + π - ATAN( y / x );
> if( y > 0.0 && |y| < |x| ) return + π - ATAN( y / x );
> if( y > 0.0 && |y| > |x| ) return +3π/2 + ATAN( x / y );
> }
> <
> Not so well written FP codes are (well) no so well written.
> <
> Also note: only 1 compare is required to perform all of the above checks
> in My 66000 ISA.

In the Mill code I've written for FP emulation, I try to short-circuit
as many of these tests as possible, so I typically try to isolate
zero(/sub-normal)/inf/nan like this:

if (exponent-1 >= 2046) // double input, unsigned exp field

or I can take the entire 64-bit double as uint64_t:

if ((ix+ix-1) >= (0xfe00000000000000-1) // Must be Zero/Inf/NaN!

I.e. shift up to get rid of sign, decrement (so zero wraps around) and
compare against Inf+Inf-1 bit pattern.

On a machine with LEA this becomes

lea rax,[rax+rax-1]
cmp rax,0xfdffffffffffffff
jae special_input

Terje

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

On 13/06/2021 19:02, MitchAlsup wrote:
> On Sunday, June 13, 2021 at 6:02:00 AM UTC-5, James Harris wrote:
>> On 13/06/2021 01:26, Quadibloc wrote:
>>> On Saturday, June 12, 2021 at 11:21:29 AM UTC-6, Ivan Godard wrote:
>>>> On 6/12/2021 8:25 AM, Quadibloc wrote:
>>>
>>>>> It has occured to me that to achieve - without the baggage that the PowerPC took
>>>>> on - complete immunity to condition codes restricting what the compiler can do,
>>>>> there is a missing class of instructions that I need to add to my architecture.
>>>
>>>>> In addition to condition-code based conditional jump instructions... I need jump
>>>>> instructions that use those flag bits originally envisaged as only for instruction
>>>>> predication. (Of course, I _could_ predicate a jump instruction, but if I can avoid
>>>>> the cost and awkwardness of choosing a block header just for that...)

....

> There are 10 ways to interpret an integer-integer compare-

A bit puzzled, here. By "10 ways" I take it you mean things like signed
and unsigned less-than, less-or-equal, etc but checking my favourite list,

http://www.scs.stanford.edu/05au-cs240c/lab/i386/appd.htm

it looks as though there are 14 meaningful comparisons, altogether.

>
> -even if you
> cast out ½ of them you can't encode 5-states in 2-bits--so you have to
> have signed and unsigned compare instructions.

Yes, I was thinking that having signed and unsigned opcodes might allow
there to be just 1 status bit, using it for overflow (regarding Carry as
unsigned overflow) but I've not checked through the details.

Speaking of 2 bits, though, there's IBM's very clever 2-bit condition
code which is not two flags but an encoding of the numbers 0 to 3 with
each such number having a meaning. I last used that system decades ago
and cannot remember the details but I recall it working very well. If
nothing else it shows that the 4-bit NZCV is not the only way.

--
James Harris

On 6/14/2021 1:12 AM, Terje Mathisen wrote:
> Thomas Koenig wrote:
>> James Harris <james.harris.1@gmail.com> schrieb:
>>> On 12/06/2021 21:50, MitchAlsup wrote:
>>>> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
>>>
>>> ...
>>>
>>>>> So you are saying that simply forcing carry-in takes 4 extra gate
>>>>> delays, on top of routing the three address bits, and also merging
>>>>> them
>>>>> with the generated cnt3 bit?
>>>> <
>>>> Yes, it is sad that SW people see AND and ADD as the same latency.
>>>
>>> As what you might call a software person I don't see AND and ADD as
>>> needing the same latency and I find it a bit irksome when CPUs require
>>> the same time (1 cycle) for each -
>>
>> You would need an elastic pipeline for this; in this case, you could
>> also make your additions somewhat faster in the case where you
>> do not need to propagate carries very far (or your multipliers if
>> you are, for example, multiplying two 8-bit numbers with a 64-bit
>> multiplier).
>>
>> There are papers on this, but no major architecture has done this to
>> date (unless I have missed something, which may well be the case).
>
> These sort of elastic pipelines are pretty much incompatible with
> crypto: You need a way to make sure your algorithms will run in constant
> time, with zero dependency on the actual keys being used.
>
> I.e. even the classic early-out multipliers would have made it
> impossible for me to write a version of DFC (an AES candiate) which was
> constant time and less than 10% slower than the maximum-speed
> implementation.
>
> Terje
>

Yes. Among the early complaints about static scheduling is that it
precludes any gain from early-out. Slowly, very slowly, the field is
realizing that you don't want early-out anyway.

MitchAlsup wrote:
> On Sunday, June 13, 2021 at 3:33:45 PM UTC-5, Ivan Godard wrote:
>> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
>>> Ivan Godard wrote:
>
>>> I.e. any kind of compound check.
>>>
>>> Terje
> <
>> And that's the question. True, there could be bits for </=/> and you do
>> a compound for <= and >=, but that seems pointless to me; you should
>> have a negate flag (branch direction) in the instruction instead of
>> compounding. Otherwise, how often are compound checks of real operands
>> in real code? Yes, FP folding a NaN check is a reasonable use - but how
>> often is NaN checked for in real code regardless of how you do it?
> <
> Well Written FP codes do it all the time::
> <
> double ATAN2( double y, double x )
> { // IEEE 754-2019 quality ATAN2
> // deal with NANs
> if( ISNAN( x ) ) return x;
> if( ISNAN( y ) ) return y;
> // deal with infinities
> if( x == +∞ && |y|== +∞ ) return copysign( π/4, y );
> if( x == +∞ ) return copysign( 0.0, y );
> if( x == -∞ && |y|== +∞ ) return copysign( 3π/4, y );
> if( x == -∞ ) return copysign( π, y );
> if( |y|== +∞ ) return copysign( π/2, y );
> // deal with signed zeros
> if( x == 0.0 && y != 0.0 ) return copysign( π/2, y );
> if( x >=+0.0 && y == 0.0 ) return copysign( 0.0, y );
> if( x <=-0.0 && y == 0.0 ) return copysign( π, y );
> // calculate ATAN2 high performance style
> if( x > 0.0 )
> {
> if( y < 0.0 && |y| < |x| ) return - π/2 - ATAN( x / y );
> if( y < 0.0 && |y| > |x| ) return + ATAN( y / x );
> if( y > 0.0 && |y| < |x| ) return + ATAN( y / x );
> if( y > 0.0 && |y| > |x| ) return + π/2 - ATAN( x / y );
> }
> if( x < 0.0 )
> {
> if( y < 0.0 && |y| > |x| ) return + π/2 + ATAN( x / y );
> if( y < 0.0 && |y| > |x| ) return + π - ATAN( y / x );
> if( y > 0.0 && |y| < |x| ) return + π - ATAN( y / x );
> if( y > 0.0 && |y| > |x| ) return +3π/2 + ATAN( x / y );
> }
> <
> Not so well written FP codes are (well) no so well written.
> <
> Also note: only 1 compare is required to perform all of the above checks
> in My 66000 ISA.
>> So if compounds are ignorably rare then the bit vector is just an
>> encoding idea and should be measured on code density.

How many bits is the cmp bit vector?
I would imagine the above IF construct shows up in a lot of FP code.
Can you use your cmp bit vector as an index to a switch instruction,
or would it bloat too much?

Or maybe a two switches, filter out all NAN's and INF's first,
then deal with all the number variations.

On Monday, June 14, 2021 at 12:55:42 AM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Saturday, June 12, 2021 at 2:23:09 PM UTC-5, EricP wrote:
> >> That removes the IP from the register set and moves all the above mode
> >> specifier bits into the opcode, where they can be optimally assigned.
> > <
> > I am currently playing with the notion where there is a small register file
> > (8 entries) which is really fast, and a larger register file (64-256 entries)
> > which is 1 cycle access, and then memory which is 3-4 cycles of access
> > and supports sizes other than 64-bits. {The first 8 entries of the large
> > file is the small 8 register file.}
>
> So, this is a NURA (Non-Uniform Register Access) machine?
>
> I am sure the compiler writes would love it. :-)
>
> (Personally I would be perfectly happy, 8 effective registers are enough
> for almost all the inner loop code I have ever written.)
<
2 of the Livermore loops require 6 base registers.
And then there is that IP and SP are part of the register file.
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Monday, June 14, 2021 at 6:21:10 AM UTC-5, James Harris wrote:
> On 13/06/2021 19:02, MitchAlsup wrote:
> > On Sunday, June 13, 2021 at 6:02:00 AM UTC-5, James Harris wrote:
> >> On 13/06/2021 01:26, Quadibloc wrote:
> >>> On Saturday, June 12, 2021 at 11:21:29 AM UTC-6, Ivan Godard wrote:
> >>>> On 6/12/2021 8:25 AM, Quadibloc wrote:
> >>>
> >>>>> It has occured to me that to achieve - without the baggage that the PowerPC took
> >>>>> on - complete immunity to condition codes restricting what the compiler can do,
> >>>>> there is a missing class of instructions that I need to add to my architecture.
> >>>
> >>>>> In addition to condition-code based conditional jump instructions.... I need jump
> >>>>> instructions that use those flag bits originally envisaged as only for instruction
> >>>>> predication. (Of course, I _could_ predicate a jump instruction, but if I can avoid
> >>>>> the cost and awkwardness of choosing a block header just for that....)
> ...
> > There are 10 ways to interpret an integer-integer compare-
> A bit puzzled, here. By "10 ways" I take it you mean things like signed
> and unsigned less-than, less-or-equal, etc but checking my favourite list,
>
> http://www.scs.stanford.edu/05au-cs240c/lab/i386/appd.htm
>
> it looks as though there are 14 meaningful comparisons, altogether.
<
If you keep track of overflow and carry:: but my CMP instruction does not
create those.
<
> >
> > -even if you
> > cast out ½ of them you can't encode 5-states in 2-bits--so you have to
> > have signed and unsigned compare instructions.
<
> Yes, I was thinking that having signed and unsigned opcodes might allow
> there to be just 1 status bit, using it for overflow (regarding Carry as
> unsigned overflow) but I've not checked through the details.
<
You should consider carry to be "significance" overflow.
>
> Speaking of 2 bits, though, there's IBM's very clever 2-bit condition
> code which is not two flags but an encoding of the numbers 0 to 3 with
> each such number having a meaning. I last used that system decades ago
> and cannot remember the details but I recall it working very well. If
> nothing else it shows that the 4-bit NZCV is not the only way.
>
>
> --
> James Harris

On Monday, June 14, 2021 at 7:31:37 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Sunday, June 13, 2021 at 3:33:45 PM UTC-5, Ivan Godard wrote:
> >> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
> >>> Ivan Godard wrote:
> >
> >>> I.e. any kind of compound check.
> >>>
> >>> Terje
> > <
> >> And that's the question. True, there could be bits for </=/> and you do
> >> a compound for <= and >=, but that seems pointless to me; you should
> >> have a negate flag (branch direction) in the instruction instead of
> >> compounding. Otherwise, how often are compound checks of real operands
> >> in real code? Yes, FP folding a NaN check is a reasonable use - but how
> >> often is NaN checked for in real code regardless of how you do it?
> > <
> > Well Written FP codes do it all the time::
> > <
> > double ATAN2( double y, double x )
> > { // IEEE 754-2019 quality ATAN2
> > // deal with NANs
> > if( ISNAN( x ) ) return x;
> > if( ISNAN( y ) ) return y;
> > // deal with infinities
> > if( x == +∞ && |y|== +∞ ) return copysign( π/4, y );
> > if( x == +∞ ) return copysign( 0.0, y );
> > if( x == -∞ && |y|== +∞ ) return copysign( 3π/4, y );
> > if( x == -∞ ) return copysign( π, y );
> > if( |y|== +∞ ) return copysign( π/2, y );
> > // deal with signed zeros
> > if( x == 0.0 && y != 0.0 ) return copysign( π/2, y );
> > if( x >=+0.0 && y == 0.0 ) return copysign( 0.0, y );
> > if( x <=-0.0 && y == 0.0 ) return copysign( π, y );
> > // calculate ATAN2 high performance style
> > if( x > 0.0 )
> > {
> > if( y < 0.0 && |y| < |x| ) return - π/2 - ATAN( x / y );
> > if( y < 0.0 && |y| > |x| ) return + ATAN( y / x );
> > if( y > 0.0 && |y| < |x| ) return + ATAN( y / x );
> > if( y > 0.0 && |y| > |x| ) return + π/2 - ATAN( x / y );
> > }
> > if( x < 0.0 )
> > {
> > if( y < 0.0 && |y| > |x| ) return + π/2 + ATAN( x / y );
> > if( y < 0.0 && |y| > |x| ) return + π - ATAN( y / x );
> > if( y > 0.0 && |y| < |x| ) return + π - ATAN( y / x );
> > if( y > 0.0 && |y| > |x| ) return +3π/2 + ATAN( x / y );
> > }
> > <
> > Not so well written FP codes are (well) no so well written.
> > <
> > Also note: only 1 compare is required to perform all of the above checks
> > in My 66000 ISA.
> >> So if compounds are ignorably rare then the bit vector is just an
> >> encoding idea and should be measured on code density.
> How many bits is the cmp bit vector?
<
64; of which 28 have assigned values (the rest are set to 0).
<
> I would imagine the above IF construct shows up in a lot of FP code.
> Can you use your cmp bit vector as an index to a switch instruction,
> or would it bloat too much?
<
I have it set up like the classify function of OpenGL. Where you apply
a bit mask and if any are set you take the branch. Individually this
is a branch on bit in the compare result vector.
>
> Or maybe a two switches, filter out all NAN's and INF's first,
> then deal with all the number variations.

Terje Mathisen [2021-06-14 07:55:39] wrote:
> MitchAlsup wrote:
>> On Saturday, June 12, 2021 at 2:23:09 PM UTC-5, EricP wrote:
>>> That removes the IP from the register set and moves all the above mode
>>> specifier bits into the opcode, where they can be optimally assigned.
>> <
>> I am currently playing with the notion where there is a small register file
>> (8 entries) which is really fast, and a larger register file (64-256 entries)
>> which is 1 cycle access, and then memory which is 3-4 cycles of access
>> and supports sizes other than 64-bits. {The first 8 entries of the large
>> file is the small 8 register file.}
> So, this is a NURA (Non-Uniform Register Access) machine?
> I am sure the compiler writes would love it. :-)
> (Personally I would be perfectly happy, 8 effective registers are enough for
> almost all the inner loop code I have ever written.)

I believe you're familiar with a machine called "Mill" which has fast
registers (called "belt positions") and slow registers (placed in
a thingy called "scratchpad") ;-)

Stefan

MitchAlsup wrote:
> On Monday, June 14, 2021 at 7:31:37 AM UTC-5, EricP wrote:
>> MitchAlsup wrote:
>>> On Sunday, June 13, 2021 at 3:33:45 PM UTC-5, Ivan Godard wrote:
>>>> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
>>>>> Ivan Godard wrote:
>>>>> I.e. any kind of compound check.
>>>>>
>>>>> Terje
>>> <
>>>> And that's the question. True, there could be bits for </=/> and you do
>>>> a compound for <= and >=, but that seems pointless to me; you should
>>>> have a negate flag (branch direction) in the instruction instead of
>>>> compounding. Otherwise, how often are compound checks of real operands
>>>> in real code? Yes, FP folding a NaN check is a reasonable use - but how
>>>> often is NaN checked for in real code regardless of how you do it?
>>> <
>>> Well Written FP codes do it all the time::
>>> <
>>> double ATAN2( double y, double x )
>>> { // IEEE 754-2019 quality ATAN2
>>> // deal with NANs
>>> if( ISNAN( x ) ) return x;
>>> if( ISNAN( y ) ) return y;
>>> // deal with infinities
>>> if( x == +∞ && |y|== +∞ ) return copysign( π/4, y );
>>> if( x == +∞ ) return copysign( 0.0, y );
>>> if( x == -∞ && |y|== +∞ ) return copysign( 3π/4, y );
>>> if( x == -∞ ) return copysign( π, y );
>>> if( |y|== +∞ ) return copysign( π/2, y );
>>> // deal with signed zeros
>>> if( x == 0.0 && y != 0.0 ) return copysign( π/2, y );
>>> if( x >=+0.0 && y == 0.0 ) return copysign( 0.0, y );
>>> if( x <=-0.0 && y == 0.0 ) return copysign( π, y );
>>> // calculate ATAN2 high performance style
>>> if( x > 0.0 )
>>> {
>>> if( y < 0.0 && |y| < |x| ) return - π/2 - ATAN( x / y );
>>> if( y < 0.0 && |y| > |x| ) return + ATAN( y / x );
>>> if( y > 0.0 && |y| < |x| ) return + ATAN( y / x );
>>> if( y > 0.0 && |y| > |x| ) return + π/2 - ATAN( x / y );
>>> }
>>> if( x < 0.0 )
>>> {
>>> if( y < 0.0 && |y| > |x| ) return + π/2 + ATAN( x / y );
>>> if( y < 0.0 && |y| > |x| ) return + π - ATAN( y / x );
>>> if( y > 0.0 && |y| < |x| ) return + π - ATAN( y / x );
>>> if( y > 0.0 && |y| > |x| ) return +3π/2 + ATAN( x / y );
>>> }
>>> <
>>> Not so well written FP codes are (well) no so well written.
>>> <
>>> Also note: only 1 compare is required to perform all of the above checks
>>> in My 66000 ISA.
>>>> So if compounds are ignorably rare then the bit vector is just an
>>>> encoding idea and should be measured on code density.
>> How many bits is the cmp bit vector?
> <
> 64; of which 28 have assigned values (the rest are set to 0).
> <
>> I would imagine the above IF construct shows up in a lot of FP code.
>> Can you use your cmp bit vector as an index to a switch instruction,
>> or would it bloat too much?
> <
> I have it set up like the classify function of OpenGL. Where you apply
> a bit mask and if any are set you take the branch. Individually this
> is a branch on bit in the compare result vector.
>> Or maybe a two switches, filter out all NAN's and INF's first,
>> then deal with all the number variations.

Just spitballing...

If one wanted to use the cmp vector in switch instructions,
it could have a "bit pack" instruction which takes a 64-bit source
and a 64-bit mask immediate, and for every '1' bit in the mask it
packs that source bit to the next available position on the right.
So mask b0010_0100_0101 extracts b9, b6, b2, b0 to bits b[3:0] in dest.
Then use that as the switch index.

So for the above, maybe 4 switch instructions.

MitchAlsup wrote:
> On Sunday, June 13, 2021 at 5:52:08 PM UTC-5, EricP wrote:
>> Terje Mathisen wrote:
>>> MitchAlsup wrote:
>>>> On Saturday, June 12, 2021 at 12:12:07 PM UTC-5, Terje Mathisen wrote:
>>>>> EricP wrote:
>>>>>> Terje Mathisen wrote:
>>>>>>> EricP wrote:
>>>>>>>> So toss out auto inc/dec address modes and put in two instructions
>>>>>>>>
>>>>>>>> // pdp-11 asm has dest reg on the right
>>>>>>>> ADDTY #tiny,reg Add Tiny
>>>>>>>> SUBTY #tiny,reg Subtract Tiny
>>>>>>>>
>>>>>>>> where tiny is 1..7 and 0 means 8. Much more generally useful.
>>>>>>> I would rather have 0..7 meaning 1..8, since this is trivially
>>>>>>> achieved by always enabling an incoming carry to the address adder.
>>>>>>> Special-casing 0 to mean 8 seems like it would need more gates?
>>>>>>>
>>>>>>> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
>>>>>>>
>>>>>>> Terje
>>>>>> 1..7, 0 => 8 allows the 3 lower bits to be used directly
>>>>>> and a 3-input NOR-3 gate to drive the 4th bit.
>>>>>>
>>>>>> 0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
>>>>>> an AND-2 and an AND-3 carry lookaheads.
>>>>>>
>>>>>> Its in the decoder and there are other more expensive things there,
>>>>>> so it wouldn't be on the critical path either way.
>>>> <
>>>>> The logic is simple either way, but since we're already going to use the
>>>>> (address) adder, just setting carry_in is effectively free.
>>>> <
>>>> What makes you think the AGEN adder has a carry in ??
>>> I realize that it doesn't need one: The bottom bit can be handled with a
>>> half adder which I'm guessing is at least one gate delay faster, and
>>> that can negate any gain from not having to generate cnt3?
>>>
>>> OTOH, if this is dedicated circuit, then it would know to always add the
>>> carry-in, so the bottom half adder would just be slightly different:
>>>
>>> s0 = a == b
>>> carry_out = a | b;
>>>
>>> Right?
>>>
>>> Terje
>>>
>> what I was talking about was the encoding of a field in the instruction
>> which would always be set by the assembler/compiler so there is no reason
>> for it not to be encoded as simply as possible for the hardware.
> <
> For what follows I an using the term "decoder" a a block of logic that asserts
> on of 2^n output signals in response to n bit input signal. {There are lots of
> other kinds of decoders (greater than, less than) but this one is also known
> as the equality decoder.

A unary (one-hot) decoder, check.

> <
> One can simply build the decoder of range(0..7) to assert on domain(1..8)
> at zero cost. {we have not had this one in the discussion yet, but it needs
> to be}

I don't follow you here. Are you talking about feeding the unary decoder
output into a binary encoder, just offset by 1 position?

> <
> The lesser cost is the AND gate which converts 000 into 1000. Then the
> lower 3 bits go into a decoder to assert one of 1..7 the AND gate asserting
> 8. (the zero output of the decoder is not used and if the synthesizer is any
> good, the great gate muncher will remove that logic.}
> <

You have lost me.

I saw #tiny as just another kind of immediate binary that happens to be
stashed in an opcode register field. When the instruction is decoded
as ADDTY or SUBTY the converted tiny value gets transferred (MUX'd)
into the uOp immediate field, and the uOp instruction field
is set to ADD or SUB.

After that uOp is treated as any other instruction with an immediate operand.

Thomas Koenig wrote:
> James Harris <james.harris.1@gmail.com> schrieb:
>> On 12/06/2021 21:50, MitchAlsup wrote:
>>> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
>> ...
>>
>>>> So you are saying that simply forcing carry-in takes 4 extra gate
>>>> delays, on top of routing the three address bits, and also merging them
>>>> with the generated cnt3 bit?
>>> <
>>> Yes, it is sad that SW people see AND and ADD as the same latency.
>> As what you might call a software person I don't see AND and ADD as
>> needing the same latency and I find it a bit irksome when CPUs require
>> the same time (1 cycle) for each -
>
> You would need an elastic pipeline for this; in this case, you could
> also make your additions somewhat faster in the case where you
> do not need to propagate carries very far (or your multipliers if
> you are, for example, multiplying two 8-bit numbers with a 64-bit
> multiplier).
>
> There are papers on this, but no major architecture has done this to
> date (unless I have missed something, which may well be the case).

I was reading something on elastic pipelines and stumbled
on the term for this: they called them "Telescopic units" and
Google scholar shows a a few hits. Seems to be mostly 20 years ago.

I haven't read the papers but the abstracts sounds on-topic.

"Results, obtained on a large set of benchmark circuits, show an
average throughput improvement exceeding 27%, at the price of a
modest area increase (less than 8% on average)."

Telescopic units: a new paradigm for performance optimization
of VLSI designs, 1998
https://ieeexplore.ieee.org/abstract/document/700720/
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.3722&rep=rep1&type=pdf

Telescopic units: Increasing the average throughput of pipelined
designs by adaptive latency control, 1997
https://dl.acm.org/doi/abs/10.1145/266021.266029
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.32.3516&rep=rep1&type=pdf

On 6/13/2021 11:45 PM, Ivan Godard wrote:
> On 6/13/2021 6:29 PM, Stephen Fuld wrote:
>> On 6/13/2021 1:33 PM, Ivan Godard wrote:
>>> On 6/13/2021 1:03 PM, Terje Mathisen wrote:
>
>>> And that's the question. True, there could be bits for </=/> and you
>>> do a compound for <= and >=, but that seems pointless to me; you
>>> should have a negate flag (branch direction) in the instruction
>>> instead of compounding. Otherwise, how often are compound checks of
>>> real operands in real code? Yes, FP folding a NaN check is a
>>> reasonable use - but how often is NaN checked for in real code
>>> regardless of how you do it?
>>>
>>> So if compounds are ignorably rare then the bit vector is just an
>>> encoding idea and should be measured on code density.
>>
>> One other point.  Mitch's scheme does all those checks with a single
>> op code for the compare and one (or two if you include the
>> predication) for for the conditional branch/predicate.  So depending
>> upon how the alternative handles things, you might require fewer op
>> codes.  How much that is worth is, of course, dependent on lots of
>> other factors.
>>
>>
>
> Yes; it shifts entropy from opcode to bit selector. But it doesn't
> reduce the total entropy.

Of course, you are right, but if (unlike the Mill) you have fixed length
instructions, especially with fixed length fields within them, you might
have more, otherwise unused, bits available in other places. e.g. in a
32 bit fixed instruction, for a conditional branch, typically one of
the, otherwise unused, register specifier fields is available to hold
those bits.

As I said before, YMMV.

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