only certain Linux distros can use AMD 64 bit processor

[Daeron]

MS Opens up XP 64 Beta
Pedro Hernandez Feb 04 2004

AMD's desktop 64-bit CPU has already begun to appear in PCs from
several computer makers. Despite the processors' prowess at running
32-bit operating systems and applications, only certain Linux distros
could make full use of the chip's 64-bit potential.

Now thanks to Microsoft, early adopters of AMD's Athlon64 and Opteron
can run a beta version of XP 64 was previously only available to
members of MSDN.

http://www.enterpriseitplanet.com/networking/news/article.php/3308591

[Robert Redelmeier]

Daeron <doug_mentohl@yahoo.co.uk> wrote: only certain Linux distros could make full use of the chip's 64-bit potential.

This is misleading even if literally true.

A new kernel is required by _any_ OS before new CPU features
can be safely used. The OS has to be aware of the new features
/registers to be able to save & restore them on task switches,
or to schedule their use. This applies for SMP, SSE2, SMT
and now x32-64.

With Linux or *BSD, this new kernel is extremely simple to
install. Just download upgraded kernel source, configure,
compile and install. With MS-Win*, y0ou have to wait until
MS releases and upgrades to their kernel, and hope the licence
terms are not onerous.

kernel != distro .

Yes, every Linux distro and *BSD release installs some sort
of default kernel. I can't recall ever using it for longer
than it too to compile a custom kernel. ISTR that linking
a custom kernel was part of the Tru64 install.

-- Robert

[RusH]

Robert Redelmeier <redelm@ev1.net.invalid> wrote :
and hope the licence terms are not onerous.

allready too late, MOLP acceptance means you will pay them whenever
they tell you "bend over boy"


Pozdrawiam.
--
RusH //
http://kiti.pulse.pdi.net/qv30/
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.

[Tharato Romano]

"Robert Redelmeier" <redelm@ev1.net.invalid> wrote in message
news:K8aVb.20299
A new kernel is required by _any_ OS before new CPU features can be safely used. The OS has to be aware of the new features /registers to be able to save & restore them on task switches, or to schedule their use. This applies for SMP, SSE2, SMT and now x32-64. With Linux or *BSD, this new kernel is extremely simple to install.

Maybe this is true, but it's also true that Linux and BSD can't really do
anything useful in the mainstream besides, you are advertising this shit in
the wrong newsgroup. Take this shit somewhere else.

[Spam Me Please]

That's pretty mean ;-)).

Whatever
>> "Tharato" == Tharato Romano <tharatt@nipon.net> writes:

Tharato> "Robert Redelmeier" <redelm@ev1.net.invalid> wrote in
Tharato> message news:K8aVb.20299
A new kernel is required by _any_ OS before new CPU features can be safely used. The OS has to be aware of the new features /registers to be able to save & restore them on task switches, or to schedule their use. This applies for SMP, SSE2, SMT and now x32-64. With Linux or *BSD, this new kernel is extremely simple to install.

Tharato> Maybe this is true, but it's also true that Linux and BSD
Tharato> can't really do anything useful in the mainstream besides,
Tharato> you are advertising this shit in the wrong newsgroup. Take
Tharato> this shit somewhere else.

[Tony Hill]

On Sat, 07 Feb 2004 18:30:02 GMT, Robert Redelmeier
<redelm@ev1.net.invalid> wrote:Daeron <doug_mentohl@yahoo.co.uk> wrote: only certain Linux distros could make full use of the chip's 64-bit potential.This is misleading even if literally true.A new kernel is required by _any_ OS before new CPU featurescan be safely used. The OS has to be aware of the new features/registers to be able to save & restore them on task switches,or to schedule their use. This applies for SMP, SSE2, SMTand now x32-64.With Linux or *BSD, this new kernel is extremely simple toinstall. Just download upgraded kernel source, configure,compile and install. With MS-Win*, y0ou have to wait untilMS releases and upgrades to their kernel, and hope the licenceterms are not onerous.kernel != distro .

MUCH more than the kernel is required, at least if you want it to be
halfway useful as a 64-bit processor. Sure, you COULD just throw a
64-bit kernel on a 32-bit machine, but you wouldn't be able to run any
dynamically linked 64-bit applications (pretty much all applications
beyond "Hello world" are dynamically linked these days).

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, and while there have been a few other processors
that could do this natively (UltraSparc and Itanium jump to mind
here), usually the Linux folk haven't bothered supporting the "legacy"
architecture. With the Athlon64 and Opteron, they do.

What this means, in terms of Linux, is that to get a fully functional
AMD64 system you need two sets of libraries, one compiled for AMD64
and one compiled for IA32. You also need a kernel and a bit of glue
to get this all working together. Linux now supports this fairly
well, but it took a little while to get there. If you look at many of
the distributions out there you'll find that they started out as
64-bit only for the AMD64 platform for just this reason.


So, while it is theoretically possible to role your own AMD64 port
from an existing IA32 port, it's not a very easy task, especially if
you want to make it a bi-arch (AMD64/IA32) port. Since there are
still some common apps that aren't 64-bit clean (eg KDE) and some
fairly important binary-only packages that aren't available for AMD64
yet (eg a Java JRE until about 3 days ago), a bi-arch port is a REAL
good thing to have.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Jan Panteltje]

On a sunny day (Sat, 07 Feb 2004 22:26:44 GMT) it happened "Tharato Romano"
<tharatt@nipon.net> wrote in <ECdVb.13816$cc.1873@fe3.columbus.rr.com>:
"Robert Redelmeier" <redelm@ev1.net.invalid> wrote in messagenews:K8aVb.20299 A new kernel is required by _any_ OS before new CPU features can be safely used. The OS has to be aware of the new features /registers to be able to save & restore them on task switches, or to schedule their use. This applies for SMP, SSE2, SMT and now x32-64. With Linux or *BSD, this new kernel is extremely simple to install.Maybe this is true, but it's also true that Linux and BSD can't really doanything useful in the mainstream besides, you are advertising this shit inthe wrong newsgroup. Take this shit somewhere else.
Poor guy, you must be the one who was locked up for 10 years in MS
building forced to program 16 bit apps on cola and pizza (cold pizza),
while the rest of the world was busy installing Linux.
No you won't get you pay check from MS, as now they are giving away
their soft free, and no money coming in.
Try to get them to make a window in that room at least so you can see the
penguins playing.
Q

[Felger Carbon]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:d28f5bc332daa4f805f6439699d6cec1@news.1usenet.com... 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, and while there have been a few other processors that could do this natively (UltraSparc and Itanium jump to mind here), usually the Linux folk haven't bothered supporting the
"legacy" architecture. With the Athlon64 and Opteron, they do.

My K6-2/450 boots in 286 mode, with 64K segments. To get into 386
mode, there's a lot of thrashing around, including doing things with
the A20 line etc. Since I mostly run Win98SE, I assume that Win98
also boots in 286 mode.

Are you telling me that AMD64 CPUs are **not** _tri-arch_ chips? 286
mode, 386 mode, and AMD64 mode, with booting always starting in 286
mode?

Felger Carbon
Who is honestly confused

[Yousuf Khan]

"Felger Carbon" <fmsfnf@jfoops.net> wrote in message
news:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net... My K6-2/450 boots in 286 mode, with 64K segments. To get into 386 mode, there's a lot of thrashing around, including doing things with the A20 line etc. Since I mostly run Win98SE, I assume that Win98 also boots in 286 mode.

I don't think anything after Windows 3.1 booted in anything less than 386
mode.

Yousuf Khan

[Nate Edel]

Yousuf Khan <news.tally.bbbl67@spamgourmet.com> wrote: "Felger Carbon" <fmsfnf@jfoops.net> wrote in message news:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net... My K6-2/450 boots in 286 mode, with 64K segments. To get into 386 mode, there's a lot of thrashing around, including doing things with the A20 line etc. Since I mostly run Win98SE, I assume that Win98 also boots in 286 mode. I don't think anything after Windows 3.1 booted in anything less than 386 mode.

It still has to start in real mode. _EVERYTHING_ on a standard-BIOS PC
starts in real mode.

--
Nate Edel http://www.nkedel.com/

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer

[Felger Carbon]

"Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
news:bvwVb.13459$R6H.9045@twister01.bloor.is.net.cable.rogers.com... "Felger Carbon" <fmsfnf@jfoops.net> wrote in message news:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net... My K6-2/450 boots in 286 mode, with 64K segments. To get into 386 mode, there's a lot of thrashing around, including doing things
with the A20 line etc. Since I mostly run Win98SE, I assume that Win98 also boots in 286 mode. I don't think anything after Windows 3.1 booted in anything less
than 386 mode.

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.

[Felger Carbon]

"Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
news:bvwVb.13459$R6H.9045@twister01.bloor.is.net.cable.rogers.com... "Felger Carbon" <fmsfnf@jfoops.net> wrote in message news:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net... My K6-2/450 boots in 286 mode, with 64K segments. To get into 386 mode, there's a lot of thrashing around, including doing things
with the A20 line etc. Since I mostly run Win98SE, I assume that Win98 also boots in 286 mode. I don't think anything after Windows 3.1 booted in anything less
than 386 mode.

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

"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. ;-)

[Yousuf Khan]

"Felger Carbon" <fmsfnf@jfoops.net> wrote in message
news:%9yVb.20079$uM2.18925@newsread1.news.pas.earthlink.net... I don't think anything after Windows 3.1 booted in anything less than 386 mode. 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.

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.

The only operating systems that operated in the 286 mode were Windows 3.x in
its "Standard Mode", and OS/2 1.x. Windows 3.x in "Enhanced Mode" was in 386
mode. All Windows 9X and NT and OS/2 2.x+ operated in 386 mode.

Yousuf Khan

[Keith R. Williams]

In article <tJyVb.16595$F23.1745
@newsread2.news.pas.earthlink.net>, fmsfnf@jfoops.net says... "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message news:bvwVb.13459$R6H.9045@twister01.bloor.is.net.cable.rogers.com... "Felger Carbon" <fmsfnf@jfoops.net> wrote in message news:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net... My K6-2/450 boots in 286 mode, with 64K segments. To get into 386 mode, there's a lot of thrashing around, including doing things with the A20 line etc. Since I mostly run Win98SE, I assume that Win98 also boots in 286 mode. I don't think anything after Windows 3.1 booted in anything less than 386 mode. Yousuf, thanx for posting the link to the article on x86-64. Did you read it? Here's one paragraph: "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. ;-)

360 is a kludged architecture, by today's standards, yet forty
years later it still makes money. There is a very good reason!
....and AMD64 followed that reasoning, as opposed to IA64 that
failed following in the footsteps of the failed alternative.

Some refuse to learn from history.

--
Keith

[Yousuf Khan]

"Felger Carbon" <fmsfnf@jfoops.net> wrote in message
news:tJyVb.16595$F23.1745@newsread2.news.pas.earthlink.net... "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. ;-)

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.

Yousuf Khan

[Rob Stow]

Felger Carbon wrote: "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message news:bvwVb.13459$R6H.9045@twister01.bloor.is.net.cable.rogers.com..."Felger Carbon" <fmsfnf@jfoops.net> wrote in messagenews:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net...My K6-2/450 boots in 286 mode, with 64K segments. To get into 386mode, there's a lot of thrashing around, including doing things withthe A20 line etc. Since I mostly run Win98SE, I assume that Win98also boots in 286 mode.I don't think anything after Windows 3.1 booted in anything less than 386mode. 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.

Shortly after reading this post, I went to a friends place for
a while. We found an MS-DOS 3.3 disk image on the internet and
put that onto a floppy. Tried it on his Opteron dualie and his
girlfriend's Athlon64. No go. *Nothing* happens - it just sits
there with a blank screen with a cursor blinking at pos (0,0).
Tried an MS-DOS 6.22 diskette - no problems.

Got home 5 minutes ago and tried that same MS-DOS 3.3 diskette on
my Athlon XP2400+ system - worked fine.

[Robert Redelmeier]

Tony Hill <hilla_nospam_20@yahoo.ca> wrote: MUCH more than the kernel is required, at least if you want it to be halfway useful as a 64-bit processor. Sure, you COULD just throw a 64-bit kernel on a 32-bit machine, but you wouldn't be able to run any dynamically linked 64-bit applications (pretty much all applications beyond "Hello world" are dynamically linked these days).

Even "Hello, World." Good point, but not that difficult to handle.

IMHO, the apps that benefit from 64bit are big things like
databases that need 64 bit pointers. These are usually
bloatware already, and come with their own libs. Of course
these need 64bit compiles, and certain glibc replacements
(earlier on the lib search path).

For the rest, X and even blockmoves I don't see much
advantage to 64 bit.

-- Robert

[jack]

Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
<snip>

:: advertising this shit in the wrong newsgroup. Take this shit
:: somewhere else.

: Poor guy, you must be the one who was locked up for 10 years in MS
: building forced to program 16 bit apps on cola and pizza (cold pizza),
: while the rest of the world was busy installing Linux.
: No you won't get you pay check from MS, as now they are giving away
: their soft free, and no money coming in.
: Try to get them to make a window in that room at least so you can see
: the penguins playing.

LOL!! We can't ALL be as Linux-savy as you, dude. Still LOL!

J.

[Tony Hill]

On Sun, 08 Feb 2004 18:17:25 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:d28f5bc332daa4f805f6439699d6cec1@news.1usenet.com... AMD64 introduced a rather new problem to Linux and *BSD; it's a bi-arch system. The Athlon64 and Opteron support both AMD64 codeand IA32 code natively, and while there have been a few other processors that could do this natively (UltraSparc and Itanium jump to mind here), usually the Linux folk haven't bothered supporting the"legacy" architecture. With the Athlon64 and Opteron, they do.My K6-2/450 boots in 286 mode, with 64K segments. To get into 386mode, there's a lot of thrashing around, including doing things withthe A20 line etc. Since I mostly run Win98SE, I assume that Win98also boots in 286 mode.Are you telling me that AMD64 CPUs are **not** _tri-arch_ chips? 286mode, 386 mode, and AMD64 mode, with booting always starting in 286mode?

Yes and no.

x86 processors boot up in 16-bit real mode (ie you're "286 mode"), but
then quickly switch out of it and into 32-bit protected mode when they
get into the operating system. While in 32-bit protected mode they
can still execute 16-bit code.

With an AMD64 processor, it works just like this if you use a 32-bit
operating system, but if you're using a 64-bit operating systems,
things change. Booting up starts the same with 16-bit real mode, but
the OS then switches the chip to 64-bit long mode. While in 64-bit
long mode, the AMD64 processor can execute either it's native 64-bit
code or 32-bit code, but it can NOT execute 16-bit code. In fact,
both 16-bit real mode and virtual 8086 mode have been deprecated in
AMD64 long mode.

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.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Tony Hill]

On Mon, 09 Feb 2004 04:06:39 GMT, Robert Redelmeier
<redelm@ev1.net.invalid> wrote:Tony Hill <hilla_nospam_20@yahoo.ca> wrote: MUCH more than the kernel is required, at least if you want it to be halfway useful as a 64-bit processor. Sure, you COULD just throw a 64-bit kernel on a 32-bit machine, but you wouldn't be able to run any dynamically linked 64-bit applications (pretty much all applications beyond "Hello world" are dynamically linked these days).Even "Hello, World." Good point, but not that difficult to handle.IMHO, the apps that benefit from 64bit are big things likedatabases that need 64 bit pointers. These are usuallybloatware already, and come with their own libs. Of coursethese need 64bit compiles, and certain glibc replacements(earlier on the lib search path).For the rest, X and even blockmoves I don't see muchadvantage to 64 bit.

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.

Sometimes the performance boost is not quite enough to overcome the
performance loss of running 64-bit code (ie your pointers are twice as
big requiring twice as much bandwidth and cache), so programs compiled
in AMD64 mode will run slower. Other times the extra registers more
than offset the difference, making AMD64 code faster. On average
AMD64 code seems to be about 2-5% faster.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Mike Tomlinson]

In article <d28f5bc332daa4f805f6439699d6cec1@news.1usenet.com>, Tony
Hill <hilla_nospam_20@yahoo.ca> writes
AMD64 introduced a rather new problem to Linux and *BSD; it's abi-arch system. The Athlon64 and Opteron support both AMD64 code andIA32 code natively
^^^^^^^^^
Could I just clarify this? By IA32, you do mean 32-bit x86, not Itanium
code? Thanks.

--
A. Top posters.
Q. What's the most annoying thing on Usenet?

[Robert Redelmeier]

Tony Hill <hilla_nospam_20@yahoo.ca> wrote: 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]

"Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
news:%iAVb.39208$3YE1.35906@news04.bloor.is.net.cable.rogers.com... "Felger Carbon" <fmsfnf@jfoops.net> wrote in message news:%9yVb.20079$uM2.18925@newsread1.news.pas.earthlink.net... 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. 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]

"Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
news:BUAVb.39854$3YE1.27501@news04.bloor.is.net.cable.rogers.com... 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]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:527fd7f10d8f0468997bbc325acdec05@news.1usenet.com... 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]

"Felger Carbon" <fmsfnf@jfoops.net> wrote in message
news:ikPVb.17466$F23.1868@newsread2.news.pas.earthlink.net... 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]

"Felger Carbon" <fmsfnf@jfoops.net> wrote in message
news:ikPVb.17465$F23.12319@newsread2.news.pas.earthlink.net... 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]

On Sun, 08 Feb 2004 22:27:37 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:
"Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in messagenews:bvwVb.13459$R6H.9045@twister01.bloor.is.net.cable.rogers.com... "Felger Carbon" <fmsfnf@jfoops.net> wrote in message news:V2vVb.16325$F23.2484@newsread2.news.pas.earthlink.net... My K6-2/450 boots in 286 mode, with 64K segments. To get into 386 mode, there's a lot of thrashing around, including doing thingswith the A20 line etc. Since I mostly run Win98SE, I assume that Win98 also boots in 286 mode. I don't think anything after Windows 3.1 booted in anything lessthan 386 mode.Yousuf, thanx for posting the link to the article on x86-64. Did youread it? Here's one paragraph:

Where was that?... never saw it and can't find the post.
"ConclusionSo what we have is a situation where x86 desktop processors are likelyto take over the whole desktop and above markets. A 64bit x86 is along way from being the perfect processor; it's a kludged 64bitarchitecture built on a kludged 32bit architecture built on a kludged16bit architecture that was designed to be compatible with the 8bit8080. Hardly the best choice."So our Brit friends also seem to think that the AMD64 is a tri-archchip. ;-)

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]

"Felger Carbon" <fmsfnf@jfoops.net> wrote in message
news:jkPVb.17467$F23.11110@newsread2.news.pas.earthlink.net... 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]

Felger Carbon <fmsfnf@jfoops.net> wrote: 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 http://www.nkedel.com/

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer

[Nate Edel]

Yousuf Khan <news.20.bbbl67@spamgourmet.com> wrote: "Felger Carbon" <fmsfnf@jfoops.net> wrote in message 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.

"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 http://www.nkedel.com/

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer

[Nate Edel]

Mike Tomlinson <nospam@nospam.jasper.org.uk> wrote: In article <d28f5bc332daa4f805f6439699d6cec1@news.1usenet.com>, Tony Hill <hilla_nospam_20@yahoo.ca> writes
AMD64 introduced a rather new problem to Linux and *BSD; it's abi-arch system. The Athlon64 and Opteron support both AMD64 code andIA32 code natively ^^^^^^^^^ Could I just clarify this? By IA32, you do mean 32-bit x86, not Itanium code? Thanks.

Itani[c/um] is IA64.

--
Nate Edel http://www.nkedel.com/

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer

[Tony Hill]

On Mon, 09 Feb 2004 16:09:50 GMT, Robert Redelmeier
<redelm@ev1.net.invalid> wrote:Tony Hill <hilla_nospam_20@yahoo.ca> wrote: 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.

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, andseldom find any difficulty. More registers would need to besaved 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
hilla <underscore> 20 <at> yahoo <dot> ca

[Tony Hill]

On Mon, 09 Feb 2004 17:21:19 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:527fd7f10d8f0468997bbc325acdec05@news.1usenet.com... 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. MyK6-2 does not operate real mode and 32-bit mode concurrently, you haveto 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 acompiled MS Basic program in the DOS box, every FP instructiongenerates an interrupt, and the 32-bit DOS has to "thunk" back to16-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
hilla <underscore> 20 <at> yahoo <dot> ca

[Tony Hill]

On Mon, 9 Feb 2004 15:58:08 +0000, Mike Tomlinson
<nospam@nospam.jasper.org.uk> wrote:In article <d28f5bc332daa4f805f6439699d6cec1@news.1usenet.com>, TonyHill <hilla_nospam_20@yahoo.ca> writesAMD64 introduced a rather new problem to Linux and *BSD; it's abi-arch system. The Athlon64 and Opteron support both AMD64 code andIA32 code natively ^^^^^^^^^Could I just clarify this? By IA32, you do mean 32-bit x86, not Itaniumcode? 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.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Felger Carbon]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:f74d66dbe92c12d1786b85d9d5499145@news.1usenet.com... 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]

"Nate Edel" <archmage@sfchat.org> wrote in message
news:cbplf1-mke.ln1@mail.sfchat.org... 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?

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]

Tony Hill <hilla_nospam_20@yahoo.ca> wrote: 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.

--
Nate Edel http://www.nkedel.com/

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer

[Tony Hill]

On Tue, 10 Feb 2004 15:50:04 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:f74d66dbe92c12d1786b85d9d5499145@news.1usenet.com... 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 Ifully anticipate Intel to come out with some sort of Intel64 name)._Official_ name? The Trilateral Commission enforces these names usingtheirblack 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.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca