Can we install a VM to support 6 GB memory on a 32-bit machine?
Basically we want to install 3 VM's running linux sharing the 6 GM
memory. At the first glance it seems not possible. Do we need a 64-bit
processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
since we will be running Java on the VM's do we need 64-bit Java
compiler as well?

Thanks for your help

At Thu, 19 Jun 2008 06:50:55 -0700 (PDT) "soup_or_power@yahoo.com" <soup_or_power@yahoo.com> wrote:

> 
> Can we install a VM to support 6 GB memory on a 32-bit machine?
> Basically we want to install 3 VM's running linux sharing the 6 GM
> memory. At the first glance it seems not possible. Do we need a 64-bit
> processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
> since we will be running Java on the VM's do we need 64-bit Java
> compiler as well?

I really doubt that you can run a 64-bit VM on a 32-bit machine.

If the Java application needs a 64-bit address space, then yes, you
need a 64-bit Java run-time.

> 
> Thanks for your help
>                                                                                                  

-- 
Robert Heller             -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software        -- Linux Installation and Administration
http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
heller@deepsoft.com       -- Contract Programming: C/C++, Tcl/Tk
     

On Thu, 19 Jun 2008 06:50:55 -0700, soup_or_power@yahoo.com wrote:

> Can we install a VM to support 6 GB memory on a 32-bit machine?
> Basically we want to install 3 VM's running linux sharing the 6 GM
> memory. At the first glance it seems not possible. Do we need a 64-bit
> processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also since
> we will be running Java on the VM's do we need 64-bit Java compiler as
> well?
> 
> Thanks for your help

You need a 64 bit machine to run a 64 bit OS even in a VM. A 32 bit 
machine can support 6G of RAM but each thread is limited to 3G so it 
would certainly possible to run three 2G VMs on a 32 bit system. However 
the 32 bit processors lacked hardware support for VMs so performance of 
three VMs will suffer. The Core2 Intel and socket AM2 AMD processors have 
hardware VM support so you should probably get a new system for that 
alone.

Your choice of Virtualizers depends on how your virtual IO requirements 
and if you need a virtual desktop. The free version of VMware, VMware 
Server, has no support for shared folders (i.e. the ability to mount a 
host directory in the VM), so the only way to access the host's file 
system is through NFS. The performance of NFS on VMware sucks so if you 
are doing a lot of disk IO to the host you don't want to use VMware 
Server. If you are doing all of your disk IO to the virtual disk then the 
performance is quite good and Server works fine. VMware Workstation is 
nearly identical to VMware Server but with the addition of Shared 
Folders. Shared Folders fixes the virtual IO problem so if you want to 
access the host's disks you should used VMware Workstation ($189). 
Workstation and VMware Server 2.0 (which is still beta) support 8G of 
RAM, VMware Server 1.0.6 (the production version of Server) only supports 
3.6G of RAM. The console performance of the VMware products is excellent 
so if you need a virtual desktop you will want a VMware product. VMware 
works with or without hardware support, but faster if you have hardware 
support.

Another option is KVM (Kernel Virtual Machine) which is built into the 
Linux kernel. You will want a very recent distro for this like Fedora 9. 
KVM lacks shared folders and it's NFS performance is truly awful, twice 
as slow as VMware, but it's performance if you are only accessing the 
virtual disk is almost the same as native. The virtual console on KVM is 
also awful, it's very nearly unusable. However if you are running a 
server you don't need a virtual desktop so the bad console performance 
won't matter. KVM requires hardware support so you will need a Core2 or 
newer A64/Opteron to use it.

I haven't bothered to benchmark VirtualBox for a couple of reasons. The 
most important is that it's limited to 2G which is inadequate for my 
purposes. The second is that getting networking to work is really 
painful. Networking works out of the box on VMware and KVM. VMware is the 
most flexible, it allows you to have bridged, NAT or host only networking 
or any combination. You can also easily specify the IPs of the subnets 
and you can have multiple nets. KVM is NAT out of the box, if you are 
happy with that it's fine. VirtualBox requires that you create a bridge 
on the host and do a lot of manual configuration. A VirtualBox VM can 
access the outside world out of the box, but the external world can't 
access the VirtualBox VM without doing a lot of hand configuration. 
VirtualBox does have Shared Folders and it has a very nice GUI and good 
console performance.

Here are some benchmarks that I ran over the last few days. I was running 
an NCVerilog regression which does a fair about of IO. As you can see as 
long as you are using a virtual disk the performance is excellent on both 
VMware and KVM. If access the host disk then only VMware Workstation has 
good performance. 

Native				06:34
VM Server 2, virtual disk	08:05
VM Server 2, NFS		18:37
VM Workstation, shared folder	08:14
KVM, Virtual disk		07:42
KVM, NFS			38:36

On Thu, 19 Jun 2008 06:50:55 -0700 (PDT), "soup_or_power@yahoo.com"
<soup_or_power@yahoo.com> wrote, quoted or indirectly quoted someone
who said :

>Can we install a VM to support 6 GB memory on a 32-bit machine?
>Basically we want to install 3 VM's running linux sharing the 6 GM
>memory. At the first glance it seems not possible. Do we need a 64-bit
>processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
>since we will be running Java on the VM's do we need 64-bit Java
>compiler as well?
 
Any desktop you buy today will have a 64 bit processor, even if it
runs most of the time a 32-bit OS.

You don't need an Itanium, PowerPC or something fancy. Just an
ordinary AMD will do.  The limit will be how much RAM your motherboard
can hold. A low end motherboard won't give you enough RAM to make
64-bit worth the candle.


You do need a 64-bit OS though.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Thu, 19 Jun 2008 06:50:55 -0700 (PDT), "soup_or_power@yahoo.com"
<soup_or_power@yahoo.com> wrote, quoted or indirectly quoted someone
who said :

>Can we install a VM to support 6 GB memory on a 32-bit machine?
>Basically we want to install 3 VM's running linux sharing the 6 GM
>memory. At the first glance it seems not possible. Do we need a 64-bit
>processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
>since we will be running Java on the VM's do we need 64-bit Java
>compiler as well?

see http://mindprod.com/bgloss/sixtyfourbit.html
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

> A low end motherboard won't give you enough RAM to make 64-bit worth the
> candle.

Not true, the latest P45 motherboards can support 16G and the older Core2 
and A64 DDR2 motherboards can all support at least 8G (I don't know if 
there is an actual limit in the P35 chipset or if they simply haven't 
tested the motherboards with 16G).

At today's prices there is no reason not to get 8G of DDR2, 8G of 
DDR2-800 memory is $170 on NewEgg. 16G is still very pricey, a 4G DIMM is 
$270 so it will cost you nearly $1100 to put 16G into a machine, that's 
actually very reasonable in real terms but it seems expensive when you 
compare it to the price of 2G DIMMs. 64bit Linux is a little faster than 
32 bit Linux so there is really no reason to use 32 bit Linux on any 
64bit capable machine. Windows user are in a different boat, they either 
have to use the execrable Vista or live with the 3.6G  memory limit in 
XP. However the OP was asking about Virtual machines so he will be using 
a Linux host anyway. Even if he needs Windows VMs he would still be 
better off running them on a 64 bit Linux host.

On Fri, 20 Jun 2008 11:06:21 -0500, General Schvantzkopf
<schvantzkopf@yahoo.com> wrote, quoted or indirectly quoted someone
who said :

>Not true, the latest P45 motherboards can support 16G and the older Core2 
>and A64 DDR2 motherboards can all support at least 8G (I don't know if 
>there is an actual limit in the P35 chipset or if they simply haven't 
>tested the motherboards with 16G).

I figure you need 4+ gig to make 64 bit pay.  I wanted to warn people
against buying a 2gig motherboard and then hoping to go 64-bit. 

I googled and had a look at some low end motherboard/cpus:

http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=3440252&Sku=MBM-A13G-3500
$97 max 2 gig

http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=3799143&sku=MBM-K8M800-4400
$122 max 2 gig

http://motherboards.bizrate.com/motherboards/gigabyte-ga-g31m-s2l-micro-atx-motherboard--pid719310883/#details
$60 max 4 gif (no cpu)

http://motherboards.bizrate.com/motherboards/intel-dg31pr-micro-atx-motherboard--pid625085355/compareprices__rf--mot006.html
$65 max 4 gig (no cpu)

http://motherboards.bizrate.com/motherboards/asus-p5k-se-epu-atx-intel-motherboard--pid752966283/compareprices__rf--mot006.html
$90  max 8 gig (no cpu)

-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

General Schvantzkopf wrote:
>> A low end motherboard won't give you enough RAM to make 64-bit worth the
>> candle.
> 
> Not true, the latest P45 motherboards can support 16G and the older Core2 
> and A64 DDR2 motherboards can all support at least 8G (I don't know if 
> there is an actual limit in the P35 chipset or if they simply haven't 
> tested the motherboards with 16G).

I don't think I will call those for low end motherboards.

                                  64bit Linux is a little faster than
> 32 bit Linux so there is really no reason to use 32 bit Linux on any 
> 64bit capable machine. Windows user are in a different boat, they either 
> have to use the execrable Vista or live with the 3.6G  memory limit in 
> XP.

Wrong.

XP, 2003 and 2008 also comes in 64 bit versions.

>     However the OP was asking about Virtual machines so he will be using 
> a Linux host anyway. Even if he needs Windows VMs he would still be 
> better off running them on a 64 bit Linux host.

Both VMWare and MS delivers virtualization software for Windows. If one
prefer Windows no need to not chose it.

Arne

Roedy Green wrote:
> On Thu, 19 Jun 2008 06:50:55 -0700 (PDT), "soup_or_power@yahoo.com"
> <soup_or_power@yahoo.com> wrote, quoted or indirectly quoted someone
> who said :
>> Can we install a VM to support 6 GB memory on a 32-bit machine?
>> Basically we want to install 3 VM's running linux sharing the 6 GM
>> memory. At the first glance it seems not possible. Do we need a 64-bit
>> processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
>> since we will be running Java on the VM's do we need 64-bit Java
>> compiler as well?
> 
> see http://mindprod.com/bgloss/sixtyfourbit.html

#Thus they can handle numbers up to 9,223,372,036,854,775,807 as a
#single chunk.

64 bit means 64 bit virtual addresses not 64 bit integers.

#Computer programs can be up to 9 million gigabytes long

I assume you are trying to tell that the virtual address space
is 9 million GB. Which is wrong. The potential max of virtual
address space is 16 EB (16 billion GB). Current implementations
are limited to 256 TB (256000 GB).

[I assume x86-64]

[I am ignoring the 1024 versus 1000 issue]

#Low-end CPUs may not be particularly fast in 64-bit mode.

Unless slowed down by lack of memory because 64 bit requires more
memory, then 64 bit apps will always be faster due to more registers
and new FP instructions. Low end or not low end.

#Many dual Xeon boards are limited to 8 gigabytes total

I doubt that is still the case today.

#The architecture features 64 general purpose registers (vs only 8 in 32
#bit mode)

No - only 16 GP registers in x86-64.

#Because of AMD�s success with this instruction set, and the slow
#Itanium sales, Intel implemented AMD64 too, renaming it Intel-64

Intel has used multiple names for its 64 bit: IA-32e, EMT64T and
Intel64. I think the last one is confusing because Itanium is
called IA-64.

Arne

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:485c4a09$0$90265$14726298@news.sunsite.dk...

<snip>

> XP, 2003 and 2008 also comes in 64 bit versions.

FWIW, we use 64-bit JVM on 64-bit Windows Server 2003 on Dell  Xeon 
4-processor dual-core duo (16 processors) and 32GB ram for high-performance 
(compute-bound) simulation.  No special config is needed and we get great 
performance.   We plan to test under linux eventually but currently some of 
our component models require Windows.

Matthew Humphrey http://www.iviz.com/

In comp.os.linux.misc General Schvantzkopf <schvantzkopf@yahoo.com> wrote:
> 
> 64bit capable machine. Windows user are in a different boat, they either 
> have to use the execrable Vista or live with the 3.6G  memory limit in 
> XP. However the OP was asking about Virtual machines so he will be using 

Huh? Have been using 64-bit XP for a long time now- no mem limit I am aware of.

Stan
-- 
Stan Bischof ("stan" at the below domain)
www.worldbadminton.com 

stan@worldbadminton.com wrote:
> In comp.os.linux.misc General Schvantzkopf <schvantzkopf@yahoo.com> wrote:
>> 64bit capable machine. Windows user are in a different boat, they either 
>> have to use the execrable Vista or live with the 3.6G  memory limit in 
>> XP. However the OP was asking about Virtual machines so he will be using 
> 
> Huh? Have been using 64-bit XP for a long time now- no mem limit I am aware of.

They were referring to the memory limit of 32-bit XP.

-- 
Lew

On Jun 19, 3:50=A0pm, "soup_or_po...@yahoo.com"
<soup_or_po...@yahoo.com> wrote:
> Can we install a VM to support 6 GB memory on a 32-bit machine?
> Basically we want to install 3 VM's running linux sharing the 6 GM
> memory. At the first glance it seems not possible. Do we need a 64-bit
> processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
> since we will be running Java on the VM's do we need 64-bit Java
> compiler as well?
>
> Thanks for your help

32-bit Linux can support more than 4GB of memory if you use the
correct options when build the kernel.
The 'server' build of most distributions usually support this option.
You will then be able to run 3 JVM instances each using 2GB.

On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>64 bit means 64 bit virtual addresses not 64 bit integers.

64-bit registers, 64-bit addresses and 64-bit operands usually all go
together.  Can you think of any exceptions?


-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-531578214-1214254561=:26228
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 23 Jun 2008, Roedy Green wrote:

> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> 64 bit means 64 bit virtual addresses not 64 bit integers.
>
> 64-bit registers, 64-bit addresses and 64-bit operands usually all go 
> together.  Can you think of any exceptions?

The Atari Jaguar. 64-bit registers, 24-bit addresses and 32-bit operands!

Well, sort of. The CPU was a Motorola 68000, which is a 32-bit chip with 
24 address pins and an instruction set that's still slanted towards 16-bit 
operations. The graphics, memory control and sound chips were clean 
32-bit. The data bus was 64-bit. The interesting bit was the blitter and 
'object processor', both of which were somewhat specialised chips designed 
for shunting data around and doing repetitive operations of limited 
complexity to it - but doing them incredibly fast. They were 64-bit.

You might say that since the 68k CPU was 32-bit, the machine was 32-bit, 
but the idea was that the 68k was just there to boot the system, 
initialise the other chips, manage controller input, etc, and that the 
real heart of the system was the custom chipset, which would execute all 
the real logic - the 68k was a sort of management chip, not a CPU. 
However, according to my very superficial understanding of the Jaguar's 
history, game programmers did use the 68k for game logic, and used the 
custom chips purely for graphics.

In any case, the only other chip which could really have been considered 
the primary element was the GPU, which was a general-purpose RISC chip 
with some graphics-specific extensions, but that was only 32 bit anyway. 
So, it was more of a 32-bit machine with a 64-bit bus and some 64-bit 
graphics chips.

If i can change the numbers a bit, all the 8-bit processors had 16-bit 
address spaces. Some 16-bit machines had >16-bit address spaces too, like 
all that segment register madness on the early x86 chips.

tom

-- 
I hate to advocate drugs, alcohol, violence, or insanity to anyone,
but they've always worked for me. -- Hunter S. Thompson
---910079544-531578214-1214254561=:26228--

On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>I assume you are trying to tell that the virtual address space
>is 9 million GB. Which is wrong. The potential max of virtual
>address space is 16 EB (16 billion GB)

Often you can't always  use all 64 bits for addressing, but if you
did, that would give you addresses 0 .. 2^64-1
i..e 0.. 18,446,744,073,709,551,615

We have the problem of binary and decimal gigabytes. The article
http://mindprod.com/ggloss/sixtyfourbit.html is in the Buyer's
Glossary, not the Java glossary, so it is not aimed at programmers.  I
thought it thus best to stick to decimal.  It does not really matter.
The point I am trying to make is the addressing limit is well beyond
what you could afford in real ram.

A decimal gigabyte is 10^9, so that would make it the addressability
18,446,744 gb (twice the 9 million gb I used presuming the sign bit
bit of addressing would be chewed up by housekeeping.)

How did you get your number 16 billion GB. ? three orders of magnitude
bigger?

I presume the 16-18 difference comes from you using binary gigabytes.

To sort out the confusion, NIST has devised new prefixes when you mean
binary.
see http://physics.nist.gov/cuu/Units/binary.html
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> 64 bit means 64 bit virtual addresses not 64 bit integers.
> 
> 64-bit registers, 64-bit addresses and 64-bit operands usually all go
> together.  Can you think of any exceptions?

Yes.

The VAX instruction set supports 64 bit operands in ASHQ, CLRQ, EDIV,
EMUL and MOVQ instructions.

x86 has the CDQ instruction that has a 64 bit operand.

The original CDC Cyber used 18 bit addresses (word not byte), but
had 60 bit registers for arithmetic.

If we go really way back then IBM, DEC, Univac and GE all made
computers with 36 bit registers and 18 bit addresses (word again).


Arne

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> I assume you are trying to tell that the virtual address space
>> is 9 million GB. Which is wrong. The potential max of virtual
>> address space is 16 EB (16 billion GB)
> 
> Often you can't always  use all 64 bits for addressing, but if you
> did, that would give you addresses 0 .. 2^64-1
> i..e 0.. 18,446,744,073,709,551,615
> 
> We have the problem of binary and decimal gigabytes. The article
> http://mindprod.com/ggloss/sixtyfourbit.html is in the Buyer's
> Glossary, not the Java glossary, so it is not aimed at programmers.  I
> thought it thus best to stick to decimal.  It does not really matter.
> The point I am trying to make is the addressing limit is well beyond
> what you could afford in real ram.
> 
> A decimal gigabyte is 10^9, so that would make it the addressability
> 18,446,744 gb (twice the 9 million gb I used presuming the sign bit
> bit of addressing would be chewed up by housekeeping.)
> 
> How did you get your number 16 billion GB. ? three orders of magnitude
> bigger?
> 
> I presume the 16-18 difference comes from you using binary gigabytes.
> 
> To sort out the confusion, NIST has devised new prefixes when you mean
> binary.
> see http://physics.nist.gov/cuu/Units/binary.html

The post you replied to contained the following (that you did not
quote):

#[I am ignoring the 1024 versus 1000 issue]

Is that statement unclear ????

Arne

Tom Anderson wrote:
> On Mon, 23 Jun 2008, Roedy Green wrote:
> 
>> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> 64 bit means 64 bit virtual addresses not 64 bit integers.
>>
>> 64-bit registers, 64-bit addresses and 64-bit operands usually all go 
>> together.  Can you think of any exceptions?
> 
> The Atari Jaguar. 64-bit registers, 24-bit addresses and 32-bit operands!

I think Roedy was asking for extant, relevant examples.

-- 
Lew

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
> 
>> I assume you are trying to tell that the virtual address space
>> is 9 million GB. Which is wrong. The potential max of virtual
>> address space is 16 EB (16 billion GB)
> 
> Often you can't always  use all 64 bits for addressing, but if you
> did, that would give you addresses 0 .. 2^64-1
> i..e 0.. 18,446,744,073,709,551,615

Didn't check this exactly, but it looks reasonable. If we estimate
2^10 as 1000 decimal then 2^60 becomes 1000^6 or 10^18. And 2^64
will then be 16 * 10^18.

[ snip ]

> A decimal gigabyte is 10^9, so that would make it the addressability
> 18,446,744 gb (twice the 9 million gb I used presuming the sign bit
> bit of addressing would be chewed up by housekeeping.)

(18 * 10^18) / (10^9) = 18 * 10^9.
If you just strip the last _nine_ digits of 18,446,744,073,709,551,615
-like you suggest to be doing above- you'll get 18,446,744,073 gb.

> How did you get your number 16 billion GB. ? three orders of magnitude
> bigger?

Just by counting the digits I suppose.


Regards,

Kees.

-- 
Kees Theunissen.

Arne Vajh�j wrote:
> Roedy Green wrote:
>> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
>> wrote, quoted or indirectly quoted someone who said :
>>> I assume you are trying to tell that the virtual address space
>>> is 9 million GB. Which is wrong. The potential max of virtual
>>> address space is 16 EB (16 billion GB)
>>
>> Often you can't always  use all 64 bits for addressing, but if you
>> did, that would give you addresses 0 .. 2^64-1
>> i..e 0.. 18,446,744,073,709,551,615
>>
>> We have the problem of binary and decimal gigabytes. The article
>> http://mindprod.com/ggloss/sixtyfourbit.html is in the Buyer's
>> Glossary, not the Java glossary, so it is not aimed at programmers.  I
>> thought it thus best to stick to decimal.  It does not really matter.
>> The point I am trying to make is the addressing limit is well beyond
>> what you could afford in real ram.
>>
>> A decimal gigabyte is 10^9, so that would make it the addressability
>> 18,446,744 gb (twice the 9 million gb I used presuming the sign bit
>> bit of addressing would be chewed up by housekeeping.)
>>
>> How did you get your number 16 billion GB. ? three orders of magnitude
>> bigger?
>>
>> I presume the 16-18 difference comes from you using binary gigabytes.
>>
>> To sort out the confusion, NIST has devised new prefixes when you mean
>> binary.
>> see http://physics.nist.gov/cuu/Units/binary.html
> 
> The post you replied to contained the following (that you did not
> quote):
> 
> #[I am ignoring the 1024 versus 1000 issue]
> 
> Is that statement unclear ????

Oh and:

18,446,744,073,709,551,616 / 10^9 is *not* 18,446,744 !

It *is* billion not million !!

Arne

On Mon, 23 Jun 2008 20:19:12 -0400, Lew <lew@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>> 
>> The Atari Jaguar. 64-bit registers, 24-bit addresses and 32-bit operands!
>
>I think Roedy was asking for extant, relevant examples.

That's fair.  We were discussing the definition of "64-bit".  You need
the exceptions to hammer out an air-tight definition.

One that might boggle the mind is my old LGP-30 computer that had 0
RAM, but a rotating magnetic drum.

It had one 32-bit register.  The store was 32 bits, but the low order
bit had to be 0, and in practice the low order 2 bits were not used.
Addresses were 16 bits wide, with word addressibility.  I have
referred to it as a 31.5 bit computer.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Mon, 23 Jun 2008 21:25:32 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>18,446,744,073,709,551,616 / 10^9 is *not* 18,446,744 !
>
>It *is* billion not million !!

I chopped off 9 digits on two different occasions and rechecked.  Oh
dear.  Wetware is failing badly.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Mon, 23 Jun 2008 20:01:57 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>#[I am ignoring the 1024 versus 1000 issue]
>
>Is that statement unclear ????

I felt the discrepancy needed clarification.  

I run into this all the time. Whenever A says something that agrees
with what B says, restates what B says, or elaborates what B says,  or
asks for confirmation of an interpretation of what B said, then B
complains, as if the general assumption is that every statement in a
newsgroup must necessarily be a refutation of some previous poster.

I find this amusing given the ostensible purpose of debate is to
persuade others to agree with you. 
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :



>> see http://mindprod.com/bgloss/sixtyfourbit.html

Please have a second look at the entry. I have updated it based on
your feedback.

>
>#Thus they can handle numbers up to 9,223,372,036,854,775,807 as a
>#single chunk.
>
>64 bit means 64 bit virtual addresses not 64 bit integers.
>
>#Computer programs can be up to 9 million gigabytes long
>
>I assume you are trying to tell that the virtual address space
>is 9 million GB. Which is wrong. The potential max of virtual
>address space is 16 EB (16 billion GB). Current implementations
>are limited to 256 TB (256000 GB).
>
>[I assume x86-64]
>
>[I am ignoring the 1024 versus 1000 issue]
>
>#Low-end CPUs may not be particularly fast in 64-bit mode.
>
>Unless slowed down by lack of memory because 64 bit requires more
>memory, then 64 bit apps will always be faster due to more registers
>and new FP instructions. Low end or not low end.
>
>#Many dual Xeon boards are limited to 8 gigabytes total
>
>I doubt that is still the case today.
>
>#The architecture features 64 general purpose registers (vs only 8 in 32
>#bit mode)
>
>No - only 16 GP registers in x86-64.
>
>#Because of AMD�s success with this instruction set, and the slow
>#Itanium sales, Intel implemented AMD64 too, renaming it Intel-64
>
>Intel has used multiple names for its 64 bit: IA-32e, EMT64T and
>Intel64. I think the last one is confusing because Itanium is
>called IA-64.
>
>Arne
>
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On 06/23/2008 03:41 PM, Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
> 
>> 64 bit means 64 bit virtual addresses not 64 bit integers.
> 
> 64-bit registers, 64-bit addresses and 64-bit operands usually all go
> together.  Can you think of any exceptions?

Intel i860? 32-bit ALU, 64-bit FPU

PS2 Emotion engine is another possibility.  It has mixed 64-bit and
32-bit engines, 128-bit registers, and operates on 32-bit values.

Roedy Green <see_website@mindprod.com.invalid> wrote:

>One that might boggle the mind is my old LGP-30 computer that had 0
>RAM, but a rotating magnetic drum.
>
>It had one 32-bit register.
Please, let's not do the computer equivalent of "The Four Yorkshire
Men" <http://www.youtube.com/watch?v=GqNGhcdtMbc> again.

Since I have recently complained about irrelevant YouTube links I
should add that the link is to a Monty Python skit about how happy but
poor the men were in the good old days.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1721684216-1214329977=:32679
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 24 Jun 2008, Roedy Green wrote:

> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>>> see http://mindprod.com/bgloss/sixtyfourbit.html
>
> Please have a second look at the entry. I have updated it based on
> your feedback.
>
>> #Low-end CPUs may not be particularly fast in 64-bit mode.
>>
>> Unless slowed down by lack of memory because 64 bit requires more
>> memory, then 64 bit apps will always be faster due to more registers
>> and new FP instructions. Low end or not low end.

"If you added sufficient RAM to your 64-bit system to compensate, it would 
run faster mainly because the newer 64-bit architectures have 8 times as 
many high speed registers."

Whoaaa nelly. No.

Firstly, about the number of registers. The x86-64 architecture has more 
registers than the x86. But architectures don't execute code - processors 
do. And for a long time now, we've had a thing called register renaming, 
which goes along with out-of-order and superscalar execution, which means 
that the number of registers on the processor, physical registers, can 
exceed the number of architectural registers. The x86-32 architecture may 
only have 8 registers, but, for instance, the Pentium 4 Netburst design 
has 128 physical registers.

I don't know if there's a correlation between the number of architectural 
registers, and the number of physical registers you can use effectively. 
If there is, then a register-rich 64-bit architecture could have even more 
physical registers, and your point might still be valid.

However, there's another point. You're bang on about 64-bit machines 
having bigger pointers (and possibly integers), and so data structures 
using more memory. But this doesn't just affect the amount of memory a 
structure uses, it affects the bandwidth it takes to move it in from 
memory, and the amount of space it takes up in the cache. If you're 
walking a linked list, for instance, then you need to load one pointer per 
link; with an 8 GB/s memory interface, that's 2 billion links per second 
on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, if a link 
object comprises a two-word object header and two one-word pointer fields, 
then 4 MB of cache will hold a quarter of a million links on a 32-bit 
machine, but only 128 thousand on a 64-bit.

So, if you're adding things to your machine to compensate for the 
64-bitness, it needs to be not just RAM, but cache and bus bandwidth. I 
don't believe that either of those things are limited by the width of a 
register - 32-bit machines routinely have >32-bit buses already, and cache 
size is limited by the size of the processor die and the process 
technology - so i don't think 64-bit machines have any intrinsic advantage 
here.

tom

-- 
Curse me, God, for making you this way!
---910079544-1721684216-1214329977=:32679--

Tom Anderson wrote:
> However, there's another point. You're bang on about 64-bit machines
> having bigger pointers (and possibly integers), and so data structures
> using more memory. But this doesn't just affect the amount of memory a
> structure uses, it affects the bandwidth it takes to move it in from
> memory, and the amount of space it takes up in the cache. If you're
> walking a linked list, for instance, then you need to load one pointer per
> link; with an 8 GB/s memory interface, that's 2 billion links per second
> on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, if a link
> object comprises a two-word object header and two one-word pointer fields,
> then 4 MB of cache will hold a quarter of a million links on a 32-bit
> machine, but only 128 thousand on a 64-bit.

Mitigating that factor, one 64-bit quantity might hold that two-word
object header, and thus not inflate the memory requirement for that
piece.

It's all accordin'.

--
Lew

Roedy Green wrote:
> On Mon, 23 Jun 2008 20:01:57 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> #[I am ignoring the 1024 versus 1000 issue]
>>
>> Is that statement unclear ????
> 
> I felt the discrepancy needed clarification.  
> 
> I run into this all the time. Whenever A says something that agrees
> with what B says, restates what B says, or elaborates what B says,  or
> asks for confirmation of an interpretation of what B said, then B
> complains, as if the general assumption is that every statement in a
> newsgroup must necessarily be a refutation of some previous poster.
> 
> I find this amusing given the ostensible purpose of debate is to
> persuade others to agree with you. 

I do not have a problem with clarifications.

But I find it rather confusing when you use "I presume ..."
and then you list something that is explicit in the text
you are replying to.

If you use "To clarify ..." then people will be less confused.

Arne

Tom Anderson wrote:
> "If you added sufficient RAM to your 64-bit system to compensate, it 
> would run faster mainly because the newer 64-bit architectures have 8 
> times as many high speed registers."
> 
> Whoaaa nelly. No.
> 
> Firstly, about the number of registers. The x86-64 architecture has more 
> registers than the x86. But architectures don't execute code - 
> processors do. And for a long time now, we've had a thing called 
> register renaming, which goes along with out-of-order and superscalar 
> execution, which means that the number of registers on the processor, 
> physical registers, can exceed the number of architectural registers. 
> The x86-32 architecture may only have 8 registers, but, for instance, 
> the Pentium 4 Netburst design has 128 physical registers.

It does not matter (for the point under discussion).

The compiler (JIT if Java) can only use the architectural registers. And
the CPU can only map architectural registers to physical registers - it
can not memory addresses to physical registers.

> However, there's another point. You're bang on about 64-bit machines 
> having bigger pointers (and possibly integers), and so data structures 
> using more memory. But this doesn't just affect the amount of memory a 
> structure uses, it affects the bandwidth it takes to move it in from 
> memory, and the amount of space it takes up in the cache. If you're 
> walking a linked list, for instance, then you need to load one pointer 
> per link; with an 8 GB/s memory interface, that's 2 billion links per 
> second on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, 
> if a link object comprises a two-word object header and two one-word 
> pointer fields, then 4 MB of cache will hold a quarter of a million 
> links on a 32-bit machine, but only 128 thousand on a 64-bit.
> 
> So, if you're adding things to your machine to compensate for the 
> 64-bitness, it needs to be not just RAM, but cache and bus bandwidth. I 
> don't believe that either of those things are limited by the width of a 
> register - 32-bit machines routinely have >32-bit buses already, and 
> cache size is limited by the size of the processor die and the process 
> technology - so i don't think 64-bit machines have any intrinsic 
> advantage here.

They do have a small one.

http://www.digit-life.com/articles2/cpu/insidespeccpu2000-part-m.html

measured it to 1.6% to 3.8% for SPECint2000 benchmark.

Arne

Arne Vajh�j wrote:
> Tom Anderson wrote:
>> "If you added sufficient RAM to your 64-bit system to compensate, it 
>> would run faster mainly because the newer 64-bit architectures have 8 
>> times as many high speed registers."
>>
>> Whoaaa nelly. No.
>>
>> Firstly, about the number of registers. The x86-64 architecture has 
>> more registers than the x86. But architectures don't execute code - 
>> processors do. And for a long time now, we've had a thing called 
>> register renaming, which goes along with out-of-order and superscalar 
>> execution, which means that the number of registers on the processor, 
>> physical registers, can exceed the number of architectural registers. 
>> The x86-32 architecture may only have 8 registers, but, for instance, 
>> the Pentium 4 Netburst design has 128 physical registers.
> 
> It does not matter (for the point under discussion).
> 
> The compiler (JIT if Java) can only use the architectural registers. And
> the CPU can only map architectural registers to physical registers - it
> can not memory addresses to physical registers.
> 
>> However, there's another point. You're bang on about 64-bit machines 
>> having bigger pointers (and possibly integers), and so data structures 
>> using more memory. But this doesn't just affect the amount of memory a 
>> structure uses, it affects the bandwidth it takes to move it in from 
>> memory, and the amount of space it takes up in the cache. If you're 
>> walking a linked list, for instance, then you need to load one pointer 
>> per link; with an 8 GB/s memory interface, that's 2 billion links per 
>> second on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, 
>> if a link object comprises a two-word object header and two one-word 
>> pointer fields, then 4 MB of cache will hold a quarter of a million 
>> links on a 32-bit machine, but only 128 thousand on a 64-bit.
>>
>> So, if you're adding things to your machine to compensate for the 
>> 64-bitness, it needs to be not just RAM, but cache and bus bandwidth. 
>> I don't believe that either of those things are limited by the width 
>> of a register - 32-bit machines routinely have >32-bit buses already, 
>> and cache size is limited by the size of the processor die and the 
>> process technology - so i don't think 64-bit machines have any 
>> intrinsic advantage here.
> 
> They do have a small one.
> 
> http://www.digit-life.com/articles2/cpu/insidespeccpu2000-part-m.html
> 
> measured it to 1.6% to 3.8% for SPECint2000 benchmark.

The floating point shows much bigger advantages for 64 bit, because
that is not only more registers but are getting rid of the stack model
for FP registers.

Arne

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>>> see http://mindprod.com/bgloss/sixtyfourbit.html
> 
> Please have a second look at the entry. I have updated it based on
> your feedback.

Looks much better.

One note though. If you are not programming but playing games,
then you may have a huge graphics card in the PC.

32 bit versions of desktop Windows (XP & Vista) not
only has the 4 GB limit on virtual address space that
all 32 bit OS has - it also has a 4 GB limit on
physical addresses. And PCI and PCIe devices reserves
chunks of 256 MB physical address space. Which means
that on 32 bit XP you can only use 4 GB RAM - RAM on
graphics card rounded up to multipla of 256 MB - a few
other smaller things.

So your 4+ GB most definitely includes 4 GB and I would
tend to write it as >3 GB to emphasize the point.

Arne

On Tue, 24 Jun 2008 22:11:12 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>But I find it rather confusing when you use "I presume ..."
>and then you list something that is explicit in the text
>you are replying to.

You were not explicit.  You made only a vague reference saying you
were "ignoring" the issue. Besides it doesn't matter a rat's ass.
Why are you so hard up for credit?

-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
<twic@urchin.earth.li> wrote, quoted or indirectly quoted someone who
said :

>I don't know if there's a correlation between the number of architectural 
>registers, and the number of physical registers you can use effectively. 
>If there is, then a register-rich 64-bit architecture could have even more 
>physical registers, and your point might still be valid.

Registers used to be very expensive so older architectures tend to be
tight on registers. 64-bitness islogically independent of number of
registers. I have modified that sentence to make clear I am talking
only about the AMD architecture.

Seems to me some years ago I read about a 32-bit machine with an
astounding (at least astounding at the time) number of registers
organised as a sliding register window. This strikes me as the best
way to handle things to avoid spending most of your life
saving/restoring registers.

In the 80s I wrote a lot of assembler.  I spent many hours tracing my
own code and other programs single stepping. I was horrified at the
ratio of housekeeping to application arithmetic, particularly call
overhead.  The key to a faster new architecture will be to streamline
procedure calls.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
<twic@urchin.earth.li> wrote, quoted or indirectly quoted someone who
said :

>But this doesn't just affect the amount of memory a 
>structure uses

A Java object consists mostly of references to other objects, usually
Strings.  Each of these is twice the size.

Even the ints could well be twice as fat. Often placing ints on an
even 64 bit boundary will speed access.  So depending on how your run
time works, many of your ints could have 32 bits of padding too.

I don't know if the stacks go 64 bit internally. If so, they too would
be twice as fat.

The machine code itself is would be fluffier too.  8-bit later 16- bit
and 32 bit code was designed for compactness as the expense of
orthogonality. The extra registers in 64 bit will chew up more
selector space in the instructions.
 
What we need are some space benchmarks with some real world JVMs to
get an idea of just how much extra ram you need to run 64-bit.

I have a 64 bit capable machine.  All I need is some energy to perform
the experiments.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
<twic@urchin.earth.li> wrote, quoted or indirectly quoted someone who
said :

> If you're 
>walking a linked list, for instance, then you need to load one pointer per 
>link; with an 8 GB/s memory interface, that's 2 billion links per second 
>on a 32-bit machine, but only 1 billion on a 64-bit

would not the memory fetch bus typically twice as wide on 64 bit, thus
giving you the name effective throughput in links per second?

There are so many variables, I feel silly trying to predict the net
effect.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Tue, 24 Jun 2008 22:22:24 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>The compiler (JIT if Java) can only use the architectural registers. And
>the CPU can only map architectural registers to physical registers - it
>can not memory addresses to physical registers.

You meant to say "It can not MAP memory addresses to physical
registers" right?

Some old DEC architectures could do that.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Mon, 23 Jun 2008 20:01:57 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>The post you replied to contained the following (that you did not
>quote):
>
>#[I am ignoring the 1024 versus 1000 issue]
>
>Is that statement unclear ????

YES . Please see http://mindprod.com/jgloss/newsgroups.html

I am not talking to you. I am talking to the audience which consists
primarily of newbies.  It is not necessarily obvious to them.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Tue, 24 Jun 2008, Lew wrote:

> Tom Anderson wrote:
>> However, there's another point. You're bang on about 64-bit machines
>> having bigger pointers (and possibly integers), and so data structures
>> using more memory. But this doesn't just affect the amount of memory a
>> structure uses, it affects the bandwidth it takes to move it in from
>> memory, and the amount of space it takes up in the cache. If you're
>> walking a linked list, for instance, then you need to load one pointer per
>> link; with an 8 GB/s memory interface, that's 2 billion links per second
>> on a 32-bit machine, but only 1 billion on a 64-bit. Similarly, if a link
>> object comprises a two-word object header and two one-word pointer fields,
>> then 4 MB of cache will hold a quarter of a million links on a 32-bit
>> machine, but only 128 thousand on a 64-bit.
>
> Mitigating that factor, one 64-bit quantity might hold that two-word 
> object header, and thus not inflate the memory requirement for that 
> piece.

The two-word header i'm familiar with, from Bacon's work on inflatable 
locks, consists of a pointer to the vtable and a pointer to a semaphore, 
with some flags stored in the low bits. If you want the pointers to be 
proper pointers, they'll have to be full words. However, cleverness here 
is certainly possible

> It's all accordin'.

Hyup.

tom

-- 
As a matter of fact, it is estimated that 10% of all meth labs explode.

On Fri, 20 Jun 2008 15:58:35 GMT, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>
>see http://mindprod.com/bgloss/sixtyfourbit.html

Thanks for all your input in whipping that entry into shape.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

On Wed, 25 Jun 2008, Roedy Green wrote:

> Seems to me some years ago I read about a 32-bit machine with an 
> astounding (at least astounding at the time) number of registers 
> organised as a sliding register window. This strikes me as the best way 
> to handle things to avoid spending most of your life saving/restoring 
> registers.

SPARC does this, i believe. It does seem like a very good idea. I think it 
deals with running out of registers by raising an interrupt, and then 
there are kernel-mode instructions which let the handler spill registers 
to memory, and load them back later. All very clever.

tom

-- 
shouting drunkenly about 6502 assembler at parties

On Wed, 25 Jun 2008, Roedy Green wrote:

> On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
> <twic@urchin.earth.li> wrote, quoted or indirectly quoted someone who
> said :
>
>> But this doesn't just affect the amount of memory a structure uses
>
> A Java object consists mostly of references to other objects, usually 
> Strings.  Each of these is twice the size.
>
> Even the ints could well be twice as fat. Often placing ints on an
> even 64 bit boundary will speed access.  So depending on how your run
> time works, many of your ints could have 32 bits of padding too.
>
> I don't know if the stacks go 64 bit internally. If so, they too would
> be twice as fat.
>
> The machine code itself is would be fluffier too.  8-bit later 16- bit 
> and 32 bit code was designed for compactness as the expense of 
> orthogonality.

Hmm. Not sure that's true. The PDP-11 instruction set is often held up as 
a model of orthogonality, and that's 16-bit.

You're probably right about code getting bigger, though. That seems to be 
a trend.

> The extra registers in 64 bit will chew up more selector space in the 
> instructions.

Only a bit or two. That's the power of the exponential function!

Anyway, i don't know if these remarks were aimed at me - i was *agreeing* 
that 64-bit uses more memory.

tom

-- 
shouting drunkenly about 6502 assembler at parties

On Wed, 25 Jun 2008, Roedy Green wrote:

> On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
> <twic@urchin.earth.li> wrote, quoted or indirectly quoted someone who
> said :
>
>> If you're walking a linked list, for instance, then you need to load 
>> one pointer per link; with an 8 GB/s memory interface, that's 2 billion 
>> links per second on a 32-bit machine, but only 1 billion on a 64-bit
>
> would not the memory fetch bus typically twice as wide on 64 bit, thus 
> giving you the name effective throughput in links per second?

No. Bus width is not coupled to register width these days. I'm not sure if 
there is an architectural limit to bus width - the latest graphics 
chipsets have 512-bit buses connecting the GPU to the card's RAM. Thinking 
about it, the width should be limited to the width of a cache line, since 
that's the unit you do memory reads in. Although i suppose you could 
always transfer multiple lines at once.

tom

-- 
shouting drunkenly about 6502 assembler at parties

Tom Anderson wrote:
> On Wed, 25 Jun 2008, Roedy Green wrote:
> 
>> Seems to me some years ago I read about a 32-bit machine with an 
>> astounding (at least astounding at the time) number of registers 
>> organised as a sliding register window. This strikes me as the best 
>> way to handle things to avoid spending most of your life 
>> saving/restoring registers.
> 
> SPARC does this, i believe. It does seem like a very good idea. I think 
> it deals with running out of registers by raising an interrupt, and then 
> there are kernel-mode instructions which let the handler spill registers 
> to memory, and load them back later. All very clever.

I've done performance work both with SPARC, and before that with some
Celerity systems that did something similar.

It has its good points, but also presents problems.

First, there is the physical problem of getting fast enough transfers
between the registers and the ALU. Generally, the bigger a memory the
slower transfers between the memory and a given place in the processor.
There is a lot to be said for making the register structure very small,
very fast, and very close to the ALU.

Second, consider what happens on register stack overflow/underflow,
especially with modern coding styles that tend to have many small
functions. By the time a register window needs to be saved or restored,
the system has no data about which registers are really in use, and
which contain junk. The result is that the whole block needs to be
transfered.

I used to hate the Ackermann function, because the code to evaluate it,
which appears in a lot of benchmarks, requires large, rapid changes in
call stack depth.

Patricia

Tom Anderson wrote:
> On Wed, 25 Jun 2008, Roedy Green wrote:
>> Seems to me some years ago I read about a 32-bit machine with an 
>> astounding (at least astounding at the time) number of registers 
>> organised as a sliding register window. This strikes me as the best 
>> way to handle things to avoid spending most of your life 
>> saving/restoring registers.
> 
> SPARC does this, i believe. It does seem like a very good idea. I think 
> it deals with running out of registers by raising an interrupt, and then 
> there are kernel-mode instructions which let the handler spill registers 
> to memory, and load them back later. All very clever.

It sounds as a great idea.

But I doubt that it is in practice.

HW at that level is beyond me, but I draw my conclusions from
the fact that newer RISC architectures (PPC, Alpha and Itanium)
does not use register windowing (Itanium uses register windowing
which has the same idea though).

Arne

Roedy Green wrote:
> On Tue, 24 Jun 2008 22:22:24 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> The compiler (JIT if Java) can only use the architectural registers. And
>> the CPU can only map architectural registers to physical registers - it
>> can not memory addresses to physical registers.
> 
> You meant to say "It can not MAP memory addresses to physical
> registers" right?

Yup.

Arne

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1627387952-1214490003=:29641
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 25 Jun 2008, Arne Vajh�j wrote:

> Tom Anderson wrote:
>> On Wed, 25 Jun 2008, Roedy Green wrote:
>>> Seems to me some years ago I read about a 32-bit machine with an 
>>> astounding (at least astounding at the time) number of registers organised 
>>> as a sliding register window. This strikes me as the best way to handle 
>>> things to avoid spending most of your life saving/restoring registers.
>> 
>> SPARC does this, i believe. It does seem like a very good idea. I think it 
>> deals with running out of registers by raising an interrupt, and then there 
>> are kernel-mode instructions which let the handler spill registers to 
>> memory, and load them back later. All very clever.
>
> It sounds as a great idea.
>
> But I doubt that it is in practice.
>
> HW at that level is beyond me, but I draw my conclusions from the fact 
> that newer RISC architectures (PPC, Alpha and Itanium) does not use 
> register windowing (Itanium uses register windowing which has the same 
> idea though).

I wonder if it's because more modern architectures do register renaming, 
which means they don't need windowing. Both are effectively ways of using 
more physical registers than you have architectural registers, so having 
both is redundant; windowing takes less logic, but renaming gives you more 
performance, so as processors have got bigger, there's been a shift from 
windowing to renaming. Pure speculation, of course.

tom

-- 
Hesgadin. It was in two parts - both of them silent. I remember this map
came with a letter accusing me of stealing eggs. I had never understood
the relationship of the map to the accusation. I still don't, but I'm
grateful for the map.
---910079544-1627387952-1214490003=:29641--

Roedy Green wrote:
> On Tue, 24 Jun 2008 22:11:12 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> But I find it rather confusing when you use "I presume ..."
>> and then you list something that is explicit in the text
>> you are replying to.
> 
> You were not explicit.  You made only a vague reference saying you
> were "ignoring" the issue.

You still do not "presume" you can always "elaborate" or "give details".

>                            Besides it doesn't matter a rat's ass.

If you don't think usenet posts matter, then why do you post ?

Arne

Roedy Green wrote:
> On Mon, 23 Jun 2008 20:01:57 -0400, Arne Vajh�j <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> The post you replied to contained the following (that you did not
>> quote):
>>
>> #[I am ignoring the 1024 versus 1000 issue]
>>
>> Is that statement unclear ????
> 
> YES . Please see http://mindprod.com/jgloss/newsgroups.html
> 
> I am not talking to you. I am talking to the audience which consists
> primarily of newbies.  It is not necessarily obvious to them.

No.

But if that is the case then you should explain instead of
misleading them !

Arne