x86-64

[pskyboy]

After reading through the x86-64 manuals i had a few points i wanted to raise especially to do with OS design for this architecture.

To start with the good fatures are:-
1. Its 64bit (Whay)
2. There is no segmentation in 64bit mode (Whay)
3. You can have up to 16exabytes of virtual memory (a bit excessive i know)
4. You can have up to 4 petabytes of physical memory if anyone has that much let me know

And now teh bad points
1. Hardware task switching is no longer available personally not sure if this is a good or bad thing

2. The biggest problem in my view and one that pissed most of us of masively on the last generation IA-32 now becomes a bigger problem. In order to get into 64bit mode you have to do a initalisation heiracy what i mean by this is you have to start in real mode and initialise a protected mode and then from protected mode initalize Long Mode (64 bit mode) which to me looks like a complete pain of a way to do it. In my view they should of allowed for you to jump to long mode from real mode. oh well

Whats everyones elses view on this

Peter

[Pype.Clicker]

did they planned that we might wish some legacy 32bits programs running together with new 64bits programs on the very same system ? i mean is v80586 easier to use than v8086 ?

[Tim]

pskyboy:
1. Nobody uses hardware task switching except for a few of us amateur OS developers. Removing that from the chip leaves room for some more cool features.
2. You only switch to protected/long mode once, when the OS boots. Also, you only have to write the code to do the switch once.

Pype.Clicker:
If I understand correctly, you can run several full 32-bit operating systems under the one 64-bit kernel. If nothing else, that should make the 64-bit versions of VMware and Bochs better...

[pskyboy]

Yeah technically 32bit protected mode isn't actually needed as 32bit software can be run in compatibility mode aunder long mode which is a 32bit mode under the 64bit mode.

Yeah, and as for the task switching i suspected that it wasn't used hence hwy they got rid of it but im one of those people that belives if its faster keep it but i guess there are better ways of doing task switching.

[.bdjames]

I have discussed this with osmaker and a local computer
hobbist and I do not think I am alone when I say that
because the AMD chipset IS true backwards compatible that
it will win out against Intel in a fair race. However I have
discussed this with my stepfather and the IA64 chips are
selling (high end pc servers), because they are the latest
"thing". The race is on, can AMD get the x86-64 out before
Intel saturates the market, I do not know.

Remember the pentium pro.

BTW, fo those have programmed for the sparc, how similar
is IA64 to it?

[K.J.]

Just thought I'd let you all know, the Bochs CVS tree has x86-64 support in it. However I think that the TSS part of x86-64 is not yet complete. Still, if someone wants the windows version with what x86-64 options there are compiled in, PM and I'll email it to you.

K.J.

[Schol-R-LEA]

I have to disagree; eliminating backwards compatibility in the IA-64 was one of the smartest things Intel ever did. Why? Because, at the hardware level, any new design - including the x86-64 - would essentially be emulating the x86 instructions anyway; the x86-64 no more runs x86 opcodes directly than a Macintosh running VirtualPC does. Even the current Pentiums are closer to emulation of the x86 instruction set than they are to a direct execution of it. If there is a substantial difference between the two platforms in the speed at which they run legacy software, I'd be quite surprised.

More importantly, since they don't expect the IA-64 to compete on the desktop - it's meant to challenge the SPARC and it's ilk for the server market - it has no need whatsoever to run any of the older software. This is especially true since it will probably quickly be dominated by Linux; Linux system software is remarkably portable, even by the standards of the Unix community. Even given the semi-portable design of the NT/2K kernel (as embodied in the Hardware Abstraction Layer), it will take Microsoft far more time and effort to port XP to the new platform.

Of course, that also means that there is a wide window of opportunity for an enterprising OS designer in that field. But I digress...

The x86-64, IMAO, is a dead end. Even if it ever works - and I'm guessing it won't, the underlying technology is too creaky and cranky - it will only live long enough to drag AMD down. While it is meant to compete in the server market, like the Itanium, it is too much of compromise for too little gain - for companies who are deciding, not between Windows or Linux, but between SPARC, Itanium, or Power4, 'backwards compatibility' is just as likely to refer to emulating an IBM mainframe, rather than a PC.

Meanwhile, the desktop market, which does value the ability to run old software, is unlikely to embrace something that provides little advantage except with it's specific version of the newer software.

Now, its true that Intel's assertion that they will keep the IA-32 platform alive has been sounding rather hollow, but they aren't about to kill of their main cash cow, either - especially since, despite all, they still haven't got the damn IA-64 working properly, never mind to market. Still, since Intel seems disinterested in extending their 32-bit offering any further - there will be no Pentium V, probably, though they surely will continue to speed the PIV up over time - it means that AMD will be in the market for super x86s more or less to themselves. Is that a good thing for them? No - because it means, MS notwithstanding, they will never develop the independent software base the need unless they have a new killer app to push them forward. Look at how long it took the market for Windows to develop; it wasn't until the development of Photoshop and other Windows-only PC software that Windows began to catch on, even with backwards compatibility of DOS software a basic part of it (Win 3.1 was little more than a DOS shell, while later version still kept DOS as a major part of the underlying system). No matter how good the technology is, wthout something that absolutely has to be on the Opteron - and it is unlikely that anything will be - it will certainly die, just as OS/2 did, for the lack of any strong justification of it's existence.

In any case, there are newer designs which do have such advantages - IBM's 'Cell' architecture, for example, which is designed to make multiprocessing very simple - which will most likely make the argument a moot one.

[gonchuki]

The x86-64, IMAO, is a dead end.

you are wrong, probably you got confused with your own words... the same thing that MS did at software level (with DOS, Win 3.1, and so on), is what AMD is doing right now at hardware level! Want it or not, you need a smooth transition to the new technology, you can't just port everything to 64-bits, it would be impossible, just think porting thousands of lines of assembly code in your programs... or even worse rewrite everything from scratch!
you just can't do it suddenly... you have to give time for the developers to catch up with the new technology. Similar situation is that of MS with their DOS... it took more than 15 years to finally wipe out the old MSDOS from windows, and they still offer minimal compatibility with DOS apps...

i don't think Intel will have success with their IA64 once the Opteron is out... just think: Linux will probably be the only x86-64 OS as microsoft doesn't want to develop one for AMD, and the vast majority of servers today run Linux with Apache and all the other free server apps, so think, will Intel succeed with its lowly supported IA64? or will AMD win with it's high support from Linux and being able to run todays software?

If there is a substantial difference between the two platforms in the speed at which they run legacy software, I'd be quite surprised.

There will be a difference! do you know how the Transmeta Crusoe works??? its the same thing, the processor runs with a different instruction set but all the decoding from x86 is done on the fly, with no major penalty! this is what the Opteron will do, but with a more sofisticated technology, and not to be run in a slow performer chip (like the Crusoe) but to run in a speed demon like the AMD's Opteron...

[K.J.]

I have to disagree; eliminating backwards compatibility in the IA-64 was one of the smartest things Intel ever did. Why? Because, at the hardware level, any new design - including the x86-64 - would essentially be emulating the x86 instructions anyway; the x86-64 no more runs x86 opcodes directly than a Macintosh running VirtualPC does.

Schol... find out about what you are talking about before you speak. x86-64 DOES NOT EMULATE THE x86/IA-32! It's just a regular x86 with new stuff added. All you have to do is read the overview stuff of x86-64 from AMD to find this out.

K.J.

[Schol-R-LEA]

I have to disagree; eliminating backwards compatibility in the IA-64 was one of the smartest things Intel ever did. Why? Because, at the hardware level, any new design - including the x86-64 - would essentially be emulating the x86 instructions anyway; the x86-64 no more runs x86 opcodes directly than a Macintosh running VirtualPC does.

Schol... find out about what you are talking about before you speak. x86-64 DOES NOT EMULATE THE x86/IA-32! It's just a regular x86 with new stuff added. All you have to do is read the overview stuff of x86-64 from AMD to find this out.

K.J.

There's is no point in getting into the details of this, but I'll repeat what I've said: to the best of my knowledge, no supposed 'x86' processor after the original Pentium (including the AMD Athalon and Duron lines, to the best of my knowledge) has really run the x86 opcodes directly. While the emulation is fixed in firmware (you can't run the actual low-level code directly), none of the existing processors truly run x86 software natively, or even as conventional microcoded operations. They all translate the opcodes on the fly to their native instruction sets.

From Intel's website glossary:

Micro-architecture
The architecture of a processor refers to the instruction set, registers, and memory- resident data structures that are public to a programmer and are maintained and enhanced from one generation of architecture to the next.

The micro-architecture of a processor refers to implementation of a processor architecture in silicon. Within a family of processors, like the Intel IA-32 processors, the micro-architecture typically changes from one processor generation to the next, while implementing the same public processor architecture. Intel's IA-32 architecture is based on the x86 instruction set and registers. It has been enhanced and extended through generations of IA-32 processors, while maintaining backwards compatibility for code written to run on the earliest IA-32 processors.

As I understand it, this goes beyond the normal CISC procedure of opcode translation into microcode; while I cannot recall the details, I seem the remember something about the translation occuring before pipelining, in the PPro and later, and that some commonly repeated sequences of opcodes get translated as a block into the equivalent low-level idiom. My memory may be off, however.

If anyone can give details on this, or corrections (with pointers to the relevant data), please do so. In the meantime, I think I'll read through the Intel P4 manual and get the details.

Now, it could be argued that this is irrelevant - the firmware translation is invisible, and thus they may as well be running it directly - but the fact remains that there is the extra translation level involved. It was precisely to eliminate this sort of overhead that the RISC designs were adopted. In principle, you would expect a RISCy system like SPARC or PowerPC to emulate an x86 at very nearly the same speed as the 'hardware emulation' at the same clock rate, and this is in fact borne out - there's some performance hit, but not all that much.

In any case, the newer designs (Itanium among others) have advantages that will allow them to go much faster than an x86 possibly could. Look at the history of the PowerMac: when they switched from 680x0 to PowerPC, everything, even the old software running under the emulator, sped up noticably. This was because the PPC could emulate the 68K code faster than the original could run it directly. If Intel has done the job even remotely right, then this should be true for the Itanium emulating a x86 as well - though I'm not quite convinced that they have.

As for why there cannot be the gradual change from 32-bit to 64-bit: the issue at hand is not the addressing width, but the architecture. Most hardware designers feel that the x86 architecture - even under emulation - is at the end of it's feasible lifetime, and that attempts to push it any faster result in rapidly diminishing returns (i.e., that doubling the clock speeds to 4GHz will take twice as long as going from 1GHz to 2GHz did, at greater cost and lower chip yields, and result in less than a double speedup). Thus, the Itanium is not even remotely related to the x86, any more than the PowerPC or the SPARC are. It is a completely new design, and switching to it will require a new software base.

Most likely, any new (desktop) systems based on it or any other new chip design will intially include an emulation layer similar to that used during the PowerMac transition. Eventually, support for older code will dropped, but the fact of the matter is, that will happen eventually anyway.

[pskyboy]

I must agree with Shol-R-LEA i think thw x86 architecture needs to be dropped and a new architecture needs to replace it. The x86 architecture has got a lot of legacy built in and its about time we got rid of it.

In my opinion also why not just run an emulator for older software i mean if you got a 2.5Ghz+ 64bit chip with a new architecture its gonna emulate a 32bit processor fast enough that you won't notice the difference for most things.

My feeling though is that neither the AMD or Intel solutions are fit for the job of a new architecture the problem is the intel chips are hideously expensive and haven't been ported to a desktop chip. Where as AMD is lunching its products at the sektop market which is why i belive the x86-64 architecture will take off.

I think the best thing we can hope for is the x86-64 architecture to take off and then AMD to release the next chip with v2 x86-64 which is purely the x86-64 mode ie. just long mode and all the previous stuff ripped out plus maybe a few extra enhancments.

Peter

[Locke]

Well, elaborating on some topics on the x86-64:

The purpose of the x86-64 was to provide a multi-capable chipset that could do 32-bit and 64-bit natively. I believe the x86-64 specification actually calls for an IA-32 compatible chip to be present near or on the chip itself. This causing no speed loss what-so-ever, and solving the natural problem:
when converting to lower bit-counts than the standard of the chip, you get speed losses. This doesn't matter in OS creation so much as Game Design. The biggest reson is that game design is implimente in such a way that a single ms of time can result in a drop of over 10 - 20 frames per second. In an OS, the ms is critical, but not so much as that.

That's what x86-64 targets: The OS could run in 64-bit mode and provide a ton of potential and power. At the same time, the 32-bit mode would be more appropriate for games and other applications relying on frame-rate style speeds. Specifications of the x86-64 mode are actually designed to be a desktop system along with a server-style solution, I know this for a fact.

But Yes, AMD is doing the smartest thing they could do: They know they need to go 64-bit to continue to produce powerful machines and give programmers headway into new dimensions, they know that they need to make it transitional, and voila..the perfect solution: x86-64. It's the 32-bit and 64-bit in one! It also posses a great ability for expansion.