Re:328 registers!!!
by
Lord+Sauron
·
· Score: 2, Interesting
Real programmers who had to deal with the lack of registers. For instance, take the infamous Z-80. It had only 7 general purpose 8-bit registers, A,B,C,D,E,H and L, and you could use BC, DE and HL as a 16-bit register.
It also had 2 16-bit index registers, a 16-bit stack pointer and a 16-bit program counter. Wich, of course, shouldn't be used for calculations.
So you could count the registers on your hand. Ye good ol' times.
Re:Better link
by
Segfault+11
·
· Score: 3, Interesting
Re:Why this strange name ?
by
Spencerian
·
· Score: 2, Interesting
I'd have to disagree with the use of titanium in some cases. True, a lot of companies are using the name for the cool factor, but Apple's application of titanium as its outer case for its professional PowerBook line is both aethestic and functional.
The PowerPC G4 chip is a hot beast (nothing like the P3 or P4, but hot enough) that the titanium is used in part as a heat sink. Apple's application of the metal seems to get lots of oohs and ahhs as a result of this blend.
-- Vos teneo officium eram periculosus ut vos recipero is.
Re:wrong direction?
by
Mydron
·
· Score: 2, Interesting
You've missed the point.
Complex compiling issues are NOT a result of CISC or RISC in this case. In fact, RISC is far easier to write an efficient compiler for than CISC. The instructions offered by RISC more closely mimic the kinds of basic operations compilers manipulate in the very back end of compilation. Register sets are usually general and very orthogonal, compared to CISC (Intel in particular) where you have very few registers and they all have special meaning depending on context.
The complexity in building compiling tools with respect to the itanium is all about VLIW, parallelization and scheduling. These are incredibly complex topics with many subtle features that make optimization and analysis very difficult.
Also, think again if you think compilers are written once for an achitecture and then set in stone -- 'once the damn thing is done' it definately will not be done. It will probably be buggy and poor at doing these new complicated tasks compiler writers have never had to do before. It will likely take a few iterations before the compiler tools start to show off the architecture. The question is which will come first, the latter or industry's frustration with poor performance out of expensive silicon.
compiler technology crucial
by
mrm677
·
· Score: 2, Interesting
Itanium is making the compiler do alot of work! This presents a gigantic challenge for compiler writers. My concern is with GCC. We all know that GCC does not produce the tightest, fastest code. For IA-32, this is not a big deal because there is only so much optimization that can be done with that ISA (instruction set architecture). However with Itanium, the compiler will probably affect runtime execution speed by 100% or more. Will the GCC people have the resources and expertise to handle IA-64 (Itanium)??
the real problem for intel is that the arch does badly for programs that are not cache hitters
they took one look at the people trying to do predictive memory loads and decided not too. this was a LONG time ago and now people have solved the problem so that most of the time you can get things from cache
IA64 fails to get things from cache too well (one of the reasons why they stuck such a large one on) so suffers from the latencey problems more than most
simple
regards
john 'try runnning spec marks on it' jones
it's always been about the compilers
by
jrst
·
· Score: 4, Interesting
Many of the comments about compiler technology in this thread could be taken verbatim from discussions about RISC architectures 20 years ago. Or from the HLL (high level language) architecture discussions 30 years ago. (Anyone remember the cries for "closing the semantic gap" between processor's and languages? No? Point made.)
Hardware is getting more complex; it takes more sophistication to deal with it. Binding a (general purpose) processor to a language in order to make language implementation easier is exactly the wrong way to support a wider variety of languages. Making the most of a processor's capabilities is what compilers are for. That's what compiler writers get paid for.
That's not to say I'm in love with the Itanium. At first glance I found it a baroque rehash of old ideas. But time--and compiler writer's--will tell.
A visionary's gutfeel regarding 64-bit widespread
by
pinkpineapple
·
· Score: 3, Interesting
When Steve Jobs was asked about what he was envisioning regarding 64-bit processor adoption (related to the fact that at that time, IBM came out with the Power4 kick ass cpu), his reply was that it would take about 10 years for the common of the mortals (you and me mostly, but not him:-) to see 64-bit systems on the shelves at Fry's or CompUSA.
Given that it was coming out from the mouth of the CEO of a company that :
- can afford the move quickly and nicely (PowerPC architecture is clean compare to IA-64 + x86 and is 32-bit backward compatible).
- had successfully shifted the kernel to a clean replacement (less kludges) allowing the transition in a blink of an eye (ok, maybe 6 months)
- has a park of installed machines in places like labs (see gentech), and design studio.
- runs applications that would benefit the most are all in the Apple camp (A/V and number crunching apps like photoshop, maya and final cut)
- develops a big chunck of the major apps for its platform leading the way in term of design and adoption of new tech.
it would seem that we have about 8 more years of 32-bit glory or galore in front of us, before the current cpu architectures get displaced and eventually die.
Which 64-bit architecture will succeed is not clear today. Knowing that MS doesn't rush their OS out of the door to support the IA-64, it seems to be a little premature to tell.
PPA, the girl next door.
-- -- I feel better now. Thanks for asking.
Gad, what a turkey
by
Animats
·
· Score: 3, Interesting
I can't see why Intel bothered with this thing.
Intel pioneered mainstream superscalar out-of-order machines with the Pentium Pro/II/III architecture, which made it possible to make CISC architectures go fast. That was a major achievement. It made classic RISC obsolete - why put up with the code bloat?
Then came the Inanium. VILW, code bloat, ugly architecture, requires near-omniscience from the compiler, very tough to program in assembler, a power hog, and with mediocre performance. If anybody else had launched this, it would have died before first shipment. As it is, it's dying anyway.
Dell dropped their Itanium workstation recently.
The Itanium may end up as a niche product, like the forgotten i860, i960, and iapx432 processors.
I'm hearing rumors of a new 64-bit machine from Intel that's basically an improved x86, like the AMD Sledgehammer. That may be what actually gets used.
Re:Gad, what a turkey
by
timmyd
·
· Score: 2, Interesting
even though the IA-64 arch does seem to have some weird stuff into it, i wouldn't call it UGLY especially when comparing it to the IA-32 "architecture" (or rather lack of it.) and who programs in assembler nowadays? (excluding the MMX/SSE stuff which however is a direct consequence of the crap fpu on IA-32)
IA-64 still has backwards compatibility with ia-32, which has realmode, v86, and protected mode. that makes the ia-64 a mess to start with. compilers still generate assembler in some cases and some people have to use asm for low level things in the kernel and doing things that you can't do in C, like calling software interrupts, which, by the way, requires that you enter either v86 or real mode which isn't as simple as changing the PE bit. you have to setup the stack, and memory segments again and real mode can only physically access 2^20/1024/1024=1 megabyte of memory at once. maybe if intel would stop building on their old crap the whole thing would get a little simplier.
but i guess it would be boring if everything was as simple and stable as a calculator.
Real programmers who had to deal with the lack of registers. For instance, take the infamous Z-80. It had only 7 general purpose 8-bit registers, A,B,C,D,E,H and L, and you could use BC, DE and HL as a 16-bit register.
It also had 2 16-bit index registers, a 16-bit stack pointer and a 16-bit program counter. Wich, of course, shouldn't be used for calculations.
So you could count the registers on your hand. Ye good ol' times.
Of course, for some perspective on the nature of processor speculation, I point you to nearly any issue in Byte's print archive.
I registered my hate for Jon Katz
I'd have to disagree with the use of titanium in some cases. True, a lot of companies are using the name for the cool factor, but Apple's application of titanium as its outer case for its professional PowerBook line is both aethestic and functional.
The PowerPC G4 chip is a hot beast (nothing like the P3 or P4, but hot enough) that the titanium is used in part as a heat sink. Apple's application of the metal seems to get lots of oohs and ahhs as a result of this blend.
Vos teneo officium eram periculosus ut vos recipero is.
You've missed the point.
Complex compiling issues are NOT a result of CISC or RISC in this case. In fact, RISC is far easier to write an efficient compiler for than CISC. The instructions offered by RISC more closely mimic the kinds of basic operations compilers manipulate in the very back end of compilation. Register sets are usually general and very orthogonal, compared to CISC (Intel in particular) where you have very few registers and they all have special meaning depending on context.
The complexity in building compiling tools with respect to the itanium is all about VLIW, parallelization and scheduling. These are incredibly complex topics with many subtle features that make optimization and analysis very difficult.
Also, think again if you think compilers are written once for an achitecture and then set in stone -- 'once the damn thing is done' it definately will not be done. It will probably be buggy and poor at doing these new complicated tasks compiler writers have never had to do before. It will likely take a few iterations before the compiler tools start to show off the architecture. The question is which will come first, the latter or industry's frustration with poor performance out of expensive silicon.
Itanium is making the compiler do alot of work! This presents a gigantic challenge for compiler writers. My concern is with GCC. We all know that GCC does not produce the tightest, fastest code. For IA-32, this is not a big deal because there is only so much optimization that can be done with that ISA (instruction set architecture). However with Itanium, the compiler will probably affect runtime execution speed by 100% or more. Will the GCC people have the resources and expertise to handle IA-64 (Itanium)??
the real problem for intel is that the arch does badly for programs that are not cache hitters
they took one look at the people trying to do predictive memory loads and decided not too. this was a LONG time ago and now people have solved the problem so that most of the time you can get things from cache
IA64 fails to get things from cache too well (one of the reasons why they stuck such a large one on) so suffers from the latencey problems more than most
simple
regards
john 'try runnning spec marks on it' jones
Many of the comments about compiler technology in this thread could be taken verbatim from discussions about RISC architectures 20 years ago. Or from the HLL (high level language) architecture discussions 30 years ago. (Anyone remember the cries for "closing the semantic gap" between processor's and languages? No? Point made.)
Hardware is getting more complex; it takes more sophistication to deal with it. Binding a (general purpose) processor to a language in order to make language implementation easier is exactly the wrong way to support a wider variety of languages. Making the most of a processor's capabilities is what compilers are for. That's what compiler writers get paid for.
That's not to say I'm in love with the Itanium. At first glance I found it a baroque rehash of old ideas. But time--and compiler writer's--will tell.
When Steve Jobs was asked about what he was envisioning regarding 64-bit processor adoption (related to the fact that at that time, IBM came out with the Power4 kick ass cpu), his reply was that it would take about 10 years for the common of the mortals (you and me mostly, but not him :-) to see 64-bit systems on the shelves at Fry's or CompUSA.
Given that it was coming out from the mouth of the CEO of a company that :
- can afford the move quickly and nicely (PowerPC architecture is clean compare to IA-64 + x86 and is 32-bit backward compatible).
- had successfully shifted the kernel to a clean replacement (less kludges) allowing the transition in a blink of an eye (ok, maybe 6 months)
- has a park of installed machines in places like labs (see gentech), and design studio.
- runs applications that would benefit the most are all in the Apple camp (A/V and number crunching apps like photoshop, maya and final cut)
- develops a big chunck of the major apps for its platform leading the way in term of design and adoption of new tech.
it would seem that we have about 8 more years of 32-bit glory or galore in front of us, before the current cpu architectures get displaced and eventually die.
Which 64-bit architecture will succeed is not clear today. Knowing that MS doesn't rush their OS out of the door to support the IA-64, it seems to be a little premature to tell.
PPA, the girl next door.
-- I feel better now. Thanks for asking.
Then came the Inanium. VILW, code bloat, ugly architecture, requires near-omniscience from the compiler, very tough to program in assembler, a power hog, and with mediocre performance. If anybody else had launched this, it would have died before first shipment. As it is, it's dying anyway. Dell dropped their Itanium workstation recently. The Itanium may end up as a niche product, like the forgotten i860, i960, and iapx432 processors.
I'm hearing rumors of a new 64-bit machine from Intel that's basically an improved x86, like the AMD Sledgehammer. That may be what actually gets used.