64bit processors

My thought is that although 64bit CPU is a good thing, it damn well better have backwards compatiblity for running 32bit code. Otherwise, it won''t be able to run 99.99999999999999999999999999999999999999999999999% of code that currently exists .

Can safely drop 16bit "real mode" though, no need to support 15 year old code.

Your for loops will now be able to loop 18 quadrillion times instead of a measly 4 billion

As for the effect on game programming, I think it will allow much more precise calculations (physics, movement, pixels, etc), without any speed hits. But what do I know...

From what I read, Intel''s chip isn''t going to support 32 bit code, but AMD''s will.

That may have changed since it''s been a few months since Ive read anything about 64 bit chips

I think Intel''s will support 32 bit through some sort of emulation or something. It will use the 64 bit architecture to fake 32 bit, so it ends up being slower. Apparently Intel is abandoning the x86 architecture for their 64 bit chips. This is what I originally heard, so it may have changed by now.

I do know that AMD is using an extension of the x86 architecture (ugh!) and thus will support 32 bit natively just like the x86 architecture supports 16 bit. I suspect that this will not be terribly elegant, much like the x86 architecture.

I wonder how long it will be before the average person has a 64 bit machine.

Anonymous Poster: No duh.!!!! its a risk Motorola Processor. it has been that was for over a decade. And no duh about your math and etc. If its 64 bit it will do 64 bit instructions

It will also increase the maximam amount of RAM you can use on a system. This is, of course, pointless though, coz we are only up to 2GB. Unless the hardware manufacturers know something we dont :S

Intel''s 64-bit: it is not opcode compatable with IA32 (386-P4), bit it is assembly compatable (all it take to convert most code from IA32 to IA64 is a recompile). I don''t realy know much more than that... don''t own one =)

AMD''s 64-bit: from what I understand it will be IA32 compatable the 64-bit parts will just be an extention like 32-bit is an extention of the the 16-bit opcodes.


Memoery Limit: no actualy 4GB is not the limit any more. I beleave it was with the P2 (or about there) they started to expand the address space. I beleave its up to 48-bits. You can''t address that much all at once, so what they have done is use a HighMem/LowMem setup like back in the 16-bit days to address over 1MB of ram.

Unless the hardware manufacturers know something we dont

yes they do aparently =) they''re are some motherboards out there that support up to 16GB or ram (take a look at super micro''s xeon boards).

quote:

---

Do you guys think 64bit processors(Such as ClawHammer)will effect game programming in a big way? If so how will it effect it?

---

Not much. There will probably be IA-32 and x86-64 binaries distributed for games, but other than that, it''s just another CPU bolted onto the PC architecture offerring an incremental performance gain. Not much change will happen.

quote:

---

its a risk Motorola Processor

---

I think you mean the term "RISC", as in Reduced Instruction Set Computer. I''m not sure how Motorola fits into this post at all.

quote:

---

I think Intel''s will support 32 bit through some sort of emulation or something.

---

"Will"? IA-64 has been available for a couple of years now. It already does run 32-bit code. It''s not done through software emulation, the IA-64 is actually able to decode and execute 32-bit instructions by making use of the same processor resources that the native 64-bit instruction set uses. The performance for 32-bit code is very poor because of the radical difference between IA-64 and IA-32.

In the future, it is conceivable that 32-bit support will be dropped.

quote:

---

Apparently Intel is abandoning the x86 architecture for their 64 bit chips.

---

No way! This has never been their position. IA-64 is a high-end architecture and they have no known plans to bring it to desktop systems within the next 5 years. They don''t even think AMD''s x86-64 will compete with it because AMD is for the low (and perhaps mid) end.

I kind of don''t get that, though, because IA-64 isn''t THAT expensive. It''s definitely not low-end, but IIRC, some of the Itanium II servers can be had for as "little" as $5-6K. Typical workstation prices are $10-15K. Compare this with POWER4 which starts at $12K and typically runs over $50-100K and the new Alpha EV7s which can be had cheapest for $44K, last I heard.

quote:

---

the memory consumtion is alsow higher in 64 bit architecture,

---

This is true. However, I think most C compilers on 64-bit architectures define "int" as 32-bit, so not much has changed. Most of the loads and stores will still be 32-bit and some ABIs under certain architectures can even get away with using 32-bit values for pointers.

Instruction size isn''t generally affected on RISC processors. Alpha, PowerPC, MIPS, and PA-RISC all use 32-bit instruction words. Itanium has 41-bit instructions which appear as "bundles" of 3 instructions + 5 additional bits for template encoding (so the processor knows how to decode and dispatch the 3 instructions and to carry information about parallelism among groups of instructions.)

quote:

---

As for the effect on game programming, I think it will allow much more precise calculations (physics, movement, pixels, etc), without any speed hits.

---

Isn''t most of this stuff handled with floating point? X86 has roughly the same floating point precision as the 64-bit processors do. I think some architectures like SPARC have support for 128-bit floating point precision, but I think the highest x86-64 and IA-64 support are 80 and 82-bit, respectively (correct me if I''m wrong about x86-64.)

X86-64 should give a bit of a speed boost to floating point code simply because it has more registers available and they''re not stack-based anymore, IIRC. It''s true that instruction decoding and OoO techniques in modern X86 processors help out a lot with old X87 FP code, but it''ll be much easier to write code using a normal register layout. There''s also SSE and SSE2 registers which give a great boost to the Pentium 4''s performance over normal FPU code.

quote:

---

Can safely drop 16bit "real mode" though, no need to support 15 year old code.

---

Believe it or not, I still have some handy DOS apps which run in 16-bit mode. Don''t just drop 16-bit mode, drop both 32-bit and 16-bit. Use an entirely new ISA! Bite the bullet, because the longer you wait, the harder it will be. How long are we going to offer backwards compatibility?

Software translation should be fast enough until vendors port their applications.

It''s really a shame Alpha never took off. The only interesting 64-bit architectures left are PPC64/POWER and IA-64, though PowerPC is rather ugly, IMHO, and IA-64 is a bit byzantine in many regards and performs erratically (though generally, the Itanium II scores are very impressive.)

quote:

---

Your for loops will now be able to loop 18 quadrillion times instead of a measly 4 billion

---

''fraid not. That has nothing to do with 64-bitness.

quote:

---

I beleave its up to 48-bits.

---

Yeah, right. If you''re talking about IA-32, try 36.

Starting with the Pentium Pro, 4 more address bits were added bring the total amount of addressable memory up to 64GB.

quote:

---

You can''t address that much all at once, so what they have done is use a HighMem/LowMem setup like back in the 16-bit days to address over 1MB of ram.

---

It''s true that it''s not available all at once, but it''s not exactly comparable to the 16-bit days where the 20-bit bus only allowed 1MB of memory, max.

It''s actually a much more clean solution than most people give Intel credit for. The extra 4 bits are encoded into the page table data, so while a process can only have a maximum of 4GB memory (because of 32-bit addresses), you can have different processes occupy different 4GB chunks of the total 64GB address space.

Of course, if you wanted to give a process access outside of its 4GB, you would have you use some sort of bankswitching mechanism. I''m not aware of any operating systems that do this.

quote:

---

Intel''s 64-bit: it is not opcode compatable with IA32 (386-P4), bit it is assembly compatable (all it take to convert most code from IA32 to IA64 is a recompile). I don''t realy know much more than that... don''t own one =)

---

It _can_ execute IA-32 code natively. There is a processor mode which allows this.

I''ve never heard the term "assembly compatible." You can''t just "reassemble" code. The IA-64 instructions themselves are totally different.

As far as compiled programs go, if they''re portable, you can recompile them, in theory, without much (if any) modification. But that''s true for any architecture.

Of course IA-32 compatibility in IA-64 seems almost like an after-thought. The expectation is that if you''re running IA-64 hardware, you''ll be recompiling your software or writing new software altogether.


It''ll be interesting to see what happens in the next 5 years. The race for the future of 64-bit computing is on between X86-64, IA-64, and PowerPC.

----
Bart

trzy: nice post. I wasn't 100% shure on alot of that. I was just quoting what I was able to find on it (didn't realy look to hard).


"Of course, if you wanted to give a process access outside of its 4GB, you would have you use some sort of bankswitching mechanism. I'm not aware of any operating systems that do this."


actualy there is, its alittle known OS called Linux =)
I know 2.4.17 and up do... I'm thinking all the 2.4.x kernels do. The default way they handle it is the first 3GB is permanatly mapped the 3GB-4GB range is "swap space" for everything above that. It can be changed anyway you like. I haven't played with it... only got 1GB or ram =)

[edited by - Great Milenko on February 14, 2003 12:56:10 AM]

[edited by - Great Milenko on February 14, 2003 12:56:33 AM]

yea, Well I was telling them what I know about the processer. I wasn''t pulling the "facts" out of my ass. About 99% of what I now about them has been from the intel website & they''re docs. Its just that I haven''t looked at them in a long time. I thought I had explained that... guess not =)

quote:

---

Original post by Anonymous Poster
BTW, if you want to run some code on Alpha, Itanium, and PA-RISC machines, check out the HP TestDrive program.

---

realy =)

thats cool as hell I might hafta check that out =)

quote:

---

Original post by Anonymous Poster
Does Linux really allow this? I always thought it allowed a maximum of 2-3GB of memory for user processes, with the rest for the kernel.

---

Ok I just made an ass of my self again =)

I just found some info on this feature, from Ingo Molnar (the maintianer of high mem support). Its an archived e-mail message from the mailing-list. Its some what dated (Wed, 3 Nov 1999), but......

http://mail.nl.linux.org/linux-mm/1999-11/msg00016.html

basicaly when you turn on high mem support to 64GB mode, userland address space is still 4GB, but each process can have its own 4GB chunk of ram.

BTW if you haven''t read the link -> High mem support scence version pre4-2.3.23 =)

"Your for loops will now be able to loop 18 quadrillion times instead of a measly 4 billion

'fraid not. That has nothing to do with 64-bitness."

It has.. The registers of x86-64 can hold 18 quadtrillions so you can decrement them 18 quadtrillion times and compare with zero

"Starting with the Pentium Pro, 4 more address bits were added bring the total amount of addressable memory up to 64GB."

But that's accomplished with the PAE extension and it's not very good performance-wise

[edited by - noVum on February 15, 2003 2:17:02 PM]