On 6/28/2021 10:36 AM, BGB wrote:
> On 6/26/2021 10:43 AM, MitchAlsup wrote:
>> On Saturday, June 26, 2021 at 4:32:18 AM UTC-5, Thomas Koenig wrote:
>>> Split register files have been proposed, for example in
>>> http://www.owlnet.rice.edu/~elec525/projects/prf_report.pdf .
>>> However, at least in this report the ISA was not changed.
>>>
>>> So, how about this:
>> <><><>
>>>
>>> Comments? Would offer no advantages over conventional ooO
>>> architecture? Has been tried before and didn't catch on
>>> because...?
>> <
>> Just put me down as no. How registers are named and used is a compiler
>> problem not a hardware problem.
>
> Agreed.
>
>
>> <
>> If you need more read ports, replicate the register file and see that
>> both
>> copies get the same values written into them.
>> <
>> If you need more write ports, you are already SoL.
>>
>
> IME, what worked OK on Xilinx FPGAs:
>   Clone the register arrays for each read port;
>   Clone the register arrays again for each write port;
>   Use an array of tag bits to encode which array is up-to-date.
>
> For 6R+3W, this effectively means 18 internal copies of the main
> register array, plus a mess of internal 2-bit tag-bit registers.

I don't understand this. Let's say you write to one register. Say it
happens to be lane 1. Subsequent reads must come from that copy, and
not any other (as they are not current), so the extra read ports and
register copies are unused. You have the same contention issues, lots
more hardware and no benefit.

What am I missing?

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

On 6/28/2021 1:19 PM, Stephen Fuld wrote:
> On 6/28/2021 10:36 AM, BGB wrote:
>> On 6/26/2021 10:43 AM, MitchAlsup wrote:
>>> On Saturday, June 26, 2021 at 4:32:18 AM UTC-5, Thomas Koenig wrote:
>>>> Split register files have been proposed, for example in
>>>> http://www.owlnet.rice.edu/~elec525/projects/prf_report.pdf .
>>>> However, at least in this report the ISA was not changed.
>>>>
>>>> So, how about this:
>>> <><><>
>>>>
>>>> Comments? Would offer no advantages over conventional ooO
>>>> architecture? Has been tried before and didn't catch on
>>>> because...?
>>> <
>>> Just put me down as no. How registers are named and used is a compiler
>>> problem not a hardware problem.
>>
>> Agreed.
>>
>>
>>> <
>>> If you need more read ports, replicate the register file and see that
>>> both
>>> copies get the same values written into them.
>>> <
>>> If you need more write ports, you are already SoL.
>>>
>>
>> IME, what worked OK on Xilinx FPGAs:
>>    Clone the register arrays for each read port;
>>    Clone the register arrays again for each write port;
>>    Use an array of tag bits to encode which array is up-to-date.
>>
>> For 6R+3W, this effectively means 18 internal copies of the main
>> register array, plus a mess of internal 2-bit tag-bit registers.
>
> I don't understand this.  Let's say you write to one register.  Say it
> happens to be lane 1.  Subsequent reads must come from that copy, and
> not any other (as they are not current), so the extra read ports and
> register copies are unused.  You have the same contention issues, lots
> more hardware and no benefit.
>
> What am I missing?
>

Both LUTRAM (Distributed RAM) and Block-RAM follows a pattern where you
can generally write to it in one location and read from it in another.

LUTRAM is slightly more flexible in the sense that it can be read via
combinatorial logic, whereas Block-RAM can't (can only be read via a
clock-edge), ...

But, internally LUTRAM is fairly specific about having a 1:1 mapping
between input and output locations (it effectively only has two
unidirectional ports; so one port can only write to the array, and the
other can only read from it).

One can do multiple reads from a array in Verilog (so, write from one
location, read from multiple locations), but typically it ends up being
implicitly duplicated between each location it is accessed from when
this is done.

But, as soon as one tries to write to the same array from multiple
locations, "crap hits the fan" in terms of resource costs. Not sure what
happens exactly, but the LUT cost basically goes insane when this happens.

Hence the use of the 2-bit tag array, which at least partly contains
this issue. While the tag array itself still suffers from this issue,
given it is only 2 bits wide (so, ~ 128 bits for 64 GPRs), the relative
cost is a lot less than if it were 64 bits wide.

In order to follow 1:1 pattern, one effectively ends up with the arrays
being duplicated both based on the write ports, as well as the read
ports, and so 3*6=18.

And, every time one stores a value via a write port, it ends up being
duplicated to 6 different arrays in parallel (one accessible via each of
the read ports), and reading from a read port reads from one of the 3
arrays it has access to, one from each write port, based on the tag bits
for the associated register.

As noted, something about this pattern breaks on Altera FPGAs though,
implying there may be some significant functional difference in how they
handle LUTRAM.

In the fallback case, the 2nd place option basically replaces the LUTRAM
arrays with a bunch of state-machine registers (Flip-Flops) and a big
"case()" block to select values from the various registers for the
various register ports. This approach seems to have a lower per-port
cost, but is a lot more sensitive to the number and size of the registers.

But, yeah, if there is a cheaper way to do all this, it might be useful
to know about...

On Saturday, June 26, 2021 at 8:03:56 AM UTC-6, Anton Ertl wrote:

> url = {http://www.ece.wisc.edu/~hskim/papers/kimh_ildp.pdf},

> url = {http://www.ece.wisc.edu/~wddd/2007/papers/wddd_01.pdf},
> url2 = {http://www-sal.cs.uiuc.edu/~zilles/papers/lanes.wddd-2007.pdf},

Sad to say, your links are broken.

John Savard

On Monday, June 28, 2021 at 4:28:15 PM UTC-5, BGB wrote:
> On 6/28/2021 1:19 PM, Stephen Fuld wrote:
> > On 6/28/2021 10:36 AM, BGB wrote:
> >> On 6/26/2021 10:43 AM, MitchAlsup wrote:
> >>> On Saturday, June 26, 2021 at 4:32:18 AM UTC-5, Thomas Koenig wrote:
> >>>> Split register files have been proposed, for example in
> >>>> http://www.owlnet.rice.edu/~elec525/projects/prf_report.pdf .
> >>>> However, at least in this report the ISA was not changed.
> >>>>
> >>>> So, how about this:
> >>> <><><>
> >>>>
> >>>> Comments? Would offer no advantages over conventional ooO
> >>>> architecture? Has been tried before and didn't catch on
> >>>> because...?
> >>> <
> >>> Just put me down as no. How registers are named and used is a compiler
> >>> problem not a hardware problem.
> >>
> >> Agreed.
> >>
> >>
> >>> <
> >>> If you need more read ports, replicate the register file and see that
> >>> both
> >>> copies get the same values written into them.
> >>> <
> >>> If you need more write ports, you are already SoL.
> >>>
> >>
> >> IME, what worked OK on Xilinx FPGAs:
> >> Clone the register arrays for each read port;
> >> Clone the register arrays again for each write port;
> >> Use an array of tag bits to encode which array is up-to-date.
> >>
> >> For 6R+3W, this effectively means 18 internal copies of the main
> >> register array, plus a mess of internal 2-bit tag-bit registers.
> >
> > I don't understand this. Let's say you write to one register. Say it
> > happens to be lane 1. Subsequent reads must come from that copy, and
> > not any other (as they are not current), so the extra read ports and
> > register copies are unused. You have the same contention issues, lots
> > more hardware and no benefit.
> >
> > What am I missing?
> >
> Both LUTRAM (Distributed RAM) and Block-RAM follows a pattern where you
> can generally write to it in one location and read from it in another.
<
In a single clock cycle.
>
> LUTRAM is slightly more flexible in the sense that it can be read via
> combinatorial logic, whereas Block-RAM can't (can only be read via a
> clock-edge), ...
<
By capturing of the address at the clock edge and presenting read data
by the successive clock edge.
>
> But, internally LUTRAM is fairly specific about having a 1:1 mapping
> between input and output locations (it effectively only has two
> unidirectional ports; so one port can only write to the array, and the
> other can only read from it).
>
> One can do multiple reads from a array in Verilog (so, write from one
> location, read from multiple locations), but typically it ends up being
> implicitly duplicated between each location it is accessed from when
> this is done.
<
Reads can be done with decoder selecting multiplexer outputs.
Writes are more complicated in that one needs to multiplex the write
from several write busses and coordinate with a select line. If you try
to write the same register from two ports at the same time, the logic
can actually kill itself--two current sources fighting over a single voltage.
>
>
> But, as soon as one tries to write to the same array from multiple
> locations, "crap hits the fan" in terms of resource costs. Not sure what
> happens exactly, but the LUT cost basically goes insane when this happens.
<
Whereas read ports are vectors of multiplexers spread over an array of
latches/flip-flops, Write ports have a multiplexer from the several writing
buses to each register and "a bit more logic". Write ports are about
quadratically more gates than read ports.
>
> Hence the use of the 2-bit tag array, which at least partly contains
> this issue. While the tag array itself still suffers from this issue,
> given it is only 2 bits wide (so, ~ 128 bits for 64 GPRs), the relative
> cost is a lot less than if it were 64 bits wide.
>
>
> In order to follow 1:1 pattern, one effectively ends up with the arrays
> being duplicated both based on the write ports, as well as the read
> ports, and so 3*6=18.
>
> And, every time one stores a value via a write port, it ends up being
> duplicated to 6 different arrays in parallel (one accessible via each of
> the read ports), and reading from a read port reads from one of the 3
> arrays it has access to, one from each write port, based on the tag bits
> for the associated register.
>
>
> As noted, something about this pattern breaks on Altera FPGAs though,
> implying there may be some significant functional difference in how they
> handle LUTRAM.
>
>
> In the fallback case, the 2nd place option basically replaces the LUTRAM
> arrays with a bunch of state-machine registers (Flip-Flops) and a big
> "case()" block to select values from the various registers for the
> various register ports. This approach seems to have a lower per-port
> cost, but is a lot more sensitive to the number and size of the registers.
>
>
> But, yeah, if there is a cheaper way to do all this, it might be useful
> to know about...
<
There is at the transistor level, there is not from the gate level.

On Saturday, June 26, 2021 at 8:03:56 AM UTC-6, Anton Ertl wrote:

> ILDP has been evaluated by other researchers [salverda&zilles07], and
> found to have more disadvantages than the original paper promised.

Despite the link being broken, Googling the original paper turned it up.

The proposed architecture seems to work like this:

There are eight accumulators; each one is associated with its own
pipeline. There's a bank of 64 registers, shared between the eight
pipelines.

This way, each pipeline can be in-order, but the computer is keeping
busy since instructions belonging to different strands are interleaved
in the program.

John Savard

On Monday, June 28, 2021 at 5:50:49 PM UTC-5, Quadibloc wrote:
> On Saturday, June 26, 2021 at 8:03:56 AM UTC-6, Anton Ertl wrote:
> > ILDP has been evaluated by other researchers [salverda&zilles07], and
> > found to have more disadvantages than the original paper promised.
> Despite the link being broken, Googling the original paper turned it up.
>
> The proposed architecture seems to work like this:
>
> There are eight accumulators; each one is associated with its own
> pipeline. There's a bank of 64 registers, shared between the eight
> pipelines.
>
> This way, each pipeline can be in-order, but the computer is keeping
> busy since instructions belonging to different strands are interleaved
> in the program.
>
> John Savard
<
Make 8 into 4 and 64 registers into 32 and it describes the Mc 88100
pipeline.

On 6/28/2021 5:33 PM, MitchAlsup wrote:
> On Monday, June 28, 2021 at 4:28:15 PM UTC-5, BGB wrote:
>> On 6/28/2021 1:19 PM, Stephen Fuld wrote:
>>> On 6/28/2021 10:36 AM, BGB wrote:
>>>> On 6/26/2021 10:43 AM, MitchAlsup wrote:
>>>>> On Saturday, June 26, 2021 at 4:32:18 AM UTC-5, Thomas Koenig wrote:
>>>>>> Split register files have been proposed, for example in
>>>>>> http://www.owlnet.rice.edu/~elec525/projects/prf_report.pdf .
>>>>>> However, at least in this report the ISA was not changed.
>>>>>>
>>>>>> So, how about this:
>>>>> <><><>
>>>>>>
>>>>>> Comments? Would offer no advantages over conventional ooO
>>>>>> architecture? Has been tried before and didn't catch on
>>>>>> because...?
>>>>> <
>>>>> Just put me down as no. How registers are named and used is a compiler
>>>>> problem not a hardware problem.
>>>>
>>>> Agreed.
>>>>
>>>>
>>>>> <
>>>>> If you need more read ports, replicate the register file and see that
>>>>> both
>>>>> copies get the same values written into them.
>>>>> <
>>>>> If you need more write ports, you are already SoL.
>>>>>
>>>>
>>>> IME, what worked OK on Xilinx FPGAs:
>>>> Clone the register arrays for each read port;
>>>> Clone the register arrays again for each write port;
>>>> Use an array of tag bits to encode which array is up-to-date.
>>>>
>>>> For 6R+3W, this effectively means 18 internal copies of the main
>>>> register array, plus a mess of internal 2-bit tag-bit registers.
>>>
>>> I don't understand this. Let's say you write to one register. Say it
>>> happens to be lane 1. Subsequent reads must come from that copy, and
>>> not any other (as they are not current), so the extra read ports and
>>> register copies are unused. You have the same contention issues, lots
>>> more hardware and no benefit.
>>>
>>> What am I missing?
>>>
>> Both LUTRAM (Distributed RAM) and Block-RAM follows a pattern where you
>> can generally write to it in one location and read from it in another.
> <
> In a single clock cycle.

Yeah.

One can possibly do more stuff if they treat the read and write cases as
mutually exclusive.

One can generally read from and write to BRAM every cycle, though if
reading from the same location that was just written to, the data tends
to be stale (forwarding logic is generally needed to work around this case).

>>
>> LUTRAM is slightly more flexible in the sense that it can be read via
>> combinatorial logic, whereas Block-RAM can't (can only be read via a
>> clock-edge), ...
> <
> By capturing of the address at the clock edge and presenting read data
> by the successive clock edge.

Yeah.

Looking into it, it seems that Xilinx and Altera differ here slightly:
Xilinx allows the LUTRAM to use a combinatorial access pattern.

Most of the Altera LUTRAM seems to use a pattern of using rising and
falling clock edges for input and output for most other LUTRAM sizes.

So, Xilinx LUTRAMs are:
32x3 bit;
64x2 bit;
128x1 bit.

With write-on-rising-edge / read-whenever behavior.

And, Altera is (Cyclone V):
32x20 bit (MLAB-640)

With write on falling edge, read on rising edge.

Not sure if an MLAB can be split up and used as multiple (independent)
RAMs, or if it always (only) uses the entire 20 bits.

And, apparently, if it doesn't fit into the above pattern, it is faked
using LUTs and Flip-Flops.

This sort of implies that at-best, each copy of the GPR array would need
8x MLABs, or 144 MLABs per core (where 1 MLAB ~= 10 adjacent ALMs ~= 20
LUT6's; with up to 1/4 of the device usable as MLABs).

So, best possible case, the GPR file in the BJX2 core should use ~ 14%
of the LUTRAM budget in a DE10 or similar (still unconfirmed if Quartus
will accept 64-element arrays assuming edge-timing behavior is followed,
....).

....

So, I guess a difference here is that the Xilinx LUTRAM is a little more
flexible and fine-grained, whereas the Altera LUTRAM is less flexible
and coarser grained.

Either way, can note that my initial tests trying to synthesize stuff
for a DE10 didn't particularly make me want to jump out and buy one
(more so when it is also "kinda expensive").

>>
>> But, internally LUTRAM is fairly specific about having a 1:1 mapping
>> between input and output locations (it effectively only has two
>> unidirectional ports; so one port can only write to the array, and the
>> other can only read from it).
>>
>> One can do multiple reads from a array in Verilog (so, write from one
>> location, read from multiple locations), but typically it ends up being
>> implicitly duplicated between each location it is accessed from when
>> this is done.
> <
> Reads can be done with decoder selecting multiplexer outputs.
> Writes are more complicated in that one needs to multiplex the write
> from several write busses and coordinate with a select line. If you try
> to write the same register from two ports at the same time, the logic
> can actually kill itself--two current sources fighting over a single voltage.

OK.

>>
>>
>> But, as soon as one tries to write to the same array from multiple
>> locations, "crap hits the fan" in terms of resource costs. Not sure what
>> happens exactly, but the LUT cost basically goes insane when this happens.
> <
> Whereas read ports are vectors of multiplexers spread over an array of
> latches/flip-flops, Write ports have a multiplexer from the several writing
> buses to each register and "a bit more logic". Write ports are about
> quadratically more gates than read ports.

Or something like this.

In any case, the naive strategy of trying to use the same array being
written from multiple locations at the same time is "don't do it, it is
bad"...

Would be nice if the Verilog compiler were like "Well, I can transform
it into several LUTRAMs and some tag bits", but instead the pattern
tends to be more like "Well, it doesn't fit one of the known patterns;
fake it using an epic crap ton of LUTs and FFs instead...".

>>
>> Hence the use of the 2-bit tag array, which at least partly contains
>> this issue. While the tag array itself still suffers from this issue,
>> given it is only 2 bits wide (so, ~ 128 bits for 64 GPRs), the relative
>> cost is a lot less than if it were 64 bits wide.
>>
>>
>> In order to follow 1:1 pattern, one effectively ends up with the arrays
>> being duplicated both based on the write ports, as well as the read
>> ports, and so 3*6=18.
>>
>> And, every time one stores a value via a write port, it ends up being
>> duplicated to 6 different arrays in parallel (one accessible via each of
>> the read ports), and reading from a read port reads from one of the 3
>> arrays it has access to, one from each write port, based on the tag bits
>> for the associated register.
>>
>>
>> As noted, something about this pattern breaks on Altera FPGAs though,
>> implying there may be some significant functional difference in how they
>> handle LUTRAM.
>>
>>
>> In the fallback case, the 2nd place option basically replaces the LUTRAM
>> arrays with a bunch of state-machine registers (Flip-Flops) and a big
>> "case()" block to select values from the various registers for the
>> various register ports. This approach seems to have a lower per-port
>> cost, but is a lot more sensitive to the number and size of the registers.
>>
>>
>> But, yeah, if there is a cheaper way to do all this, it might be useful
>> to know about...
> <
> There is at the transistor level, there is not from the gate level.
>

OK.

On Monday, June 28, 2021 at 5:55:49 PM UTC-6, MitchAlsup wrote:

> Make 8 into 4 and 64 registers into 32 and it describes the Mc 88100
> pipeline.

I looked into the 88100 again after that.

It is a tragic story that it got pushed aside by the PowerPC from IBM,
just like how PA-RISC got pushed aside by the Itanium.

I suppose you can say the 88100 had four pipelines - one for integer,
one for floating-point, two for the memory controllers - but that's not
what that paper was talking about. The paper was describing a system
where there were eight accumulators visible to the programmer, and
eight integer pipelines associated with them. If floating-point is added,
there would be another eight floating-point pipelines perhaps.

So they don't seem to have stolen your idea.

John Savard

On Monday, June 28, 2021 at 11:03:20 PM UTC-6, Quadibloc wrote:

> It is a tragic story that it got pushed aside by the PowerPC from IBM,
> just like how PA-RISC got pushed aside by the Itanium.

Of course, that part of the story would have been _more_ tragic had
it not been for the truly tragic part - of how Motorola couldn't price
the 88100 aggressively to give it a start because of infighting from the
68000 section of the company.

Would Lisa Su have put up with that kind of nonsense within AMD for
a second?

Now, it _is_ true that AMD might be said to have "done the same thing" in
a sense - it shelved a project to make ARM server chips in order to concentrate
on Ryzen. But while there's a similarity, in that x86 and the 68k are "present-day"
projects, and moving to ARM or to RISC with the 88100 are investments in the
future, I think it's far and away clear that what AMD did was in the best interests of
the company as a whole, with its limited development resources, while what
Motorola did was not.

John Savard

On 6/28/2021 10:09 PM, Quadibloc wrote:
> On Monday, June 28, 2021 at 11:03:20 PM UTC-6, Quadibloc wrote:
>
>> It is a tragic story that it got pushed aside by the PowerPC from IBM,
>> just like how PA-RISC got pushed aside by the Itanium.
>
> Of course, that part of the story would have been _more_ tragic had
> it not been for the truly tragic part - of how Motorola couldn't price
> the 88100 aggressively to give it a start because of infighting from the
> 68000 section of the company.
>
> Would Lisa Su have put up with that kind of nonsense within AMD for
> a second?
>
> Now, it _is_ true that AMD might be said to have "done the same thing" in
> a sense - it shelved a project to make ARM server chips in order to concentrate
> on Ryzen.

Also, in the mid 1990s they dropped any future development for their
existing 29000 series of RISC chips

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

On Tuesday, June 29, 2021 at 12:03:20 AM UTC-5, Quadibloc wrote:
> On Monday, June 28, 2021 at 5:55:49 PM UTC-6, MitchAlsup wrote:
>
> > Make 8 into 4 and 64 registers into 32 and it describes the Mc 88100
> > pipeline.
> I looked into the 88100 again after that.
>
> It is a tragic story that it got pushed aside by the PowerPC from IBM,
> just like how PA-RISC got pushed aside by the Itanium.
>
> I suppose you can say the 88100 had four pipelines - one for integer,
> one for floating-point, two for the memory controllers - but that's not
> what that paper was talking about.
<
4 data pipelines {integer, memory, FADD, and FMUL} and
1 inst pipeline {fetch}
<
> The paper was describing a system
> where there were eight accumulators visible to the programmer, and
> eight integer pipelines associated with them. If floating-point is added,
> there would be another eight floating-point pipelines perhaps.
>
> So they don't seem to have stolen your idea.
<
I was not complaining about a steal, I was pointing out that, like them,
there are other computers that consist of multiple in order pipelines.
I generally reserve the word-pair "Partially ordered" to describe multiple
in order pipelines. it is like the difference between MM markov models
and GG markov models.
>
> John Savard

On Tuesday, June 29, 2021 at 1:09:19 AM UTC-4, Quadibloc wrote:
[snip]
> Of course, that part of the story would have been _more_ tragic had
> it not been for the truly tragic part - of how Motorola couldn't price
> the 88100 aggressively to give it a start because of infighting from the
> 68000 section of the company.

I doubt M88k could have succeeded as a merchant RISC processor.
The Unix workstation market fragmented in ISA (even more than in
software), I think, in large part because the vendors (HP, Sun, IBM, DEC,
SGI?) were large enough to do their own in-house RISCs (a RISC ISA is
easier to design and easier to implement) and were used to vertical
integration (in some cases down to fabrication).

MIPS tried to be a merchant vendor but failed.

Unix eventually developed standardization (and has seemed to move
to just 'Linux-compatible'), but even with a common parent and
initial software base HP-UX was (I have read) very different from
AIX which was different from Solaris, and so on.

One of the reasons Itanium was expected to do better was
that it was expected to be a merchant processor with Intel
selling the same product to any buyer without discrimination.
Even if the ISA/architectural concept did not have issues and
x86 had not been extended to 64 bits, Itanium would not
have matched the hope because HP was given preferential
treatment and with increasing integration (and volume
effects) system-level hardware distinctives become less
cost-effective. (EPIC issues and x86-64 did exist, so such
secondary effects were not as significant.)

The role of merchant processor vendor is not easy.
ARM avoided this by (mainly) not making chips, being a
design (and support) vendor. (This also meant that some
optimizations were hindered — e.g., cores were less tuned
to their memory systems because users would want to
configure different memory systems.)

Paul A. Clayton <paaronclayton@gmail.com> schrieb:

> Unix eventually developed standardization (and has seemed to move
> to just 'Linux-compatible'), but even with a common parent and
> initial software base HP-UX was (I have read) very different from
> AIX which was different from Solaris, and so on.

In those days, compiling an open source package was a bit
of a nightmare... all those #ifdef __HPUX (or whatever you
had).

I still have a login on an AIX and a Solaris box. AIX feels...
strange:

$ ls asdfasdfasdf
ls: 0653-341 The file asdfasdfasdf does not exist.

Numbered error messages are so IBM and so not UNIX.

In article <e8cd2e19-e6eb-42c7-b1e3-8a507e269c98n@googlegroups.com>,
paaronclayton@gmail.com (Paul A. Clayton) wrote:

> ... HP-UX was (I have read) very different from
> AIX which was different from Solaris, and so on.

Significantly different: API differences, different compiler and linker
options, different content in system headers, weird memory layouts of
their own for 32-bit processes (64-bit are much more alike), different
ideas about shared libraries. Nothing that you can't overcome, but you
need a fairly generalised set of development tooling to do it.

> Itanium would not have matched the hope because HP was given
> preferential treatment and with increasing integration (and
> volume effects) system-level hardware distinctives become less
> cost-effective.

A contributing factor was that Intel allowed HP to have a monopoly on
motherboard chipsets for small systems. That meant that ISVs who wanted
to support Itanium on a small scale had to buy HP's systems, which were
expensive (an HP-UX license was priced in) and kind of fiddly to
administer. That meant that ISVs tended to go "maybe next year?" and
little software was available.

John

"Thomas Koenig" wrote in message
news:sbadsa$r84$1@newsreader4.netcologne.de...

> James Van Buskirk <not_valid@comcast.net> schrieb:

> > Do you support pivot operations, like a perhaps partial bit
> > reversal permutation of the register file?

> I haven't given it any thought so far (but then again,
> I am not sure what exactly this means).

> Could you maybe elaborate?

An FFT can be thought of as factoring the DFT matrix into matrices
with at most 2 nonzero entries per row. The conceptually simplest
realization of an FFT algorithm thus reads two values from memory
and then produces two linear combinations of them using values
loaded from the constants pool and then stores the results back
in memory. Even if everything comes from L1 cache this process
kind of blows up your load-store bandwidth.

You can minimize cache access by loading 2**N values into the
register file and them walking them through N stages (effective
factor matrix multiplies) before once again entrusting the results
to the memory subsystem.

With the register file organized into 8 conspiracies or 'cells' of 8
registers each which can't talk to each other directly but only
via dedicated data swizzling operations you are limited to N=3
before you have to reshuffle the data between cells and even
then you have the problem of intermediate results and
constants trying to burst the scheme at its seams. The data
swizzling amounts to bit-reversed addressing so if it could be
achieved by some magic operation that would get us to N=6
or thereabouts.

Various flavors of DCTs share the core algorithm with full-
complex and real-half complex FFTs so this magic would seem
to have the potential to help all of these algorithms.

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Brett <ggtgp@yahoo.com> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>> On 6/26/2021 2:32 AM, Thomas Koenig wrote:
>>>
>>>> See the Texas Instruments C64
>>>
>>> That's rather interesting, thanks!
>>>
>>> Looks rather similar to what I had in mind, except that they allow
>>> at least some cross-operation between the different register files,
>>> and they had 16 registers (later 32) per register file.
>>>
>>
>> I like it, however I would burn two instruction bits for the two banks.
>> So you can say bank 0, bank 1, both banks, sequential load to both, etc.
>
> What would you appy them to? Assuming a three-register instruction,
> (and assuming that r0-15 are in the first bank and r16-r31 in the
> second) would you then be able to write
>
> add r2,r17,r22

Add.12 r2,r17,r22 ; both banks run same instruction.

A loop unroll of one is just tagging the opcode to run on both banks.
Which gives good code density.

Add.1s r2,r17,r22 ; add bank 1 but splat result to both banks.

Also would do load pair splat, so banks get sequential items for loop
unroll use, which saves an address register in the second bank from having
to be a clone plus 1 and other grief. The saved register could then be your
loop index, etc.

You get loop unrolling without doubling your rename width or ports, both of
which are critical limits to scaling.

> (so the bank 1 ALU presumably does the calculation and sends over
> the result to bank 0)?
>
> Also, this would use one bit only if you have two banks. I was
> envisioning more than two, then the advantage in encoding bits
> starts to disappear.

You can use 2 bank bits and 1 splat or other bit, cheaper than three 6 bit
register specifiers. 2+1+(3*4) = 15, verses 3*6 = 18.

With four banks the four common choices are; bank 1, all, alternate primary
bank, and all but primary bank. Which is better than my 2 bank mask bits in
the same opcode space.

You can expand this to 3 bits, or the full 4 bit mask each bank which is
wasteful. There is also the issue of splat variants if any, which may
better be handled by other opcodes. There will be a copy bank register
instruction that handles all the tough cases.

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Paul A. Clayton <paaronclayton@gmail.com> schrieb:
>
>> Unix eventually developed standardization (and has seemed to move
>> to just 'Linux-compatible'), but even with a common parent and
>> initial software base HP-UX was (I have read) very different from
>> AIX which was different from Solaris, and so on.
>
> In those days, compiling an open source package was a bit
> of a nightmare... all those #ifdef __HPUX (or whatever you
> had).
>
> I still have a login on an AIX and a Solaris box. AIX feels...
> strange:
>
> $ ls asdfasdfasdf
> ls: 0653-341 The file asdfasdfasdf does not exist.
>
> Numbered error messages are so IBM and so not UNIX.

Numbers are BETTER, I can look a number up and get more diagnostics.
Of course not actually having used AIX I cant say this was truly useful.

Brett <ggtgp@yahoo.com> wrote:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Brett <ggtgp@yahoo.com> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>> On 6/26/2021 2:32 AM, Thomas Koenig wrote:
>>>>
>>>>> See the Texas Instruments C64
>>>>
>>>> That's rather interesting, thanks!
>>>>
>>>> Looks rather similar to what I had in mind, except that they allow
>>>> at least some cross-operation between the different register files,
>>>> and they had 16 registers (later 32) per register file.
>>>>
>>>
>>> I like it, however I would burn two instruction bits for the two banks.
>>> So you can say bank 0, bank 1, both banks, sequential load to both, etc.
>>
>> What would you appy them to? Assuming a three-register instruction,
>> (and assuming that r0-15 are in the first bank and r16-r31 in the
>> second) would you then be able to write
>>
>> add r2,r17,r22
>
> Add.12 r2,r17,r22 ; both banks run same instruction.
>
> A loop unroll of one is just tagging the opcode to run on both banks.
> Which gives good code density.
>
> Add.1s r2,r17,r22 ; add bank 1 but splat result to both banks.
>
> Also would do load pair splat, so banks get sequential items for loop
> unroll use, which saves an address register in the second bank from having
> to be a clone plus 1 and other grief. The saved register could then be your
> loop index, etc.
>
> You get loop unrolling without doubling your rename width or ports, both of
> which are critical limits to scaling.
>
>> (so the bank 1 ALU presumably does the calculation and sends over
>> the result to bank 0)?
>>
>> Also, this would use one bit only if you have two banks. I was
>> envisioning more than two, then the advantage in encoding bits
>> starts to disappear.
>
> You can use 2 bank bits and 1 splat or other bit, cheaper than three 6 bit
> register specifiers. 2+1+(3*4) = 15, verses 3*6 = 18.
>
> With four banks the four common choices are; bank 1, all, alternate primary
> bank, and all but primary bank. Which is better than my 2 bank mask bits in
> the same opcode space.
>
> You can expand this to 3 bits, or the full 4 bit mask each bank which is
> wasteful. There is also the issue of splat variants if any, which may
> better be handled by other opcodes. There will be a copy bank register
> instruction that handles all the tough cases.

I have thought about this some more and how it overlaps vector registers
but with more flexibility and have decided that 5 banks of 16 registers is
best so that one can do away with vector registers since you have that
functionality.

All addressing is done in the first two banks, and the other banks are for
unrolling and long calculations that need more than 16 registers. Only the
last four banks support floating point and vector type operations. All
registers are 64 bits.

Basically a sort of super upgraded RISC 68000, without the crap instruction
set arch and limits. You can’t do addressing in vector registers, but can
with this arch.

You could also do a Mill variant of this arch, and with 5 belts you can
dump the evil kluge visible scratchpad resulting in a nicer cleaner
architecture.

You get 80 general registers and quad loop unrolling without quadrupling
your rename width or ports, both of which are critical limits to scaling.

I like this so much I am going to call this approach post RISC. ;)
You are rolling the vector registers into the general register set and
getting a breakthrough in performance.

On 7/5/2021 12:15 AM, Brett wrote:
> Brett <ggtgp@yahoo.com> wrote:
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>> Brett <ggtgp@yahoo.com> schrieb:
>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>> On 6/26/2021 2:32 AM, Thomas Koenig wrote:
>>>>>
>>>>>> See the Texas Instruments C64
>>>>>
>>>>> That's rather interesting, thanks!
>>>>>
>>>>> Looks rather similar to what I had in mind, except that they allow
>>>>> at least some cross-operation between the different register files,
>>>>> and they had 16 registers (later 32) per register file.
>>>>>
>>>>
>>>> I like it, however I would burn two instruction bits for the two banks.
>>>> So you can say bank 0, bank 1, both banks, sequential load to both, etc.
>>>
>>> What would you appy them to? Assuming a three-register instruction,
>>> (and assuming that r0-15 are in the first bank and r16-r31 in the
>>> second) would you then be able to write
>>>
>>> add r2,r17,r22
>>
>> Add.12 r2,r17,r22 ; both banks run same instruction.
>>
>> A loop unroll of one is just tagging the opcode to run on both banks.
>> Which gives good code density.
>>
>> Add.1s r2,r17,r22 ; add bank 1 but splat result to both banks.
>>
>> Also would do load pair splat, so banks get sequential items for loop
>> unroll use, which saves an address register in the second bank from having
>> to be a clone plus 1 and other grief. The saved register could then be your
>> loop index, etc.
>>
>> You get loop unrolling without doubling your rename width or ports, both of
>> which are critical limits to scaling.
>>
>>> (so the bank 1 ALU presumably does the calculation and sends over
>>> the result to bank 0)?
>>>
>>> Also, this would use one bit only if you have two banks. I was
>>> envisioning more than two, then the advantage in encoding bits
>>> starts to disappear.
>>
>> You can use 2 bank bits and 1 splat or other bit, cheaper than three 6 bit
>> register specifiers. 2+1+(3*4) = 15, verses 3*6 = 18.
>>
>> With four banks the four common choices are; bank 1, all, alternate primary
>> bank, and all but primary bank. Which is better than my 2 bank mask bits in
>> the same opcode space.
>>
>> You can expand this to 3 bits, or the full 4 bit mask each bank which is
>> wasteful. There is also the issue of splat variants if any, which may
>> better be handled by other opcodes. There will be a copy bank register
>> instruction that handles all the tough cases.
>
> I have thought about this some more and how it overlaps vector registers
> but with more flexibility and have decided that 5 banks of 16 registers is
> best so that one can do away with vector registers since you have that
> functionality.
>
> All addressing is done in the first two banks, and the other banks are for
> unrolling and long calculations that need more than 16 registers. Only the
> last four banks support floating point and vector type operations. All
> registers are 64 bits.
>
> Basically a sort of super upgraded RISC 68000, without the crap instruction
> set arch and limits. You can’t do addressing in vector registers, but can
> with this arch.
>
> You could also do a Mill variant of this arch, and with 5 belts you can
> dump the evil kluge visible scratchpad resulting in a nicer cleaner
> architecture.

Code can have unbounded numbers of concurrently live operands that have
to be put somewhere. If you don't have a scratchpad then you have to be
prepared to stash to memory. Even if you do have a scratchpad you have
to be prepared fo it to overflow and need stashing to memory too.
Scratchpad, like registers, is just an optimization of memory for
certain common special cases.

Ivan Godard <ivan@millcomputing.com> wrote:
> On 7/5/2021 12:15 AM, Brett wrote:
>> Brett <ggtgp@yahoo.com> wrote:
>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>> Brett <ggtgp@yahoo.com> schrieb:
>>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>>> On 6/26/2021 2:32 AM, Thomas Koenig wrote:
>>>>>>
>>>>>>> See the Texas Instruments C64
>>>>>>
>>>>>> That's rather interesting, thanks!
>>>>>>
>>>>>> Looks rather similar to what I had in mind, except that they allow
>>>>>> at least some cross-operation between the different register files,
>>>>>> and they had 16 registers (later 32) per register file.
>>>>>>
>>>>>
>>>>> I like it, however I would burn two instruction bits for the two banks.
>>>>> So you can say bank 0, bank 1, both banks, sequential load to both, etc.
>>>>
>>>> What would you appy them to? Assuming a three-register instruction,
>>>> (and assuming that r0-15 are in the first bank and r16-r31 in the
>>>> second) would you then be able to write
>>>>
>>>> add r2,r17,r22
>>>
>>> Add.12 r2,r17,r22 ; both banks run same instruction.
>>>
>>> A loop unroll of one is just tagging the opcode to run on both banks.
>>> Which gives good code density.
>>>
>>> Add.1s r2,r17,r22 ; add bank 1 but splat result to both banks.
>>>
>>> Also would do load pair splat, so banks get sequential items for loop
>>> unroll use, which saves an address register in the second bank from having
>>> to be a clone plus 1 and other grief. The saved register could then be your
>>> loop index, etc.
>>>
>>> You get loop unrolling without doubling your rename width or ports, both of
>>> which are critical limits to scaling.
>>>
>>>> (so the bank 1 ALU presumably does the calculation and sends over
>>>> the result to bank 0)?
>>>>
>>>> Also, this would use one bit only if you have two banks. I was
>>>> envisioning more than two, then the advantage in encoding bits
>>>> starts to disappear.
>>>
>>> You can use 2 bank bits and 1 splat or other bit, cheaper than three 6 bit
>>> register specifiers. 2+1+(3*4) = 15, verses 3*6 = 18.
>>>
>>> With four banks the four common choices are; bank 1, all, alternate primary
>>> bank, and all but primary bank. Which is better than my 2 bank mask bits in
>>> the same opcode space.
>>>
>>> You can expand this to 3 bits, or the full 4 bit mask each bank which is
>>> wasteful. There is also the issue of splat variants if any, which may
>>> better be handled by other opcodes. There will be a copy bank register
>>> instruction that handles all the tough cases.
>>
>> I have thought about this some more and how it overlaps vector registers
>> but with more flexibility and have decided that 5 banks of 16 registers is
>> best so that one can do away with vector registers since you have that
>> functionality.
>>
>> All addressing is done in the first two banks, and the other banks are for
>> unrolling and long calculations that need more than 16 registers. Only the
>> last four banks support floating point and vector type operations. All
>> registers are 64 bits.
>>
>> Basically a sort of super upgraded RISC 68000, without the crap instruction
>> set arch and limits. You can’t do addressing in vector registers, but can
>> with this arch.
>>
>> You could also do a Mill variant of this arch, and with 5 belts you can
>> dump the evil kluge visible scratchpad resulting in a nicer cleaner
>> architecture.
>
> Code can have unbounded numbers of concurrently live operands that have
> to be put somewhere. If you don't have a scratchpad then you have to be
> prepared to stash to memory. Even if you do have a scratchpad you have
> to be prepared fo it to overflow and need stashing to memory too.
> Scratchpad, like registers, is just an optimization of memory for
> certain common special cases.

I have used architectures with scratchpads or that could configure half the
cache as scratchpad, yuck.
And I have the talent to use such, for the average programer the idea is a
joke.

The age of two way caches that suffer aliasing issues is over, use the
cache as God intended.

Of course in your case the compiler is using the scratchpad, and it may
give you more bandwidth, and that bandwidth costs less power than the
cache.

But I still think a scratchpad is an over complicated kludge and thus you
are living in the past. More importantly it will scare off mediocre
programers. The belt is scary enough as is.

On an OS call the scratchpad can leak information unless cleared, a small
performance liability.

The real problem is that you only have one virtual belt, as that makes
opcodes smaller and seemingly makes things simpler. But not all problems
fit in one belt, fat code blows apart a single belt. Thus a scratchpad to
shoehorn more code with good performance. Fat code purely from cache would
perform badly.

You also have compiler issues, which makes handling more belts difficult.
It is easy to say that one bank should be used for globals and thus rarely
rotate, another for addressing and others for compute, but convincing a
compiler to do something intelligent is really hard.

A loop has a limited number of dependent compute chains, it should be
possible to just randomly assign opcode chains to belts. Filling belts
roughly evenly over time.

You have some secrete sauce still I bet to get to 32 ops a cycle, how you
handle vector support spreading across units? Etc. Maybe you have lots of
belts hiding under the virtual belt, and thus are doing what I am
suggesting.

It’s been years since I read your docs, I apologize for any
mischaracterizations I have made. My mental model of your architecture is
undoubtedly wrong.

I thank you for your posts, they are enlightening.

Brett

On 7/6/2021 1:04 AM, Brett wrote:
> Ivan Godard <ivan@millcomputing.com> wrote:
>> On 7/5/2021 12:15 AM, Brett wrote:
>>> Brett <ggtgp@yahoo.com> wrote:
>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>> Brett <ggtgp@yahoo.com> schrieb:
>>>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>>>> On 6/26/2021 2:32 AM, Thomas Koenig wrote:
>>>>>>>
>>>>>>>> See the Texas Instruments C64
>>>>>>>
>>>>>>> That's rather interesting, thanks!
>>>>>>>
>>>>>>> Looks rather similar to what I had in mind, except that they allow
>>>>>>> at least some cross-operation between the different register files,
>>>>>>> and they had 16 registers (later 32) per register file.
>>>>>>>
>>>>>>
>>>>>> I like it, however I would burn two instruction bits for the two banks.
>>>>>> So you can say bank 0, bank 1, both banks, sequential load to both, etc.
>>>>>
>>>>> What would you appy them to? Assuming a three-register instruction,
>>>>> (and assuming that r0-15 are in the first bank and r16-r31 in the
>>>>> second) would you then be able to write
>>>>>
>>>>> add r2,r17,r22
>>>>
>>>> Add.12 r2,r17,r22 ; both banks run same instruction.
>>>>
>>>> A loop unroll of one is just tagging the opcode to run on both banks.
>>>> Which gives good code density.
>>>>
>>>> Add.1s r2,r17,r22 ; add bank 1 but splat result to both banks.
>>>>
>>>> Also would do load pair splat, so banks get sequential items for loop
>>>> unroll use, which saves an address register in the second bank from having
>>>> to be a clone plus 1 and other grief. The saved register could then be your
>>>> loop index, etc.
>>>>
>>>> You get loop unrolling without doubling your rename width or ports, both of
>>>> which are critical limits to scaling.
>>>>
>>>>> (so the bank 1 ALU presumably does the calculation and sends over
>>>>> the result to bank 0)?
>>>>>
>>>>> Also, this would use one bit only if you have two banks. I was
>>>>> envisioning more than two, then the advantage in encoding bits
>>>>> starts to disappear.
>>>>
>>>> You can use 2 bank bits and 1 splat or other bit, cheaper than three 6 bit
>>>> register specifiers. 2+1+(3*4) = 15, verses 3*6 = 18.
>>>>
>>>> With four banks the four common choices are; bank 1, all, alternate primary
>>>> bank, and all but primary bank. Which is better than my 2 bank mask bits in
>>>> the same opcode space.
>>>>
>>>> You can expand this to 3 bits, or the full 4 bit mask each bank which is
>>>> wasteful. There is also the issue of splat variants if any, which may
>>>> better be handled by other opcodes. There will be a copy bank register
>>>> instruction that handles all the tough cases.
>>>
>>> I have thought about this some more and how it overlaps vector registers
>>> but with more flexibility and have decided that 5 banks of 16 registers is
>>> best so that one can do away with vector registers since you have that
>>> functionality.
>>>
>>> All addressing is done in the first two banks, and the other banks are for
>>> unrolling and long calculations that need more than 16 registers. Only the
>>> last four banks support floating point and vector type operations. All
>>> registers are 64 bits.
>>>
>>> Basically a sort of super upgraded RISC 68000, without the crap instruction
>>> set arch and limits. You can’t do addressing in vector registers, but can
>>> with this arch.
>>>
>>> You could also do a Mill variant of this arch, and with 5 belts you can
>>> dump the evil kluge visible scratchpad resulting in a nicer cleaner
>>> architecture.
>>
>> Code can have unbounded numbers of concurrently live operands that have
>> to be put somewhere. If you don't have a scratchpad then you have to be
>> prepared to stash to memory. Even if you do have a scratchpad you have
>> to be prepared fo it to overflow and need stashing to memory too.
>> Scratchpad, like registers, is just an optimization of memory for
>> certain common special cases.
>
> I have used architectures with scratchpads or that could configure half the
> cache as scratchpad, yuck.
> And I have the talent to use such, for the average programer the idea is a
> joke.
>
> The age of two way caches that suffer aliasing issues is over, use the
> cache as God intended.
>
> Of course in your case the compiler is using the scratchpad, and it may
> give you more bandwidth, and that bandwidth costs less power than the
> cache.
>
> But I still think a scratchpad is an over complicated kludge and thus you
> are living in the past. More importantly it will scare off mediocre
> programers. The belt is scary enough as is.
>
> On an OS call the scratchpad can leak information unless cleared, a small
> performance liability.

Calls, to the OS or otherwise, get a whole new scratchpad (or so it
appears), courtesy the hardware spiller.

> The real problem is that you only have one virtual belt, as that makes
> opcodes smaller and seemingly makes things simpler. But not all problems
> fit in one belt, fat code blows apart a single belt. Thus a scratchpad to
> shoehorn more code with good performance. Fat code purely from cache would
> perform badly.

Yes; hence the scratchpad.

> You also have compiler issues, which makes handling more belts difficult.
> It is easy to say that one bank should be used for globals and thus rarely
> rotate, another for addressing and others for compute, but convincing a
> compiler to do something intelligent is really hard.

There's only one belt at present. Rather than two belts, just configure
a belt twice as big.

> A loop has a limited number of dependent compute chains, it should be
> possible to just randomly assign opcode chains to belts. Filling belts
> roughly evenly over time.

Too much fanout in open code, although FP codes are better; you would
wind up doing a lot of inter-belt transfers because the dataflow is
tree-like rather than linear.

> You have some secrete sauce still I bet to get to 32 ops a cycle, how you
> handle vector support spreading across units? Etc. Maybe you have lots of
> belts hiding under the virtual belt, and thus are doing what I am
> suggesting.

Nope. Remember, the belt is a naming device, not a shift register.

> It’s been years since I read your docs, I apologize for any
> mischaracterizations I have made. My mental model of your architecture is
> undoubtedly wrong.
>
> I thank you for your posts, they are enlightening.

You're welcome.

> Brett
>

> I have used architectures with scratchpads or that could configure half the
> cache as scratchpad, yuck.

I don't think these scratchpads are very much like the Mill's scratchpad.

I suspect the "yuck" above refers to the problems you end up having of
administering this scratchpad, sharing it between unrelated functions.

Mill's scratchpad is more like a CPU-supported notion of frame
activation record. Every time you enter a function you get a fresh new
scratchpad and when you return from a function, the scratchpad is thrown
away and the caller recovers instead the scratchpad it had before the
call (scrachpads get "pushed on/popped off the stack" behind the scene).

So it's easy for programmers and compilers to use it as a kind of "slow
register file with register-windows".

Stefan

> There's only one belt at present. Rather than two belts, just configure
> a belt twice as big.

I think his idea is that with 2 belts (and with control over which
results go to which belt) you can arrange to put on belt 1 the
results that are only needed very shortly, and on belt 2 the results
that are needed in the longer term. If most results are needed only
shortly then belt 1 will move faster and belt 2 will indeed store its
result longer.

Instead, you use the scratchpad which incurs a higher latency. IIUC you
don't care too much about this latency because it should be reasonably
easy to schedule your scratchpad saves&loads in advance, so as long as
"save+load" doesn't take more time than the number of cycles results
stay on the belt (i.e. the length of the belt measured in cycles), then
you can still arrange to have the results "at hand" without delay
when you need them.

Stefan

On 7/6/2021 5:57 AM, Stefan Monnier wrote:
>> I have used architectures with scratchpads or that could configure half the
>> cache as scratchpad, yuck.
>
> I don't think these scratchpads are very much like the Mill's scratchpad.
>
> I suspect the "yuck" above refers to the problems you end up having of
> administering this scratchpad, sharing it between unrelated functions.
>
> Mill's scratchpad is more like a CPU-supported notion of frame
> activation record. Every time you enter a function you get a fresh new
> scratchpad and when you return from a function, the scratchpad is thrown
> away and the caller recovers instead the scratchpad it had before the
> call (scrachpads get "pushed on/popped off the stack" behind the scene).
>
> So it's easy for programmers and compilers to use it as a kind of "slow
> register file with register-windows".
>
>
> Stefan
>

Yes; good description.

On 7/6/2021 6:06 AM, Stefan Monnier wrote:
>> There's only one belt at present. Rather than two belts, just configure
>> a belt twice as big.
>
> I think his idea is that with 2 belts (and with control over which
> results go to which belt) you can arrange to put on belt 1 the
> results that are only needed very shortly, and on belt 2 the results
> that are needed in the longer term. If most results are needed only
> shortly then belt 1 will move faster and belt 2 will indeed store its
> result longer.
>
> Instead, you use the scratchpad which incurs a higher latency. IIUC you
> don't care too much about this latency because it should be reasonably
> easy to schedule your scratchpad saves&loads in advance, so as long as
> "save+load" doesn't take more time than the number of cycles results
> stay on the belt (i.e. the length of the belt measured in cycles), then
> you can still arrange to have the results "at hand" without delay
> when you need them.
>
>
> Stefan
>

As the belt is just an encoding device, it can be judged on the
compactness it achieves. Belts don't have a "speed"; things last until
the more recent set exhausts the capacity. So you could partition the
belt and decide to put short-life things in one and longer-life things
in the other, by convention. You'd still need a scratchpad for things
with still longer lives, but the scratch might be less used (and hence
smaller) because there would be fewer holes in the slow belt than in a
double-sized fast belt.

However, this is just a way to selectively preserve longer-life belt
content. We do preservation now with the rescue() operation, which takes
a bitmask covering the belt space and renumbers the selected operands to
the front. It's unclear to me whether a 32-long belt with rescues for
33+ drop lives is worse than two 16-long belts with rescues for one of
them. For space they are the same: choose one of 32 (or 2X16) costs five
bits. For usage, if the average life is 16-32 drops then the 32-long is
best because with 2X16 the data falls off the quick belt and overfills
the slow belt.

Needs some thought.