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


Groups > comp.arch > #3161

Re: indexing register

Message-ID <4E583E70.9080101@SPAM.comp-arch.net> (permalink)
Date 2011-08-26 20:46 -0400
From "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net>
Organization comp-arch.net
Newsgroups comp.arch
Subject Re: indexing register
References <j33jr6$e0g$1@reader1.panix.com> <771a70b7-04f0-4a4d-9f21-29534f085eea@glegroupsg2000goo.googlegroups.com> <da17268b-590b-483b-aa37-5474b068a378@glegroupsg2000goo.googlegroups.com> <fubg575p1r13idmpdvsafhnvpgmi8c0m9j@4ax.com>

Show all headers | View raw


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,

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web