Will Prescott work on Win64?

[Ancra]

... establishing the bitness of the CPU,
which is exclusively a property of the ISA.

- ! !

Well,well.- Why didn't you say so before? We're in perfect agreement
then!


ancra

 

[Rupert Pigott]

[SNIP]

My argument is that the capabilities does not follow from the GPR.

Yes, quite correct for *YOUR* definition of 64 bitness.

(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' elaborations
were 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?

However *YOUR* definition isn't the one shared by the
rest of the world.

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

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.

Yes, but I'm such a convoluted person, that I feel practice sometimes
outlives its usefulness. Much have happened in those 50 years.

I don't think it ever really does outlive it's usefullness
to be honest. There are always lessons to be learnt from
the past as well as present. I do confess to thinking the
same way as yourself and beating up on this very group in
the very same way. I think the last great crusade I launched
was in the thread entitled something like "Dead horse
flogging" from a long time ago.

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?

Personally I've found it to be rather handy. I've done
stuff like SIMD work with it, done 3D graphics in integer
because 64bits give me enough range to get by etc...
In the current world dominated by register-register style
machines 64bit GPRs is a big deal, especially as addresses
are often held in GPRs.

Cheers,
Rupert

 

[Ancra]

I don't think it ever really does outlive it's usefullness
to be honest. There are always lessons to be learnt from
the past as well as present. I do confess to thinking the
same way as yourself and beating up on this very group in
the very same way. I think the last great crusade I launched
was in the thread entitled something like "Dead horse
flogging" from a long time ago.

Well I've folded and changed my mind. It means Dan is right about his
preliminary statement "It's not that easy" too.
But it's alright. I now think that is the way it will have to be. Any
real or percieved difficulties from tying cpu bitness to gp registers
have to be dealt with when encountered, rather than preempted. And
wider explanations of meaning of "bitness" will be separate stories.
But I do still feel that gpr-length, as criteria for bitness, has
outlived most of its usefulness, even if I now agree with it.

Personally I've found it to be rather handy. I've done
stuff like SIMD work with it, done 3D graphics in integer
because 64bits give me enough range to get by etc...
In the current world dominated by register-register style
machines 64bit GPRs is a big deal, especially as addresses
are often held in GPRs.

I agree of course. When I work, I run fairly close to the 2GB
boundary, 1.2 - 1.8GB app space (Windows PC). I need x86-64 soon.
In the PC world (I'm involved through crossposting from
achw.pc-homebuilt) bitness very much concerns addressing.

Cheers


ancra

 

[Dan Pop]

I don't really think you need to be a computer architect to come up with
a reasonable definition:

The bitness of a system is (mostly) determined by the largest flat
address range you can easily handle.

There are many flaws in this definition:

1. It doesn't address the Harvard architectures with different sizes for
the data and the code address spaces.

2. It makes no difference between systems with byte addressing and systems
with word addressing.

3. If we put it to work, we get the following results for several well
known architectures:

Z80 - 16-bit
PDP-8 - 7-bit
PDP-10 - 18-bit
IBM 360 - 24-bit
Cray-1 - 48-bit

(This is quite obvious to asm hackers, but much less so for others, as
long as the compiler can hide the ugly stuff.)

It is quite obvious to asm hackers whose experience is limited to
architectures where all the bits of the GPRs are used for addressing
purposes.

By your definition, an architecture with 64-bit GPRs supporting 48-bit
addressing is a 48-bit architecture, while the computing indistry
would consider it a 64-bit architecture, without any if's and but's.
The traditional Cray vector processors fall into this category.

Dan

 

[Terje Mathisen]

By your definition, an architecture with 64-bit GPRs supporting 48-bit
addressing is a 48-bit architecture, while the computing indistry
would consider it a 64-bit architecture, without any if's and but's.

Huh?

How can you read that into what I wrote?

If I do all address arithmetic on 64-bit registers, then it is indeed a
64-bit system, even if parts of that address range doesn't really point
to real (or even virtual) memory.

The traditional Cray vector processors fall into this category.

In the paragraphs you snipped, I mentioned how being allowed to use the
64-bit MMX registers to address the 36-bit physical address range of
some x86 cpus would have made them (ugly) 64-bit cpus.

Is this very different from your Cray?

Terje

 

[Dan Pop]

Huh?

How can you read that into what I wrote?

If I do all address arithmetic on 64-bit registers, then it is indeed a
64-bit system, even if parts of that address range doesn't really point
to real (or even virtual) memory.

If you do all address arithmetic on 64-bit registers, "the largest flat
address range you can easily handle" on such a system is still 48-bit,
period. Therefore, by your *own* definition, it is a 48-bit architecture.

In the paragraphs you snipped, I mentioned how being allowed to use the
64-bit MMX registers to address the 36-bit physical address range of
some x86 cpus would have made them (ugly) 64-bit cpus.

Which doesn't make any sense, of course. "The largest flat address
range you can easily handle" in this scenario is still 36-bit, period.

You were not consistent with your own definition. According to your
definition, that would make it a 36-bit processor.

You're confusing the integer arithmetic capabilities of the CPU and its
addressing capabilities. It makes no sense to talk about 64-bit
addressing, unless the architecture defines a biunivocal relationship
between the address range and the range of values representable in a
64-bit CPU register.

Dan

 

[Terje Mathisen]

Which doesn't make any sense, of course. "The largest flat address
range you can easily handle" in this scenario is still 36-bit, period.

By "handle" I meant which size would a pointer be, and how would I do
address arithmetic on it. I don't care how many of the bits are actually
brought out on the memory bus, only that the total is large enough for
the task I'm doing.

You were not consistent with your own definition. According to your
definition, that would make it a 36-bit processor.

You're confusing the integer arithmetic capabilities of the CPU and its
addressing capabilities. It makes no sense to talk about 64-bit
addressing, unless the architecture defines a biunivocal relationship
between the address range and the range of values representable in a
64-bit CPU register.

I don't think I'm confused, but I seem to be confusing, at least to you.

Sorry about that.

Terje

 

[Jean-Marc Bourguet]

By "handle" I meant which size would a pointer be, and how would I do
address arithmetic on it. I don't care how many of the bits are actually
brought out on the memory bus, only that the total is large enough for the
task I'm doing.

8 bits processors -- like Z80 -- handle easely address arithmetic on
16 bits adresses.

A+

 

[Dan Pop]

By "handle" I meant which size would a pointer be, and how would I do
address arithmetic on it. I don't care how many of the bits are actually
brought out on the memory bus, only that the total is large enough for
the task I'm doing.

But that total is still not (necessarily) determined by the size of the
registers used for computing the address. See my examples.

I don't think I'm confused, but I seem to be confusing, at least to you.

Regardless of what you think, you are confusing arithmetic capabilities
and addressing capabilities. You have provided ample proof in this
thread. Your definition is broken for 8-bit CPUs and for many 64-bit
CPUs, as well as for a fair number of historical architectures.

Dan

 

[Stephan Schulz]

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?

Not "what", but "who"! I and my baseball bat both volunteer, and I
strongly believe there are thousands more who are willing to resort to
any type of action to spare us a return to those dark ages!

;-)

Bye,

Stephan

 

[Robert Wessel]

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?

Since all segments descriptors are mapped into a single 4GB linear
address for each process on x86, you can't extend addressing past 4GB
using segmentation. The architectural change required to allow that
would be minor, however, but it's not present in any x86 currently
available.

An OS could play games by dynamically remapping the page and segment
tables at each segment register load, but it's ugly, and hasn't been
implemented by anyone that I know of. See the following for a
somewhat longer discussion of the technique:

http://groups.google.com/groups?hl=...11042118.7027b148%40posting.google.com&rnum=1

 

[Andy Freeman]

Secondly, you're off target a bit:
Win32 only gives an app 2GB process space, not 4.

2GByte is the max user space in the default configuration for Win32.

However, there's a boot-time option for later versions of Win32 OSes
that let specially configured applications have 3GByte of user space.
These Win32 OSes aren't as happy running with this configuration, but
it is the right choice in some cases.

I predict that more and bigger registers, not address space, is the
first thing that will move high end games to x86-64.