Guillaume <message@bottle.org> schrieb:
> Le 02/01/2022 à 23:37, MitchAlsup a écrit :
>> Why is there not an IMAX instruction in every modern ISA ??

> The reason is that the RISC-V ISA is very modular, so they have choosen
> to keep the base ISA minimal, and then extend it.
>
> It has benefits of course - you can design cores that are as minimal or
> as featureful as needed, while still being compliant

One thing I do not understand is why multiplication and division
are in one extension.

Given the difference in effort for low-cost mutiplier and a divider,
why is it not possible to have multiplication instructions, but no
division instructions?

Le 03/01/2022 à 23:05, Thomas Koenig a écrit :
> Guillaume <message@bottle.org> schrieb:
>> Le 02/01/2022 à 23:37, MitchAlsup a écrit :
>>> Why is there not an IMAX instruction in every modern ISA ??
>
>> The reason is that the RISC-V ISA is very modular, so they have choosen
>> to keep the base ISA minimal, and then extend it.
>>
>> It has benefits of course - you can design cores that are as minimal or
>> as featureful as needed, while still being compliant
>
> One thing I do not understand is why multiplication and division
> are in one extension.
>
> Given the difference in effort for low-cost mutiplier and a divider,
> why is it not possible to have multiplication instructions, but no
> division instructions?

The 'M' extension is so "small" that they probably didn't see a point in
further splitting it. But you're right, and that may happen in the
future. Meanwhile, while not being 100% compliant (you can't claim the
'M' extension if you don't implement division), it's already something
that's been taken into account by compilers. So at least with GCC, you
can use an option that allows it to generate only multplication
instructions, but not division instructions (so divisions and modulo
will be emulated in software.)

On 1/3/2022 9:28 AM, MitchAlsup wrote:
> On Monday, January 3, 2022 at 4:01:36 AM UTC-6, Ivan Godard wrote:
>> On 1/2/2022 2:37 PM, MitchAlsup wrote:
>>> On Sunday, January 2, 2022 at 12:55:45 PM UTC-6, Guillaume wrote:
>>>> Le 01/01/2022 à 18:35, Marcus a écrit :
>>>>> On 2022-01-01, Thomas Koenig wrote:
>>>>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>>>>
>>>>>>> Just like x86 condition codes, POWER compilers will probably do a better
>>>>>>> job if they can inline bool functions, so that the condition code can be
>>>>>>> used directly instead of first having to be reified as an int, then
>>>>>>> tested again in the calling function.
>>>>>>
>>>>>> Very much so.
>>>>>>
>>>>>> _Bool gt (long int a, long int b)
>>>>>> {
>>>>>> return a > b;
>>>>>> }
>>>>>>
>>>>>> long int mymax(long int a,long int b)
>>>>>> {
>>>>>> return gt(a,b) ? a : b;
>>>>>> }
>>>>>>
>>>>>> will give you, with -O3 on a current trunk,
>>>>>>
>>>>>> cmpd r3,r4
>>>>>> isellt r3,r4,r3
>>>>>> blr
>>>>>>
>>>>>> for mymax.
>>>>>>
>>>>>
>>>>> The MRISC32 version, https://godbolt.org/z/r6rTj5aWv
>>>>>
>>>>> mymax:
>>>>> max r1,r1,r2
>>>>> ret
>>>>>
>>>>> ;-)
>>>> For RISCV, it's:
>>>> mymax:
>>>> bge a0,a1,.L4
>>>> mv a0,a1
>>>> .L4:
>>>> ret
>>>>
>>>> So, requires a conditional branch...
>>>> But, for floating point (if supported), there is the 'fmax' instruction.
>>> <
>>> Why is there not an IMAX instruction in every modern ISA ??
>> because you don't need it when you have "?:".
>>
>> gtr(b0, b1), pick(b0, b1, b2), retn(b0);
>>
>> one bundle, one cycle.
> <
> and at least 4 times as much transport energy.

I guess you are adding three for the pick. Mill doesn't - pick is all
done in the namer; no data is moved at all.

As for the rest, the compare requires both the values going from
wherever to the ALU, whether it's an op or folded into a branch, so that
move cost should be the same for all ISAs. The Mill retn also does not
move anything - again, it's all in the namer. So the total actual moves
is two, which makes it hard to use four times anything :-)

Perhaps you haven't noticed me saying: *the belt is not physically a
shift register*.

Ivan Godard <ivan@millcomputing.com> schrieb:

> Perhaps you haven't noticed me saying: *the belt is not physically a
> shift register*.

It's usually implemented as a circular buffer, correct?

On 1/4/2022 12:39 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> Perhaps you haven't noticed me saying: *the belt is not physically a
>> shift register*.
>
> It's usually implemented as a circular buffer, correct?

Not at all.

Computed values are left where they were produced - FU's output latches,
for example - just as in a forwarding bypass network. Move only happens
if the location is needed by some other computation, and then only to an
adjacent location, also on the bypass network - which the way issue
happens guarantees is free.

All the belt advance does is migrate the program-to-physical mapping -
the name - to a new physical location. The cost is the same as when an
OOO migrates the l2p mapping of a logical register to a different
physical register when the logical register is reused by the program.

The cost of the remap is the same as in an x86, or my66 or whatever -
the number of bits involved is determined by the number of physical
locations that the hardware maps to. That's around 40 for a mid-range
Silver, several hundred for typical OOO.

However, an OOO does have a physical move to the architected register
eventually. Mill has no such move, because the whole mapping is passed
through call and return which includes all traps and interrupts. That
state does eventually get saved, lazily, when task switch happens,
whereas an OOO does it on every writeback.

Ivan Godard wrote:
> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>> shift register*.
>>
>> It's usually implemented as a circular buffer, correct?
>
> Not at all.
>
> Computed values are left where they were produced - FU's output latches,
> for example - just as in a forwarding bypass network. Move only happens
> if the location is needed by some other computation, and then only to an
> adjacent location, also on the bypass network - which the way issue
> happens guarantees is free.

Moving results out of the way is what makes this work.
If you only have one adder FU and you get a bunch of add instructions
in a row, then you need to stash older results in other registers
and this becomes the equivalent of a delayed register writeback.
But I think you need a crossbar to accomplish this while a
traditional approach just needs some small number of result buses.

On Tuesday, January 4, 2022 at 11:49:07 AM UTC-6, EricP wrote:
> Ivan Godard wrote:
> > On 1/4/2022 12:39 AM, Thomas Koenig wrote:
> >> Ivan Godard <iv...@millcomputing.com> schrieb:
> >>
> >>> Perhaps you haven't noticed me saying: *the belt is not physically a
> >>> shift register*.
> >>
> >> It's usually implemented as a circular buffer, correct?
> >
> > Not at all.
> >
> > Computed values are left where they were produced - FU's output latches,
> > for example - just as in a forwarding bypass network. Move only happens
> > if the location is needed by some other computation, and then only to an
> > adjacent location, also on the bypass network - which the way issue
> > happens guarantees is free.
<
> Moving results out of the way is what makes this work.
> If you only have one adder FU and you get a bunch of add instructions
> in a row, then you need to stash older results in other registers
<
Using the definition that a register is a name SW can use to reference
a value, you don't need registers per seé, you just need containers.
Luke's scoreboard design used several such containers at the end of
each calculation unit so the unit can continue to plow through calculations
while result deliver was held up by WAR, and WAW hazards and maybe
result bus scheduling.
<
> and this becomes the equivalent of a delayed register writeback.
> But I think you need a crossbar to accomplish this while a
> traditional approach just needs some small number of result buses.
<
Thing is that is you broadcast the result as soon as it is calculated
(even if you can't write it into the RF) you make up for most of the
lack of resources (busses) performance hit.

MitchAlsup wrote:
> On Tuesday, January 4, 2022 at 11:49:07 AM UTC-6, EricP wrote:
>> Ivan Godard wrote:
>>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>>>> Ivan Godard <iv...@millcomputing.com> schrieb:
>>>>
>>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>>>> shift register*.
>>>> It's usually implemented as a circular buffer, correct?
>>> Not at all.
>>>
>>> Computed values are left where they were produced - FU's output latches,
>>> for example - just as in a forwarding bypass network. Move only happens
>>> if the location is needed by some other computation, and then only to an
>>> adjacent location, also on the bypass network - which the way issue
>>> happens guarantees is free.
> <
>> Moving results out of the way is what makes this work.
>> If you only have one adder FU and you get a bunch of add instructions
>> in a row, then you need to stash older results in other registers
> <
> Using the definition that a register is a name SW can use to reference
> a value, you don't need registers per seé, you just need containers.
> Luke's scoreboard design used several such containers at the end of
> each calculation unit so the unit can continue to plow through calculations
> while result deliver was held up by WAR, and WAW hazards and maybe
> result bus scheduling.

I mean register as in latch or flip-flop attached to the output of an FU,
not register as in register file.

I had something similar in my uArch. Some FU can be pipelined or otherwise
take multiple clocks to do their thing. For these "expensive" units I
did not want to have to stall the launch of the next calculation just
because a result register (latches) was full waiting to write back the
prior result on one of the two result buses.
Some units had a second result register to buffer 1 result
as it only cost 1 set of latches and tri-state buffers.

> <
>> and this becomes the equivalent of a delayed register writeback.
>> But I think you need a crossbar to accomplish this while a
>> traditional approach just needs some small number of result buses.
> <
> Thing is that is you broadcast the result as soon as it is calculated
> (even if you can't write it into the RF) you make up for most of the
> lack of resources (busses) performance hit.

Remember, one of my goals was to be a resource frugal OoO.
In my case the two broadcast/forwarding buses also wrote to RF ports
and a round robin arbiter selects two of multiple bus access bidders
each clock to broadcast/write results.

On Tuesday, January 4, 2022 at 1:25:49 PM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Tuesday, January 4, 2022 at 11:49:07 AM UTC-6, EricP wrote:
> >> Ivan Godard wrote:
> >>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
> >>>> Ivan Godard <iv...@millcomputing.com> schrieb:
> >>>>
> >>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
> >>>>> shift register*.
> >>>> It's usually implemented as a circular buffer, correct?
> >>> Not at all.
> >>>
> >>> Computed values are left where they were produced - FU's output latches,
> >>> for example - just as in a forwarding bypass network. Move only happens
> >>> if the location is needed by some other computation, and then only to an
> >>> adjacent location, also on the bypass network - which the way issue
> >>> happens guarantees is free.
> > <
> >> Moving results out of the way is what makes this work.
> >> If you only have one adder FU and you get a bunch of add instructions
> >> in a row, then you need to stash older results in other registers
> > <
> > Using the definition that a register is a name SW can use to reference
> > a value, you don't need registers per seé, you just need containers.
> > Luke's scoreboard design used several such containers at the end of
> > each calculation unit so the unit can continue to plow through calculations
> > while result deliver was held up by WAR, and WAW hazards and maybe
> > result bus scheduling.
<
> I mean register as in latch or flip-flop attached to the output of an FU,
> not register as in register file.
<
Just making it clear to everyone. But perhaps you, too, can take on the word
"flip-flop" when you mean a HW container that does not necessarily have a SW
name. Thus, after trying to explain to SW+HW audiences for a decade that
the HW concept of a "register" was significantly different than the SW concept,
The only sane point of view when working in both domains was to use a new
word for one of the domains. Since HW is the smaller domain, I chose a different
word for the HW concept. This was easy because HW already had a name (flip-flop)
that everyone in HW understood.
>
> I had something similar in my uArch. Some FU can be pipelined or otherwise
> take multiple clocks to do their thing. For these "expensive" units I
> did not want to have to stall the launch of the next calculation just
> because a result register (latches) was full waiting to write back the
> prior result on one of the two result buses.
<
We did this in the FADD unit when doing FDIV instruction in Mc 88100.
The first stage remained "unBusy" even while an FDIV was in progress.
<
> Some units had a second result register to buffer 1 result
> as it only cost 1 set of latches and tri-state buffers.
<
I have not needed this as I either did strict pipelines or fully resourced
OoO pipelines. Luke, however, did. And, here, I think scoreboards work
better than reservation stations.
> > <
> >> and this becomes the equivalent of a delayed register writeback.
> >> But I think you need a crossbar to accomplish this while a
> >> traditional approach just needs some small number of result buses.
> > <
> > Thing is that is you broadcast the result as soon as it is calculated
> > (even if you can't write it into the RF) you make up for most of the
> > lack of resources (busses) performance hit.
<
> Remember, one of my goals was to be a resource frugal OoO.
> In my case the two broadcast/forwarding buses also wrote to RF ports
> and a round robin arbiter selects two of multiple bus access bidders
> each clock to broadcast/write results.
<
Bet that caused some interesting complexity in the instruction scheduler.

On 1/4/2022 9:48 AM, EricP wrote:
> Ivan Godard wrote:
>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>>> shift register*.
>>>
>>> It's usually implemented as a circular buffer, correct?
>>
>> Not at all.
>>
>> Computed values are left where they were produced - FU's output
>> latches, for example - just as in a forwarding bypass network. Move
>> only happens if the location is needed by some other computation, and
>> then only to an adjacent location, also on the bypass network - which
>> the way issue happens guarantees is free.
>
> Moving results out of the way is what makes this work.
> If you only have one adder FU and you get a bunch of add instructions
> in a row, then you need to stash older results in other registers
> and this becomes the equivalent of a delayed register writeback.
> But I think you need a crossbar to accomplish this while a
> traditional approach just needs some small number of result buses.
>
>

Still not :-)

Our FU slots can (and typically do) support operations of different
natural latencies (pipe lengths). Each slot can accept one op per cycle,
so if the latencies differ you can get more than one result retiring in
the same cycle. Consequently the FUs have one result FF per supported
latency.

If a op of latency N retires in cycle C to FF#N, necessarily the
following cycle C+1 the FF#N+1 is free (think about it). Consequently,
the FU's FFs are daisy chained so that each cycle FF#N is moved to
FF#N+1 and every result always is retiring to a known free FF; the set
of FFs are right next to each other so the move is trivial.

That gets rid of all moves except the move from FF#last, which has no
last+1. If that FF was originally filled and is still live (it may have
been daisy chained enough to have fallen off the belt) then it gets
moved to a dynamically allocated skid FF in the spiller. There can be at
most one such move per slot. There can be at most <belt size> skid FFs
needed for this.

This move to the spiller is the only point which resembles a writeback
stage in a genreg machine. In limited measurement of limited test code,
we see ~25% of all drops reach the spiller and actually cost power
(Silver); fewer in configs with short belts and more in ones with long
belts. I don't know if OOOs skip writeback of superseded results, but
the fanout of the mux trees to the spiller (16 in Silver) is much less
than that to a OOO regfile will hundreds more registers.

The idea of a "last use" bit in the encoding has come up several times
here. Falling off the belt is an implicit last use, so perhaps an
explicit bit could give the same saving in writeback that the Mill displays.

On Sunday, January 2, 2022 at 3:38:00 PM UTC-7, MitchAlsup wrote:

> Why is there not an IMAX instruction in every modern ISA ??

Surely if one is going to include video decompression assist
instructions, they wouldn't be limited to just one aspect ratio...

But seriously, I do see where you're going. Picking the larger
of two numbers in a single instruction avoids a _branch_, and
branches are positively horrible in modern implementations.

Usually, though, you don't just want the larger of the two, you
want information about which one was larger, and that makes
the instruction much more complicated and/or specialized.

*And there are so many other cases like this.*

Instruction predication is an example of addressing this issue
from the other end; instead of having no-branch instructions that
do stuff, it tries to take the sting out of branches. Obviously, though,
it's somewhat limited, it works best for avoiding branches around
very short sequences of code.

Is there another way to take the sting out of branches...

John Savard

On Wednesday, January 5, 2022 at 8:34:24 AM UTC-7, Quadibloc wrote:
> Is there another way to take the sting out of branches...

Clearly,

set flag on condition
....
branch on flag

doesn't do it. It doesn't give the CPU enough information.

Branches are bad because modern computers are heavily
pipelined. So if the branch is taken - or not taken, if the
branch is assumed to be taken - the pipeline has to be
flushed; what a waste!

Let's take the case of a 1 to n loop. You know well ahead
of time if the branch is to be taken or not.

So what you *really* want would be:

branch, when there is a branch, on condition
....
this is the conditional branch previously mentioned, branch from here

or it could be...

conditional branch with variable number of delay slots
.....
marker that says this is the end of the delay slots

As long as enough code is put in the ... part (including
no branches at all, of course)

....and one correctly ensures that the required information
is saved and restored in the case of an interrupt

it might actually work.

John Savard

On Wednesday, January 5, 2022 at 8:43:40 AM UTC-7, Quadibloc wrote:
> On Wednesday, January 5, 2022 at 8:34:24 AM UTC-7, Quadibloc wrote:
>
> > Is there another way to take the sting out of branches...
> Clearly,
>
> set flag on condition
> ...
> branch on flag
>
> doesn't do it. It doesn't give the CPU enough information.

Upon reflection, it _does_ give the CPU enough information, as
it does exactly what the other solutions suggested afterwards
do. The CPU can very quickly - when decoding the instruction -
check if the flag is set, do direct the fetching of subsequent
instructions.

John Savard

On Wednesday, January 5, 2022 at 8:49:29 AM UTC-7, Quadibloc wrote:
> On Wednesday, January 5, 2022 at 8:43:40 AM UTC-7, Quadibloc wrote:
> > On Wednesday, January 5, 2022 at 8:34:24 AM UTC-7, Quadibloc wrote:
> >
> > > Is there another way to take the sting out of branches...
> > Clearly,
> >
> > set flag on condition
> > ...
> > branch on flag
> >
> > doesn't do it. It doesn't give the CPU enough information.
> Upon reflection, it _does_ give the CPU enough information, as
> it does exactly what the other solutions suggested afterwards
> do. The CPU can very quickly - when decoding the instruction -
> check if the flag is set, do direct the fetching of subsequent
> instructions.

Further reflection led me to think...

since a regular 'branch on condition' instruction just tests some condition
code bits, which were set by a previous instruction,

then as long as it's clear from instruction decoding which instructions
can set the condition codes - and there's a C bit in the instruction to turn
setting them off, so lots of delay can be put between the instruction that
set the codes and the branch...

then why should branches be a problem at all any longer?

And _then_ I realized what I was missing. Sure, this deals with the problem
of flushing the pipeline, because the decode stage is soon enough.

But before an instruction is decoded, it has to be *fetched* from memory,
and DRAM is really, really slow. So since branches also affect what you need
to fetch, and waiting for DRAM causes even more delay than flushing the
pipeline... branches are unavoidably a pain. Of course, stuff like SMT,
giving the computer something else useful to do, helps to cover that up...

Thus, the _other_ idea crossing my mind might be the useful one; something
which takes a short code sequence, and says, 'this sequence has branching in
it, keep it in the instruction cache'... while that only applies to some cases,
it would handle the pessimal case of code with lots of branching after every
few instructions...

John Savard

Ivan Godard wrote:
> On 1/4/2022 9:48 AM, EricP wrote:
>> Ivan Godard wrote:
>>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>
>>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>>>> shift register*.
>>>>
>>>> It's usually implemented as a circular buffer, correct?
>>>
>>> Not at all.
>>>
>>> Computed values are left where they were produced - FU's output
>>> latches, for example - just as in a forwarding bypass network. Move
>>> only happens if the location is needed by some other computation, and
>>> then only to an adjacent location, also on the bypass network - which
>>> the way issue happens guarantees is free.
>>
>> Moving results out of the way is what makes this work.
>> If you only have one adder FU and you get a bunch of add instructions
>> in a row, then you need to stash older results in other registers
>> and this becomes the equivalent of a delayed register writeback.
>> But I think you need a crossbar to accomplish this while a
>> traditional approach just needs some small number of result buses.
>>
>>
>
> Still not :-)
>
> Our FU slots can (and typically do) support operations of different
> natural latencies (pipe lengths). Each slot can accept one op per cycle,
> so if the latencies differ you can get more than one result retiring in
> the same cycle. Consequently the FUs have one result FF per supported
> latency.
>
> If a op of latency N retires in cycle C to FF#N, necessarily the
> following cycle C+1 the FF#N+1 is free (think about it). Consequently,
> the FU's FFs are daisy chained so that each cycle FF#N is moved to
> FF#N+1 and every result always is retiring to a known free FF; the set
> of FFs are right next to each other so the move is trivial.

This sounds like it has a belt's worth of FF for each FU.
And some of them are shift registers?
I'm a bit confused.

I envisioned this having 1 belt of FF values and two crossbars,
one crossbar to route any belt FF to any FU operands,
one to route any FU result to the proper empty FF for its latency.

It is the logical to physical map that actually shifts.
And a scoreboard tracks when FF operands are ready
and are written into their correct physical slot.

Belt
FF ---->Xbar<--Map
^ | |
| v |
Xbar<---FU v
<------FU

> That gets rid of all moves except the move from FF#last, which has no
> last+1. If that FF was originally filled and is still live (it may have
> been daisy chained enough to have fallen off the belt) then it gets
> moved to a dynamically allocated skid FF in the spiller. There can be at
> most one such move per slot. There can be at most <belt size> skid FFs
> needed for this.
>
> This move to the spiller is the only point which resembles a writeback
> stage in a genreg machine. In limited measurement of limited test code,
> we see ~25% of all drops reach the spiller and actually cost power
> (Silver); fewer in configs with short belts and more in ones with long
> belts. I don't know if OOOs skip writeback of superseded results, but
> the fanout of the mux trees to the spiller (16 in Silver) is much less
> than that to a OOO regfile will hundreds more registers.
>
> The idea of a "last use" bit in the encoding has come up several times
> here. Falling off the belt is an implicit last use, so perhaps an
> explicit bit could give the same saving in writeback that the Mill
> displays.

If the belt was a compacting FIFO which allows slots to be deleted
from the interior then a "last use" bit lets it delete slots
without pushing items off the far end.

Here A,B are on the belt and C,D,E are appended.
Then C is dropped from the middle and F appended.

E D C->B A => F->E D C B A => ->F E D B A
^
last use

And its just the logical to physical map that is modified to drop C.

As you have pointed out before, since many/most results are referenced
only once this would allow more intermediate results to be held on the
belt longer resulting in fewer spills to scratch.

On Wednesday, January 5, 2022 at 5:14:16 PM UTC-6, EricP wrote:
> Ivan Godard wrote:
> > On 1/4/2022 9:48 AM, EricP wrote:
> >> Ivan Godard wrote:
> >>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:

> > The idea of a "last use" bit in the encoding has come up several times
> > here. Falling off the belt is an implicit last use, so perhaps an
> > explicit bit could give the same saving in writeback that the Mill
> > displays.
<
One can use register-write-elision to perform essentially the same thing
(on a machine with restrictions on the write ports.) Once a write passes
commit and a younger write is past the commit point, the older write can
be discarded instead of being written into the RF (after obeying WARs)
<
> If the belt was a compacting FIFO which allows slots to be deleted
> from the interior then a "last use" bit lets it delete slots
> without pushing items off the far end.
<
Good observation. If the belt is sufficiently long this would have negligible
utility, but if the belt is short enough it may be of value.
>
> Here A,B are on the belt and C,D,E are appended.
> Then C is dropped from the middle and F appended.
>
> E D C->B A => F->E D C B A => ->F E D B A
> ^
> last use
>
> And its just the logical to physical map that is modified to drop C.
>
> As you have pointed out before, since many/most results are referenced
> only once this would allow more intermediate results to be held on the
> belt longer resulting in fewer spills to scratch.

On 1/5/2022 3:13 PM, EricP wrote:
> Ivan Godard wrote:
>> On 1/4/2022 9:48 AM, EricP wrote:
>>> Ivan Godard wrote:
>>>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>
>>>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>>>>> shift register*.
>>>>>
>>>>> It's usually implemented as a circular buffer, correct?
>>>>
>>>> Not at all.
>>>>
>>>> Computed values are left where they were produced - FU's output
>>>> latches, for example - just as in a forwarding bypass network. Move
>>>> only happens if the location is needed by some other computation,
>>>> and then only to an adjacent location, also on the bypass network -
>>>> which the way issue happens guarantees is free.
>>>
>>> Moving results out of the way is what makes this work.
>>> If you only have one adder FU and you get a bunch of add instructions
>>> in a row, then you need to stash older results in other registers
>>> and this becomes the equivalent of a delayed register writeback.
>>> But I think you need a crossbar to accomplish this while a
>>> traditional approach just needs some small number of result buses.
>>>
>>>
>>
>> Still not :-)
>>
>> Our FU slots can (and typically do) support operations of different
>> natural latencies (pipe lengths). Each slot can accept one op per
>> cycle, so if the latencies differ you can get more than one result
>> retiring in the same cycle. Consequently the FUs have one result FF
>> per supported latency.
>>
>> If a op of latency N retires in cycle C to FF#N, necessarily the
>> following cycle C+1 the FF#N+1 is free (think about it). Consequently,
>> the FU's FFs are daisy chained so that each cycle FF#N is moved to
>> FF#N+1  and every result always is retiring to a known free FF; the
>> set of FFs are right next to each other so the move is trivial.
>
> This sounds like it has a belt's worth of FF for each FU.
> And some of them are shift registers?
> I'm a bit confused.

There can be (and usually are) several FUs per slot, forming in effect a
"superFU". There is only one set of output FFs per slot, one per
latency. These are daisy chained. I suppose that you can think of the
output FF daisy as being a shift register, and it could be done that
way, but it also could be done by simply rotating which FF is considered
which latency, thereby replacing a physical data move with a
result-to-FF fanout. That's a HW design choice; IANAHWG.

> I envisioned this having 1 belt of FF values and two crossbars,
> one crossbar to route any belt FF to any FU operands,
> one to route any FU result to the proper empty FF for its latency.

Only one crossbar, which routes belt FF to slot operands. The slots know
which op has which latency and so directly connect the compute logic to
the right output FF. Say a slot has a 1-cycle adder and a 3-cycle
multiplier. The adder will be connected directly to the lat1 FF, the
mult to the lat3 FF, and nothing will go to the lat2 FF; this is not a
crossbar.

Meanwhile, the lat1 FF daisies to the lat2 FF, the lat2 FF to the lat3,
and the lat3 to the spiller (although the config might put a lat4 or
more in there, depending on the tradeoff between more sources on the
input crossbar vs more value making it all the way op the daisy to press
on the spiller).

> It is the logical to physical map that actually shifts.
> And a scoreboard tracks when FF operands are ready
> and are written into their correct physical slot.
>
>   Belt
>    FF ---->Xbar<--Map
>    ^       |  |
>    |       v  |
>   Xbar<---FU  v
>       <------FU
>
There's no scoreboard, because Mill is statically scheduled. The FU
result either goes direct to the right FF (which is actually built into
that FU) or fans out to it 1->N, so there's no second xbar. If you did
put in a scoreboard then you could use dynamic scheduling.

However, dynamic requires another xbar into the scoreboard, and xbars
get out of hand quickly with increasing concurrency; the practical limit
seems to be around 8-way issue even with ridiculously long pipes. Mill
is intended for use up into concurrencies in the 20-30 range, so static
seems the only way to go, with other devices to avoid costs like cache
misses.

>> That gets rid of all moves except the move from FF#last, which has no
>> last+1. If that FF was originally filled and is still live (it may
>> have been daisy chained enough to have fallen off the belt) then it
>> gets moved to a dynamically allocated skid FF in the spiller. There
>> can be at most one such move per slot. There can be at most <belt
>> size> skid FFs needed for this.
>>
>> This move to the spiller is the only point which resembles a writeback
>> stage in a genreg machine. In limited measurement of limited test
>> code, we see ~25% of all drops reach the spiller and actually cost
>> power (Silver); fewer in configs with short belts and more in ones
>> with long belts. I don't know if OOOs skip writeback of superseded
>> results, but the fanout of the mux trees to the spiller (16 in Silver)
>> is much less than that to a OOO regfile will hundreds more registers.
>>
>> The idea of a "last use" bit in the encoding has come up several times
>> here. Falling off the belt is an implicit last use, so perhaps an
>> explicit bit could give the same saving in writeback that the Mill
>> displays.
>
> If the belt was a compacting FIFO which allows slots to be deleted
> from the interior then a "last use" bit lets it delete slots
> without pushing items off the far end.
>
> Here A,B are on the belt and C,D,E are appended.
> Then C is dropped from the middle and F appended.
>
>   E D C->B A  =>  F->E D C B A  =>  ->F E D B A
>                          ^
>                       last use
>
> And its just the logical to physical map that is modified to drop C.

That is in effect what the rescue instruction does, although by saying
what is live instead of what is dead (rescue takes a per-position bit
mask argument). This is just a matter of encoding, trading a last-use
bit in each belt argument specifier of every instruction against a
rescue with a bit per position that you only put in if a live value is
about to fall off.

>
> As you have pointed out before, since many/most results are referenced
> only once this would allow more intermediate results to be held on the
> belt longer resulting in fewer spills to scratch.

With the rescue instruction, we wind up spilling to scratch only when
the number of live operands exceeds the size of the belt. This is
equivalent to the forced spills in a genreg when the number of live
operands exceeds to number of architectural registers.

Ivan Godard <ivan@millcomputing.com> wrote:
> On 1/5/2022 3:13 PM, EricP wrote:
>> Ivan Godard wrote:
>>> On 1/4/2022 9:48 AM, EricP wrote:
>>>> Ivan Godard wrote:
>>>>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>>
>>>>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>>>>>> shift register*.
>>>>>>
>>>>>> It's usually implemented as a circular buffer, correct?
>>>>>
>>>>> Not at all.
>>>>>
>>>>> Computed values are left where they were produced - FU's output
>>>>> latches, for example - just as in a forwarding bypass network. Move
>>>>> only happens if the location is needed by some other computation,
>>>>> and then only to an adjacent location, also on the bypass network -
>>>>> which the way issue happens guarantees is free.
>>>>
>>>> Moving results out of the way is what makes this work.
>>>> If you only have one adder FU and you get a bunch of add instructions
>>>> in a row, then you need to stash older results in other registers
>>>> and this becomes the equivalent of a delayed register writeback.
>>>> But I think you need a crossbar to accomplish this while a
>>>> traditional approach just needs some small number of result buses.
>>>>
>>>>
>>>
>>> Still not :-)
>>>
>>> Our FU slots can (and typically do) support operations of different
>>> natural latencies (pipe lengths). Each slot can accept one op per
>>> cycle, so if the latencies differ you can get more than one result
>>> retiring in the same cycle. Consequently the FUs have one result FF
>>> per supported latency.
>>>
>>> If a op of latency N retires in cycle C to FF#N, necessarily the
>>> following cycle C+1 the FF#N+1 is free (think about it). Consequently,
>>> the FU's FFs are daisy chained so that each cycle FF#N is moved to
>>> FF#N+1  and every result always is retiring to a known free FF; the
>>> set of FFs are right next to each other so the move is trivial.
>>
>> This sounds like it has a belt's worth of FF for each FU.
>> And some of them are shift registers?
>> I'm a bit confused.
>
> There can be (and usually are) several FUs per slot, forming in effect a
> "superFU". There is only one set of output FFs per slot, one per
> latency. These are daisy chained. I suppose that you can think of the
> output FF daisy as being a shift register, and it could be done that
> way, but it also could be done by simply rotating which FF is considered
> which latency, thereby replacing a physical data move with a
> result-to-FF fanout. That's a HW design choice; IANAHWG.
>
>> I envisioned this having 1 belt of FF values and two crossbars,
>> one crossbar to route any belt FF to any FU operands,
>> one to route any FU result to the proper empty FF for its latency.
>
> Only one crossbar, which routes belt FF to slot operands. The slots know
> which op has which latency and so directly connect the compute logic to
> the right output FF. Say a slot has a 1-cycle adder and a 3-cycle
> multiplier. The adder will be connected directly to the lat1 FF, the
> mult to the lat3 FF, and nothing will go to the lat2 FF; this is not a
> crossbar.
>
> Meanwhile, the lat1 FF daisies to the lat2 FF, the lat2 FF to the lat3,
> and the lat3 to the spiller (although the config might put a lat4 or
> more in there, depending on the tradeoff between more sources on the
> input crossbar vs more value making it all the way op the daisy to press
> on the spiller).
>
>> It is the logical to physical map that actually shifts.
>> And a scoreboard tracks when FF operands are ready
>> and are written into their correct physical slot.
>>
>>   Belt
>>    FF ---->Xbar<--Map
>>    ^       |  |
>>    |       v  |
>>   Xbar<---FU  v
>>       <------FU
>>
> There's no scoreboard, because Mill is statically scheduled. The FU
> result either goes direct to the right FF (which is actually built into
> that FU) or fans out to it 1->N, so there's no second xbar. If you did
> put in a scoreboard then you could use dynamic scheduling.
>
> However, dynamic requires another xbar into the scoreboard, and xbars
> get out of hand quickly with increasing concurrency; the practical limit
> seems to be around 8-way issue even with ridiculously long pipes. Mill
> is intended for use up into concurrencies in the 20-30 range, so static
> seems the only way to go, with other devices to avoid costs like cache
> misses.

Apple dominating Spec with the M1 while not having HyperThreading is
something I had though impossible due to dram misses. So a smart enough CPU
can pull of what you claim, which I was polite enough not to mock. Barely,
dodged a bullet there. ;)

I used to think Mill was doomed due to not going OoOE, curing mindset is
hard.
Apple has corrected my mindset and I now believe you can beat OoOE, at far
lower cost and power. Pointing out the Apple M1 crushing x86 is something
you could add to your investor relations. Break the x86 mindset.

But you don’t have a billion dollars of brute force to add those smarts in
every corner to prevent glass jaws. ;(

Your biggest glass jaw may be aliasing in C code forcing crap code
generation, you can add speculation and replay on fault to cure this. But
that may cost more than you can afford on your first designs?

This one change would convince every good programmer that Mill is viable,
and could beat Apple’s 6 wide design. Otherwise you can’t do effective 6
wide as aliasing caps your performance, you have a write every 6
instructions at most.

>>> That gets rid of all moves except the move from FF#last, which has no
>>> last+1. If that FF was originally filled and is still live (it may
>>> have been daisy chained enough to have fallen off the belt) then it
>>> gets moved to a dynamically allocated skid FF in the spiller. There
>>> can be at most one such move per slot. There can be at most <belt
>>>> skid FFs needed for this.
>>>
>>> This move to the spiller is the only point which resembles a writeback
>>> stage in a genreg machine. In limited measurement of limited test
>>> code, we see ~25% of all drops reach the spiller and actually cost
>>> power (Silver); fewer in configs with short belts and more in ones
>>> with long belts. I don't know if OOOs skip writeback of superseded
>>> results, but the fanout of the mux trees to the spiller (16 in Silver)
>>> is much less than that to a OOO regfile will hundreds more registers.
>>>
>>> The idea of a "last use" bit in the encoding has come up several times
>>> here. Falling off the belt is an implicit last use, so perhaps an
>>> explicit bit could give the same saving in writeback that the Mill
>>> displays.
>>
>> If the belt was a compacting FIFO which allows slots to be deleted
>> from the interior then a "last use" bit lets it delete slots
>> without pushing items off the far end.
>>
>> Here A,B are on the belt and C,D,E are appended.
>> Then C is dropped from the middle and F appended.
>>
>>   E D C->B A  =>  F->E D C B A  =>  ->F E D B A
>>                          ^
>>                       last use
>>
>> And its just the logical to physical map that is modified to drop C.
>
> That is in effect what the rescue instruction does, although by saying
> what is live instead of what is dead (rescue takes a per-position bit
> mask argument). This is just a matter of encoding, trading a last-use
> bit in each belt argument specifier of every instruction against a
> rescue with a bit per position that you only put in if a live value is
> about to fall off.
>
>>
>> As you have pointed out before, since many/most results are referenced
>> only once this would allow more intermediate results to be held on the
>> belt longer resulting in fewer spills to scratch.
>
> With the rescue instruction, we wind up spilling to scratch only when
> the number of live operands exceeds the size of the belt. This is
> equivalent to the forced spills in a genreg when the number of live
> operands exceeds to number of architectural registers.
>

On Thursday, January 6, 2022 at 9:26:01 PM UTC-6, gg...@yahoo.com wrote:
> Ivan Godard <iv...@millcomputing.com> wrote:

> Apple dominating Spec with the M1 while not having HyperThreading is
> something I had though impossible due to dram misses.
<
So, you bought into the <ahem> hype !
<
> So a smart enough CPU
> can pull of what you claim, which I was polite enough not to mock. Barely,
> dodged a bullet there. ;)
>
> I used to think Mill was doomed due to not going OoOE, curing mindset is
> hard.
> Apple has corrected my mindset and I now believe you can beat OoOE, at far
> lower cost and power. Pointing out the Apple M1 crushing x86 is something
> you could add to your investor relations. Break the x86 mindset.
>
> But you don’t have a billion dollars of brute force to add those smarts in
> every corner to prevent glass jaws. ;(
>
> Your biggest glass jaw may be aliasing in C code forcing crap code
> generation, you can add speculation and replay on fault to cure this. But
> that may cost more than you can afford on your first designs?
<
The thing I don't understand about Mill (of whom I am a fan) is what kind
of code gets produced when 7 out of 8 loops run alias free, but the 8th
iteration does something different (alias, miss, TLB,...) than the other loops.
<
>
> This one change would convince every good programmer that Mill is viable,
> and could beat Apple’s 6 wide design. Otherwise you can’t do effective 6
> wide as aliasing caps your performance, you have a write every 6
> instructions at most.
<
Performance measured by wall clock time sells itself.
<
>

On 1/6/2022 7:25 PM, Brett wrote:
> Ivan Godard <ivan@millcomputing.com> wrote:
>> On 1/5/2022 3:13 PM, EricP wrote:
>>> Ivan Godard wrote:
>>>> On 1/4/2022 9:48 AM, EricP wrote:
>>>>> Ivan Godard wrote:
>>>>>> On 1/4/2022 12:39 AM, Thomas Koenig wrote:
>>>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>>>
>>>>>>>> Perhaps you haven't noticed me saying: *the belt is not physically a
>>>>>>>> shift register*.
>>>>>>>
>>>>>>> It's usually implemented as a circular buffer, correct?
>>>>>>
>>>>>> Not at all.
>>>>>>
>>>>>> Computed values are left where they were produced - FU's output
>>>>>> latches, for example - just as in a forwarding bypass network. Move
>>>>>> only happens if the location is needed by some other computation,
>>>>>> and then only to an adjacent location, also on the bypass network -
>>>>>> which the way issue happens guarantees is free.
>>>>>
>>>>> Moving results out of the way is what makes this work.
>>>>> If you only have one adder FU and you get a bunch of add instructions
>>>>> in a row, then you need to stash older results in other registers
>>>>> and this becomes the equivalent of a delayed register writeback.
>>>>> But I think you need a crossbar to accomplish this while a
>>>>> traditional approach just needs some small number of result buses.
>>>>>
>>>>>
>>>>
>>>> Still not :-)
>>>>
>>>> Our FU slots can (and typically do) support operations of different
>>>> natural latencies (pipe lengths). Each slot can accept one op per
>>>> cycle, so if the latencies differ you can get more than one result
>>>> retiring in the same cycle. Consequently the FUs have one result FF
>>>> per supported latency.
>>>>
>>>> If a op of latency N retires in cycle C to FF#N, necessarily the
>>>> following cycle C+1 the FF#N+1 is free (think about it). Consequently,
>>>> the FU's FFs are daisy chained so that each cycle FF#N is moved to
>>>> FF#N+1  and every result always is retiring to a known free FF; the
>>>> set of FFs are right next to each other so the move is trivial.
>>>
>>> This sounds like it has a belt's worth of FF for each FU.
>>> And some of them are shift registers?
>>> I'm a bit confused.
>>
>> There can be (and usually are) several FUs per slot, forming in effect a
>> "superFU". There is only one set of output FFs per slot, one per
>> latency. These are daisy chained. I suppose that you can think of the
>> output FF daisy as being a shift register, and it could be done that
>> way, but it also could be done by simply rotating which FF is considered
>> which latency, thereby replacing a physical data move with a
>> result-to-FF fanout. That's a HW design choice; IANAHWG.
>>
>>> I envisioned this having 1 belt of FF values and two crossbars,
>>> one crossbar to route any belt FF to any FU operands,
>>> one to route any FU result to the proper empty FF for its latency.
>>
>> Only one crossbar, which routes belt FF to slot operands. The slots know
>> which op has which latency and so directly connect the compute logic to
>> the right output FF. Say a slot has a 1-cycle adder and a 3-cycle
>> multiplier. The adder will be connected directly to the lat1 FF, the
>> mult to the lat3 FF, and nothing will go to the lat2 FF; this is not a
>> crossbar.
>>
>> Meanwhile, the lat1 FF daisies to the lat2 FF, the lat2 FF to the lat3,
>> and the lat3 to the spiller (although the config might put a lat4 or
>> more in there, depending on the tradeoff between more sources on the
>> input crossbar vs more value making it all the way op the daisy to press
>> on the spiller).
>>
>>> It is the logical to physical map that actually shifts.
>>> And a scoreboard tracks when FF operands are ready
>>> and are written into their correct physical slot.
>>>
>>>   Belt
>>>    FF ---->Xbar<--Map
>>>    ^       |  |
>>>    |       v  |
>>>   Xbar<---FU  v
>>>       <------FU
>>>
>> There's no scoreboard, because Mill is statically scheduled. The FU
>> result either goes direct to the right FF (which is actually built into
>> that FU) or fans out to it 1->N, so there's no second xbar. If you did
>> put in a scoreboard then you could use dynamic scheduling.
>>
>> However, dynamic requires another xbar into the scoreboard, and xbars
>> get out of hand quickly with increasing concurrency; the practical limit
>> seems to be around 8-way issue even with ridiculously long pipes. Mill
>> is intended for use up into concurrencies in the 20-30 range, so static
>> seems the only way to go, with other devices to avoid costs like cache
>> misses.
>
> Apple dominating Spec with the M1 while not having HyperThreading is
> something I had though impossible due to dram misses. So a smart enough CPU
> can pull of what you claim, which I was polite enough not to mock. Barely,
> dodged a bullet there. ;)
>
> I used to think Mill was doomed due to not going OoOE, curing mindset is
> hard.
> Apple has corrected my mindset and I now believe you can beat OoOE, at far
> lower cost and power. Pointing out the Apple M1 crushing x86 is something
> you could add to your investor relations. Break the x86 mindset.
>
> But you don’t have a billion dollars of brute force to add those smarts in
> every corner to prevent glass jaws. ;(
>
> Your biggest glass jaw may be aliasing in C code forcing crap code
> generation, you can add speculation and replay on fault to cure this. But
> that may cost more than you can afford on your first designs?
>
> This one change would convince every good programmer that Mill is viable,
> and could beat Apple’s 6 wide design. Otherwise you can’t do effective 6
> wide as aliasing caps your performance, you have a write every 6
> instructions at most.

Aliasing doesn't seem to be a problem. There is enough bandwidth in the
hierarchy that we can issue all the loads and stores as fast as their
arguments are available. Requests are issued in program order with no
overtaking, so there's no ambiguity. Deferred loads let is issue a load
before a store that is ahead of it in program order; the load retire
stations snoop the requests and reissue is a collision is detected
(which is rare). There's no LSQ; the L1 victim buffers serve for that.

We don't (yet) have address prediction, so stepping through a pointer
chain requires the loads to be done one by one. There's no good example
of that in our test suite; we may reopen the issue when we have a case
in hand.

On 1/6/2022 7:33 PM, MitchAlsup wrote:
> On Thursday, January 6, 2022 at 9:26:01 PM UTC-6, gg...@yahoo.com wrote:
>> Ivan Godard <iv...@millcomputing.com> wrote:
>
>> Apple dominating Spec with the M1 while not having HyperThreading is
>> something I had though impossible due to dram misses.
> <
> So, you bought into the <ahem> hype !
> <
>> So a smart enough CPU
>> can pull of what you claim, which I was polite enough not to mock. Barely,
>> dodged a bullet there. ;)
>>
>> I used to think Mill was doomed due to not going OoOE, curing mindset is
>> hard.
>> Apple has corrected my mindset and I now believe you can beat OoOE, at far
>> lower cost and power. Pointing out the Apple M1 crushing x86 is something
>> you could add to your investor relations. Break the x86 mindset.
>>
>> But you don’t have a billion dollars of brute force to add those smarts in
>> every corner to prevent glass jaws. ;(
>>
>> Your biggest glass jaw may be aliasing in C code forcing crap code
>> generation, you can add speculation and replay on fault to cure this. But
>> that may cost more than you can afford on your first designs?
> <
> The thing I don't understand about Mill (of whom I am a fan) is what kind
> of code gets produced when 7 out of 8 loops run alias free, but the 8th
> iteration does something different (alias, miss, TLB,...) than the other loops.

If any iteration load-misses for longer than the delay then we stall;
it's an in-order machine. Stores cannot miss, although if the store rate
exceeds the DRAM write rate for long enough you will stall after you've
filled all the caches. Caches are in virtual so aliasing doesn't matter.
TLB is after the caches and is all lazy and doesn't impact loops at all,
unless a load misses all the caches and also the TLB (very rare; entries
are very big). The PLB can miss, but that too is very rare because the
entries cover all of a mmap allocation no matter how big.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Marcus wrote:
>
>> On 2021-12-30, EricP wrote:
>>
>>> C,C++ and a bunch of languages explicitly define booleans as 0 or 1
>>> so this definition won't be optimal for those languages.
>>> VAX Fortran used 0,-1 for LOGICAL but I don't know if that
>>> was defined by the language or implementation dependant.
>
> -1 is better than 1, it can be used as a mask.
>
>> As a software developer I'm painfully aware of this. I decided not to
>> care too much about it, though. Really, most software that relies on
>> this property of C should be frowned upon. E.g. expressions like:
>>
>> a = b + (c == d);
>>
>> ...aren't really good programming practice.
>
> No! Please tell me it ain't so!
>
> I use that type of constructs [frequently ...]

Totally with you on this. People who don't see the benefit of
using 0/1 values instead of if/else in cases like this are stuck
in an antiquated way of thinking.

Marcus <m.delete@this.bitsnbites.eu> writes:

> On 2021-12-31, Terje Mathisen wrote:
>
>> Marcus wrote:
>>
>>> On 2021-12-30, EricP wrote:
>>>
>>>> C,C++ and a bunch of languages explicitly define booleans as 0 or
>>>> 1 so this definition won't be optimal for those languages. VAX
>>>> Fortran used 0,-1 for LOGICAL but I don't know if that was
>>>> defined by the language or implementation dependant.
>>
>> -1 is better than 1, it can be used as a mask.
>>
>>> As a software developer I'm painfully aware of this. I decided
>>> not to care too much about it, though. Really, most software that
>>> relies on this property of C should be frowned upon. E.g.,
>>> expressions like:
>>>
>>> a = b + (c == d);
>>>
>>> ...aren't really good programming practice.
>>
>> No! Please tell me it ain't so!
>>
>> I use that type of constructs all over the place when writing
>> branchless code/doing table lookups etc.
>
> I think that you'll find that the following code produces the
> exact same result:
>
> int a;
> if (c == d) {
> a = b + 1;
> } else {
> a = b;
> }
>
> It too is completely branchless.

Being branchless is not the high order bit here.

> My main gripe with the former version is the implicit type
> conversion (boolean to integer), and that I don't like to see
> logical operands and arithmetic operands mixed in the same
> expression.

Apparently you are thinking of some other language, not C.
The result of comparison operators such as == have type int,
not some boolean type. And that is not just an accident.

EricP <ThatWouldBeTelling@thevillage.com> writes:

> The & and | operators normally act on integral data types [...]

Please forgive me for bringing up a technical fine point. The
operators & and | normally act on integer data types, not
integral data types. (In fact C doesn't have "integral" data
types.) The distinction is not just rhetorical: a constant such
as 3.0 has an integral value, but it does not have an integer
value.

Ivan Godard <ivan@millcomputing.com> writes:

[ on splitting registers by type ]

> Splitting regs by type does offer some code (and encoding)
> advantages, but also some drawbacks. Think about how you would
> do VARARGS when bools are passed in the flags :-)

Not an issue, because variadic arguments of boolean type are
promoted to int before being passed. Indeed, one reason for
that rule is precisely to avoid the kinds of questions that
come up with narrow types such as booleans.