Big OOO, SpMT, and possible designs (Was Re: Free/Open x86 Sim)
|
Prev: A post to comp.risks that everyone on comp.arch should read
Next: Call for papers : HPCS-10, USA, July 2010
From: nmm1 on 30 May 2010 05:09 In article <4C01EDA0.7080107(a)patten-glew.net>, Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: > >We are using different terminology. > >When I say "non-deterministic" I mean a feature that, when executed >may gives different answers if it is run several different times on >the same machine. "Non-reproducible" is a related term. I often >talk about "deterministic reproducibility". > > . . . > >You, Nick, seem to be using "non-deterministic" to mean "undefined". >True, the broad meaning of undefined might include non-deterministic. It does, and it often does in practice. An intermediate point, which is one of the things that I was thinking of, was that different revisions of the same chip may behave differently. From the point of view of writing portable code, that is non-deterministic. >However, much progress in computer architecture has involved >refining the meaning of various undefined features. Do you mean words or features? If words, the documentation didn't say so - and, in the absence of such a statement, the normal meaning prevails. If features, then that is a change in the x86 architecture, so I would have to check if it still applies to the current ranges, though it did apply until recently. Regards, Nick Maclaren.
From: Andy 'Krazy' Glew on 30 May 2010 11:06 On 5/30/2010 2:09 AM, nmm1(a)cam.ac.uk wrote: > In article<4C01EDA0.7080107(a)patten-glew.net>, > Andy 'Krazy' Glew<ag-news(a)patten-glew.net> wrote: >> >> However, much progress in computer architecture has involved >> refining the meaning of various undefined features. > > Do you mean words or features? If words, the documentation didn't > say so - and, in the absence of such a statement, the normal meaning > prevails. If features, then that is a change in the x86 architecture, > so I would have to check if it still applies to the current ranges, > though it did apply until recently. Both. For example, what should happen if the user executes writes a register with a value such that "the effect of writing such and such a value into the register is undefined?" In the past, some designers have been very liberal in the implementation of such undefined values. Something along the lines of GCC invoking Tower of Hanoi for certain undefined actions in C. However, at the very least we cannot say arbitrarily undefined. For example, if an unpriviliged user is performing the action, we may have the restriction that the action may be undefined, but cannot be allowed to result in a violation of the User/Kernel securiy model. ("Undefined but secure"). Similar considerations now apply to OS features - undefined actions cannot be allowed to violate the virtual machine security model. As for documentation: you don't see the entire documentation, Nick. You see the external architecture documentation. The guys who build the chip have another set of requirements.
From: nmm1 on 30 May 2010 16:57 In article <4C027F05.7040007(a)patten-glew.net>, Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: > >As for documentation: you don't see the entire documentation, Nick. >You see the external architecture documentation. The guys who build >the chip have another set of requirements. Precisely. The thread was about the architecture, and that is what I was talking about - I know perfectly well that the design of a particular chip is more specific. My point was and is that the x86 architecture allows non-determinicity, not that any particular x86 is non-deterministic. The same was true of the original 'system architecture' range - the System/360 - after all! Regards, Nick Maclaren.
From: nedbrek on 1 Jun 2010 07:09
"Andy 'Krazy' Glew" <ag-news(a)patten-glew.net> wrote in message news:4C0079AC.5030405(a)patten-glew.net... > On 5/28/2010 9:11 AM, nmm1(a)cam.ac.uk wrote: >> In article<4BFFCF43.5010004(a)patten-glew.net>, >> Andy 'Krazy' Glew<ag-news(a)patten-glew.net> wrote: >>> >>> Hadn't expected you to say that Itanium was an in-order design with >>> baby steps towards out-of-order. >> >> That's because I didn't. >> >> Those were NOT baby steps, but gargantuan leaps, though I agree not >> in the same direction as the sort of out-of-order you work on. >> In particular, they introduced out-of-order processing into an >> area of the kernel which had been solidly in-order from time >> immemorial, and where getting even THAT right was hard enough. > > I am not so sure I know what kernel areas you refer to, (RSE?), but I have > a > similar opinion about the ALAT: it made single threaded > user code non-deterministic, just like parallel code. Not a good thing. > > However, in all of this I always seek to guarantee sequential semantics > for a > single thread: although the actual events happen out of order, it is as if > they happened in order. My exposure to the OS on Itanium was only through thought experiments, so I may not have the same things in mind as Nick... One big one was architecting stalls for load use, rather than on the initial load. Imagine: ld r1 = [big miss] if r2, go far away add = r1 (compiler has hoisted a load above a branch which results in the load value not being used) A page fault should be detectable before too many instructions go by (theoretically, before anything reaches WB). I'm not sure if the Itanium guys were so conscientious. They might have pushed the restart onto software. Now imagine you have a big, clustered SMP. The load goes off to a remote node's memory, and comes back with a double bit ECC. Say 200 clocks. 1200 instructions have gone by, and you have to try and make sense of where the process is... maybe it doesn't matter if you are just going to kill it... maybe there are more correctable things that can happen at the remote node... >>> In some ways, the ways you mention, Itanium exposed out-of-order >>> effects to the programmer while keeping the pipeline in-order. >> >> And that's the point. Despite common belief, computer architecture >> has been about both hardware and software (and their interaction) >> for at least the past 45 years - and all that the Itanic did was >> to simplify the hardware designer's life a little while making the >> software designer's one almost impossible. I don't think it simplified the designer's life much. RSE was famous for breaking people. The register renaming scheme was a pain. A lot of things were big wire hogs. The initial implementations didn't do mapped renaming or dynamic scheduling, but those are well understood implementations. I would really like to know how much of the design was motivated by "AMD will never figure out how to build this!" Ned |