Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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