Looking at AMD's roadmap, it looks like athlon 64 is here to stay on
desktop
(Well unless AMD goes bankrupt, Then maybe Apple will take over)
Of course 64bit system were avaliable in servers for quite some time
but
i dont think we all own a server at home!
It is a shift another shift in paradigm.
As intel move to the end of the 'pentium 4' (after 3.2ghz) roadmap, a
new pentium was anticipated in Q4 next yr (from what i read from
inquirer)
Maybe intel might enable 64bit on their pentium 5!
No. Intel may actually secretly have a compatible 64-bit design on
backburner, as a fallback, but it isn't the P5, the P5 is another
'P7-core' CPU, just as the P4. It cannot be made into 64-bit.
(P6-core being PentiumPro, PII, PIII, PIIIe, Xeon, Celeron, Tualatin)
(P5-core being Pentium and PentiumMMX)
Hey wait a minute, Intel would prefer a pubilcity stun to knock out
AMD...
so maybe they will better AMD by pushing out a 128bit processor!!
No. We ran out of space with 16 bits already before the IBM PC. It has
taken us 25 years to run out of space with 32 bits. If the technology
moves at the same exponential rate, Moores law and all that, in the
future, it will still take at least another 25 years (probably 50) to
run out of 48 bits, and we will have 64. This may be a good time to
explain these bit-thingys:
When we today talk about 16-, 32-, 64-bit, we are talking about the
length of the adress, used by any cpu-instruction to refer to data in
memory.
Thus it doesn't have anything to do with the width of the data being
manipulated. Early "8-bit" processors, performing instructions on
8-bit wide data segments, actually had 16-bit adressing as well, so in
our sense, they too were "16-bit" CPU's. The PC is still a byte
adressable architecture, so we still have one adress for each 8 bits
of data in memory. In many other ways, the "width" of our cpu's have
moved on. We have 64-bit wide databus since the Pentium, and
internally, todays cpu's have both 128-bit and 256-bit wide buses.
And, of course, we have 64-bit cpu registers for floating point and
extended instructinsets, besides the 32-bit integer registers. On dual
channel mobos, you could even make some claim that we have moved on to
a 128-bit wide databus.
But let's get back to the length of adress. The external adressbus is
actually 36-bit wide, as well. BUT the instruction set only uses 32
bits for adresses! A good way to get a grip on this is perhaps to look
back.
The first generation of 8-bit PC's (not IBM PC's, just PC's) used, as
already stated, 16 bits to adress data. This was direct hardware
adressing (later called real-mode), so the adress went straight out on
the adressbus, and enabled some byte in RAM. A big problem with this
is that only 64KB RAM can be adressed. Early homecomputers were thus
limited to max 64KB RAM.
Unfortunatly, someone then had a very stupid idea. Mobos with more
than 64KB were built. 128KB, even 256KB. The wider adressbus
originated from a chip on the mobo, where a contained static value was
combined with the 16 bits from the cpu's adressbus, to form a longer
adress. Any and each application using more than 64KB had to manage
the memory itself. It had to write the current page to the combining
chip, every time it went across a page border. And that is actually
quite awkward and bugprone.
The preferred OS at the time was CP/M. It worked just as DOS. It
simply loaded & launched the app and then went away, leaving all the
hardware directly to the app. Common cpu's at the time were Intels
8080-85 series, the compatible, but extended Zilog Z80 and the odd
one, the clever little 6502.
Intel then had some crazy stillborn cpu design in the works. (the '286
and the Itanium are by no ways unique for Intel). As it was becoming
increasingly clear that it was a failure, Intel began looking for a
savior.
They simply extended the 8080's 8-bit registers to 16-bits. This is
quite simple. You simply insert more of the same logic between the
carry and 0. You still have 16-bit adressing though. Doing something
about that requires a much more fundamental redesign. Longer
instructions need to be decoded etc. Instead Intel opted for a dirty
solution. They simply took the crude paged concept, I've already
described, and moved the combiner/pageregister into the cpu itself.
The 8086 was born. The 8086 had a 16-bit databus and a 20-bit external
adressbus and could adress 1MB. But code still used 16-bit adresses.
Unfortunatly, IBM then chose this abomination instead of Motorolas
vastly superiour 68000 cpu (it already had real 32-bit adressing!).
Much have been said and written about this incomprehensible choice.
Bill Gates have called it "the ultimate triumph of marketing hype over
science and engineering". I suppose he learned some real truths from
that, which he then has been able to exploit successfully in many
ways. ...And so did Intel.
For some obscure reasons, clueless PC journalists, far into the
nineties, often referred to 68k-cpu computers (Mac, Amiga, Atari,
Next, early SUN) as "16-bit", just as 8086 and '286 PC's. That's BS,
some 68k machines may have had only 16-bit mainboard databus, and some
(Mac) may only have used 24-bit adresses to begin with, but the 68k
cpu family was always 32-bit technology, right from the start.
The basic problem of the 8086 is that you need long pointers for
computing adresses in large dataobjects. But on the 8086, these long
pointers can't be used directly by an instruction since it's limited
to 16-bits. Instead a correct page has to be computed and set, and a
short pointer, into this page, has to be computed and used instead.
All of this must be done by the apps own code, inside the app. This
degrades performance horrendously, and is also extremely bugprone.
(Mind you, if you can use short pointers only, you don't suffer any
performance penalty from 16-bit code. This is partly why Win95 doesn't
suffer at all, despite having some legacy 16-bit code in the 'user'
API. Win95 still has to 'thunk' those 32-bit calls (from 32-bit apps)
to 16-bit calls, but the 'thunking' is compensated by win95 not doing
any context shifts during system calls.)
Another problem with the 8086 was that it could only adress 1MB.
Intels solution to that was the '286. This keeps 16-bit adressing, but
extends the paging scheme to produce a 24-bit external adress. So it
can adress 16MB. 286 adressing is extremely complex and the 286 is
generally rated as the worst CPU-design of all time.
The 286 made Bill Gates and Microsoft very upset. So annoyed, that
they drew up the wishlist for the 386's memoryhandling, memorymodes
and instructionsets and forced Intel to design the processor. Many
don't know this, but the 386 wasn't an idea originating inside Intel.
Microsoft persuaded Intel to build it to their desires. And very well
done by MS too, I think. All subsequent PC cpu, 486, Pentium, PII,
PIII, K6, K6-2, Athlon, P4, AthlonXP still use the 386
instructionset/memory architecture.
(The Athlon64 intends to break with that tradition. But it also
intends to stay backwards compatible, just like the 386 did.)
Finally, Intel had a real cpu, that could execute instructions using
32-bit adresses. 32bits are good for 4GB. A 32-bit app could finally
have a linear memoryspace. Which means that any adress arithmatic is
simple and straightforward.
The 386 also separates the adresses, used by the instructions in the
programcode, from actual adresses. It uses a complex paging scheme to
map hardware 'real' adresses, as they go out on the cpu's adressbus,
to software 'virtual' adresses, as used by the code instructions. The
information about the mapping is contained in something called
pagedescriptors. These typically reside in the cpu level1 cache. This
separation allows features that are called 'virtual memory' and
'protected memory', but that is a responsibility of the OS to
implement. It also allows the 386 to run both it's own 32-bit code as
well as 286 16-bit protected mode code and - in a special mode called
'virtual real mode' or 'virtual mode' for short - 8086 16-bit code,
concurrently, in the same OS.
AMD intend to re-perform the 386 trick, that brought linear adress
space and 32-bit adressing to the PC, yet another time. This time with
64 bits.
64-bits are about getting a bigger adress space for the app. Win32
only provides 2GB, and that is beginning to be a tight fit for a lot
of applications.
The Athlon64 will not be faster because it's '64-bit'. It's going to
be faster because it's AMD's next cpu generation.
Ultimately though, it's going to completely outperform 32 bit cpus,
like the P5, on big data apps, presicely because it's 64-bit. 32-bit
apps have to handle large data in a much more convoluted manner. Same
as some Win16 apps had to do, when they ran out of their 16MB space.
The performance penalty is going to be enormous.
ancra
