flat assembler
Message board for the users of flat assembler.

Index > Heap > AMD64 screwed our future for next 20 years? Or the eternity

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
kake_zinger



Joined: 15 Jul 2004
Posts: 51
kake_zinger
Recently AMD and their newest 64-bit offering has been hailed as the new hero.

But let's look at the downside and get depressed: their extensions introduce a whopping 8 new 64-bit general purpose registers, giving us the total of 12 usable registers, as ebp, esp, esi, edi or whatever their 64-bit counterparts are called are't really usable, at least not all the time. And even others are eaten up simply for adressing modes. Realistically this leaves us with only 8 really global registers for data.

16 damn registers. Whereas most other 64-bit CPU's have more like 32 and have had that for what 20+ years now. Or like The Itanic, a whopping 128 registers. That's something they really got right the first time.

What's the point of a superfast memory bus on a superfast CPU if you can do a whopping 16 loads or stores at one time? Lack of registers is insane as long as we're going to be limited by memory speed. No amount of cache is really a substitute for registers.

This makes me sick. They could have revolutionized desktop computing for ever, as there's hardly any reason to move to 128 bit computing for quite some time. We're going to be stuck with 12 usable registers for the rest of eternity now that Intel has adopted AMD's extensions. There aren't really enough swearwords in existence in all languages combined to express my true feelings of this.

Somebody please point out something good about all this. Or tell me where to get affordable Power5 (not PowerPC but the real thing) evaluation boards in order to leave the x86 ship for good. Or anything just please anything. Like emigration to Mars. Or gene programming. Why program boring machines when you could be programming real living...things.

What would be the current dream CPU for asm programming and why?
Post 25 Nov 2004, 21:48
View user's profile Send private message Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
What would be the current dream CPU for asm programming and why?


I don't like registers, so a dream machine for me would be a stack processor. Since it'd have FORTH at the heart of its instruction set, all the better Smile

Seriously though: The market doesn't want to throw out the existing software when moving to a new processor. AMD63 might not be ideal, but it does work, and provides a trusted, well-understood, foundation for the next five, ten, or twenty years.
Post 25 Nov 2004, 22:14
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
They did the RIGHT thing IMHO.

Registers are good, a few extra are always welcome but not too many as we do not want those CPU's transformed into RISCS. I see no use for 128 registers other than helping dumb C/C++ compilers that can not take care of efficient algorithms otherwise.

SO they did the right thing... remember Contact :
"Small steeps... always small steeps"
Post 26 Nov 2004, 01:55
View user's profile Send private message Visit poster's website Reply with quote
bubach



Joined: 17 Sep 2004
Posts: 340
Location: Trollhättan, Sweden
bubach
The nightmare would be to push and pop all 128 registers when doing function calls.. Wink
Post 26 Nov 2004, 08:12
View user's profile Send private message Reply with quote
kake_zinger



Joined: 15 Jul 2004
Posts: 51
kake_zinger
crc, why would the market need to throw something out if there were 24 new registers instead of just 8? I'm not advocating going Itanic and changing the architecture fundamentally, just more radical changes instead of the very meager measures AMD did. After all register starvation has been an x86 problem since forever. A reasonably large number of usable registers has been the order for 64bit CPU's since times of MIPS and SPARC, we're talking about ancient times of (early) eighties here. Oh yes and Alpha in early 90's, 32 int + 32 fp regs there, too. Now comes AMD 20+ years later and decide that less is more.

bogdanontanu, Pentium/AMD64 is already a very risc-like load-store architecture, as the memory ops have such large penalties that nobody uses them anyway. There's the imbalance of CPU and memory bus speed. More registers are necessary to keep the CPU well fed and avoid constant small traffic congestion on the memory bus. The biggest performance hiccup has been cpu/membus disparity since times of 486DX2. You can't take small steps with the x86 architecture, because the 'level' is always fixed to the current CPU architecture. Face it, we're going to be stuck with this for a very long time, just like with 80386. Unless Intel and AMD get their act together and realize that they're losing the performance game to IBM while bickering between themselves. It's Power5 who's the king of the hill today, not AMD64 (design limits), not Itanic (marketing, attitude, price and what not limits!).

bubach, hehe yeah. But with more registers you perhaps wouldn't have to store anything when making a function call, because you could keep a certain amount of registers reserved for function calls. No slow memory access necessary at all.

And worst of all, they added Yet Another CPU Mode. Personally I was more than happy with Protected Mode. But no, AMD decided to do away with protection and ditch the hardware multitasker in 64bit mode. Just when CPU's were getting fast enough for the hw tasker to be actually useful. From security standpoint, it is superior to anything else in my view, as it also had IO permissions. AMD's reasoning is that as no mainstream OS uses it anyway it's unnecessary. Yeah and thanks to you AMD no mainstream will use it in the future either because you made it just impossible. Instead of evolving we're devolving.

And every 64bit register use has to be prefixed with REX, a new prefix? Like, wtf? Yes the assembler can add those itself, but still. AMD's job gives me more the impression of a hasty hack instead of a mature succession. Instead of just steadily widening the capabilities of the Protected Mode they created a whole new mess, completely unnecessarily in my point of view. They changed too much, added too little. It's not a smooth, naturally growing change like 286->386 was. What a long time it is since those days.
Post 26 Nov 2004, 21:41
View user's profile Send private message Reply with quote
PopeInnocent



Joined: 01 Jan 2004
Posts: 18
Location: USA
PopeInnocent
The vast majority of well-written functions (around 10 to 30 lines of high-level code) do fine with seven registers. When writing assembly code, I rarely have to resort to main memory to store variables. Still, the addition of 8 general-purpose registers is useful... But how useful would another 16 be? Or another 128? In terms of bang for the buck, I think AMD made the right choice by using 16 total general registers.

Since when were EBP, ESI, and EDI not useful? Sure, ESP is taken up, but every modern PC architecure of which I am aware uses a general-purpose register for the processor stack. Is it that you can't access the low 8 bits of EBP, ESI, and EDI by themselves? Feel lucky that you get any 8-bit registers at all. RISC architectures are one size fits all, everything is 32 or 64 bits.

Itanic?? Heheh, I guess you don't think much of Merced either. The law of diminishing returns is in full effect for Intel's 64-bit processor. Most of the time 100 or so of those registers are a waste of transistors.

Don't worry about being stuck with 12 or 15 or whatever usable registers for time and all eternity. AMD64 versions of <choose your favorite OS> run ye olde 16-bit DOS programs in emulation, and it seems likely that in the future the entire x86 architecture will be emulated a la Transmeta. When that time comes, you can code to the underlying architecture using all ten trillion registers.

I'm sorry you're sick. I hope you feel better. Razz

So, those good things you wanted to hear about:

Affordable 64-bit. Honestly, you drooled over those Alpha processors, didn't you? You don't have to drool over an AMD64. You can get one for $120, today.

x86 is less boring than ever. Not only do you have your choice of 16-bit and 32-bit modes, you get 2 additional 64-bit modes for no additional price!

Server features! Integrated memory controller, non-uniform memory architecture, insane scalability! For a few grand, you too can have a 8-way multiprocessor computer that will run Windows, Linux, and MS-DOS!

Have I mentioned price? AMD managed to build a 64-bit processor that spanks the Itanium on the price/performance scale, and only gets better as time goes on. All of those compromises that you hate so much were aimed at making 64-bit computing affordable and ubiquitous, something everyone could enjoy, not just the elite (relatively) few who could afford a 64-bit system.
Post 29 Nov 2004, 05:31
View user's profile Send private message Reply with quote
kake_zinger



Joined: 15 Jul 2004
Posts: 51
kake_zinger
Well, I see that you're taking the historical view, and comparing AMD64 to the x86 line. Yes, this is a great leap forward. They just could have done so much more. Now both AMD and Intel lose out to Power5, and there is no solution in sight for beating it (Power5 is multithreaded multicore already). Power5 simply is a way superior CPU in every aspect. I expect the migration to Apple systems to continue. Better CPU, better systems designs, great OS. Should probably give it a try myself. Maybe, a few grand poorer and a few apples richer, I'd be ready to join the PC ranks again Smile
Post 29 Nov 2004, 16:16
View user's profile Send private message Reply with quote
kake_zinger



Joined: 15 Jul 2004
Posts: 51
kake_zinger
Funny, barely four days after my post, and what do I read from The Register: IBM TO POWER CHINA. Check it out http://www.theregister.com/2004/12/02/ibm_power_china/

This could be the start for something huge. Perhaps the much needed break from the x86 architecture.
Post 02 Dec 2004, 22:55
View user's profile Send private message Reply with quote
weiss



Joined: 03 Jan 2006
Posts: 25
weiss
i know this is an old post, but i agree with kake_zinger on this one.

my main problem with x64 is the way you cannot unharm upper 32-bits of a "64-bit" register when using 32-bit instructions.

for example with ROL/ROR on 32-bit EAX will change whole "64-bits" of RAX
its stupid, to me.
just as is the zero-extension of when you use XOR EAX,EAX the RAX is zero-extended.

i'm just odd then??, its not really 64-bits to me at all..pseudo-64
it is faster though, just not cutting-edge technology you would expect in the year 2006
Post 17 Nov 2006, 15:06
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
It's true that the hop from 16 bits to 32 bits it's not the same that the hop from 32 bits to 64 bits but the problem is that actually 64 bits it's not so requiered as 32 bits so I think that AMD has decided to make 32 bit default as much as possible to avoid too much use of prefixes.
Post 17 Nov 2006, 15:18
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i think radical change is needed. not some patches over patched patches of triple-patched patch of processor.
Post 17 Nov 2006, 16:31
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
donkey7



Joined: 31 Jan 2005
Posts: 127
Location: Poland, Malopolska
donkey7
read manuals from:
http://agner.org/optimize/

modern superscalar processors have seven 'real' general purpose registers, but much more 'virtual' registers (afair up to 128 temporary registers). read section 2.2 on http://agner.org/optimize/microarchitecture.pdf

register renaming, out-of-order execution, retirement and much more things are done in realtime by processor. cpus would be much cooler without parts responsible for this jobs - compilers (or assembly programmers) should take care of that before writing the exe file.

so your discussion about the number of register is pointless as already there are much more registers in cpus than you think.


huge corporations like intel or amd spend millions of dollars for improving their current processor design instead of getting rid of those bastards (x86). they do insane things: powers the old, stupidly designed x86 architecture with extremely messed instruction decoders, temporary registers (instead of normal), complex branch prediction, stack-based fpu with special handling for fxch, out-of-order execution and many many other things (including support for outdated and rarely used addressing modes).

all thos things are transparent for ordinary coder - ie. he doesn't know that it even exists! but they makes life complicated - especially when someone needs to optimize code for speed.

i consider every improvement/ extension in x86 architecture as very unwise move.

better introduce some completely new architecture and sold the new processors as helpers for current processors - ie. create some processor called 'adfaeg' and offer it as an addition to current processor. they can be connected with hypertransport or something (including common dma, io and mem controller). since more people would own that processors, more programers would write code for it and in consequence new architectore will become industry standard. (okay, this is somewhat crazy idea, but may give impression for someone)
Post 17 Nov 2006, 17:04
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
kake_zinger wrote:
Perhaps the much needed break from the x86 architecture.
weiss wrote:
i'm just odd then??, its not really 64-bits to me at all..pseudo-64
not in my opinion, you are absolutely correct....
vid wrote:
i think radical change is needed.
yup... and the change, I envision, would toss out the window the ENTIRE Intel/Msoft design, and start over.
When you think about, really, isn't MOST of what we discuss on this forum based upon an architectural design from the 1960's, i.e. memory scarce and expensive, cpu slow, data movement from memory to cpu in (at most) 32 bit chunks, as opposed to the present, when memory controllers on the LEAST performant motherboard transfer data at 64 bits/clock. Don't we need a forum section dedicated to thoughts on the future vis a vis new processor design? The costs to create a new cpu design are now DRAMATICALLY lower. What formerly (1970's) cost millions of dollars to design, now can be done for 50k$. Imagine a whole new cpu architecture, designed around MODERN memory controllers, in other words, USING THE EXISTING SOCKETS, and existing motherboards/memory, and peripherals, including pin assignments for Vss and ground, construct a NEW cpu architecture with one goal in mind: compatible with existing memory controllers, existing sockets, existing motherboards, to keep costs for the consumer low.
What characteristics would such a cpu have? Which instructions? How many registers, and what size operands? How many different addressing modes. How would it use the DMA controller?
Here's my two cents:
1. new "cpu" inserts into one of several different EXISTING sockets. (legal problems???)
2. new "cpu" is a collection of tens (hundreds) of programmable cpu's each with a dozen registers....one of them is the director of the other cpu's.
3. memory is divided into private and public, and one or several of the cpu's are devoted to managing the memory for the rest of the cpus.
4. new "cpu" i.e. the chip itself, fits into an existing socket, e.g. 939, or whatever, and contains, ON TOP OF IT, a second platform, accessing the same Vcc and ground connections, but representing a HUGE lookup table, replacing the FPU i.e. eeprom......
5. obviously, new architecture is COMPLETELY incompatible with old....
SO WHAT!!!
nothing wrong with an entirely new architecture. On my new machine, there will be only a couple of addressing modes, and only a few instructions......Yes, it will be SLOW. SLOW. SLOW. i.e. SLOW to execute. But, it will be EASY to program. Easy to program in Assembly. Easy to diagnose, easy to repair, FROM AN ASSEMBLY LANGUAGE PERSPECTIVE....
My two pence....
Smile
Post 17 Nov 2006, 18:32
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
donkey7 wrote:

so your discussion about the number of register is pointless as already there are much more registers in cpus than you think.


Not really!

All that register renaming and other stuff is complicated to implement, increases transistor count, etc. And some algorithms could be easier to implement with more "visible" registers. And compilers tend to have an easier time with more registers as well, rather than register spilling.

I pretty much agree with the rest you wrote, though Smile

_________________
Image - carpe noctem
Post 17 Nov 2006, 22:08
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
tom: you know anyone who could physically CREATE such processor? Wink
Post 18 Nov 2006, 12:29
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
donkey7



Joined: 31 Jan 2005
Posts: 127
Location: Poland, Malopolska
donkey7
f0dder:
i agree. maybe i've written something improperly. i meant that number of registers doesn't play a big role in processor design today.

btw:
amd recently presented 'stream processor'.
( http://ati.amd.com/products/streamprocessor/index.html )
i think it's a good move / big step to future.

the cpu design should look like (in my opinion):
- one or more multicore cpus - two cores that runs at half speed emits much less heat than one core at full speed.
- separate cpu from fpu - fpu has own buffer and memory controller. and must be programmed by cpu.
- remove any floating point support from cpu - this should be present only in fpu.
- one addressing mode,
- one word size (eg. only 64 bit registers - no 8 bit subregisters),
- etc. generally processors should be much more capable of parallel processing.

finally, i think parallel processing is the fufutre and x86 was designed to be 'all in one' - everything in one cpu - so this is outdated design and should be abandoned.
Post 18 Nov 2006, 12:42
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland
Tomasz Grysztar
It's funny that integrating FPU and CPU (that first happened with 486) may be considered "outdated design", while earlier there were separate coprocessors like 387.
Post 18 Nov 2006, 12:52
View user's profile Send private message Visit poster's website Reply with quote
Filter



Joined: 08 Oct 2006
Posts: 67
Filter
donkey7 wrote:


better introduce some completely new architecture and sold the new processors as helpers for current processors - ie. create some processor called 'adfaeg' and offer it as an addition to current processor. they can be connected with hypertransport or something (including common dma, io and mem controller). since more people would own that processors, more programers would write code for it and in consequence new architectore will become industry standard. (okay, this is somewhat crazy idea, but may give impression for someone)


Doing this will create a need for a hybrid processor because some people will use the one processor because it's always available and supports legacy while others will use the newer processor because it's faster.

Intel did something similar with the Pentium Pro not in that the new would replace the old but that they added upon the existing model because backwards compatibility is highly desired by the customers but the need for more RISC like instuctions/registers was there.

For those of you who like RISC why not just go with a RISC processor? I believe you can get motherboards and RISC processors just like you can get x86. You can run Linux on it and program anything you like.


Last edited by Filter on 18 Nov 2006, 13:43; edited 1 time in total
Post 18 Nov 2006, 13:37
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
vid wrote:
who could physically CREATE such processor
1. All of the motherboard companies in TaiWan, and China, plus Japanese, German, Dutch, Italian-Franco, and Korean engineers at Mitsubishi, Hitachi, Sony, NEC, Matsushita, Fujitsu, Siemens, Philips, STMicroelectronics, Samsung and Sanyo;
2. Here in USA, Intel, AMD, and TI of course, plus a dozen smaller circuit board manufacturing companies, not quite as famous;
3. IBM, Motorola, National Semiconductor, and General Electric.
Every one of these companies has meaningful experience with the prerequisite electrical engineering skills needed to create relevantly doped silicon, and most have a corresponding dearth of skills/interest in the software design aspect of such a project. Marketing/Finance people, who tend to dominate MOST companies, would immediately veto any project which was incompatible with M$. To insert such a novel chip assembly into an existing socket/motherboard, would also raise significant questions about legal issues, patent protections, and so on, and therefore, one can envision such a suggestion being squashed before it ever begins.
The door is wide open, waiting for someone to step through it. A computer design, based not on what one can accomplish with CIRCUIT LOGIC, but with software convenience....
Columbus again appealing to the wealthy princes of Europe that the world is indeed round......How many years did he devote in seeking a patron, before Spain made the gamble?
Smile
Post 18 Nov 2006, 13:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17267
Location: In your JS exploiting you and your system
revolution
AMD's take on "upgrading" the x86 architechure was brilliantly executed. Let me explain: When I say brilliant, I don't mean they gave us a good product, I mean that they saw many failures from other companies giving 64 bit solutions and dicovered how to attract current users to use their new technology.

Now, the non-preservation-of-high-32-bits thing was done for performance reasons (it is easier to keep the processor fast by updating all bits together. As we know, x86 users in general are performance sensitive, so AMD knew they had to keep performance high.

The extra 8 registers was also cleverly done, only one extra byte needed in the instruction stream, but at the same time doubling the amount of data that the instruction could manipulate.

PC relative addressing, the one thing that was always missing from the 32 bit code, was also added. They designed it in such a away that it did not impact on the existing addressing modes and needed no extra bytes encoding.

Also, the 32-bit-by-default meant that one can select 64-bit only when required. This gives a decent performance boost. Lots of code doesn't need full-time 64-bit, so by allowing the smaller 32-bit meant smaller code and faster execution by zeroing the upper bits.

This was a guaranteed recipe for success. People wanted high performance, more registers, and simpler relocatable code. And they got it, all without breaking the x86 look and feel.

Now, I also initially thought that the upper-32-bit-zeroed thing was a bad move, but later realised that the performance was going to be more important, and when I wrote some real code, I then understood that almost never did I need to keep the high order bits and having extra circuitry (to preserve the uppers bits) slowing it all down was definitely a negative thing I would rather not have.

As for the extra 8 registers, of course having huge register files would be great but it comes at a huge cost also. Extra bytes in the instruction stream, harder to keep the existing x86 feel, and larger register store files. There is also a problem if they converted the existing register renaming to real registers, then that puts the onus on the programmer the avoid conflicts manually, thus slowing down lots of existing code. So it became a tradeoff, only 8 extra registers but maintain high performance for existing code, and make future code easier to write.

Now, we also have to consider why is the AMD style a (commercial) sucess but others failed? There was always the Alpha, which has been around for a long time, but of course, not x86 compatible, breaks almost every code available. Then there was Intel's flop with the Itanium. It had 128 registers (both int and float), and programmer specified parallel execution. So why did it fail? The first reason is cost, too expensive. The second reason is the compilers needed are incredibly complex to get good code, and assembly code was a nightmare to write. Intel did a lot of good things in the Itanium, but it just was too incompatible for the mainstream program writers to accept. One thing to note is that the huge register files and other such "bloat circuitry" created a huge problem with obtaining decent clock speeds. The Itanium runs just too slow for the associated cost.

Keeping the FPU inside the chip is defintely a good thing, this is the most important step taken by Intel with the 486. With no FPU, the chip is less popular for the general public. They won't want to spend extra for an FPU, but at the same time will complain that all there programs run too slow (many programs need FPU, e.g. Excel). So the FPU is a must have for a commercially viable CPU.

Some readers on this board may think that I am too commercially focussed. But we all must realise that without commercial success for a CPU we would be paying *much* more than we do now. I personally don't want to pay kilo-bucks for a CPU that is slow but has 128 registers. Much better that I pay cento-bucks for a CPU that is fast, has 16 registers and is more compatible.
Post 18 Nov 2006, 14:07
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.