only certain Linux distros can use AMD 64 bit processor

[Mike Tomlinson]

AMD64 introduced a rather new problem to Linux and *BSD; it's a
bi-arch system. The Athlon64 and Opteron support both AMD64 code and
IA32 code natively

^^^^^^^^^
Could I just clarify this? By IA32, you do mean 32-bit x86, not Itanium
code? Thanks.

 

[Robert Redelmeier]

All else being equal, 64-bit would be slower. Of course, the trick is
that all else is NOT equal with AMD64. In 64-bit mode you get twice
as many registers, and given that x86 is rather register starved
(especially since a lot of IA32 instructions only work with certain
registers), this can give you a decent performance boost.

This would require compilers that use the registers.
I'm not sure they're available.

IMHO, x86 is _not_ register starved. I code in asm, and
seldom find any difficulty. More registers would need to be
saved on context switches, and during things like inline asm.

When I need to, I resort to the stack frame (nice addr modes)
and with the fast L1 caches on x86, there is almost never a
drop in speed. `dec [ebp-8]` is often just as fast as `dec ecx`
provided there are is real work being done in the loop.

-- Robert

 

[Felger Carbon]

It boots up in Real Mode, which is synonymous with 8086 compatibility mode
to me. The 286 mode is synonymous with 16-bit Protected Mode to me. And 386
mode is synonymous with 32-bit Protected Mode to me. All of these CPUs start
in Real mode, including AMD64, and then you have to transition to the other
modes using the operating system.

Darn. DOS _does_ boot in 8086 (real) mode, not 286. It remains a
fact that, including the "other modes" (note plural other) adds up to
three architectures - 16-bit, 32-bit, and 64-bit.

 

[Felger Carbon]

The thing is with the 386 mode and below, all previous architectures worked
as natural subsets of the 386 Protected mode. In AMD64, only all of the
previous Protected modes are supported, but not the Real mode (though it can
probably be easily emulated). Also in AMD64, you can pick and choose which
of the Protected modes that you want to support; if you want to support 386
only, then you can ignore the 286 Protected mode, and vice-versa. Also AMD64
has all of those extra registers which previous architectures never had
access to.

AMD64 is a bi-arch for this reason.

We have a difference of opinion. I think you're saying AMD64 will not
run 8086 legacy programs, such as my MS compiled basic or Generic
CADD. I don't know yet whether this is true or not.

 

[Felger Carbon]

So, while the Athlon64 and Opteron can execute instructions in the
three different modes (4 if you count virtual 8086 mode, but I'm
ignoring that for now), it is NOT a tri-arch chip because it can't
execute all three concurrently.

Oh, **concurrently**! That's a horse-apple of a different color. My
K6-2 does not operate real mode and 32-bit mode concurrently, you have
to be in one mode or the other. The result is, when I'm running a
compiled MS Basic program in the DOS box, every FP instruction
generates an interrupt, and the 32-bit DOS has to "thunk" back to
16-bit mode tp process the interrupt, then resume 32-bit mode.

 

[Yousuf Khan]

We have a difference of opinion. I think you're saying AMD64 will not
run 8086 legacy programs, such as my MS compiled basic or Generic
CADD. I don't know yet whether this is true or not.

AMD64 will run them as long as you are using it in 32-bit Protected Mode.
Once you switch to 64-bit Long Mode, then it loses contact with the 8086
days.

Yousuf Khan

 

[Yousuf Khan]

Darn. DOS _does_ boot in 8086 (real) mode, not 286. It remains a
fact that, including the "other modes" (note plural other) adds up to
three architectures - 16-bit, 32-bit, and 64-bit.

Actually, it adds upto 5 modes: 16-bit Real, 16-bit Protected, 32-bit
Protected, 32-bit Real (rarely used), and 64-bit Long.

64-bit Long is backwards compatible only with the 16-bit and 32-bit
Protected Modes, but none of the Real Modes. 64-bit Long can natively run
all programs compiled to the 16- and 32-bit Protected Mode guidelines,
provided the proper API libraries are also available for those programs.

Actually, even in the Protected Mode days, Real Mode execution was not
natively supported until the 386 came along and implemented a Real Mode
emulator which was called the Virtual-8086 mode. Programs written to Real
Mode guidelines couldn't run in a Protected Mode OS until this V86 mode came
along.

So yes, you can say AMD64 is a tri-architecture chip, as the general
architectures are Real Mode, Protected Mode, and Long Mode. But once you're
executing in Long Mode, there is no longer any support for Real Mode.

Yousuf Khan

 

[George Macdonald]

Yousuf, thanx for posting the link to the article on x86-64. Did you
read it? Here's one paragraph:

Where was that?... never saw it and can't find the post.

"Conclusion
So what we have is a situation where x86 desktop processors are likely
to take over the whole desktop and above markets. A 64bit x86 is a
long way from being the perfect processor; it's a kludged 64bit
architecture built on a kludged 32bit architecture built on a kludged
16bit architecture that was designed to be compatible with the 8bit
8080. Hardly the best choice."

So our Brit friends also seem to think that the AMD64 is a tri-arch
chip. ;-)

Either our "Brit friends" don't "know" or are blowing smoke. IA32 *did* do
some clean up with a more general purpose register set vs. the dedicated
functions of the 16-bit registers. With x86-64 we add a decent count of
integer registers and lose the FP stack. From my POV it's beginning to
look like many other CISC CPUs with 16 registers.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Yousuf Khan]

Oh, **concurrently**! That's a horse-apple of a different color. My
K6-2 does not operate real mode and 32-bit mode concurrently, you have
to be in one mode or the other. The result is, when I'm running a
compiled MS Basic program in the DOS box, every FP instruction
generates an interrupt, and the 32-bit DOS has to "thunk" back to
16-bit mode tp process the interrupt, then resume 32-bit mode.

No, but your K6-2 does run V86 Mode concurrently with 32-bit Protected Mode.
Where V86 Mode is an emulation of Real Mode under Protected Mode.

Yousuf Khan

 

[Nate Edel]

This puzzles me, Yousuf. You seem to be saying that a CPU that will
run Win98SE (for example) will not also boot DOS 3.3. In my
experience, this is simply not so. If you read the CPU's hardware
manual, you will discover that the CPU comes up in 286 mode.

Actually, it comes up in Real Mode, which existed on the 286 but was 99%
identical (basically just minus the A20 wrap around) to the 8088/8086.

"286" isn't a mode: 286s had Protected Mode, just as do the 386+, although
the 386 Protected Mode had a lot of features that the 286 didn't support.

 

[Nate Edel]

Actually, it adds upto 5 modes: 16-bit Real, 16-bit Protected, 32-bit
Protected, 32-bit Real (rarely used), and 64-bit Long.

"32-bit Real" (aka "unreal mode") was never formally supported, was it?

Also, 16-bit protected and 32-bit protected mode are not really two separate
modes. A IA32 processor in protected mode can have a mix of 32-bit and
16-bit segments.

You might make a case for V86 being separate from real mode, however.

 

[Nate Edel]

^^^^^^^^^
Could I just clarify this? By IA32, you do mean 32-bit x86, not Itanium
code? Thanks.

Itani[c/um] is IA64.

 

[Tony Hill]

This would require compilers that use the registers.
I'm not sure they're available.

They are. GCC has supported AMD64 for a while (supporting the extra
registers was a pretty small change there, since GCC already supports
plenty of architectures with more registers). Microsoft's Visual
Studio.net suite supports AMD64 as well, while Portland Group and NAG
have compilers as well. Sun is also working on AMD64 support in it's
upcoming Sun One Studio for Solaris x86.

Basically Intel ICC is the only compiler that doesn't support AMD64,
and if Intel continues with their recent plans to produce an
AMD64-compitible Xeon, even they should support the instruction set
soon.

IMHO, x86 is _not_ register starved. I code in asm, and
seldom find any difficulty. More registers would need to be
saved on context switches, and during things like inline asm.

You might not find this to be a problem, but pretty much the rest of
the world agrees that this is one of x86's shortcomings. It's not a
critical problem, hell I've coded for an architecture with a grand
total of ONE register before, but extra registers definitely DO help
with performance. AMD has already proven this quite clearly. Take a
look at AMD's SPEC results here:

http://www.spec.org/cpu2000/results/res2003q3/cpu2000-20030908-02502.html

One 8 of the 11 sub-benches, AMD used 64-bit code. The other 3 used
32-bit code. Since AMD is obviously going to try to make the code as
fast as possible, and as mentioned previously, 64-bit is slower except
when the extra registers are used, then those extra 8 registers are
helping things more often than not.

 

[Tony Hill]

Oh, **concurrently**! That's a horse-apple of a different color. My
K6-2 does not operate real mode and 32-bit mode concurrently, you have
to be in one mode or the other.

Certainly! The concurrency comes from the software side of things as
much as the hardware side.

The result is, when I'm running a
compiled MS Basic program in the DOS box, every FP instruction
generates an interrupt, and the 32-bit DOS has to "thunk" back to
16-bit mode tp process the interrupt, then resume 32-bit mode.

Yup, and with AMD64 you can do this thunking between 64 and 32-bit
mode, but NOT back to 16-bit mode. So your MS Basic program in a DOS
box might not work under WinXP 64-bit edition (though DOS has been
entirely emulated since WinNT days, so that might take care of this
problem).

 

[Tony Hill]

^^^^^^^^^
Could I just clarify this? By IA32, you do mean 32-bit x86, not Itanium
code? Thanks.

Yup. IA32 is the official name for 32-bit x86 code, much like AMD64
is the official name for 64-bit x86 code, aka x86-64. (though I fully
anticipate Intel to come out with some sort of Intel64 name).

Despite the similarities in name, IA32 and IA64 have absolutely
nothing in common except that they both come from Intel.

 

[Felger Carbon]

Yup. IA32 is the official name for 32-bit x86 code, much like AMD64
is the official name for 64-bit x86 code, aka x86-64. (though I fully
anticipate Intel to come out with some sort of Intel64 name).

_Official_ name? The Trilateral Commission enforces these names using
their
black helicopters?? ;-)

 

[Yousuf Khan]

"32-bit Real" (aka "unreal mode") was never formally supported, was it?

It was one of those things that were never really mentioned except as a loud
whisper. Intel programming docs had a specific procedure that you had to
follow in order to switch back into Real Mode from Protected Mode, which
included setting the segment descriptor size limit back down to 16-bit,
prior to switching to Real Mode -- the RM segments would inherit the
previous PM segment size limits. However, people discovered that if you
ignored that procedure, you could still switch back into Real Mode, and your
RM segments would have a greater than 16-bit size limit.

Also, 16-bit protected and 32-bit protected mode are not really two separate
modes. A IA32 processor in protected mode can have a mix of 32-bit and
16-bit segments.

No, they weren't really separate modes. I was just calling them that for
illustrative purposes. 32-bit PM was a superset of 16-bit PM, or 16-bit PM
was a subset of 32-bit PM, however you want to look at it.

You might make a case for V86 being separate from real mode, however.

V86 was a very wierd little animal, sort of a bastard child of RM and PM. It
acted like RM for DOS programs running under it, but it followed all of the
rules of PM, since it was running as a special kind of segment within PM.
It was a kludge, no doubt about it, but an especially important kludge,
which I think did more to drive the initial acceptance of 32-bit processors
than 32-bit operating systems did.

I don't think most people were even aware that when they bought their 386
computers and ran DOS on it, that they were actually running it under a
Protected Mode OS. Most people's first experience with a PM OS was not
through Windows or OS/2 or Unix, but it was simply DOS running under an
Extended Memory Manager. The EMM, like Qemm386, was a supervisor OS which
ran DOS underneath it as a client OS inside a V86 shell, and provided DOS
with extended memory management services, while letting DOS handle disk i/o
and file system management, etc. But the V86 shell was the all important
bridge between Real Mode and Protected Mode that drove acceptance of the
32-bit OSes.

AMD64 removes support for the V86 mode while under Long Mode, because
there's very few DOS applications left nowadays.

Yousuf Khan

 

[Nate Edel]

Yup, and with AMD64 you can do this thunking between 64 and 32-bit
mode, but NOT back to 16-bit mode. So your MS Basic program in a DOS
box might not work under WinXP 64-bit edition (though DOS has been
entirely emulated since WinNT days, so that might take care of this
problem).

"Entirely emulated" using V86 mode, I'm pretty sure, not "entirely emulated"
in the sense of VirtualPC on a PPC Mac or running Bochs...

Ditto for DOSEMU under Linux.

Lacking V86 under Long mode strikes me as a non-free tradeoff on x86-64. I'm
not saying it's wrong by any means, but unless someone's got the equivalent
of a process-level Bochs, it means no more DOS games for those of us who
still enjoy them, and no more collected little tools.

 

[Tony Hill]

_Official_ name? The Trilateral Commission enforces these names using
their
black helicopters?? ;-)

Yup, better make sure that your tin-foil hat is securely fastened
before using the term "32-bit x86"!

By "official name" I merely mean that it is what Intel and AMD call
their instruction sets in all of their publications.