64 bit processors

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

I have a question about the line of true 64 bit processors. When they
are running 32 bit software, do they take the instructions, data,
etc. 2 blocks at a time or is there half of the cpu that is not
being used?? Where this is leading, is to the question is it better
to have a super hi speed 32 bit cpu and OC it, or is it better to
have a 64 bit cpu of less speed. Om that case would they be about
equal? In other words, is it worth it to buy a 64 bit cpu now, even
if it is only running 32 bit software and may still be doing that for
some time??

 

[Ed]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Mon, 13 Dec 2004 20:31:43 -0600, Jmonahan@ev1.net wrote:

>I have a question about the line of true 64 bit processors. When they
>are running 32 bit software, do they take the instructions, data,
>etc. 2 blocks at a time or is there half of the cpu that is not
>being used?? Where this is leading, is to the question is it better
>to have a super hi speed 32 bit cpu and OC it, or is it better to
>have a 64 bit cpu of less speed. Om that case would they be about
>equal? In other words, is it worth it to buy a 64 bit cpu now, even
>if it is only running 32 bit software and may still be doing that for
>some time??


The AMD64 chips can run 32-bit just like any other 32-bit x86 CPU,
64-bit is just (free) icing on the cake.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2242&p=6
http://reviews.zdnet.co.uk/hardware/0,39023760,39164010,00.htm
http://techreport.com/reviews/2004q4/athlon64-fx55/index.x?pg=5
http://www6.tomshardware.com/cpu/20041115/pentium4_570-20.html

Ed

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Mon, 13 Dec 2004 20:31:43 -0600, Jmonahan wrote:

> I have a question about the line of true 64 bit processors. When they
> are running 32 bit software, do they take the instructions, data,
> etc. 2 blocks at a time or is there half of the cpu that is not
> being used?? Where this is leading, is to the question is it better
> to have a super hi speed 32 bit cpu and OC it, or is it better to
> have a 64 bit cpu of less speed. Om that case would they be about
> equal? In other words, is it worth it to buy a 64 bit cpu now, even
> if it is only running 32 bit software and may still be doing that for
> some time??

64 bits refers to the address size not to data sizes, a 32 bit CPU can
address 4 billion bytes, a 64 bit CPU can address 4 billion X 4 billion
bytes, i.e. 2^64 or 1.6 * 10^18 bytes. We've reached the point where
4GBytes of real memory is not only possible but is even affordable so the
4Gbyte limit of a 32 bit address is a problem. By increasing the address
space to 64 bits the virtual address space becomes so large that the we
won't have to worry about it limiting the amount of RAM that you can put
into a system for another 50 years, probably much much longer than 50
years but if you make the wildly optimistic prediction that Moores law
continues to hold forever then at the rate of 1.5 years per bit (the
historical Moore rate) then it will take 48 years to use up the new
address bits.

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Mon, 13 Dec 2004 20:31:43 -0600, Jmonahan@ev1.net wrote:

>I have a question about the line of true 64 bit processors. When they
>are running 32 bit software, do they take the instructions, data,
>etc. 2 blocks at a time or is there half of the cpu that is not
>being used?? Where this is leading, is to the question is it better
>to have a super hi speed 32 bit cpu and OC it, or is it better to
>have a 64 bit cpu of less speed. Om that case would they be about
>equal? In other words, is it worth it to buy a 64 bit cpu now, even
>if it is only running 32 bit software and may still be doing that for
>some time??


The answer to the question you didn't ask is, yes buy an
Athlon 64 instead of a P4, at most uses it's faster,
including 32bit.

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Mon, 13 Dec 2004 23:52:45 -0500, General Schvantzkoph wrote:

> 64 bits refers to the address size not to data sizes,

Now that's a new one and I thought I'd heard them all. Actually, this
is incorrect too though. The A64 address bus is 40bits, 48 virtual.

> a 32 bit CPU can address 4 billion bytes

Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue, it has
a 24bit address bus). I really haven't checked, but it's very possible to
have a 32bit cpu address more than 4GB. the amount of directly addressable
ram is controlled by the size of the address bus, and has nothing to do
with 32, 64, or 128 bit cpu's.

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://mysite.verizon.net/res0exft/cpu.htm

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Tue, 14 Dec 2004 09:26:40 +0000, Wes Newell wrote:

> On Mon, 13 Dec 2004 23:52:45 -0500, General Schvantzkoph wrote:
>
>> 64 bits refers to the address size not to data sizes,
>
> Now that's a new one and I thought I'd heard them all. Actually, this
> is incorrect too though. The A64 address bus is 40bits, 48 virtual.
>
>> a 32 bit CPU can address 4 billion bytes
>
> Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue, it has
> a 24bit address bus). I really haven't checked, but it's very possible to
> have a 32bit cpu address more than 4GB. the amount of directly addressable
> ram is controlled by the size of the address bus, and has nothing to do
> with 32, 64, or 128 bit cpu's.

The physical address space of a CPU is almost never identical to the
virtual address. The virtual address space is what the programmer sees, so
in a 32 bit architecture that's 4G and in 64 bit architecture it's
1.6*10^19. The physical address space is determined by the width of the
Address Translation Unit RAM and the address pins on the CPU. The physical
address space is a choice that the CPU designers make for each design.
Pins and RAM cost money so you don't want to support a physical address
space that's larger than the maximum amount of RAM that the particular CPU
is ever likely to have. When the 68000 came out the biggest DRAM was 64K,
the CPU designers would have figured that at the end of life of the chip
the biggest DRAM would be the 1M DRAM so they picked 16M as the physical
address space because it was confortably larger then any real memory
system that it would ever have to support without being excessively
expensive. When you get to the end of an architecture's life, as we are
now with the 32 bit x86 architecture, it becomes possible to have more
real memory then virtual memory. The way this is handled is that CPUs can
support multiple virtual address spaces, each of which can have it's own
DRAM space. So a Xeon might have 16 separate threads each of which can
address 4G of RAM for a total of 64G of real memory. Each thread is still
limited to 4G but you can have lots of them. There are also ways to give
programmers access to more memory by using segmentation registers which
allows the programmers to manage multiple virtual memory spaces within one
process, that's what the 80286 did to extend the 16 bit address space of
the 8086. Segmentation is a horrible way to handle memory, a larger linear
address space is much easier for programmers to deal with. The AMD64
architecture is now back to where we were in the 68K days. The virtual
address space is so large that all the RAMs in the world couldn't fill it.
The programmer sees the 64 bit space but the actual amount of physical RAM
supported is much smaller, I'm not sure what the exact size is but I
suspect it's around 40 bits (1 terabyte) which would be confortably larger
than the amount of RAM that this generation of chips is likely to have to
support (assuming 4G and maybe even 16G RAMs by the time the last current
generation A64s are unplugged).

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

Without getting complicated, you are always using the full CPU capability.
You are not using 1/2 a CPU to do the work. When the 64 bit CPU runs 32 bit
software, it will function as if it was a 32 bit unit.

I would only spend the extra amount if I was having the necessity of a 64
bit CPU. You will need the 64 bit operating system to take advantage of it
from an operating system point of view. If you are not running 64 bit
capable software's there will also not be any advantage. Very few software's
at this time are written in the 64 bit format.

If you are buying this for future investment, this is not a good idea from
the point of view, that next year or whatever, the 64 bit machines may be
different, and some other need will arise, still making your machine
obsolete in it own way.

Buy what you need for now to get your job done the way you require it to be
done. To some extent, you can do upgrades to the existing system as they are
required. When your system becomes too obsolete, in let's say about 3 years
from now, then it would be worth to start over again on a new system with
the same philosophy.

--

Jerry G.
======


<Jmonahan@ev1.net> wrote in message
news:qljsr05mpgh8mk8i3e3rlvs64ad7jghnhp@4ax.com...
I have a question about the line of true 64 bit processors. When they
are running 32 bit software, do they take the instructions, data,
etc. 2 blocks at a time or is there half of the cpu that is not
being used?? Where this is leading, is to the question is it better
to have a super hi speed 32 bit cpu and OC it, or is it better to
have a 64 bit cpu of less speed. Om that case would they be about
equal? In other words, is it worth it to buy a 64 bit cpu now, even
if it is only running 32 bit software and may still be doing that for
some time??

 

[chip]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

"Wes Newell" <w.newell@TAKEOUTverizon.net> wrote in message
newsan.2004.12.14.09.27.26.358422@TAKEOUTverizon.net...
> On Mon, 13 Dec 2004 23:52:45 -0500, General Schvantzkoph wrote:
>
>> 64 bits refers to the address size not to data sizes,
>
> Now that's a new one and I thought I'd heard them all. Actually, this
> is incorrect too though. The A64 address bus is 40bits, 48 virtual.
>
>> a 32 bit CPU can address 4 billion bytes
>
> Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue, it has
> a 24bit address bus). I really haven't checked, but it's very possible to
> have a 32bit cpu address more than 4GB. the amount of directly addressable
> ram is controlled by the size of the address bus, and has nothing to do
> with 32, 64, or 128 bit cpu's.

The view posted by General Whateverhisnameis may be incorrect, but its an
*incredibly* common misconception.

I can't count the number of articles I have read that was lyrical about the
benefits of 64-bit being the increased address space. Presumably the author
having no clue that it would be perfectly possible to have a 16-bit (let
alone 32-bit) processor with a 48-bit or 64-bit address bus.

Chip

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

> > Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue, it
has
> > a 24bit address bus). I really haven't checked, but it's very possible
to
> > have a 32bit cpu address more than 4GB. the amount of directly
addressable
> > ram is controlled by the size of the address bus, and has nothing to do
> > with 32, 64, or 128 bit cpu's.
>
> The view posted by General Whateverhisnameis may be incorrect, but its an
> *incredibly* common misconception.
>
> I can't count the number of articles I have read that was lyrical about
the
> benefits of 64-bit being the increased address space. Presumably the
author
> having no clue that it would be perfectly possible to have a 16-bit (let
> alone 32-bit) processor with a 48-bit or 64-bit address bus.

Here's what's going on: A 32-bit processer really can only address 4
gigabytes of memory in a single address space. There are hacks like PAE
that let you put more than 4 gigs in a machine, but a single process can
only see 4 gigs of memory. That's it, there's no way around it. If you
disagree, don't argue, try getting a single process to allocate more than 4
gigs on the OS of your choice on a 32-bit processer. Come back when you've
done it.

The A64/Opterons, being 64 bit processers, can address up to a 64-bit
memory address, which is unfathomably huge. However, I believe that they
currently have only a 48-bit memory bus, which is still a boat-load of
memory.

However, going from a 32-bit instruction set to a 64-bit instruction set
with all other items equal can (and does) incur a slight overhead, as you
have to pump more bits around to get the same things accomplished. It's
generally along the lines of 1%-3% real-world performance. However, in the
case of the A64/Opteron, all other items are NOT equal - in 64-bit mode, the
new instruction set allows you to utilize a larger number of registers,
which gives you a real-world performance BOOST of around 10% in most apps.

steve

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

Chip wrote:
> "Wes Newell" <w.newell@TAKEOUTverizon.net> wrote in message
>> On Mon, 13 Dec 2004 23:52:45 -0500, General Schvantzkoph wrote:
>>
>>> 64 bits refers to the address size not to data sizes,
>>
>> Now that's a new one and I thought I'd heard them all. Actually,
>> this is incorrect too though. The A64 address bus is 40bits, 48
>> virtual.
>>
>>> a 32 bit CPU can address 4 billion bytes
>>
>> Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue,
>> it has a 24bit address bus). I really haven't checked, but it's
>> very possible to have a 32bit cpu address more than 4GB. the
>> amount of directly addressable ram is controlled by the size of
>> the address bus, and has nothing to do with 32, 64, or 128 bit
>> cpu's.
>
> The view posted by General Whateverhisnameis may be incorrect, but
> its an *incredibly* common misconception.
>
> I can't count the number of articles I have read that was lyrical
> about the benefits of 64-bit being the increased address space.
> Presumably the author having no clue that it would be perfectly
> possible to have a 16-bit (let alone 32-bit) processor with a
> 48-bit or 64-bit address bus.

There are several factors here. First is the address field in the
actual instructions, which are very likely to be (or to become) 64
bits. Second is the address field in the physical i/o interface,
which is likely to be 32 bits, or capable of 4G of physical
memory. Third is the actual memory attached, which I will assume
to be the common 1G. These three quantities must be strictly
decreasing (or same) in the order I have given them.

The operating system will be the only thing actually aware of the
real physical limits. It will arrange to map all 64 bit addresses
(via tables) into one of: a) disk location b) real memory location
c) invalid. The hardware (or even the OS software) will arrange
that any access to b) is intercepted and converted into a), while
any c) is flagged as a gross error and something serious done about
it. At the same time it can map process specific virtual addresses
(in a known address space) into the larger physical address space,
giving the ability to write all programs as if they had a machine
to themselves.

The efficiency of this mapping is crucial to the apparent speed of
the system under load.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Tue, 14 Dec 2004 08:50:44 -0500, General Schvantzkoph wrote:

> On Tue, 14 Dec 2004 09:26:40 +0000, Wes Newell wrote:
>
>> On Mon, 13 Dec 2004 23:52:45 -0500, General Schvantzkoph wrote:
>>
>>> 64 bits refers to the address size not to data sizes,
>>
>> Now that's a new one and I thought I'd heard them all. Actually, this
>> is incorrect too though. The A64 address bus is 40bits, 48 virtual.
>>
>>> a 32 bit CPU can address 4 billion bytes
>>
>> Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue, it has
>> a 24bit address bus). I really haven't checked, but it's very possible to
>> have a 32bit cpu address more than 4GB. the amount of directly addressable
>> ram is controlled by the size of the address bus, and has nothing to do
>> with 32, 64, or 128 bit cpu's.
>
> The physical address space of a CPU is almost never identical to the
> virtual address. The virtual address space is what the programmer sees, so
> in a 32 bit architecture that's 4G and in 64 bit architecture it's
> 1.6*10^19. The physical address space is determined by the width of the
> Address Translation Unit RAM and the address pins on the CPU. The physical
> address space is a choice that the CPU designers make for each design.
> Pins and RAM cost money so you don't want to support a physical address
> space that's larger than the maximum amount of RAM that the particular CPU
> is ever likely to have. When the 68000 came out the biggest DRAM was 64K,
> the CPU designers would have figured that at the end of life of the chip
> the biggest DRAM would be the 1M DRAM so they picked 16M as the physical
> address space because it was confortably larger then any real memory
> system that it would ever have to support without being excessively
> expensive. When you get to the end of an architecture's life, as we are
> now with the 32 bit x86 architecture, it becomes possible to have more
> real memory then virtual memory. The way this is handled is that CPUs can
> support multiple virtual address spaces, each of which can have it's own
> DRAM space. So a Xeon might have 16 separate threads each of which can
> address 4G of RAM for a total of 64G of real memory. Each thread is still
> limited to 4G but you can have lots of them. There are also ways to give
> programmers access to more memory by using segmentation registers which
> allows the programmers to manage multiple virtual memory spaces within one
> process, that's what the 80286 did to extend the 16 bit address space of
> the 8086. Segmentation is a horrible way to handle memory, a larger linear
> address space is much easier for programmers to deal with. The AMD64
> architecture is now back to where we were in the 68K days. The virtual
> address space is so large that all the RAMs in the world couldn't fill it.
> The programmer sees the 64 bit space but the actual amount of physical RAM
> supported is much smaller, I'm not sure what the exact size is but I
> suspect it's around 40 bits (1 terabyte) which would be confortably larger
> than the amount of RAM that this generation of chips is likely to have to
> support (assuming 4G and maybe even 16G RAMs by the time the last current
> generation A64s are unplugged).

Aha, so now they consider the bitness of the cpu to be the maximum
possible address space within the architecture if you're sumize is
correct. I wonder who keeps changing the nomenclature. In the beginning it
was defined by the data bus size, then it changed to register size (I
think Intel was the first to do this, with the 8088). Motorola redefined
thier 16bit 68000 to calling it a 32bit later. And now we have a bitness
that virtually has nothing to do with anything speed wise, actual ram
address size or anything of any value. Next thing you know they'll be
adding up all the bus widths of the cpu and calling it an xxxx bit cpu.
Got to one up the competition.

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://mysite.verizon.net/res0exft/cpu.htm

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd (More info?)

Think of it like this. 32 bit like taking a half gallon container and
filling a larger container,64 bit is taking a 1 gallon container and filling
the same larger container. the 1 gallon container will take less trips. DOUG

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

> Aha, so now they consider the bitness of the cpu to be the maximum
> possible address space within the architecture if you're sumize is
> correct. I wonder who keeps changing the nomenclature. In the beginning
> it was defined by the data bus size, then it changed to register size (I
> think Intel was the first to do this, with the 8088). Motorola redefined
> thier 16bit 68000 to calling it a 32bit later. And now we have a bitness
> that virtually has nothing to do with anything speed wise, actual ram
> address size or anything of any value. Next thing you know they'll be
> adding up all the bus widths of the cpu and calling it an xxxx bit cpu.
> Got to one up the competition.

It's always been the virtual address space that defined the bitness of a
CPU architecture. I've been in the business for 30 years and I spent the
first half of my career designing CPUs. Some marketing types in the
early days of microprocessors may have used bus size to define the bitness
of a microprocessor but no computer architect ever did that. The problem
with using register width or bus width is that it isn't consistant even
within a single CPU. The floating point registers in a 16 bit minicomputer
were 64 bits wide, that didn't make the computer a 64 bit computer. The
same thing goes for the memory datapath. The 939 pin Athlon 64s have two
64 bit memory buses, does that make them a 128 bit processor? of course
not. By the same token as serial buses like PCI express and SATA replace
parallel buses does that make the machines 1 bit processors? It is true
that the integer registers generally are the same width as the address
because you use the integer registers to compute addresses in most
architectures. However it's not required, you could use a pair of
registers to hold an address pointer. You can also have specialized
registers that are used only for addresses and other registers that are
used for general purpose integer arithmetic. In fact the base x86
architecture does use a god awful collection of single purpose registers
rather than a uniform general purpose register set.

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd (More info?)

courseyauto@aol.com (Courseyauto) wrote in
news:20041214155637.00362.00001843@mb-m17.aol.com:

> Think of it like this. 32 bit like taking a half gallon
> container and filling a larger container,64 bit is taking a 1 gallon
> container and filling the same larger container. the 1 gallon
> container will take less trips. DOUG

But it's heavier and will tire you out faster. You'll probably end up with
tendonitus, too.

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd (More info?)

courseyauto@aol.com (Courseyauto) wrote in
news:20041214155637.00362.00001843@mb-m17.aol.com:

> Think of it like this. 32 bit like taking a half gallon
> container and filling a larger container,64 bit is taking a 1 gallon
> container and filling the same larger container. the 1 gallon
> container will take less trips. DOUG

>But it's heavier and will tire you out faster. You'll probably end up >with
>tendonitus, too.

Not if the larger container is a gallon....

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd (More info?)

courseyauto@aol.com (Courseyauto) wrote in
news:20041214183644.08215.00002022@mb-m05.aol.com:

> courseyauto@aol.com (Courseyauto) wrote in
> news:20041214155637.00362.00001843@mb-m17.aol.com:
>
>> Think of it like this. 32 bit like taking a half gallon
>> container and filling a larger container,64 bit is taking a 1 gallon
>> container and filling the same larger container. the 1 gallon
>> container will take less trips. DOUG
>
>>But it's heavier and will tire you out faster. You'll probably end up
>>>with tendonitus, too.
>
> Not if the larger container is a gallon....

64-bits is more than a gallon, however. And even if it weren't, it's well
known that many computer users have Gilligan arms.

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd (More info?)

courseyauto@aol.com (Courseyauto) wrote in
news:20041214183644.08215.00002022@mb-m05.aol.com:

> courseyauto@aol.com (Courseyauto) wrote in
> news:20041214155637.00362.00001843@mb-m17.aol.com:
>
>> Think of it like this. 32 bit like taking a half gallon
>> container and filling a larger container,64 bit is taking a 1 gallon
>> container and filling the same larger container. the 1 gallon
>> container will take less trips. DOUG
>
>>But it's heavier and will tire you out faster. You'll probably end up
>>>with tendonitus, too.
>
> Not if the larger container is a gallon....

>64-bits is more than a gallon, however. And even if it weren't, it's well
>known that many computer users have Gilligan arms.

I know,they are 4 liters.

 

[Ed]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Mon, 13 Dec 2004 20:31:43 -0600, Jmonahan@ev1.net wrote:

>I have a question about the line of true 64 bit processors. When they
>are running 32 bit software, do they take the instructions, data,
>etc. 2 blocks at a time or is there half of the cpu that is not
>being used?? Where this is leading, is to the question is it better
>to have a super hi speed 32 bit cpu and OC it, or is it better to
>have a 64 bit cpu of less speed. Om that case would they be about
>equal? In other words, is it worth it to buy a 64 bit cpu now, even
>if it is only running 32 bit software and may still be doing that for
>some time??


Opteron and Athlon64 processors are able to run both 64-bit and 32-bit
operating systems and code. Under a 32-bit operating system, including
Linux, Unix, Solaris x86 and Windows, these processors run 32-bit
applications at full speed and full power -- and in many cases, more
efficiently than other x86 processors. When they boot up with a 64-bit
OS, you can mix-and-match 64-bit and 32-bit applications and tools, both
running at full speed. So, 64-bit developers have a huge array of
software available to them, both in terms of the new 64-bit tools and
servers, but also the entire existing base of 32-bit apps. It's
literally the best of both worlds, up and down the stack.

http://www.devx.com/amd/Door/16009

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

Jmonahan@ev1.net wrote:

> I have a question about the line of true 64 bit processors. When they
> are running 32 bit software, do they take the instructions, data,
> etc. 2 blocks at a time or is there half of the cpu that is not
> being used?? Where this is leading, is to the question is it better
> to have a super hi speed 32 bit cpu and OC it, or is it better to
> have a 64 bit cpu of less speed. Om that case would they be about
> equal? In other words, is it worth it to buy a 64 bit cpu now, even
> if it is only running 32 bit software and may still be doing that for
> some time??

The new processor are backwards compatible instructions with earlier
versions of the architecture. New 64-bit instructions have been added.

So a 64-bit XOR and 16-bit XOR on am Athlon 64 take about the same number of
cpu cycles.


CPU pipelining works on the flow of instructions, and generally not their
width.

gtoomey

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

Lieber Herr Schwantzkopf,


> In fact the base x86
> architecture does use a god awful collection of single purpose registers
> rather than a uniform general purpose register set.

That has always puzzled me. Why in the heck did the micro designers take
that route?

(PS -- also thirty years in computer tech, started out, however, as a
mainframe maintenance tech, considerably lower than a CPU designer)

 

[chip]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

"Steve Wolfe" <unt@codon.com> wrote in message
news:328opkF3k439bU1@individual.net...
>> > Tell me why my 32bit 68000 cpu can only address 16MB then (1 clue, it
> has
>> > a 24bit address bus). I really haven't checked, but it's very possible
> to
>> > have a 32bit cpu address more than 4GB. the amount of directly
> addressable
>> > ram is controlled by the size of the address bus, and has nothing to do
>> > with 32, 64, or 128 bit cpu's.
>>
>> The view posted by General Whateverhisnameis may be incorrect, but its an
>> *incredibly* common misconception.
>>
>> I can't count the number of articles I have read that was lyrical about
> the
>> benefits of 64-bit being the increased address space. Presumably the
> author
>> having no clue that it would be perfectly possible to have a 16-bit (let
>> alone 32-bit) processor with a 48-bit or 64-bit address bus.
>
> Here's what's going on: A 32-bit processer really can only address 4
> gigabytes of memory in a single address space. There are hacks like PAE
> that let you put more than 4 gigs in a machine, but a single process can
> only see 4 gigs of memory. That's it, there's no way around it. If you
> disagree, don't argue, try getting a single process to allocate more than
> 4
> gigs on the OS of your choice on a 32-bit processer. Come back when
> you've
> done it.
>
> The A64/Opterons, being 64 bit processers, can address up to a 64-bit
> memory address, which is unfathomably huge. However, I believe that they
> currently have only a 48-bit memory bus, which is still a boat-load of
> memory.
>
> However, going from a 32-bit instruction set to a 64-bit instruction set
> with all other items equal can (and does) incur a slight overhead, as you
> have to pump more bits around to get the same things accomplished. It's
> generally along the lines of 1%-3% real-world performance. However, in
> the
> case of the A64/Opteron, all other items are NOT equal - in 64-bit mode,
> the
> new instruction set allows you to utilize a larger number of registers,
> which gives you a real-world performance BOOST of around 10% in most apps.

Whilst we are on the subject of performance - rather than debates about
address space and number of registers, width etc. - it might be worth
mentioning about the A64 having its memory controller onboard.

Since memory transfers are not being controlled by a separate Northbridge,
the overall latency is much reduced compared with the old XP architecture.
Net effect: Huge memory bandwidth improvement, which obviously boosts
performance considerably too. For example a Sisoft Ram bandwidth (Integer
Buffered iSSE2) score of 4000 is pretty damned fantastic with an Athlon XP.
6000 or more is a walk in the park for an A64. 7000 is fairly easy and 8000
is achievable. HUGE gains in bandwidth.

Chip

 

[chip]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

"General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message
newsan.2004.12.15.02.17.43.335375@yahoo.com...
>
> It's always been the virtual address space that defined the bitness of a
> CPU architecture.

That's just not correct. Motorola classified the 68000 as 16-bit
microprocessor, yet it had a 24 bit address bus. It had 8 32-bit data
registers and 8 32-bit address registers. By your logic it should have been
called a 32-bit CPU.

Chip

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

Jerry G. wrote:

> Very few
> software's at this time are written in the 64 bit format.
>

Linux & some BDSs have been running 64 bit for years eg MIPS.
There are 64 bit builds of linux for Athlon 64.

gtoomey

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

"Aardvark J. Bandersnatch, BLT, MP, PBJ, LSMFT" wrote:
>
>> In fact the base x86 architecture does use a god awful collection
>> of single purpose registers rather than a uniform general purpose
>> register set.
>
> That has always puzzled me. Why in the heck did the micro designers
> take that route?

It started with the 8008, which had 7 8 bit registers designated a,
b, c, d, e, h, l. h and l were manipulated only as 8 bits each,
but the combination could be used to address up to a glorious 16k
of external memory. Note that hl pair, introducing register
specialization. Addressing was via a 3 bit field, which could
specify the 7 registers and the indirect via hl address, known as
m. 1/4 of the instructions simply moved data from one register to
another. Arithmetic was done with the a register (accumulator)
implied, which is also a register specialization.

The architecture was continued, for marketing and familiarity
reasons, into the 8080, which added a flags register (8 bit), an sp
register (16 bit) for stack, and instructions to combine the bc,
de, and hl registers into 16 bits and do arithmetic with them.
This was a real computer with 16 bits and an 8 bit path to external
memory. The whole personal computer explosion was really based on
this chip. Now the sp register joined the hl register as
specialized. A set of 16 bit arithmetic instructions was added
using the hl register as the 16 bit accumulator. The 6502 was
competition, and the Z80 was an enhancement (the z80 added more
specialized registers). Other chips had little influence.

The next step was the 8086 (and its 8 bit bussing clone, the
8088). Again, the register architecture was continued, with added
specialized registers and usages. The bc pair became the counting
register for string operations. The si and di indexing registers
(special purpose) were added. The bp (base register for stack
scopes) was added, all specialized. Also the various segment
registers. The adaptations kept the actual code size short yet
greatly expanded the addressing capabilities.

Other major steps were to the 80286 (not really significant) and
the 80386, which is the architectural base of most PC class
machines today.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

 

[Guest]

Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.hardware (More info?)

On Wed, 15 Dec 2004 17:52:04 +0000, VWWall wrote:

> The Z-80 had some features that had to be used by writing ASM code with
> "DB" calls. Adam Osbourne was the only one to offer it in machine.

Radio Shack TRS-80 users would probably disagree with this.

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://mysite.verizon.net/res0exft/cpu.htm