• Welcome to Valhalla Legends Archive.
 

32-bit programming coming to an end?

Started by DVX, February 03, 2004, 01:25 PM

Previous topic - Next topic

DVX

i've been hearing a lot of stuff coming up about 64-bit processors, microsoft os's 64-bit processors, etc.

this got me to thinking that is 32-bit programming coming to an end and 64-bit programming coming next very soon?

also, with longhorn and microsoft abandoning the win32 api (so i have heard), is this sort of an attempt to get us to move towards 64-bit programming?  (while microsoft is abandoning win32 api, they are making api's for .net now)

this is just what i have heard, none of it is really factual..  any comments?

Adron

You can still run 16-bit programs in Windows. It's not likely that 32-bit programming will be abandoned any time soon, even though perhaps there might eventually be a reduction in API support and development for it.

j0k3r

#2
Seeing as how this is in general, can someone expand on what this means? Are 64bit processors/programs just faster than 32bit processors/programs? Or is there a whole new layer to be revealed?
QuoteAnyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin
John Vo

Adron

They have 64-bit general purpose registers and 64-bit addressing modes.

What this mostly means is that they can handle more memory. If you're going to put more than like 2-4 GB ram in your computer, you might want to look at a 64-bit processor.

Most operations won't automatically be much faster. Today's processors already have wider memory buses than 32-bits. And it's not that often that you really need 64-bit variables instead of 32-bit ones. And using bigger variables than needed uses up more memory bandwidth...

MyndFyre

Yes...  as I recall, a 64-bit processor means that all of the internal and external architecture is 64-bit: the ALU(s), the address registers, the memory bus itself, etc.  This means that the processor can address more memory overall (32-bit processors can address up to 4gb natively; a 64-bit processor can address up to 2^64, or approximately16,000,000,000,000,000,000 bytes.  It also means that there is native support for addition of 64-bit data types, and that the memory bus can transfer more data per block movement operation than a 32-bit processor can.

That said, unless Microsoft has really shaped up its support for consumer use of 64-bit technology, I don't foresee 64-bit as a platform coming up to "common usage" until at least 2008, my prediction for when the next edition of Winblows (after Longhorn).  If you look at Windows XP 64-bit edition, nothing is supported: no internet connection sharing, no network bridge, no windows media, the list goes on.

For now, and I'm guessing it will remain the same through Longhorn, there isn't enough counsumer need to have a 64-bit PC.  The technology will stay in the realm of scientists and animators who already have specialized software to run on the platform, and who will see a true performance boost out of it.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Adron

An important thing to note today is that the memory bus size of a 32-bit processor can be much greater than 32 bits. So in most cases you won't automatically get higher memory bandwidth with a 64-bit cpu.

MyndFyre

Quote from: Adron on February 06, 2004, 12:18 PM
An important thing to note today is that the memory bus size of a 32-bit processor can be much greater than 32 bits. So in most cases you won't automatically get higher memory bandwidth with a 64-bit cpu.

Well no, but at any given time a given 32-bit processor can only address up to 4gb of memory.  If you're using some kind of hardware paging, I suppose you could address beyond that.  The address lines are what I was referring to, not the actual data bus.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Adron

Quote from: Myndfyre on February 06, 2004, 12:26 PM
Quote from: Adron on February 06, 2004, 12:18 PM
An important thing to note today is that the memory bus size of a 32-bit processor can be much greater than 32 bits. So in most cases you won't automatically get higher memory bandwidth with a 64-bit cpu.

Well no, but at any given time a given 32-bit processor can only address up to 4gb of memory.  If you're using some kind of hardware paging, I suppose you could address beyond that.  The address lines are what I was referring to, not the actual data bus.

Oh, ok. I interpreted this

Quote
and that the memory bus can transfer more data per block movement operation than a 32-bit processor can.

to mean that the data lines of the memory bus of a 64-bit processor would be wider than those of a 32-bit processor which isn't necessarily true.

There is also the relatively common "PAE" hardware paging that supports addressing more than 4 GB of memory on a 32-bit cpu.

Mesiah / haiseM

now amd goes around saying one constant thing "run your 32 bit applications without any loss in performance" blah de dah, but does that really make a difference? because if it does, then why would amd be developing 64 bit processers ground up for microsoft, and there new 64 bit applications/operating systems, if microsoft was just going to abandon 32 bit api?

But what im thinking, is the 64 bit processer would automatically handle 32 bit applications, they just say that to make there stuff look good and secure..
]HighBrow Innovations
Coming soon...

AIM Online Status: 

tA-Kane

#9
Being a 64-bit processor would mean that the instructions would be 64-bits in length, instead of 32-bits in length. If a 64-bit processor is thusly expecting that, then it may require conversion of 32-bit instructions into the native 64-bit instructions, which would result in a slight slowdown.

If this is not the case (and even if it is), how would 64-bit processors run 32-bit instructions without slowdown?
Macintosh programmer and enthusiast.
Battle.net Bot Programming: http://www.bash.org/?240059
I can write programs. Can you right them?

http://www.clan-mac.com
http://www.eve-online.com

MyndFyre

Quote from: tA-Kane on February 07, 2004, 04:22 PM
Being a 64-bit processor would mean that the instructions would be 64-bits in length, instead of 32-bits in length. If a 64-bit processor is thusly expecting that, then it may require conversion of 32-bit instructions into the native 64-bit instructions, which would result in a slight slowdown.

If this is not the case (and even if it is), how would 64-bit processors run 32-bit instructions without slowdown?

You might recall that the 8086 was touted as the world's first 20-bit processor.  It wasn't really 20-bit, it only had 20 address lines.  It was really a 16-bit processor.  The internal architecture was 16-bit.

In any case, 16-bit processor instructions are all provided in the 32-bit iX86 chips.  IIRC, NOP is E5 (I'm probably wrong....  I hated assembler and never want to see it ever again).  It will still be E5 (if that's what it is now) on the 64-bit chips.  There isn't a special "64-bit instruction set" -- there will be instructions encoded that may be longer than 32 bits for any new instructions that they add, but even new instructions don't have to be beyond 32 bits.

But when you're using a 32-bit program on a 64-bit machine, you won't be using the full potential of the system bus, the data bus, or the internal architecture, because the compiled program will be designed for different, smaller data types.  That's why it's advantageous to recompile a 16 bit application for a 32-bit environment; you'll see performance gains, especially in areas of block transfers and such.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Adron

Quote from: tA-Kane on February 07, 2004, 04:22 PM
Being a 64-bit processor would mean that the instructions would be 64-bits in length, instead of 32-bits in length. If a 64-bit processor is thusly expecting that, then it may require conversion of 32-bit instructions into the native 64-bit instructions, which would result in a slight slowdown.

The length of the instructions are probably varying. x86 instructions have very different lengths, they're not all 32 bits long.

Some 64-bit cpus seem to use an x86-like instruction/register set (AMD's?). In that case, the switch can be based on a mechanism like the switch from 16- to 32-bit; setting the processor to a default mode and using prefix bytes to make exceptions.

Some 64-bit cpus seem to use a completely different instruction/register set (Intel's?). In that case you can't readily mix 32-bit and 64-bit instructions in the same application, and I suppose that yes, a slowdown for executing 32-bit instructions could be expected.

Puzzle

I don't think Intel have released their 64-bit processor yet, have they?

I know Longhorn is being tested on the AMD processor since Intel hasn't finished theirs, or at least hadn't last time I heard.

Grok

#13
Quote from: Puzzle on March 06, 2004, 07:55 PM
I don't think Intel have released their 64-bit processor yet, have they?

I know Longhorn is being tested on the AMD processor since Intel hasn't finished theirs, or at least hadn't last time I heard.

I believe Merced was the first IA-64 processor.

64-bit extension technology is one of a number of innovations being added to Intel's IA-32 Server/Workstation platforms in 2004. It represents a natural addition to Intel's IA-32 architecture, allowing platforms to access larger amounts of memory . Processors with 64-bit extension technology will support 64-bit extended operating systems from Microsoft, Red Hat and SuSE. Processors running in legacy* mode remain fully compatible with today's existing 32-bit applications and operating systems.

FAQ:  http://www.intel.com/technology/64bitextensions/faq.htm

R.a.B.B.i.T

#14
cipher:
A cryptographic system in which units of plain text of regular length, usually letters, are arbitrarily transposed or substituted according to a predetermined code.

encryption:
1. To put into code or cipher.  (Hrm....)
2. Computer Science. To alter (a file, for example) using a secret code so as to be unintelligible to unauthorized parties.


Hence: telling somebody how to decrypt something automatically defies the definition of encryption, and the file is no longer encrypted, just hard to read.