Interesting read about upcoming K9 processors

On Thu, 05 Aug 2004 14:32:25 GMT, "Hank Oredson" wrote:

"Yousuf Khan" wrote in message
et.cable.rogers.com...
Keith wrote:
On Wed, 04 Aug 2004 16:33:24 -0400, George Macdonald wrote:
Uhh, it's called spin.:-) The fact you or I can't find the
docs/pages to confirm the "recollections" does not mean they did not
exist. Nefarious is your term but I did see a roadmap which showed
x86 relegated to mostly STBs by 2005... after a steady year by year
decline in PCs.

The charts I saw were Itanic to exceed x86 sales by 2003 and by '05
x86 was relegated to the dust-bin of embedded losers. ...and that was
in 1997ish. There was some discussion about this in AFC a few weeks
ago (I'm not the only one remembering such).

I think a lot of us can remember Intel's predictions about IA64 eventually
replacing IA32 by some point in time. You don't need some archival webpage
in order to prove it. Just the fact that so many of us who have been in
this
business for so long can recall these statements is more than enough.


I'm sure most or even all of us remember these things.

Some of the problem is in semantics: introduction, general
availability, wide use, replacement. I take "replacing" to
mean that IA32 is no longer available, and IA64 is used
in all cases including embeded devices.

Nope and it's been stated umpteen times: the err, "semantics" are the
existence of x86 vs. IA64, in the *Intel* view circa 1998, of the 2005 *PC*
space, desktop in particular, included. The roadmaps I know I saw
specifically nominated x86 for the typical STB space in the mass market at
its PC EOL cycle... in 2005. Hell the 8085 is still a healthy technical
solution in its space.

This is from an investment viewpoint: what I thought
Intel was saying about the evolution of the portions
of their product line that produced the most profit.

But the fact that I think these things is probably rather
uninteresting, since I cannot produce any actual
documents that say the specific things I think will be true ;-)

"Ay, there's the rub".

Rgds, George Macdonald

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

kal wrote:
On Fri, 06 Aug 2004 16:46:51 GMT, "Yousuf Khan"
wrote:

as a result of some dufusy arbitrary decisions that MS made. For
example, they decided not support 16-bit protected mode apps in
Win64, even though the AMD64 architecture has no problems running
either 16-bit or 32-bit protected-mode apps in compatibility mode.

I am not sure this is accurate. The issue with win16 is that some of
it still depends on the DOS (for file system etc.) so it needs the
virtual x86 mode too which is not supported in AMD64. So it is really
a technical issue which may also have been solved but that's another
topic.

I don't think that's been the case since Windows 3.1. That's the version of
Windows that brought the "32-bit file system", which replaced all calls to
DOS and BIOS with protected mode Windows ones. Even if the app made a direct
call to DOS or BIOS, the 32-bit FS would handle the call.

Yousuf Khan

George Macdonald wrote:
Apparently he also thinks that insults in Latin phraseology cadged
from his favorite look-up table are somehow umm, dignified?... exempt
from contempt?:-)

At least I have had some success here... by having the extreme honor
of being killfiled and I suggest that the rest of you do your best to
get
equal status from the err, Kentster!... before he skulks back off to
his UnReal World". Good luck with it... I can tell ya - it ain't
easy.:-)

It's too bad that his first act in coming back to the newsgroups is to try
to show that he's some kind of alpha male all over again, by picking fights.
And unfortunately he continuously picks fights over dead horses too.

Does it really matter if Intel didn't explicitly say that it was going to
kill x86? Of course, it's never going to say anything definitively about
something so far away, so there will always be plenty of wiggle room. Any
intelligent person can surmise that when the roadmap shows clear paths for
IA-64, but not so much for IA-32 that perhaps it was not expecting much to
happen beyond a certain point for that path. Intel's older roadmaps ended at
Foster and Northwood, but just kept going for Itanium. Saying, "we envision
we will continue making x86 processors into the future", is just a standard
"notwithstanding" clause.

Yousuf Khan

"Stephen Sprunk" writes:

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.


It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries. MS Windows for AMD64 has an even greater need to support all
those 32 bit app. Solaris for AMD64 will follow the same route as
Solaris for 64-bit SPARC: dual boot, and the ability to run unchanged 32
bit binaries in the 64 bit environment.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik writes:

"Stephen Sprunk" writes:

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.

It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries.

I don't see many of them on the ~1000 Linux systems I've got at work.
There are bound to be some commercial apps where that's the case,
but I'm sure Stephen was thinking about the ease for _open_source_software_
to be ported over.

Why worry about commercial apps? They are supposed to make money, let their
developing companies spend some on porting. If the open source developers
already could do it for free, where should the problem lie?

Solaris for AMD64 will follow the same route as Solaris for 64-bit SPARC:
dual boot, and the ability to run unchanged 32 bit binaries in the 64 bit
environment.

Which is, of course, what Linux on AMD64 already and always provided,
decisions of _distributions_ wrt their development / library support
nonwithstanding.

best regards
Patrick

Casper H.S. Dik writes:

"Stephen Sprunk" writes:

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.


It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries. MS Windows for AMD64 has an even greater need to support all
those 32 bit app. Solaris for AMD64 will follow the same route as
Solaris for 64-bit SPARC: dual boot, and the ability to run unchanged 32
bit binaries in the 64 bit environment.

Most Linux/x86-64 distributions support 32bit applications just
fine. The kernel certainly can run 32bit applications with very good
compatibility (I'm typing this on a Athlon64 running a 64bit kernel
with an old 32bit suse 8.1 userland). The 32bit emulation subsystem
is also very stable, because it is mostly shared now between many
other 64bit architectures, some of them using 32bit as their
primary user land.

There are unfortunately some more x86-64 linux distributions (let
unnamed) who chose to go the slightly easier route of not providing
32bit compatibility. This means they don't ship the 32bit libraries
and don't use the /lib64 - /lib separation to make it easy to
install 32bit programs into the 64bit system.

Of course even with them you can install a 32bit root into a chroot
and run your old programs in there, but it is not very nice solution
and makes administration more difficult.

I suppose the users will chose with their feet depending on if they
value 32bit compatibility or not.

-Andi

(Patrick Schaaf) writes:

Casper H.S. Dik writes:

"Stephen Sprunk" writes:

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.

It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries.

I don't see many of them on the ~1000 Linux systems I've got at work.
There are bound to be some commercial apps where that's the case,
but I'm sure Stephen was thinking about the ease for _open_source_software_
to be ported over.


Do the AMD64 versions of Redhat and SuSE recompile everything? It seems
kind to silly to have a 64 bit /bin/ls, for instance. They always left
most stuff for which performance didn't matter compiled as i386, and for
stuff where performance mattered (the kernel, openssl libraries, etc.)
there were i686 versions. I would assume it is the same way for AMD64
stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have
to do a lot more versions if they bugfix /bin/ls and have to compile a
64 bit version to go along with the i386 version!

--
Douglas Siebert

When hiring, avoid unlucky people, they are a risk to the firm. Do this by
randomly tossing out 90% of the resumes you receive without looking at them.

Douglas Siebert writes:

Do the AMD64 versions of Redhat and SuSE recompile everything? It seems

Yes, they do.

(well mostly, the 32bit compat libraries are 32bit of course. And
there are a few programs left that are 32bit only, most noteable
of them is OpenOffice. Also usually only 32bit Java is available
because the 64bit version wasn't ready when the last releases were cut)

kind to silly to have a 64 bit /bin/ls, for instance. They always left

One reason is that a 32bit /bin/ls uses a 32bit time_t and will return
bad dates after 2036.

And unlike on some other architecture 64bit AMD64 programs are not
significantly slower than their 32bit counterparts.

most stuff for which performance didn't matter compiled as i386, and for
stuff where performance mattered (the kernel, openssl libraries, etc.)
there were i686 versions. I would assume it is the same way for AMD64
stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have

You are wrong.

to do a lot more versions if they bugfix /bin/ls and have to compile a
64 bit version to go along with the i386 version!

And a s390 version and a ia64 version and a ppc64 version and ...

Linux distributions already have the infrastructure in place to handle
multi architecture updates. Adding another architecture is only a very
small amount of additional work.

-Andi

Douglas Siebert wrote in message ...
Do the AMD64 versions of Redhat and SuSE recompile everything?

The SuSE distro I last worked with (8.1 enterprise?) has 64-bit as the
default compilation environment. If you do a "make configure" you get
a 64-bit app. Thus the natural process of building a distro produces
all 64-bit commands.

(E.g. if one installs a 32-bit devel package RPM, it will not be found
for config purposes in the default 64-bit build environment.)

It seems kind to silly to have a 64 bit /bin/ls, for instance.

"Silly" or "not necessary"? One would have to decide which commands
stay 32-bit on a command by command basis as some do benefit from the
better performance and increased address space. And having ls be
32-bit doesn't gain one much except allowing the same bits to be used
for the 64-bit and 32-bit versions. If one wants that, one can install
the 32-bit distro on top of the 64-bit kernel.

But if one values the executable bits being widely useable across
architectures, it seems silly to have native code for ls at all. All
the basic commands could be Java class files, .NET assemblies, dis
code, or Perl or Python scripts or whatever.

-Z-

In comp.arch Yousuf Khan wrote:
Stephen Sprunk wrote:
M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
possible at the time they expected their code to be obsolete before
64-bit systems took over -- 4GB is enough for anybody, right? I'm
sure they didn't expect their newly-ported 32-bit code to require
porting again in less than a decade, given 16-bit x86 code had been
around for two decades. And, given that most programmers don't stay
in the same job for a decade, why would one expect them to plan for
the future (other than style)?

The move from 16-bit to 32-bit Windows was doubly difficult, because of the
need to replace segment-based addressing with linear addressing. That is not
an issue with the 32-bit to 64-bit port. I think people are justifiably
disappointed in MS, because this one should've been smooth as silk. Their
kernel was ported quickly, but nothing else is being ported quickly.

Umm... Note that WinNT was never 16 bit and that parts of code were
AFAICT always shared with Win9x.


I don't think it's entirely as a result of spaghetti code. I think it's also
as a result of some dufusy arbitrary decisions that MS made. For example,
they decided not support 16-bit protected mode apps in Win64, even though
the AMD64 architecture has no problems running either 16-bit or 32-bit
protected-mode apps in compatibility mode. They've also decided not to allow
the use of x87 FPU under 64-bit mode, relying solely on SSE, even though
AMD64 is perfectly fine with either or both; now I don't know if this is
actually going to be a problem to developers, but it does show that MS is
taking arbitrary decisions. Then it hasn't created a 32-bit to 64-bit device
driver thunking layer, which would've given device driver manufacturers an
additional amount of time to port full 64-bit drivers to Windows.

Its not an *arbitrary* decision - once you look at the POV of "we are
doing a new ABI, hey compiler folks, whats the best thing?" doing it
this way makes sense.


Yousuf Khan



--
Sander

+++ Out of cheese error +++