From: Brett Davis on 18 Apr 2010 23:25
In article <uf-dnbaq5J9o_lbWnZ2dnUVZ8sCdnZ2d(a)giganews.com>,
> In article <4BCB60FF.9030306(a)patten-glew.net>, ag-news(a)patten-glew.net (
> Glew) wrote:
> > Itanium was designed by people who thought that P6-style out-of-order
> > was going to fail.
> Ah, that makes sense. Thanks. In some ways the Itanium method of running
> several instructions at once seems more "obvious". I was convinced by it
> at first, and only gradually realised that in spite of its intuitive
> appeal, it did not work well in this example.
Intriguing, could you elaborate. (Bear in mind I would like to know the
good points in Itanium, despite the mocking of Itanic.)
Here is the Itanic Software dev manual, start at page 1:14, section 2.5:
Also the instruction set manual:
I look at Section 2.6.1/2.6.2 and I see something similar to the PowerPC
pre-load hint. (A no-harm data preload hint, could be great, is useless.)
The "acheck" and "use" stuff makes me go: What!?! Are you serious!?!
2.6.3 Predication, ARM has this. Seems to hurt clock rate?
2.7: Register Windows, Spark has this, cackle. ;)
2.8: Branch hints could be nice. Will add a form to CLIW.
2.9: Register rotation, someone needs to be locked in a rubber room. ;)
> > In many ways they were the P6 competitors. P6 was Oregon. Itanium
> > was California. Many Itanium folk were from P5.
> If they had left P5 in the relatively early days, when clock speeds were
> still under 100MHz, their implicit assumptions about speeds and
> bandwidths make more sense. Thanks again.
It is my opinion that Itanic is a disaster at any speed. ;)
From: nmm1 on 19 Apr 2010 04:58
In article <ggtgp-8BCC50.22254218042010(a)news.isp.giganews.com>,
Brett Davis <ggtgp(a)yahoo.com> wrote:
>Intriguing, could you elaborate. (Bear in mind I would like to know the
>good points in Itanium, despite the mocking of Itanic.)
Doubtless there were some. The early marketing was excellent, but
that wasn't IN Itanium.
>2.7: Register Windows, Spark has this, cackle. ;)
>2.9: Register rotation, someone needs to be locked in a rubber room. ;)
Yes and no. They can be VERY effective, as on the Hitachi SR2201.
However, what Hitachi understood and HP/Intel didn't is that you
MUST keep them clean, and they really don't mix with any break in
the sequential control flow, including fixup-by-interrupt.
>It is my opinion that Itanic is a disaster at any speed. ;)
Technically, that does seem to be the case.
From: Andrew Reilly on 19 Apr 2010 09:14
On Sun, 18 Apr 2010 22:25:42 -0500, Brett Davis wrote:
> 2.6.3 Predication, ARM has this. Seems to hurt clock rate?
I don't know that that's the limit on clock rate, but what do I know. In
any case, ARM's predicates are condition-code flavoured. More Itanium-
like are the predicates used by TI in the C6000 series of DSPs: simple
boolean values in the first five registers (why five? no idea). TI has
versions of the C6000 that run to about 1GHz, which isn't high compared
to mainstream processors, but there aren't many DSP cores faster.
Besides the TI, the Trimedia is still going, and although decamped for
the afterlife, the Transmeta Crusoe didn't really do too badly,
considering (I used one in a Fujitsu laptop). VLIW is probably
unhelpful, now that there are enough transistors and branch predictors to
make OOO behave reasonably, but it's not an unreasonable approach for a
From: Robert Myers on 20 Apr 2010 08:52
Brett Davis wrote:
> But ultimately is not register windowing just a horrid complex slow
> way to get more register bits, in a fix width instruction set?
Not in the case of Itanium, which has tons of registers.
The purpose, as I understand it, is to permit more seamless operation
across procedure calls.
From: Stefan Monnier on 19 Apr 2010 10:05
>> 2.9: Register rotation, someone needs to be locked in a rubber room. ;)
> Yes and no. They can be VERY effective, as on the Hitachi SR2201.
How did they work?