Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #3125 > unrolled thread

indexing register

Back to article view | Back to comp.arch

Contents

  indexing register Joe Keane <jgk@jgk.org> - 2011-08-24 19:36 +0000
    Re: indexing register Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-08-24 13:38 -0700
    Re: indexing register MitchAlsup <MitchAlsup@aol.com> - 2011-08-24 18:44 -0700
      Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-24 22:24 -0400
        Re: indexing register Quadibloc <jsavard@ecn.ab.ca> - 2011-08-24 20:08 -0700
          Re: indexing register Quadibloc <jsavard@ecn.ab.ca> - 2011-08-24 20:16 -0700
        Re: indexing register Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-08-25 11:05 +0100
      Re: indexing register nmm1@cam.ac.uk - 2011-08-25 08:29 +0100
      Re: indexing register MitchAlsup <MitchAlsup@aol.com> - 2011-08-26 13:42 -0700
        Re: indexing register EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-26 19:32 -0400
        Re: indexing register Robert Wessel <robertwessel2@yahoo.com> - 2011-08-26 18:53 -0500
          Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-26 20:46 -0400
            Re: indexing register Robert Wessel <robertwessel2@yahoo.com> - 2011-08-26 23:34 -0500
              Re: indexing register mac <acolvin@efunct.com> - 2011-08-28 17:23 +0000
            Re: indexing register MitchAlsup <MitchAlsup@aol.com> - 2011-08-27 14:10 -0700
      Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-27 18:19 -0500
      Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-27 20:39 -0500
        Re: indexing register "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-28 20:59 -0700
      Re: indexing register jgk@panix.com (Joe keane) - 2011-08-29 21:59 +0000
    Re: indexing register Bakul Shah <usenet@bitblocks.com> - 2011-08-25 22:46 -0700
      Re: indexing register mac <acolvin@efunct.com> - 2011-08-26 14:06 +0000

Page 1 of 2  [1] 2  Next page →

#3125 — indexing register

This is bouncing around my head.

Say we have a machine with a lot of general registers, at least 1024 and
possibly much more.  [There's some VLIWy stuff, but i think it's
irrelevant, so pretend i tell you it's a standard RISCy machine.]

We add a register BL (base latch).

Every op that get/put a register has a bit called 'index'.  If off, the
register number is in the op; if on, we add that to BL to get the correct
register number.  Now we can cheat a bit on the register field; maybe
the machine has 16384 registers, but we can only access 512 without
changing BL.

It's unclear whether access to BL is a KISS movtcr/movfcr, or we should
have some ops like save/restore.  It is tempting, we can put an adder
next to BL and he won't need to bother anyone.  In either case we also
want a compare with some bound; if out of whack, do something-or-other.

Basically register windows, but each op can choose to index or not.

Really, there's BL1 and BL2, and of course some way to switch between
them.  [Oh and you can't use it in the next instruction, the rule for
everything.]  Presumably it's not useful to let each op select.  Or
maybe three (ABL/FBL/SBL stolen from the VAX).

Comments welcome on how this is useful, or it allows neat tricks.  Is
there a reason to have more than two?  Also comparison with existing...

[toc] | [next] | [standalone]

#3127

On 8/24/2011 12:36 PM, Joe Keane wrote:
> This is bouncing around my head.
>
> Say we have a machine with a lot of general registers, at least 1024 and
> possibly much more.  [There's some VLIWy stuff, but i think it's
> irrelevant, so pretend i tell you it's a standard RISCy machine.]
>
> We add a register BL (base latch).
>
> Every op that get/put a register has a bit called 'index'.  If off, the
> register number is in the op; if on, we add that to BL to get the correct
> register number.  Now we can cheat a bit on the register field; maybe
> the machine has 16384 registers, but we can only access 512 without
> changing BL.
>
> It's unclear whether access to BL is a KISS movtcr/movfcr, or we should
> have some ops like save/restore.  It is tempting, we can put an adder
> next to BL and he won't need to bother anyone.  In either case we also
> want a compare with some bound; if out of whack, do something-or-other.
>
> Basically register windows, but each op can choose to index or not.
>
> Really, there's BL1 and BL2, and of course some way to switch between
> them.  [Oh and you can't use it in the next instruction, the rule for
> everything.]  Presumably it's not useful to let each op select.  Or
> maybe three (ABL/FBL/SBL stolen from the VAX).
>
> Comments welcome on how this is useful, or it allows neat tricks.  Is
> there a reason to have more than two?  Also comparison with existing...

Check out the AMD 29000.  If you specified zero as the register number, 
it used a the contents of a special register for the register number. 
Actually there were three "indirect registers", one for each of the 
register positions in the typical RISC instructions.

No addition, but a way to indirectly specify registers.

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

[toc] | [prev] | [next] | [standalone]

#3129

A) In general, I am a fan of flat register files and in particular when implementing SPARC V8s and V9s found that the windowed register files were a performance impediment and not a performance adder.

B) Given that you have the ability to make such a large register file without harming performance (see A above) It is my considered opinion that you would get more performance by sharing that file across several threads than by adding registers to a single context.

C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}

Mitch

[toc] | [prev] | [next] | [standalone]

#3131

On 8/24/2011 9:44 PM, MitchAlsup wrote:
> C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}

GPUs?

Those that I am familiar with have at least 128 registers accessible per 
thread, more if you count the constant registers and other register-like 
things.

Of course, not all programs use all 128 GPRs: most GPUs allow the 
setting of a maximum number of accessible registers per thread, and so 
allow more threads to be smooshed into the same register file.

But there must be some workloads that require 128+ registers, or else 
why ...

[toc] | [prev] | [next] | [standalone]

#3132

On Aug 24, 8:24 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:
> On 8/24/2011 9:44 PM, MitchAlsup wrote:
>
> > C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}

> But there must be some workloads that require 128+ registers, or else
> why ...

Well, many computers had _memories_ with 4,096 words or 32,768 words
or 131,072 words...

Perhaps what's happening is that cache memory works so well that a
design that has an explicit scratchpad memory that exchanges data with
a large memory of many gigabytes under direct program control would
not be more efficient.

John Savard

[toc] | [prev] | [next] | [standalone]

#3133

On Aug 24, 9:08 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Aug 24, 8:24 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
> wrote:
>
> > On 8/24/2011 9:44 PM, MitchAlsup wrote:
>
> > > C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}
> > But there must be some workloads that require 128+ registers, or else
> > why ...
>
> Well, many computers had _memories_ with 4,096 words or 32,768 words
> or 131,072 words...
>
> Perhaps what's happening is that cache memory works so well that a
> design that has an explicit scratchpad memory that exchanges data with
> a large memory of many gigabytes under direct program control would
> not be more efficient.

I was looking for an example, but the manual did not make it
obvious...

One computer that took the world by storm performance-wise was the
Control Data 6600.

And it could, if one were to stretch the point, be said that it had
131,072 registers, and a memory of 2,097,152 words. Because its main
core storage contained 131,072 words - and its extended core storage
contained 2,097,152 words.

John Savard

[toc] | [prev] | [next] | [standalone]

#3136

In article <4E55B24E.2040005@SPAM.comp-arch.net>,
Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote:
>On 8/24/2011 9:44 PM, MitchAlsup wrote:
>> C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}
>
>GPUs?
>
>Those that I am familiar with have at least 128 registers accessible per 
>thread, more if you count the constant registers and other register-like 
>things.
>
>Of course, not all programs use all 128 GPRs: most GPUs allow the 
>setting of a maximum number of accessible registers per thread, and so 
>allow more threads to be smooshed into the same register file.
>
>But there must be some workloads that require 128+ registers, or else 
>why ...

Efficient GPU matrix multiply tends to cache quite large blocks of one
matrix in registers (http://forum.beyond3d.com/showthread.php?t=54842
isn't a bad reference).

"The size of the register file (1024 scalars) on RV770 may seem
impressive, but with 180 cycles of latency for L1 hits, you need 8
threads (wraps in ATi parlance) to hide one texture clause behind 30
cycles of computation (128 multiply-add). This gives us less than ~120
scalars in order to compute, for instance, two 8x8 outer products per
loop: A single texture clause can load the four float8 inputs, and the
two outer products amount to 128 multiply-add instructions." 

[ he then uses 8x10 blocks, getting >4 FMA per cycle and performance of
essentially one single-precision teraflop on R4870:
http://forum.beyond3d.com/showpost.php?p=1325769&postcount=27 and half
a double-precision teraflop on RV870:
http://forum.beyond3d.com/showpost.php?p=1370187&postcount=60 ]

"The fundamental problem with this approach on NVidia is that the
per-strand state is too big. The current kernel uses 31 vec4
registers, that's 124 scalars. If you try to allocate that many on
NVidia you get only 4 threads. Clearly the state can be reduced (and
implemented on NVidia it may be cheaper still for architectural
reasons). But as you do so the code's ALU:TEX falls. Because NVidia
requires a lower ratio here, the cut-off point is lowered, so there's
some slack there."

Tom

[toc] | [prev] | [next] | [standalone]

#3135

In article <771a70b7-04f0-4a4d-9f21-29534f085eea@glegroupsg2000goo.googlegroups.com>,
MitchAlsup  <comp.arch@googlegroups.com> wrote:
>A) In general, I am a fan of flat register files and in particular when imp=
>lementing SPARC V8s and V9s found that the windowed register files were a p=
>erformance impediment and not a performance adder.
>
>B) Given that you have the ability to make such a large register file witho=
>ut harming performance (see A above) It is my considered opinion that you w=
>ould get more performance by sharing that file across several threads than =
>by adding registers to a single context.
>
>C) Can anyone name a machine with that 'took the performance world by storm=
>' and also used more than 5-bits to index the register file(s)? {Note this =
>wording expressively allows the CRAY 1 in because it indexes its register f=
>iles with only 3-bits.}

Ferranti Atlas.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3155

After af few days of thinking, I have decided that the control register programming model of many/most current architectures is/has gotten way out of hand. Dozens to hundreds of registers holding miscelaneous state that need to be changed on a task/task level.

It seems to me that all of this could be managed by HW much better and just create a page-sized area in memory to hold all this context and have the HW fetch in the new context while spewing out the old context as needed. Thus, if a newly scheduled task did not need to use any of the vast myriad of subtle state bits (because <say> it only ran for 6-dozen instructions before taking a fault) that those unused state bits would not have been fetched; much like the pains SW goes through to avoid unloading and loading FP register state.

Discuss!

Mitch

[toc] | [prev] | [next] | [standalone]

#3157

MitchAlsup wrote:
> After af few days of thinking, I have decided that the control register programming model of many/most current architectures is/has gotten way out of hand. Dozens to hundreds of registers holding miscelaneous state that need to be changed on a task/task level.
> 
> It seems to me that all of this could be managed by HW much better and just create a page-sized area in memory to hold all this context and have the HW fetch in the new context while spewing out the old context as needed. Thus, if a newly scheduled task did not need to use any of the vast myriad of subtle state bits (because <say> it only ran for 6-dozen instructions before taking a fault) that those unused state bits would not have been fetched; much like the pains SW goes through to avoid unloading and loading FP register state.
> 
> Discuss!
> 
> Mitch

What's wrong with the current mechanism which traps so the
OS only loads the FPU/XMM registers when the first
x87 FPU/MMX/SSE/SSE2/SSE3/SSSE3/SSE4 instruction is executed?
I think its setting CR0:TS and CR0:MP and clear CR0:EM flags.
I suppose they might have provided some finer grain control
by separating x87/MMX and XMM register loads.
There seem to be other enabler flags for AVX/YMM SIMD registers.

Eric

[toc] | [prev] | [next] | [standalone]

#3158

On Fri, 26 Aug 2011 13:42:35 -0700 (PDT), MitchAlsup
<MitchAlsup@aol.com> wrote:

>After af few days of thinking, I have decided that the control register programming model of many/most current architectures is/has gotten way out of hand. Dozens to hundreds of registers holding miscelaneous state that need to be changed on a task/task level.
>
>It seems to me that all of this could be managed by HW much better and just create a page-sized area in memory to hold all this context and have the HW fetch in the new context while spewing out the old context as needed. Thus, if a newly scheduled task did not need to use any of the vast myriad of subtle state bits (because <say> it only ran for 6-dozen instructions before taking a fault) that those unused state bits would not have been fetched; much like the pains SW goes through to avoid unloading and loading FP register state.
>
>Discuss!


If you're not careful, you'll reinvent x86 task gates...

The idea of having the system store the necessary state on a task
switch (and then loading the new state) is certainly attractive, but
the devil seems to be in the details.  All the implementations seem to
end up extremely complicated.  Both x87 and zSeries have vastly
complex infrastructure for supporting their task switching events.  In
both cases there are carefully crafted subsets of the control
registers that are stored/loaded, and problems will arise if that
doesn't exactly match the OS's model of the world.  In x86's case the
OS's have simply abandoned the facility, for zSeries, the facility was
specifically designed to support zOS, so it by definition matches that
reasonably well (and note that those facilities are largely unused on
the other mainframe OSs).

And further, while you might save some work storing only the changed
state, you probably are going to have a much more difficult time
optimizing the load of the new state.

But yes, the idea is fundamentally appealing, in the same way certain
other very CISC-y things are.  If you can get to work reasonably well,
and match the actual requirement, you'll be golden.

[toc] | [prev] | [next] | [standalone]

#3161

On 8/26/2011 7:53 PM, Robert Wessel wrote:
> On Fri, 26 Aug 2011 13:42:35 -0700 (PDT), MitchAlsup
> <MitchAlsup@aol.com>  wrote:
>
>> After af few days of thinking, I have decided that the control register programming model of many/most current architectures is/has gotten way out of hand. Dozens to hundreds of registers holding miscelaneous state that need to be changed on a task/task level.
>>
>> It seems to me that all of this could be managed by HW much better and just create a page-sized area in memory to hold all this context and have the HW fetch in the new context while spewing out the old context as needed. Thus, if a newly scheduled task did not need to use any of the vast myriad of subtle state bits (because<say>  it only ran for 6-dozen instructions before taking a fault) that those unused state bits would not have been fetched; much like the pains SW goes through to avoid unloading and loading FP register state.
>>
>> Discuss!
>
>
> If you're not careful, you'll reinvent x86 task gates...
>
> The idea of having the system store the necessary state on a task
> switch (and then loading the new state) is certainly attractive, but
> the devil seems to be in the details.  All the implementations seem to
> end up extremely complicated.  Both x87 and zSeries have vastly
> complex infrastructure for supporting their task switching events.  In
> both cases there are carefully crafted subsets of the control
> registers that are stored/loaded, and problems will arise if that
> doesn't exactly match the OS's model of the world.  In x86's case the
> OS's have simply abandoned the facility, for zSeries, the facility was
> specifically designed to support zOS, so it by definition matches that
> reasonably well (and note that those facilities are largely unused on
> the other mainframe OSs).
>
> And further, while you might save some work storing only the changed
> state, you probably are going to have a much more difficult time
> optimizing the load of the new state.
>
> But yes, the idea is fundamentally appealing, in the same way certain
> other very CISC-y things are.  If you can get to work reasonably well,
> and match the actual requirement, you'll be golden.

I have long proposed an instruction of the form

"Load Multiple Control Registers"

- giving a list of all the control registers to load.

Atomically.

Not in the MP sense, but in the sense that you don't need to worry about 
loading registers in any particular order.

One problem with the proliferation of control registers, especially 
those that control modes, is that you have to load registers in a 
particular order.  Certain registers cannot be loaded until other 
registers have had certain mode bits set.   Sometimes you have to set 
mode 1, write register 2, set mode 3 in the same register, overriding 
mode1, write register 4, etc.

One of my friends in validation found this really painful.  AFAIK there 
is no canonical way to set all control registers to a particular state. 
Although he observed that SMI / RSM come close,

[toc] | [prev] | [next] | [standalone]

#3169

On Fri, 26 Aug 2011 20:46:40 -0400, "Andy \"Krazy\" Glew"
<andy@SPAM.comp-arch.net> wrote:

>On 8/26/2011 7:53 PM, Robert Wessel wrote:
>> On Fri, 26 Aug 2011 13:42:35 -0700 (PDT), MitchAlsup
>> <MitchAlsup@aol.com>  wrote:
>>
>>> After af few days of thinking, I have decided that the control register programming model of many/most current architectures is/has gotten way out of hand. Dozens to hundreds of registers holding miscelaneous state that need to be changed on a task/task level.
>>>
>>> It seems to me that all of this could be managed by HW much better and just create a page-sized area in memory to hold all this context and have the HW fetch in the new context while spewing out the old context as needed. Thus, if a newly scheduled task did not need to use any of the vast myriad of subtle state bits (because<say>  it only ran for 6-dozen instructions before taking a fault) that those unused state bits would not have been fetched; much like the pains SW goes through to avoid unloading and loading FP register state.
>>>
>>> Discuss!
>>
>>
>> If you're not careful, you'll reinvent x86 task gates...
>>
>> The idea of having the system store the necessary state on a task
>> switch (and then loading the new state) is certainly attractive, but
>> the devil seems to be in the details.  All the implementations seem to
>> end up extremely complicated.  Both x87 and zSeries have vastly
>> complex infrastructure for supporting their task switching events.  In
>> both cases there are carefully crafted subsets of the control
>> registers that are stored/loaded, and problems will arise if that
>> doesn't exactly match the OS's model of the world.  In x86's case the
>> OS's have simply abandoned the facility, for zSeries, the facility was
>> specifically designed to support zOS, so it by definition matches that
>> reasonably well (and note that those facilities are largely unused on
>> the other mainframe OSs).
>>
>> And further, while you might save some work storing only the changed
>> state, you probably are going to have a much more difficult time
>> optimizing the load of the new state.
>>
>> But yes, the idea is fundamentally appealing, in the same way certain
>> other very CISC-y things are.  If you can get to work reasonably well,
>> and match the actual requirement, you'll be golden.
>
>I have long proposed an instruction of the form
>
>"Load Multiple Control Registers"
>
>- giving a list of all the control registers to load.
>
>Atomically.
>
>Not in the MP sense, but in the sense that you don't need to worry about 
>loading registers in any particular order.
>
>One problem with the proliferation of control registers, especially 
>those that control modes, is that you have to load registers in a 
>particular order.  Certain registers cannot be loaded until other 
>registers have had certain mode bits set.   Sometimes you have to set 
>mode 1, write register 2, set mode 3 in the same register, overriding 
>mode1, write register 4, etc.
>
>One of my friends in validation found this really painful.  AFAIK there 
>is no canonical way to set all control registers to a particular state. 
>Although he observed that SMI / RSM come close,


The closest I've seen to that is the S/370 load-control-register
instruction, which will load a range.  OTOH, the S/370..zSeries
control registers are not nearly the mess that the x86 ones are,
although that's partially the result of several major architectural
revisions where some of the cruft could be cleaned out.

x86 task gates do it in a limited fashion, too, of course.

[toc] | [prev] | [next] | [standalone]

#3211

>>> But yes, the idea is fundamentally appealing, in the same way certain
>>> other very CISC-y things are.  If you can get to work reasonably well,
>>> and match the actual requirement, you'll be golden.


Control registers are a common security mechanism. Make sure you get of all
that right!

[toc] | [prev] | [next] | [standalone]

#3192

On Friday, August 26, 2011 7:46:40 PM UTC-5, Andy Krazy Glew wrote:
> On 8/26/2011 7:53 PM, Robert Wessel wrote:
> > On Fri, 26 Aug 2011 13:42:35 -0700 (PDT), MitchAlsup
> > <Mitch...@aol.com>  wrote:
> >
> >> After af few days of thinking, I have decided that the control register programming model of many/most current architectures is/has gotten way out of hand. Dozens to hundreds of registers holding miscelaneous state that need to be changed on a task/task level.
> >>
> >> It seems to me that all of this could be managed by HW much better and just create a page-sized area in memory to hold all this context and have the HW fetch in the new context while spewing out the old context as needed. Thus, if a newly scheduled task did not need to use any of the vast myriad of subtle state bits (because<say>  it only ran for 6-dozen instructions before taking a fault) that those unused state bits would not have been fetched; much like the pains SW goes through to avoid unloading and loading FP register state.
> >>
> >> Discuss!
> >
> >
> > If you're not careful, you'll reinvent x86 task gates...
> >
> > The idea of having the system store the necessary state on a task
> > switch (and then loading the new state) is certainly attractive, but
> > the devil seems to be in the details.  All the implementations seem to
> > end up extremely complicated.  Both x87 and zSeries have vastly
> > complex infrastructure for supporting their task switching events.  In
> > both cases there are carefully crafted subsets of the control
> > registers that are stored/loaded, and problems will arise if that
> > doesn't exactly match the OS's model of the world.  In x86's case the
> > OS's have simply abandoned the facility, for zSeries, the facility was
> > specifically designed to support zOS, so it by definition matches that
> > reasonably well (and note that those facilities are largely unused on
> > the other mainframe OSs).
> >
> > And further, while you might save some work storing only the changed
> > state, you probably are going to have a much more difficult time
> > optimizing the load of the new state.
> >
> > But yes, the idea is fundamentally appealing, in the same way certain
> > other very CISC-y things are.  If you can get to work reasonably well,
> > and match the actual requirement, you'll be golden.
> 
> I have long proposed an instruction of the form
> 
> "Load Multiple Control Registers"
> 
> - giving a list of all the control registers to load.
> 
> Atomically.

I basically agree with this point. At the instruction before the context switch is taken, the machine is in one well defined architectural state (mode) and the subsequent fetch of the next instruction, in the new context, is made with a similarly well defined architectural state (mode), and the instruction-level programmer knows nothing about the  order of events connecting the before to the after, only that both set of states are well defined.

> Not in the MP sense, but in the sense that you don't need to worry about 
> loading registers in any particular order.
> 
> One problem with the proliferation of control registers, especially 
> those that control modes, is that you have to load registers in a 
> particular order.  Certain registers cannot be loaded until other 
> registers have had certain mode bits set.   Sometimes you have to set 
> mode 1, write register 2, set mode 3 in the same register, overriding 
> mode1, write register 4, etc.

Plus the OS/Hypervisor difficulties in "taking" interrupts and exceptions while manipulating these myriad of control registers.
 
> One of my friends in validation found this really painful.  AFAIK there 
> is no canonical way to set all control registers to a particular state. 
> Although he observed that SMI / RSM come close,

Way back in the 360 days, all this state was contained in the PSW.

Back in the CDC 6600 days, this was all contained in a task control block that could be read and written in 2 memory bank cycle times. That is a task switch took just over the time a load which produced the address for a subsequent load.

So with a modern memory controller, and with the understanding that a context switch was in progress, the inbound context information could be scheduled to DRAM in an more optimal order (like wise for the outgoing state). And let the cache hierarchy and widths do thieir jobs. So if a machine has 3 memory refs per cycle it can write three control registers per cycle.)

This leaves the interrupt vector table to contain the tack control block and a register in the processor that contains the current task control block. 

[toc] | [prev] | [next] | [standalone]

#3217

On 8/24/2011 8:44 PM, MitchAlsup wrote:
> A) In general, I am a fan of flat register files and in particular when implementing SPARC V8s and V9s found that the windowed register files were a performance impediment and not a performance adder.
>
> B) Given that you have the ability to make such a large register file without harming performance (see A above) It is my considered opinion that you would get more performance by sharing that file across several threads than by adding registers to a single context.
>
> C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}
>
> Mitch

Urgh. This on a plane with a pan. Can't google to check, but:

  I think I just read that the Fujitsu K-seriesis at the top of the 
supercomputer TOP 5000 list - or was recently.

  I am not sure, and can't google on plane, but think this uses the 
Fujitsu SPARC 64 with the HPC ACE sIMD instructionset extensions.

  256 FP and SIMD registers. Flat?

32+32 int.

The 256 registers required 8 bit register numbers that did not fit in 
SPARC's existing 32 bit instructions, so Fujitsu added an extension 
prefix instruction SXAR.	

  (TBD: write an article about the difference between extensions that 
are "pasted" to the instructions they extend, and extensions that set 
architectural registers that extend fields).

[toc] | [prev] | [next] | [standalone]

#3218

On 8/24/2011 8:44 PM, MitchAlsup wrote:
> A) In general, I am a fan of flat register files and in particular when implementing SPARC V8s and V9s found that the windowed register files were a performance impediment and not a performance adder.
>
> B) Given that you have the ability to make such a large register file without harming performance (see A above) It is my considered opinion that you would get more performance by sharing that file across several threads than by adding registers to a single context.
>
> C) Can anyone name a machine with that 'took the performance world by storm' and also used more than 5-bits to index the register file(s)? {Note this wording expressively allows the CRAY 1 in because it indexes its register files with only 3-bits.}
>
> Mitch

Actually, Mitch, I think I'll take the opposite:

  register windows<< multiple threads with separate, disjoint, register 
files << a single thread with a big flat register file (and block on 
use) n multiple threads with variable sized register files partitioning 
a big RF

  Comparable: in system software, which would you rather do: write a 
really multithreaded program I or use as inch I/o?

  Myself, I would rather write the asynch I/o program as a single 
thread, for jobs like fast file copy or backup. Sure, given enough work 
the multithreaded version may heat the asynch I/oversion. But the best 
program willprobably need to do both, and the a synch I/o version is 
often low hanging fruit, easy to get a good speedup. I only jump to 
threads first when the computation is non-trivial, e.g. where I don't 
want to lock out user input while rendering.

Explanation: registers are rather like asynch I/O handles. The more such 
handles or registers, the more such parallelism under user control.

Yes, threads do the same, but threads always have overhead, in both HW & SW.

  (By the Way, I don't care to discuss a synch I/o implementations that 
require a Kernel thread for each asynch I/O. That's stupid. Asynch I/O 
handles can be much cheaper than a Kernel thread.

Variable size RFs per thread seem to have the best of both worlds.

  My main problem with variable size RFs, or large flat RFs in generals 
is architecture: I am by no means certain that multithreaded 
microarchitectures are the best for all systems. Back of the envelope 
calculations southeast MIMD are best in some cases. With small RFs. How 
does code written for a large RF run when there isn't one?

  I am not so concerned about fitting into a 32 bit instruction with S 
bit fields. Many codes that use flat large RFs fit in loop buffers, etc.

[toc] | [prev] | [next] | [standalone]

#3223

On 8/27/2011 6:39 PM, Andy "Krazy" Glew wrote:
> On 8/24/2011 8:44 PM, MitchAlsup wrote:
>> A) In general, I am a fan of flat register files and in particular
>> when implementing SPARC V8s and V9s found that the windowed register
>> files were a performance impediment and not a performance adder.
>>
>> B) Given that you have the ability to make such a large register file
>> without harming performance (see A above) It is my considered opinion
>> that you would get more performance by sharing that file across
>> several threads than by adding registers to a single context.
>>
>> C) Can anyone name a machine with that 'took the performance world by
>> storm' and also used more than 5-bits to index the register file(s)?
>> {Note this wording expressively allows the CRAY 1 in because it
>> indexes its register files with only 3-bits.}
>>
>> Mitch
>
> Actually, Mitch, I think I'll take the opposite:
>
> register windows<< multiple threads with separate, disjoint, register
> files << a single thread with a big flat register file (and block on
> use) n multiple threads with variable sized register files partitioning
> a big RF
>
> Comparable: in system software, which would you rather do: write a
> really multithreaded program I or use as inch I/o?
>
> Myself, I would rather write the asynch I/o program as a single thread,
> for jobs like fast file copy or backup. Sure, given enough work the
> multithreaded version may heat the asynch I/oversion. But the best
> program willprobably need to do both, and the a synch I/o version is
> often low hanging fruit, easy to get a good speedup. I only jump to
> threads first when the computation is non-trivial, e.g. where I don't
> want to lock out user input while rendering.
>
> Explanation: registers are rather like asynch I/O handles. The more such
> handles or registers, the more such parallelism under user control.
>
> Yes, threads do the same, but threads always have overhead, in both HW &
> SW.
>
> (By the Way, I don't care to discuss a synch I/o implementations that
> require a Kernel thread for each asynch I/O. That's stupid. Asynch I/O
> handles can be much cheaper than a Kernel thread.
>
> Variable size RFs per thread seem to have the best of both worlds.
>
> My main problem with variable size RFs, or large flat RFs in generals is
> architecture: I am by no means certain that multithreaded
> microarchitectures are the best for all systems. Back of the envelope
> calculations southeast MIMD are best in some cases. With small RFs. How
> does code written for a large RF run when there isn't one?
>
> I am not so concerned about fitting into a 32 bit instruction with S bit
> fields. Many codes that use flat large RFs fit in loop buffers, etc.

I may back out from this.

Threads, annoyingly, are scalable.  They can be portable across more 
microarchitectures than large register files.

E.g. threads with a moderate maximum number of registers, say 16, 32, or 64

a) can run on simple machines, e.g. independent MIMD

b) can run on highly multithreaded machines, e,.g. GPU-style 
microarchitectures with 2K registers, split amongst many threads

c) can run on in-orrder, out-of-order, whatever.

Whereas large register files, like 256 regs

A) require fairly big basic machines - i.e. they do not run on the 
really lightweight MIMD procesors that are one of my design points.

B) make OOO more expensive, or at least more difficult.

[toc] | [prev] | [next] | [standalone]

#3252

In article <771a70b7-04f0-4a4d-9f21-29534f085eea@glegroupsg2000goo.googlegroups.com>,
MitchAlsup  <comp.arch@googlegroups.com> wrote:
>A) In general, I am a fan of flat register files and in particular when
>implementing SPARC V8s and V9s found that the windowed register files
>were a performance impediment and not a performance adder.

me so

I was unimpressed by register windows; it seems like more complexity and
not significant return.

I guess the question is, supposing that you have proved that a much
larger GPR file is useful, then do we need to relook this?

VLIW is fine but if we're spending 14 bits per operand and it can be
compressed with little cost...

as opposed to 'just make the cache better!' which is hard to argue
against really

[toc] | [prev] | [next] | [standalone]

#3145

On 8/24/11 12:36 PM, Joe Keane wrote:
> This is bouncing around my head.
>
> Say we have a machine with a lot of general registers, at least 1024 and
> possibly much more.  [There's some VLIWy stuff, but i think it's
> irrelevant, so pretend i tell you it's a standard RISCy machine.]
>
> We add a register BL (base latch).
>
> Every op that get/put a register has a bit called 'index'.  If off, the
> register number is in the op; if on, we add that to BL to get the correct
> register number.  Now we can cheat a bit on the register field; maybe
> the machine has 16384 registers, but we can only access 512 without
> changing BL.

AMD29k did this. Most instructions were of the form

	C = A op B

Where A, B & C were each 1 bit (same as your index) + 7 bit reg #. If the
top bit was off, you directly accessed reg1..reg127 from the register file.
If it was on, you add the 7 bit reg# to reg1 and used the lowest 7 bits
to index the other 128 registers from the 256 register file. So reg1 (called
gr1) was the same as your BL but only for 128 registers.

reg# 0 was special. Depending on whether it was in the A, B or C field, you
picked up the real reg# from `special' registers IPA, IPB or IPC and accessed
that.

> It's unclear whether access to BL is a KISS movtcr/movfcr, or we should
> have some ops like save/restore.  It is tempting, we can put an adder
> next to BL and he won't need to bother anyone.  In either case we also
> want a compare with some bound; if out of whack, do something-or-other.

This limit checking was done on function entry or exit. If the function
wanted N registers and the file has < N, you took a trap, saved some
register contents to memory and returned. Similar on function exit (if
the caller's registers were in memory, you took a trap and restored them).

> Basically register windows, but each op can choose to index or not.
>
> Really, there's BL1 and BL2, and of course some way to switch between
> them.  [Oh and you can't use it in the next instruction, the rule for
> everything.]  Presumably it's not useful to let each op select.  Or
> maybe three (ABL/FBL/SBL stolen from the VAX).

gr1 was used as a stack ptr and you adjusted it twice in a function
(except leaf functions). So don't see the need for two such registers.

> Comments welcome on how this is useful, or it allows neat tricks.  Is
> there a reason to have more than two?  Also comparison with existing...

29k was a fun processor to program! Not sure how well its 3 ported
256 register file would have scaled in speed. Perhaps modern compilers
would have made better use of its huge register set. On the other hand
a large register set made context switching between threads expensive.
It also needed to maintain a separate memory stack which complicated
things. Because of that I felt it would be better to have reg# fields
in an instructions reference *memory* relative to a stack ptr. Then
stack adjustment could be seen as a hint to move data between the cache
and memory (or throw stale data away). And context switching would be
very quick.

Bakul Shah

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web