R
Rupert Pigott
Ancra said:
D
Dan Pop
In said:
Nope, it's the former part (32-bit general purpose registers) that made it
a 32-bit CPU. The 68000 only had 24-bit addressing instructions: the
higher 8 bits of the address registers were not used when the address
of the operand was supplied by an address register, for the simple reason
that the address bus of the 68000 only had 24 bits.
Dan
B
Bill Bradley
Ancra said:
On this topic NVidia has released 64-bit drivers for the WinXP 64-bit
beta(http://www.nvidia.com/object/winxp64_52.14), so that least they
seem to be serious about support in the immediate future.
Bill
A
Ancra
It's very convenient to have at least as wide registers as the length
of the Instruction Set Adress. But the various hardware widths inside
a processor are almost arbitrary. And indeed varies a lot. Physical
width only confers performance. Software width, OTH is fundamental!
It's the adress length that decides the capabilities of the cpu.
- Really now... :-/
* - The 68000 cpu have 32-bit long instruction set adress format! *
....like all 68k members.
- Really now... :-/ So how can it throw away 8 bits from the
adresslength and get 24-bit physical adress if it doesn't have 32-bit
adress length to start with? (rethorical)
The fact that it only have 24-bit physical bus is completely
irrelevant. That's just a hardware interface. Just like the Athlon64's
40-bit adressbus.
ancra
A
Ancra
It doesn't work like that, in those neat anal retentive terms.
Unfortunatly, the thing we refer to with bits, when classifying cpus
is not consistent. But then, why should it be? Why assume it is? Why
assume a 30 year old convention can be a guide on what is the
distinctive difference between these later cpu generations?
It is correct that early cpus like 8080 are referred to as 8-bit. That
was consistent with the practice of the time to refer to the 'size' of
computers in terms of their width of data registers. This and 'word'
size was what interested the punchcard geeks in those days.
Size in these terms is an obsolete concept.
All our computers have byte addressing, 8-, 16-, 32-bit integer ops,
32-, 64-bit fp ops. There's no distinctions there anymore. Nothing of
interest. No reason to classify cpus. "WORD"? - Phew! Give me a break!
Size today is number of transistors and cpus, ...and size of
...memory!
Just ask yourself at least one time why. Why are we classifying these
16-32-64 bit processors? What's the crucial property that defines
their abilities? GPR width? - No way! It may fit, but it doesn't have
to. Theoretically it's arbitrary.
When I, MS, Linux-kernel-programmers, IBM, Sun, Intel, AMD, HP,
Motorola and those journalists that actually have a clue, talks about
16-, 32-, and 64-bit cpus, the reason for the classification is the
software they can run.
It's the SOFTWARE! There have to be a hardware implementation to run
the software, but the FUNDAMENTAL PROPERTY is the address length of
the software. This is where the bit's come from!
16-bit cpus run code with 16-bit addresses. Because of this, their
addressing is highly convoluted and contorted. A pointer doesn't fit
in 16 bits. The software itself always has to set a pageselector and
then use the appropriate index into this in the instructions
addressfield.
The necessary mapping operations on top of this, to make sure the
software fits in on the hardware, and fits in between the OS and other
apps, also severely limits the memory space. 16MB, I think for Win16,
collectively, for all apps and OS together.
32-bit cpus run 32-bit code. Here all addresses and arithmetic are
linear. Linear addressing, just by itself, results in a massive
performance boost and simplification of code.
Each process has a single context, featuring 4GB linear space, mapping
addresses to physical space. This confers a thremendous boost in
capabilities of the computer. Process space in windows is 2GB for EACH
app. This is still not enough for voxelobjects, databases, AI, finite
element, solid engineering, games, filmwork... While those apps is
running on 32-bit architectures, they're running into the limits of
the 2GB process space.
64-bit cpus also use linear process space. But because the
instructions address field is now 64-bit wide, the address space is a
whopping 16 EB! While early OS will not feature more than fraction of
that as process space, 4 TB from Windows64, we now have space to grow.
- This is it!
This is the reason AMD, Intel, IBM and Sun are building "64-bit" cpus.
This is why we're even discussing 64-bit cpus right now.
GPR width hasn't a f**k to do with it! It is of course convenient to
have integer registers as wide as addressing. Since these registers
have to do the address arithmetic. Which is why it is usually selected
as the same width as addresslength. But it doesn't have to be. It's
arbitrary. Athlon64 could have had 8, 16, 20, 32, 40 or 128-bit
integer registers. It would affect performance and it would be bad
engineering. But it wouldn't change the fact that it's a '64-bit' cpu,
in the only terms that are interesting or relevant.
Likewise, Intel have extended the Pentium architecure numorous times.
This have added 64-bit registers. They have not extended the integer
registers though. They could have. It's shit easy. But why? It
wouldn't change properties of the cpu. Sorry, 64-bit GPR wouldn't make
it a '64-bit' cpu. It would still be the same 32-bit cpu.
It has to be a new cpu. With new instructions, featuring 64-bit
addresses. And new memory management.
I have no doubt that there are lots of people out there assuming it is
some question of 'width' that affects performance. Like 32-bit is
twice as fast as 16, and 64 bits are twice as fast as 32-bit, much in
the manner of a game console. But that is of course not it at all.
Hardware widths in a cpus are prone to changes and are what you can
afford and make effective use of. Pentiums, Athlons, Athlon64s feature
elements of anything from 16 to 256-bits width. Wouldn't surprise me
if the A64 has some 512-bit wide internal bus in relation to its
caches. But I haven't studied that and I don't know it.
ancra
R
Rupert Pigott
[SNIP]
Right, so 6502s were 8 bit.
Cheers,
Rupert
Right, so 6502s were 8 bit.
Cheers,
Rupert
A
Ancra
Hi, Rupert.
Your posts are really funny, but unfortunatly I don't know what to
make of them.
Sorry.ancra
D
Dan Pop
In said:
You're confusing the with the width of the address registers with the
addressing capabilities of the processor.
Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
pointers for other purposes and failed to work on the later members of
the 68k family that had 32-bit addressing capabilities.
Which merely goes to show that the 64-bitness of the Athlon64 is not
dictated by its addressing capabilities.
Pentiums have been able to address more than 4GB of memory for quite
a while, yet no one claimed that they're more than 32-bit processors.
Just as in the case of 8-bit processors, all of them being able to
address more than 256 bytes of memory. So, whether you get it or not,
the size of an ISA is *not* determined by its addressing capabilities.
It's the size of the GPRs that matters and nothing else.
Dan
A
Alex Colvin
It is correct that early cpus like 8080 are referred to as 8-bit. That
-----?
Consider an earlier CPU, 1959's IBM 1620.
-----?
Consider an earlier CPU, 1959's IBM 1620.
?
=?ISO-8859-1?Q?Martin_H=F8yer_Kristiansen?=
Wes said:
No, but a game that uses the extra registers of the x86-64 model and
squeezes 10% more performance out, - causing every (enthusiast) hardware
website to state that "AMD64 is clearly the choice for
DOOM/UNREAL/HALFLIFE XXX" causing the masses to buy x86-64 capable
machines in droves.
Cheers
Martin
N
Nick Maclaren
|>
|> >The fact that it only have 24-bit physical bus is completely
|> >irrelevant.
|>
|> Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
|> pointers for other purposes and failed to work on the later members of
|> the 68k family that had 32-bit addressing capabilities.
Virtual or physical addresses? The physical bus affects only the
latter, and they are used only by a very small part of the kernel
if you are using an operating system like Unix. Also, systems in
the past have sometimes checked that unused bits were zero and
faulted if they weren't. In that case, the physical bus width is
irrelevant.
|> Pentiums have been able to address more than 4GB of memory for quite
|> a while, yet no one claimed that they're more than 32-bit processors.
|> Just as in the case of 8-bit processors, all of them being able to
|> address more than 256 bytes of memory. So, whether you get it or not,
|> the size of an ISA is *not* determined by its addressing capabilities.
That's physical memory again - no single process can address more
than 4 GB.
|> It's the size of the GPRs that matters and nothing else.
Definitely not. There have been systems where a single process
could address 1 TB using 32-bit registers - in an earlier period,
there were systems where one could access 1 MB using 16-bit
registers. There are several ways to do that.
I would assert that such systems are not clearly N-bit for any N,
but they are definitely NOT just N-bit systems, where N is the
number of bits in a general purpose register.
Regards,
Nick Maclaren.
|> >The fact that it only have 24-bit physical bus is completely
|> >irrelevant.
|>
|> Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
|> pointers for other purposes and failed to work on the later members of
|> the 68k family that had 32-bit addressing capabilities.
Virtual or physical addresses? The physical bus affects only the
latter, and they are used only by a very small part of the kernel
if you are using an operating system like Unix. Also, systems in
the past have sometimes checked that unused bits were zero and
faulted if they weren't. In that case, the physical bus width is
irrelevant.
|> Pentiums have been able to address more than 4GB of memory for quite
|> a while, yet no one claimed that they're more than 32-bit processors.
|> Just as in the case of 8-bit processors, all of them being able to
|> address more than 256 bytes of memory. So, whether you get it or not,
|> the size of an ISA is *not* determined by its addressing capabilities.
That's physical memory again - no single process can address more
than 4 GB.
|> It's the size of the GPRs that matters and nothing else.
Definitely not. There have been systems where a single process
could address 1 TB using 32-bit registers - in an earlier period,
there were systems where one could access 1 MB using 16-bit
registers. There are several ways to do that.
I would assert that such systems are not clearly N-bit for any N,
but they are definitely NOT just N-bit systems, where N is the
number of bits in a general purpose register.
Regards,
Nick Maclaren.
D
Dan Pop
The 68000 was unfit for virtual memory addressing. The first processor
of the family properly designed for virtual memory addressing was the
68010.
Sez who? What is preventing the design of an OS whose processes can
address more than 4GB, through segmentation, just as MSDOS allowed its
processes to access more than 64 KB?
And, anyway, the OS is irrelevant in establishing the bitness of the CPU,
which is exclusively a property of the ISA.
How is this relevant to a discussion about the bitness of a certain ISA?
Feel free to invent your own terminology, but don't expect other people
to care about it. The bitness of an ISA has been determined by nothing
else than the size of the GPRs for as long as I can remember (the IBM 360
has been a 32-bit architecture, despite 24-bit addressing and 8-bit
physical implementations).
Dan
A
Ancra
If and when I get confused, I'll let you know.
I'd say you are confused about physical addressing abilities and
software adressing. 64-bit computing is all about using _linear_
64-bit pointer software. GPRs and physical adressing are just
particulars of hardware implementations. And as I've said often enough
now, actually quite arbitrary to 64-bit computing.
(That is an out of context comment from you).
- It's just as irrelevant as mobos RAM limitations for the fundamental
properties of the cpu.
The cpu is DEFINED by its instruction set. It is LIMITED by its
hardware interface. And it is neither defined nor limited by its GPRs.
The point is that you can develop and run software on the 68000 and
any 68k, that can in linear mode utilize any memory, available sooner
or later from some hardware, theoretically up to 32-bits. And it can
do so because the cpu has an instruction set with 32-bit
adresseslength.
In our context - this thread, this group - "64-bitness" as a property,
refers to the property of *membership* in a class of cpus. The label
for this class says '64-bit'. Ultimately it doesn't matter how this
label was derived.
In particular, it doesn't matter how that other label '8'bit' was
derived 30 years ago, for that other completely different class of
cpus known as "8-bit" cpus.
What matters are the capabilities shared by the "64-bit" cpus.
And those capabilities are most definitely "dictated by its adressing
capabilities"!
I write "instruction set" again and again and again... - Don't you
know how physical adressing is managed in the post-8bit-cpu era?
No, it's the capabilities that matters! You could possibly claim that
the 'label' -name is derived from the length of the GPR. (I would
argue against it).
Speaking of getting it - what is special with GPRs?
The Pentiums also have 64-bit registers. That doesn't make the Pentium
a 64-bit cpu. Not even according to you. But if it is the registers
that matters, why not?
And why is the length of the GPR (which is really arbitrary) chosen as
it is? - Eh?
They "matters" because software does its own adressarithmetic - for
instructions adressfields - in them! That is why it's good engineering
to choose their length from the ISA.
My argument is that the capabilities does not follow from the GPR.
The capabilities signifying 16-, 32-, 64-bit classes of cpus follows
from the instruction set adresslength.
The length of GPR _also_ follows from the instruction set
adresslength.
(But it doesn't _have_ to!)
To link to the subjectline of this group: 64-bit integer registers
won't make the Prescott a '64-bit' cpu.
It needs a completely new instruction set. It needs completely new
memorymanagement. Guess what that makes it? - Right, a completely new
processor. But does it need 64-bit GPRs, to realize the capabilities
that will make it a member of the '64-bit' class? - No! It actually
doesn't need that.
A cpu belonging to the 64-bit class could have 8-bit or 1024 bit GPRs.
(It would be terribly interesting to see the reasons for that, ;-D
but that's a different story)
So it's misleading to say that the property conferring '64-bitness' is
the GPR length. It's not. - It's the instruction set that is the
ticket to the 64-bit club.
It's _always_ the instruction set.
ancra
K
Ken Hagan
Ancra said:
If you are arguing that the "8" in 8-bit does not correspond to the
"64" in 64-bit, then you are presumably of the belief that "bit-ness"
is not a term with any generally applicable meaning. This will come
as a surprise to many people, hence the current thread, I suppose.
Furthermore, since "64-bit" is now merely a label applied to a group
of processors that are currently of interest to you, I might ask two
questions.
Which processors are "64-bit"? (Just so as we know.)
Why not call them "red processors"? (This would avoid annoying
those who wish to infer some meaning from the term "bit-ness".)
If, on the other hand, the "8" and "64" are different values of the
same property, then we are under some obligation to come up with a
definition of "bit-ness" which agrees with historic usage. It seems
to me that Dan's definition manages that.
D
Dan Pop
In said:
You can do that only *after* you realise you're confused. Until then...
Dan
R
Rupert Pigott
[SNIP]
Yes, quite correct for *YOUR* definition of 64 bitness.
However *YOUR* definition isn't the one shared by the
rest of the world.
Word to the wise :
It's a good idea to run a sanity check on your arguments
if you are finding that they conflict with 50+ years of
practice.
Cheers,
Rupert
Yes, quite correct for *YOUR* definition of 64 bitness.
However *YOUR* definition isn't the one shared by the
rest of the world.
Word to the wise :
It's a good idea to run a sanity check on your arguments
if you are finding that they conflict with 50+ years of
practice.
Cheers,
Rupert
D
Del Cecchi
Or one could even do some googleing of comp.arch and the web to see what theRupert Pigott said:
concensus definition is among real computer architects and computer
scientists, rather than making something up.
del
R
Rupert Pigott
Del Cecchi said:
Bah, I never did that and I think that *might* fall into
the category of "sanity check". In this case I don't think
it's really necessary anyways, he's getting silver platter
treatment, but I bet he doesn't say thankyou.
Cheers,
Rupert
A
Ancra
- Hmm, good point. :-/
Also, as a strategy to get past labels and into the content, it
certainly seems to have failed miserably.
Cpus having an ISA with 64-bit flat virtual addressing. (and please,
no more on physical addressing or segmented mapping. Likewise I don't
think we need any wideranging discussions on canonical addressing
form).
I'm not aware of any "64-bit" cpu that does not have 64-bit GPRs. Nor
am I aware of any "32-bit" cpu that doesn't have 32-bit GPRs. I
believe this will answer your question, in the terms you are looking
for?
In this thread I've tried to deliver answers that assumes there is
some point to asking that question in the first place.
Rather than assuming "A big red truck" is a satisfactory answer to
"What is a fire engine?", however correct that may be.
I also have a tendency to question things like if it really has to be
red. ;-)
Well, that was just my point. "Inferring some meaning from the term".
"let's see here now... ok it's painted red (has 64-bit GPRs), allright
then, it's a "red processor"(64-bit cpu)!"
What does that mean? What does 64-bit GPRs mean?
If you do try to infer some meaning from that, what would you say it
would be?
And why "general purpose registers" in particular? What about other
registers? I would think at least some people, looking for answers to
the question what is '64-bitness', would feel "64-bit GPRs" leaves the
question curiously unanswered.
Yes, I have to agree with that. Just as I would have to agree to red
for redpainted cpus
Definition in the sense of how to - sofar - recocnize a 64-bit cpu.
I don't think that answers the question what 64-bit computing really
means, for the guy starting this thread. Though that's just my
assumption of course.
ancra
A
Ancra
(Hi Rupert, now I understand you ;-))
"definition"? well, bits can refer to many things.
The argument one makes is to a large part caused by how one percieves
the opponents view. And much of my 'War & Peace novel'
elaborationswere driven by Dan involving physical addressing into the discussion.
I wanted to make clarifications.
But ok, let me try this:
The capabilities, in question, belong to the concept widely known and
referred to as "64-bit computing" in connection with any discussion on
servers, 64-bit Linux, Windows64 etc.
The question I sought to answer was this: What 64-bit property confers
these capabilities to a cpu?
-Hmm, "definition"? again.
Take any article you want, on 64-bit computing, and read on. Read on
beyond the introductionary section on 64-bit GPRs, to what the purpose
of 64-bit computing is about.
Yes, but I'm such a convoluted person, that I feel practice sometimes
outlives its usefulness. Much have happened in those 50 years.
Register widths and path widths tend to vary a lot inside
architectures today. And are more governed by what you can make use
of, than by how often you have to change vacuum tubes.
But let's do it your way:
OK, '64-bitness' refers to the length of those particular registers
known as GPR.
- Then what?
What does that mean? Why does anyone need 64-bitness?
Cheers,
ancra