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:

The ISA supports n register banks with m registers each. m=8
would probably be a good first guess, n could be 4 or 8
(for example).

Arithmetic instructions are restricted to a register bank,
as is address calculation for a load/store.

Communication between register banks is restricted to memory moves.
Synchronization between banks occurs when a register move occurs
(but only for the affected register) or on branches.

Some operations (like floating point or integer division) might
only be allowed for certain banks (say you have 8 banks of 8
registers, but only 4 of these can do floating point in addition
to all the integer operations).

SIMD operations might be done in the normal register file by doing
them simultaneously on registers i*m + j, where i is from 0 to n-1
(possibly selected by a bitmap) and j is between 0 and m.

Potential advantages:

This would need fewer read/write ports per bank and fewer
interconnections.

Resorces like the (parts of the) ALU could be done per register
bank, or per two register banks.

Because the compiler would only see the arithmetic instructions
between certain registers, it would be hopefully tailor its
register allocation accordingly to expose inherent parallelism in
the algorithm (but see disadvantages below).

Register encoding for a three-op encoding would only use 2+3+3+3=11
bits for m=8 and n=4, or 3+3+3+3+3+3=12 bits for m=8 and n=8
instead of 15 and 18 bits for 32 or 64 registers, respectively.

Potential disadvantages:

Less orthogonal, this might make the compiler's job more difficult.

Not all algorithms might be suitable; a lot of the advantages could
get lost by stalls waiting for another bank (alhtough the report
quoted above seems to indicate otherwise).

This critically depends on the compiler putting instructions in
the right register bank. Current register allocation algorithms
might not be good enough for optimum performance.

Comments? Would offer no advantages over conventional ooO
architecture? Has been tried before and didn't catch on
because...?

On 6/26/2021 2:32 AM, 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:
>
> The ISA supports n register banks with m registers each. m=8
> would probably be a good first guess, n could be 4 or 8
> (for example).
>
> Arithmetic instructions are restricted to a register bank,
> as is address calculation for a load/store.
>
> Communication between register banks is restricted to memory moves.
> Synchronization between banks occurs when a register move occurs
> (but only for the affected register) or on branches.
>
> Some operations (like floating point or integer division) might
> only be allowed for certain banks (say you have 8 banks of 8
> registers, but only 4 of these can do floating point in addition
> to all the integer operations).
>
> SIMD operations might be done in the normal register file by doing
> them simultaneously on registers i*m + j, where i is from 0 to n-1
> (possibly selected by a bitmap) and j is between 0 and m.
>
> Potential advantages:
>
> This would need fewer read/write ports per bank and fewer
> interconnections.
>
> Resorces like the (parts of the) ALU could be done per register
> bank, or per two register banks.
>
> Because the compiler would only see the arithmetic instructions
> between certain registers, it would be hopefully tailor its
> register allocation accordingly to expose inherent parallelism in
> the algorithm (but see disadvantages below).
>
> Register encoding for a three-op encoding would only use 2+3+3+3=11
> bits for m=8 and n=4, or 3+3+3+3+3+3=12 bits for m=8 and n=8
> instead of 15 and 18 bits for 32 or 64 registers, respectively.
>
> Potential disadvantages:
>
> Less orthogonal, this might make the compiler's job more difficult.
>
> Not all algorithms might be suitable; a lot of the advantages could
> get lost by stalls waiting for another bank (alhtough the report
> quoted above seems to indicate otherwise).
>
> This critically depends on the compiler putting instructions in
> the right register bank. Current register allocation algorithms
> might not be good enough for optimum performance.
>
> Comments? Would offer no advantages over conventional ooO
> architecture? Has been tried before and didn't catch on
> because...?
>

See the Texas Instruments C64

In article <sb6s70$dip$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> Comments? Would offer no advantages over conventional ooO
> architecture? Has been tried before and didn't catch on
> because...?

Makes saving and restoring registers on an interrupt more complicated.

Makes rules about callee-preserved registers more complicated.

Creates artificial shortages of registers for complex expressions,
increasing spills/fills to memory.

Wrong-register compiler bugs become more complicated.

My experience of something like this is with the Z80 alternate register
set, one of whose intended uses was to avoid saving registers in
interrupt service routines. However, that was only useful if you had a
hard guarantee that no interrupt would occur while another was being
serviced. That can be possible in a fixed-purpose embedded system, if you
know that all the interrupt service routines are short and can avoid
enabling interrupts within them. In any kind of general-purpose computer,
that isn't practical.

John

John Dallman <jgd@cix.co.uk> schrieb:
> In article <sb6s70$dip$1@newsreader4.netcologne.de>,
> tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> Comments? Would offer no advantages over conventional ooO
>> architecture? Has been tried before and didn't catch on
>> because...?
>
> Makes saving and restoring registers on an interrupt more complicated.

OK; add one synchronizing "store multiple" instruction, or
even a "store multiple banks" instruction.

> Makes rules about callee-preserved registers more complicated.

Have certain banks caller-saved and other banks callee-saved.

> Creates artificial shortages of registers for complex expressions,
> increasing spills/fills to memory.

It would possible to use a register in another bank for spilling;
I would expect that a register-to-register copy between banks would
be a single-cycle operation, much faster than a L1 cache access,
which is usually four cycles these days. The main point, of course,
is how rare such cross-bank spills would be; the data in the
report I cited seems to show that they are not that frequent even
in the absence of specific optimizations.

> Wrong-register compiler bugs become more complicated.

I'd tend to think of this as a problem that can be solved rather
easily. I haven't looked at it closely, but should be rather
straigtforward to only have instructions which operate on a
subset of registers, for example in a gcc machine description.

> My experience of something like this is with the Z80 alternate register
> set, one of whose intended uses was to avoid saving registers in
> interrupt service routines. However, that was only useful if you had a
> hard guarantee that no interrupt would occur while another was being
> serviced. That can be possible in a fixed-purpose embedded system, if you
> know that all the interrupt service routines are short and can avoid
> enabling interrupts within them. In any kind of general-purpose computer,
> that isn't practical.

Hm, I don't quite see the similarity here.

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.

In article <sb70ed$fsg$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> > Makes rules about callee-preserved registers more complicated.
> Have certain banks caller-saved and other banks callee-saved.

That seems to argue for a designated bank for function arguments and
returns. Which is a plausible consequence of the idea.

> > Creates artificial shortages of registers for complex expressions,
> > increasing spills/fills to memory.
> It would possible to use a register in another bank for spilling;
> I would expect that a register-to-register copy between banks would
> be a single-cycle operation, much faster than a L1 cache access,

OK, but you said in the original posting:

*> Communication between register banks is restricted to memory moves.

If that is not the case, then the idea is less radical.

> > Wrong-register compiler bugs become more complicated.
> I'd tend to think of this as a problem that can be solved rather
> easily. I haven't looked at it closely, but should be rather
> straigtforward to only have instructions which operate on a
> subset of registers, for example in a gcc machine description.

I'm thinking more of bugs where the compiler has lot track of which
register bank a value is in, and references the right register number in
a bank that isn't the current bank. I've seen plenty of bugs where a
compiler gets the wrong register in a flat register file; this allows for
another layer of confusion.

> Hm, I don't quite see the similarity here.

You have limited numbers of a resource that you can only see one instance
of at a time. You need to keep track of which instance you can see,
without spending too much time using enquiry instructions.

John

John Dallman <jgd@cix.co.uk> schrieb:
> In article <sb70ed$fsg$1@newsreader4.netcologne.de>,
> tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> > Makes rules about callee-preserved registers more complicated.
>> Have certain banks caller-saved and other banks callee-saved.
>
> That seems to argue for a designated bank for function arguments and
> returns. Which is a plausible consequence of the idea.
>
>> > Creates artificial shortages of registers for complex expressions,
>> > increasing spills/fills to memory.
>> It would possible to use a register in another bank for spilling;
>> I would expect that a register-to-register copy between banks would
>> be a single-cycle operation, much faster than a L1 cache access,
>
> OK, but you said in the original posting:
>
> *> Communication between register banks is restricted to memory moves.
>
> If that is not the case, then the idea is less radical.

Yes, probably :-) So, let me fix it to read "Communication between
register banks is restricted to register to register moves",
which makes much more sense.

>> > Wrong-register compiler bugs become more complicated.
>> I'd tend to think of this as a problem that can be solved rather
>> easily. I haven't looked at it closely, but should be rather
>> straigtforward to only have instructions which operate on a
>> subset of registers, for example in a gcc machine description.
>
> I'm thinking more of bugs where the compiler has lot track of which
> register bank a value is in, and references the right register number in
> a bank that isn't the current bank. I've seen plenty of bugs where a
> compiler gets the wrong register in a flat register file; this allows for
> another layer of confusion.

Possible.

The solution, probably, is to stand on the shoulder of giants (i.e.
use a well-established compiler; I mentioned gcc, but LLVM should
also work), rather than roll my own.

There is a danger, of course, of getting the machine descriptin
wrong or of exposing bugs in the register allocator by excercising
rarely-used code paths, for which it might be hard to find a test
case with one of the usual architectures.

Still, if everything else fails, using a separate add (and shift,
and mul, and div, and ... ) instruction for each register bank
should do the trick.

>> Hm, I don't quite see the similarity here.
>
> You have limited numbers of a resource that you can only see one instance
> of at a time. You need to keep track of which instance you can see,
> without spending too much time using enquiry instructions.

I don't see where I would need an enquiry instructions, but I may
not have thought this through.

In article <sb7575$jgr$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> Yes, probably :-) So, let me fix it to read "Communication between
> register banks is restricted to register to register moves",
> which makes much more sense.

OK.

> There is a danger, of course, of getting the machine description
> wrong or of exposing bugs in the register allocator by excercising
> rarely-used code paths, for which it might be hard to find a test
> case with one of the usual architectures.

Absolutely. This unconventional register structure is likely to expose
bugs that have been quietly sleeping for years.

> Still, if everything else fails, using a separate add (and shift,
> and mul, and div, and ... ) instruction for each register bank
> should do the trick.

At that point, are you really gaining anything? You're using opcode space
for that which could otherwise go in register selection bits.

> I don't see where I would need an enquiry instructions, but I may
> not have thought this through.

Interrupt service routines that need to make sure they have the same bank
selected when they return. Applies to both hardware and software
interrupts.

Sanity checking for the calling convention, to be turned on in the
compiler when things are amiss.

In general, write-only state gives rise to problems when things are
happening asynchronously.

John

Thomas Koenig <tkoenig@netcologne.de> writes:
>So, how about this:
>
>The ISA supports n register banks with m registers each. m=8
>would probably be a good first guess, n could be 4 or 8
>(for example).
>
>Arithmetic instructions are restricted to a register bank,
>as is address calculation for a load/store.
>
>Communication between register banks is restricted to memory moves.
>Synchronization between banks occurs when a register move occurs
>(but only for the affected register) or on branches.
>
>Some operations (like floating point or integer division) might
>only be allowed for certain banks (say you have 8 banks of 8
>registers, but only 4 of these can do floating point in addition
>to all the integer operations).
>
>SIMD operations might be done in the normal register file by doing
>them simultaneously on registers i*m + j, where i is from 0 to n-1
>(possibly selected by a bitmap) and j is between 0 and m.
>
>Potential advantages:
>
>This would need fewer read/write ports per bank and fewer
>interconnections.
>
>Resorces like the (parts of the) ALU could be done per register
>bank, or per two register banks.
>
>Because the compiler would only see the arithmetic instructions
>between certain registers, it would be hopefully tailor its
>register allocation accordingly to expose inherent parallelism in
>the algorithm (but see disadvantages below).
>
>Register encoding for a three-op encoding would only use 2+3+3+3=11
>bits for m=8 and n=4, or 3+3+3+3+3+3=12 bits for m=8 and n=8
>instead of 15 and 18 bits for 32 or 64 registers, respectively.
>
>Potential disadvantages:
>
>Less orthogonal, this might make the compiler's job more difficult.
>
>Not all algorithms might be suitable; a lot of the advantages could
>get lost by stalls waiting for another bank (alhtough the report
>quoted above seems to indicate otherwise).
>
>This critically depends on the compiler putting instructions in
>the right register bank. Current register allocation algorithms
>might not be good enough for optimum performance.
>
>Comments?

If you do it architecturally, it certainly makes the compiler's task
harder.

I think the Multiflow architecture is organized like this (but I
think with more registers per slice), but my memory is getting hazy.

More recent instances are microarchitectural:

The 21264 is composed of two clusters, with each cluster having a copy
of all registers, and the cross-cluster communication taking an extra
cycle; this was performed automatically by the hardware, but by appropriate instruction scheduling the compiler could avoid it.

ILDP [kim&smith02] also works with copies of the full register file.

> Would offer no advantages over conventional ooO
>architecture? Has been tried before and didn't catch on
>because...?

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

Recent OoO implementations have not used the cluster-splitting that
the 21264 used (AFAIK), so apparently the cost of having many ports to
the register file is not a big problem these days. I guess that OoO
can arrange writes to go to different banks of the register file (so
only one write port per bank is necessary), and an occasional delay
cycle in read access does not hurt that much; the time-critical stuff
happens on the forwarding paths anyway. As to why the gazillion
forwarding paths between the 10 FUs (with 20 inputs) is manageable
these days, I don't know.

In any case, if your idea has merit, one can implement it in the front
end of an OoO CPU (probably easier than in a compiler, and, more
importantly, with no need to break backwards compatibility). I expect
that most programs have too intertwined data flow, and will suffer a
lot from the forced inter-cluster moves. Of course, it depends on the
other costs involved. If you can increase the clock rate by 50% with
your idea, the benefit is probably greater than the cost of the
inter-cluster moves.

@InProceedings{kim&smith02,
author = {Ho-Seop Kim and James E. Smith},
title = {An Instruction Set and Microarchitecture for
Instruction Level Distributed Processing},
crossref = {isca02},
pages = {71--81},
url = {http://www.ece.wisc.edu/~hskim/papers/kimh_ildp.pdf},
annote = {This paper addresses the problems of wide
superscalars with communication across the chip and
the number of write ports in the register file. The
authors propose an architecture (ILDP) with
general-purpose registers and with accumulators
(with instructions only accessing one accumulator
(read and/or write) and one register (read or
write); for the accumulators their death is
specified explicitly in the instructions. The
microarchitecture builds \emph{strands} from
instructions working on an accumulator; a strand
starts with an instruction writing to an accumulator
without reading from it, continues with instructions
reading from (and possibly writing to) the
accumulator and ends with an instruction that kills
the accumulator. Strands are allocated to one out of
eight processing elements (PEs) dynamically (i.e.,
accumulators are renamed). A PE consists of
mainly one ALU data path (but also a copy of the
GPRs and an L1 cache). They evaluated this
architecture by translating Alpha binaries into it,
and comparing their architecture to a 4-wide or
8-wide Alpha implementation; their architecture has
a lower L1 cache latency, though. The performance of
ILDP in clock cycles is competetive, and one can
expect faster clocks for ILDP. The paper also
presents data for other stuff, e.g. general-purpose
register writes, which have to be promoted between
strands and which are relatively few.}
}

@Proceedings{isca02,
title = "$29^\textit{th}$ Annual International Symposium on Computer Architecture",
booktitle = "$29^\textit{th}$ Annual International Symposium on Computer Architecture",
year = "2002",
key = "ISCA 29",
}

@InProceedings{salverda&zilles07,
author = {Pierre Salverda and Craig Zilles},
title = {Dependence-Based Scheduling Revisited: A Tale of Two
Baselines},
booktitle = {Sixth Annual Workshop on Duplicating, Deconstructing, and Debunking (WDDD 2007)},
year = {2007},
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},
annote = {When the authors simulated the dependence-based
scheduling work by Palacharla, Kim, and Smith, they
found 30\% lower IPC than a conventional OoO
machine, whereas the original simulations only found
a 5\% lower IPC. The paper analyses the reasons for
this, and provides a number of insights into how
hardware schedulers, execution engines, and various
features in them interact, and why and how
dependence-based scheduling works. The authors'
simulation had a number of significant differences
from the simulation in the original work: it used a
memory disambiguator, 2-cycle load latency (instead
of 1-cycle), and a better branch predictor. These
changes increase the number of strands available at
the same time, and the 8-lane dependence-based
machine becomes lane-limited (and instruction fetch
stalls waiting for a free lane), so it cannot profit
from the improvements or work around the higher
latency, whereas a conventional OoO machine can. 24
lanes would be required to bring the IPC
disadvantage of the dependence-based machine down to
5\% on the authors' simulator. OTOH, by changing
these parts of their simulation to be like the
original work, the dependence-based scheduling only
had an 11\% IPC disadvantage on an 8-lane machine
(much closer to the original 5\%)}
}

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

> The ISA supports n register banks with m registers each. m=8
> would probably be a good first guess, n could be 4 or 8
> (for example).

You might like to take a look at Bernd Paysan's 4-stack forth chip
https://bernd-paysan.de/4stack.html

Stefan

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.
<
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.

John Dallman <jgd@cix.co.uk> schrieb:
> In article <sb7575$jgr$1@newsreader4.netcologne.de>,
> tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> Yes, probably :-) So, let me fix it to read "Communication between
>> register banks is restricted to register to register moves",
>> which makes much more sense.
>
> OK.
>
>> There is a danger, of course, of getting the machine description
>> wrong or of exposing bugs in the register allocator by excercising
>> rarely-used code paths, for which it might be hard to find a test
>> case with one of the usual architectures.
>
> Absolutely. This unconventional register structure is likely to expose
> bugs that have been quietly sleeping for years.
>
>> Still, if everything else fails, using a separate add (and shift,
>> and mul, and div, and ... ) instruction for each register bank
>> should do the trick.
>
> At that point, are you really gaining anything? You're using opcode space
> for that which could otherwise go in register selection bits.

Doesn't matter either way what it's called, if it is part of
the opcode or part of the register selection bits, it will
be the same bits either way.

What I was talking about is how the compiler sees the instructions
(and that it doesn't get the registers wrong).

However, it is probably much easier easier to set up separate
register classes.

>
>> I don't see where I would need an enquiry instructions, but I may
>> not have thought this through.
>
> Interrupt service routines that need to make sure they have the same bank
> selected when they return. Applies to both hardware and software
> interrupts.

Maybe my terminology was misleading.

What I meant was that r0,r1...r7 would be in a group of registers,
as would be r8, r9, ... r15, etc so there would be a way to encode

add r0,r3,r7

in an instruction but not

add r0,r7,r13

If that was desired, the instruction sequence would be

mr r1, r13
add r0,r7,r2

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>So, how about this:
>>
>>The ISA supports n register banks with m registers each. m=8
>>would probably be a good first guess, n could be 4 or 8
>>(for example).
>>
>>Arithmetic instructions are restricted to a register bank,
>>as is address calculation for a load/store.
>>
>>Communication between register banks is restricted to memory moves.
>>Synchronization between banks occurs when a register move occurs
>>(but only for the affected register) or on branches.
>>
>>Some operations (like floating point or integer division) might
>>only be allowed for certain banks (say you have 8 banks of 8
>>registers, but only 4 of these can do floating point in addition
>>to all the integer operations).
>>
>>SIMD operations might be done in the normal register file by doing
>>them simultaneously on registers i*m + j, where i is from 0 to n-1
>>(possibly selected by a bitmap) and j is between 0 and m.
>>
>>Potential advantages:
>>
>>This would need fewer read/write ports per bank and fewer
>>interconnections.
>>
>>Resorces like the (parts of the) ALU could be done per register
>>bank, or per two register banks.
>>
>>Because the compiler would only see the arithmetic instructions
>>between certain registers, it would be hopefully tailor its
>>register allocation accordingly to expose inherent parallelism in
>>the algorithm (but see disadvantages below).
>>
>>Register encoding for a three-op encoding would only use 2+3+3+3=11
>>bits for m=8 and n=4, or 3+3+3+3+3+3=12 bits for m=8 and n=8
>>instead of 15 and 18 bits for 32 or 64 registers, respectively.
>>
>>Potential disadvantages:
>>
>>Less orthogonal, this might make the compiler's job more difficult.
>>
>>Not all algorithms might be suitable; a lot of the advantages could
>>get lost by stalls waiting for another bank (alhtough the report
>>quoted above seems to indicate otherwise).
>>
>>This critically depends on the compiler putting instructions in
>>the right register bank. Current register allocation algorithms
>>might not be good enough for optimum performance.
>>
>>Comments?
>
> If you do it architecturally, it certainly makes the compiler's task
> harder.
>
> I think the Multiflow architecture is organized like this (but I
> think with more registers per slice), but my memory is getting hazy.

Unfortunately, most Multiflow articles are behind paywalls (and
the Wikipedia article is written like an advertisement, with
little technical content).

Thanks for your pointers to literature, I will take
a look at them.

Thomas Koenig <tkoenig@netcologne.de> schrieb:
> mr r1, r13
> add r0,r7,r2

add r0,r7,r1

of course.

In article <sb7o4e$243$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> > Interrupt service routines that need to make sure they have the
> > same bank selected when they return. Applies to both hardware
> > and software interrupts.
>
> Maybe my terminology was misleading.
>
> What I meant was that r0,r1...r7 would be in a group of registers,
> as would be r8, r9, ... r15, etc so there would be a way to encode ...

Aha! Your use of "bank" led me to think that the registers were
bank-switched, so that only one bank was visible at a time. That would
mean that with n register banks, there would be n different pieces of
in-processor storage that could appear as r0. That causes a need for an
enquiry instruction, so that you can find out which bank is selected. You
see why I though the Z80 alternate register set was relevant?

What you seem to really intend is that instructions that reference more
than one register are constrained in the set of registers they can
reference, such as r0...r7, or r15...r23. But you can't reference r5 and
r20 in the same instruction, unless it's a move between them. Is that
right?

If so, all my objections above are void, because I was misunderstanding
you. This scheme doesn't have any of those problems.

I'm not sure that it is worth its extra complexity, but that's a
different level of problem.

John

On Saturday, June 26, 2021 at 12:28:48 PM UTC-5, Thomas Koenig wrote:
> John Dallman <j...@cix.co.uk> schrieb:
> > In article <sb7575$jgr$1...@newsreader4.netcologne.de>,
> > tko...@netcologne.de (Thomas Koenig) wrote:
> >
> >> Yes, probably :-) So, let me fix it to read "Communication between
> >> register banks is restricted to register to register moves",
> >> which makes much more sense.
> >
> > OK.
> >
> >> There is a danger, of course, of getting the machine description
> >> wrong or of exposing bugs in the register allocator by excercising
> >> rarely-used code paths, for which it might be hard to find a test
> >> case with one of the usual architectures.
> >
> > Absolutely. This unconventional register structure is likely to expose
> > bugs that have been quietly sleeping for years.
> >
> >> Still, if everything else fails, using a separate add (and shift,
> >> and mul, and div, and ... ) instruction for each register bank
> >> should do the trick.
> >
> > At that point, are you really gaining anything? You're using opcode space
> > for that which could otherwise go in register selection bits.
> Doesn't matter either way what it's called, if it is part of
> the opcode or part of the register selection bits, it will
> be the same bits either way.
>
> What I was talking about is how the compiler sees the instructions
> (and that it doesn't get the registers wrong).
>
> However, it is probably much easier easier to set up separate
> register classes.
> >
> >> I don't see where I would need an enquiry instructions, but I may
> >> not have thought this through.
> >
> > Interrupt service routines that need to make sure they have the same bank
> > selected when they return. Applies to both hardware and software
> > interrupts.
> Maybe my terminology was misleading.
>
> What I meant was that r0,r1...r7 would be in a group of registers,
> as would be r8, r9, ... r15, etc so there would be a way to encode
>
> add r0,r3,r7
>
> in an instruction but not
>
> add r0,r7,r13
>
> If that was desired, the instruction sequence would be
>
> mr r1, r13
> add r0,r7,r2
<
Unless you have a very tiny instruction to perform these inter-bank
MOVs, you are going to harm instruction density.

On Saturday, June 26, 2021 at 12:46:48 PM UTC-5, Thomas Koenig wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >>So, how about this:
> >>
> >>The ISA supports n register banks with m registers each. m=8
> >>would probably be a good first guess, n could be 4 or 8
> >>(for example).
> >>
> >>Arithmetic instructions are restricted to a register bank,
> >>as is address calculation for a load/store.
> >>
> >>Communication between register banks is restricted to memory moves.
> >>Synchronization between banks occurs when a register move occurs
> >>(but only for the affected register) or on branches.
> >>
> >>Some operations (like floating point or integer division) might
> >>only be allowed for certain banks (say you have 8 banks of 8
> >>registers, but only 4 of these can do floating point in addition
> >>to all the integer operations).
> >>
> >>SIMD operations might be done in the normal register file by doing
> >>them simultaneously on registers i*m + j, where i is from 0 to n-1
> >>(possibly selected by a bitmap) and j is between 0 and m.
> >>
> >>Potential advantages:
> >>
> >>This would need fewer read/write ports per bank and fewer
> >>interconnections.
> >>
> >>Resorces like the (parts of the) ALU could be done per register
> >>bank, or per two register banks.
> >>
> >>Because the compiler would only see the arithmetic instructions
> >>between certain registers, it would be hopefully tailor its
> >>register allocation accordingly to expose inherent parallelism in
> >>the algorithm (but see disadvantages below).
> >>
> >>Register encoding for a three-op encoding would only use 2+3+3+3=11
> >>bits for m=8 and n=4, or 3+3+3+3+3+3=12 bits for m=8 and n=8
> >>instead of 15 and 18 bits for 32 or 64 registers, respectively.
> >>
> >>Potential disadvantages:
> >>
> >>Less orthogonal, this might make the compiler's job more difficult.
> >>
> >>Not all algorithms might be suitable; a lot of the advantages could
> >>get lost by stalls waiting for another bank (alhtough the report
> >>quoted above seems to indicate otherwise).
> >>
> >>This critically depends on the compiler putting instructions in
> >>the right register bank. Current register allocation algorithms
> >>might not be good enough for optimum performance.
> >>
> >>Comments?
> >
> > If you do it architecturally, it certainly makes the compiler's task
> > harder.
> >
> > I think the Multiflow architecture is organized like this (but I
> > think with more registers per slice), but my memory is getting hazy.
> Unfortunately, most Multiflow articles are behind paywalls (and
> the Wikipedia article is written like an advertisement, with
> little technical content).
<
After the little success they had "way back when" and the scant pursuance
of recent, Why bother looking down dead ends for genuinely new ideas to
make forward computer architecture progress ?
>
> Thanks for your pointers to literature, I will take
> a look at them.

John Dallman <jgd@cix.co.uk> schrieb:
> In article <sb7o4e$243$1@newsreader4.netcologne.de>,
> tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> > Interrupt service routines that need to make sure they have the
>> > same bank selected when they return. Applies to both hardware
>> > and software interrupts.
>>
>> Maybe my terminology was misleading.
>>
>> What I meant was that r0,r1...r7 would be in a group of registers,
>> as would be r8, r9, ... r15, etc so there would be a way to encode ...
>
> Aha! Your use of "bank" led me to think that the registers were
> bank-switched, so that only one bank was visible at a time. That would
> mean that with n register banks, there would be n different pieces of
> in-processor storage that could appear as r0. That causes a need for an
> enquiry instruction, so that you can find out which bank is selected. You
> see why I though the Z80 alternate register set was relevant?
>
> What you seem to really intend is that instructions that reference more
> than one register are constrained in the set of registers they can
> reference, such as r0...r7, or r15...r23. But you can't reference r5 and
> r20 in the same instruction, unless it's a move between them. Is that
> right?

That is correct.

>
> If so, all my objections above are void, because I was misunderstanding
> you. This scheme doesn't have any of those problems.

> I'm not sure that it is worth its extra complexity, but that's a
> different level of problem.

Definitely, that's what I am trying to find out :-)

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, June 26, 2021 at 12:46:48 PM UTC-5, Thomas Koenig wrote:

>> Unfortunately, most Multiflow articles are behind paywalls (and
>> the Wikipedia article is written like an advertisement, with
>> little technical content).
><
> After the little success they had "way back when" and the scant pursuance
> of recent, Why bother looking down dead ends for genuinely new ideas to
> make forward computer architecture progress ?

It can be very instructive to study things from the past and learn
about what they got right and what they got wrong, and how old
ideas might work better under the changed technical circumstances,
possibly combined with new ones.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, June 26, 2021 at 12:28:48 PM UTC-5, Thomas Koenig wrote:

>> mr r1, r13
>> add r0,r7,r2
><
> Unless you have a very tiny instruction to perform these inter-bank
> MOVs, you are going to harm instruction density.

Yes.

The bits needed for register addressing are somewhat reduced by this
scheme (for example, eight bits for four banks of eight registers
each), with inter-bank register moves taking 10 register address
bits).

It might be possible to design a two-operand ISA using 16 bit
instructions only and a total of 32 registers, but this could be
a stretch, or rather the opposite, a very tight fit.

Maybe a three instructions per 64 bit word ISA would be better,
with each instruction having 21 bits.

Hmm... not yet clear on how to proceed, or if it makes sense.

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.

Generally you only need 16 registers, this gives another 16 registers for
loop unrolling while not doubling the instructions like TI C64 needs.

I can see why the TI 64 made that choice and it was the correct choice for
them.
My concern is post RISC which is now a decade away.

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

(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.

"Thomas Koenig" wrote in message
news:sb801m$80l$1@newsreader4.netcologne.de...

> John Dallman <jgd@cix.co.uk> schrieb:
> > In article <sb7o4e$243$1@newsreader4.netcologne.de>,
> > tkoenig@netcologne.de (Thomas Koenig) wrote:

> >> What I meant was that r0,r1...r7 would be in a group of registers,
> >> as would be r8, r9, ... r15, etc so there would be a way to encode ...

> > What you seem to really intend is that instructions that reference more
> > than one register are constrained in the set of registers they can
> > reference, such as r0...r7, or r15...r23. But you can't reference r5 and
> > r20 in the same instruction, unless it's a move between them. Is that
> > right?

> That is correct.

> > I'm not sure that it is worth its extra complexity, but that's a
> > different level of problem.

> Definitely, that's what I am trying to find out :-)

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

James Van Buskirk <not_valid@comcast.net> schrieb:
> "Thomas Koenig" wrote in message
> news:sb801m$80l$1@newsreader4.netcologne.de...
>
>> John Dallman <jgd@cix.co.uk> schrieb:
>> > In article <sb7o4e$243$1@newsreader4.netcologne.de>,
>> > tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> >> What I meant was that r0,r1...r7 would be in a group of registers,
>> >> as would be r8, r9, ... r15, etc so there would be a way to encode ...
>
>> > What you seem to really intend is that instructions that reference more
>> > than one register are constrained in the set of registers they can
>> > reference, such as r0...r7, or r15...r23. But you can't reference r5 and
>> > r20 in the same instruction, unless it's a move between them. Is that
>> > right?
>
>> That is correct.
>
>> > I'm not sure that it is worth its extra complexity, but that's a
>> > different level of problem.
>
>> Definitely, that's what I am trying to find out :-)
>
> 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?

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.

Say, 2-bit tag:
00: Lane 1 holds current version;
01: Lane 2 holds current version;
10: Lane 3 holds current version;
11: Register is Invalid (Read as Zero).

Though, one could also argue for:
00: Register is Invalid (Read as Zero);
01: Lane 1 holds current version;
10: Lane 2 holds current version;
11: Lane 3 holds current version.

This was the 1st place option among the options tested.

As can be noted, making the individual register arrays smaller will not
reduce cost with this approach, and splitting up the register space into
smaller arrays would, if anything, make it more expensive.

The 2nd place being:
Every register is updated independently as its own state machine;
If ID is seen on Lane 1's Write port, update to Lane 1 result;
If ID is seen on Lane 2's Write port, update to Lane 2 result;
If ID is seen on Lane 3's Write port, update to Lane 3 result;
Else, keep either prior value / forwarded-in value (*1).

Each read port from the GPR file is basically a big "case block" to
select the desired register value (or, basically, a big multiplex stage).

*1: For GPRs, the forwarded-in value is simply the register's output (so
it keeps its value unless modified externally);
For SPRs, these may take a longer trip through the execute unit.

The 2nd place option is a fair bit more expensive on Xilinx FPGAs, but
was cheaper on Altera. On Altera, the original 1st place option became
absurdly expensive, whereas the 2nd place option remained roughly similar.

The cost of this approach is effected much more significantly by the
number of registers and ports though.

Not yet tested on any Lattice devices, so not yet sure what to expect.

Another source of cost is the number of forwarding stages, where there
is a fairly steep increase in cost relative to the number of EX stages
and pipeline width (eg: 3-lane and EX1/2/3, each register read port may
potentially come from one of 9 possible places in the pipeline, one of 3
register arrays, or one of N possible SPRs).

Though, at least in the latter case, most CRs can only be read via the
Rm port in Lane 1. Some SPRs may also give different results depending
on which port they are read from, ...

Another option was to do it naively:
Just do a single register array in the Verilog;
Have multiple writes to the same array (from each write port).

This naive option is very expensive on both FPGA families (somewhat
worse than either the 1st place or 2nd place options).

Control and special registers generally need to use a variant of the 2nd
place approach.

The register space currently using a 7-bit scheme internally:
00..3F: R0..R63, Main Array (Excludes R0/R1/R15);
40..5F: Special Registers (R0/R1/R15 map into here);
60..7F: Control Registers (C0..C31).

When I moved to the current scheme, I also effectively folded the CRs
back into the same register space as GPRs, and partially eliminated them
having their own register ports (they still partly remain for vestigial
reasons; mostly still used to initiate branches and similar).

Main reason R0/R1/R15 are remapped to SPRs is mostly still because these
registers still need to be able to be accessed and updated via a
side-channel for a few special cases (eg: interrupt handling). Remapping
these in the decoder was also generally cheaper than trying to deal with
these cases in the register fetch and update logic.

For CRs, things are more varied. Most are implemented with a similar
approach to the SPRs (with associated side-channels).

Registers like PC are almost purely synthetic:
Trying to fetch its value effectively synthesizes it via the pipeline;
Storing to it triggers the branch-initiation logic.

If anything, it would make more sense to fold PC and the PreBranch
mechanism into the L1 I$, it basically being a unit which serves to
fetch instruction bundles and throw them into the pipeline unless acted
upon by a Hold signal or Branch Request. I haven't quite gone this far
yet though.

If I went this route, some additional special cases would be needed to
try to deal with superscalar though. A potential superscalar core would
be less of an issue with the current design which manages PC update
externally to the L1.

....