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 28 May 2010 08:42
In article <htoan9$gkd$1(a)news.eternal-september.org>,
nedbrek <nedbrek(a)yahoo.com> wrote:
>
>Ok, then in what way is Itanium not in-order? The front end scoops up
>instructions, expands (NOP insertion, woohoo!), rotates and presents them to
>rename and execution. Execute is set up to (almost) always be 1 cycle. DET
>performs the predication, and then there's writeback. Everything flows
>along, in program order.

I have work to do, and so am not going to reread that architecture
to remind myself of all the places I spotted out-of-order execution
being let in by the back door, so here is what I can remember.

Lazy register loading and storing, and possibly even other modes.
The extreme form was dropped with the Merced (as I said, and had
expected).

Interrupts and unwind sections. Interrupts are always out-of-order,
but unwind sections mean that a completely unrelated thread is making
changes that affect the registers of the interrupted process.

If I recall, some of the flags (e.g. floaating-point exceptions) and
the extra-specially-invalid states.


Regards,
Nick Maclaren.
From: Andy 'Krazy' Glew on 28 May 2010 10:12
On 5/28/2010 5:42 AM, nmm1(a)cam.ac.uk wrote:
> In article<htoan9$gkd$1(a)news.eternal-september.org>,
> nedbrek<nedbrek(a)yahoo.com> wrote:
>>
>> Ok, then in what way is Itanium not in-order?
>
> I have work to do, and so am not going to reread that architecture
> to remind myself of all the places I spotted out-of-order execution
> being let in by the back door, so here is what I can remember.

I thought that you were going to say that you had meant that Itanium was not the nost aggressive out-of-order design.

Hadn't expected you to say that Itanium was an in-order design with baby steps towards out-of-order.

Of course you are right, Nick, but you are using terms in a way that is so distant of the standard terminology, as used
by Ed and me and other architects at Intel (who are a plurality of the architects in the world), that communication
isn't taking place.

Nevertheless, your point is valid and interesting. Did Itanium fail because of these half-assed attempts to gain the
benefit of out-of-order on an in-order pipeline? In some ways, the ways you mention, Itanium exposed out-of-order
effects to the programmer while keeping the pipeline in-order. (Remember, the RSE register save engine never really
shipped.)

Or did Itanium fail because real out-of-order beat real in-order?


>
> Lazy register loading and storing, and possibly even other modes.
> The extreme form was dropped with the Merced (as I said, and had
> expected).
>
> Interrupts and unwind sections. Interrupts are always out-of-order,
> but unwind sections mean that a completely unrelated thread is making
> changes that affect the registers of the interrupted process.

I know that y'all have been having an interesting discussion about interrupts, and lack thereof. But I'll draw a line
in the sand there: a general purpose microprocessor that doesn't have interrupts will fail, at this poimnt in history.
You don't need to check for interrupts pendng onevery instruction, but you do need to have "asynchronous" "external"
interrupts.

>
> If I recall, some of the flags (e.g. floating-point exceptions) and
> the extra-specially-invalid states.
>
>
> Regards,
> Nick Maclaren.

From: nmm1 on 28 May 2010 12:11
In article <4BFFCF43.5010004(a)patten-glew.net>,
Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote:
>
> I thought that you were going to say that you had meant that
> nost aggressive out-of-order design.
>
> 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.

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


Regards,
Nick Maclaren.
From: MitchAlsup on 28 May 2010 18:07
On May 28, 11:11 am, n...(a)cam.ac.uk wrote:
> 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.

Minor quibble:

Computer Architecture IS the contract between hardware and software
(and has been since the Anderson paper in 1963)
Computer microarchitecture is how the hardware goes about giving the
software writer the illusion that that architecture spec is being
obeyed.

Almost all of the OutofOrder machines give the software writer the
illusion that the machine remains completely InOrder (as seen by the
instruction pointer, and by interested third parties outside the CPU
boundary). Thus, the microarchitecture is doing a bunch of hocus pocus
to run instructions out of order, and keeping a trail of crumbs so
that when the InOrder illusion become violated, order is restored
before anyone sees the OutofOrderness.

Some OutofOrder machines go so far as to make the software tell the
machine when to appear InOrder. By and large these machines have
either failed to become mainstream, are dying out, or have died out.

Mitch

From: Andy 'Krazy' Glew on 28 May 2010 22:19
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:
>>
>> I thought that you were going to say that you had meant that
>> nost aggressive out-of-order design.
>>
>> 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.

Now *that* I agree with.

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.

Inside the kernel: well, I know that I have applied out-of-order to just about every part of the kernel. I've even
figured out how to do many disk I/Os (both reads and writes) and page faults out of order. In hardware control. (BTW,
one of Yale Patt's students took an earlier software approach to doing I/Os out of order.) The only things you need to
keep in-order are (a) interactions with the user, and (b) accesses to I/Os that have order dependent side effects.
(Writes obviously need to have a certain order in commitment. But not necessarily strict.)

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.


>
>> 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.
>
>
> Regards,
> Nick Maclaren.

First  |  Prev  |  Next  |  Last
Pages: 4 5 6 7 8 9 10 11 12 13 14 15 16
Prev: A post to comp.risks that everyone on comp.arch should read
Next: Call for papers : HPCS-10, USA, July 2010