only certain Linux distros can use AMD 64 bit processor

  • Thread starter Thread starter Daeron
  • Start date Start date
D

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
 
Daeron said:
only certain Linux distros could make
full use of the chip's 64-bit potential.
Click to expand...

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
 
Robert Redelmeier said:
and hope the licence
terms are not onerous.
Click to expand...

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


Pozdrawiam.
 
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.
Click to expand...

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.
 
That's pretty mean ;-)).

Whatever

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.
 
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 .
Click to expand...

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.
 
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.
Click to expand...
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
 
Tony Hill said:
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.
Click to expand...

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
 
Felger Carbon said:
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.
Click to expand...

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

Yousuf Khan
 
Yousuf Khan said:
I don't think anything after Windows 3.1 booted in anything less than 386
mode.
Click to expand...

It still has to start in real mode. _EVERYTHING_ on a standard-BIOS PC
starts in real mode.
 
Yousuf Khan said:
I don't think anything after Windows 3.1 booted in anything less than 386
mode.
Click to expand...

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.
 
Yousuf Khan said:
I don't think anything after Windows 3.1 booted in anything less than 386
mode.
Click to expand...

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. ;-)
 
Felger Carbon said:
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.
Click to expand...

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
 
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. ;-)
Click to expand...

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.
 
Felger Carbon said:
"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. ;-)
Click to expand...

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
 
Felger said:
than 386



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.
Click to expand...

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.
 
Tony Hill said:
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).
Click to expand...

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
 
<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.
 
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?
Click to expand...

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.
 
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.
Click to expand...

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.
 
Back
Top