64 bit processor - 64 bit OS - 64 bit application
 

I have this doubt.

With 64 bit processors we need 64 bit OS and we need to have 64 bit applications.

What do these 64-bit applications have different than the 32 bits one?

Can we have 32 bit OS on 64 bit machine? I know that is a mismatch but will it work?

As a programmer do we have to worry about the 32-bit to 64-bit change.

Please help me understand the basics.

Please excuse if this is not the right place to ask this question.

Hi -
Yes, that's correct.
Or more to the point, you *must* have a 64-bit OS in order to run a 64-bit application.

Yes, certainly.

You can also run 32-bit applications on a 64-bit OS running on a 64-bit machine.

You might need to download the 32-bit versions of certain shared libraries, or they might already be installed for you. Your mileage may vary, depending on the application and the distro. But in general, 32-bit applications are compatible with 64-bit OS's. Both Linux, and Windows.

Uh - the biggie is a 64-bit vs. 32-bit address space. Which is the difference between being able to address 4GB vs. multiple petabytes ;)

This article might help:

http://en.wikipedia.org/wiki/64-bit

The thing goes this way: you need a 64 bits machine to run a 64 bits OS, and a 64 bits OS to run 64 bits apps. You are -however- not forced to run a 64 bits OS on common 64 bits architectures. But that truly depends on the capabilities of the cpu.

x86_64 cpus are born as an extension to 32 bits x86 cpus, and they do have a 32 bits native mode, so they can run as an x86 cpu, and, thus, they can run an OS that was compiled for x86 (32 bits). But this is not true if you have an itanium cpu, for example (ia64). But that's highly unlikely.

So, to sum up, as long as you have an x86_64 compatible cpu, a 64 bits OS, and the OS is capable of such thing, you should be able to run most 32 bits software as long as the required libraries are in place on their 32 bits version. Note however that the support varies widely from one version of the OS to the next one. In Windows XP the 64 bits support was really bad, but 7 should work ok. In Linux there shouldn't be a problem, but only as long as your distro maintainers enabled the IA32 support on your 64 bits kernel (most definitely do, since it doesn't harm and can come in handy in a lot of circumstances).

About 32 vs. 64, there's a lot of info about that in the net, so I'll let you do the research. The most obvious advantage is the ability to address huge memory sizes, but also the extra registers, their size, more instructions, etc. Some programs can really benefit from this, other will only grow in size for no gain at all, and in some corner cases 64 will mean a disadvantage. It might also depend greatly on the quality of the object code produced by a given compiler.

Thank you for the information.

The last question I had was to understand the 32 bit vs 64 bit from a programmer's perspective. 64 bit means 2^64 bit addressing capability.

With 32-bit I guess two registers would be required for managing address over 2^32?

What I do not understand is, this is CPU architecture, why my program should change just because the CPU now handles 64 bit? At what level of programming there would be an impact. I am sure a normal C/Java/PHP/ASP programmer is not impacted with this change!

Is it true that if there is more than 4GB requirement of memory 64 bit would be fast there and slower if the program does not need that support (I assume handling 64 bit address would be slower than 32 bit)

Should there be support to pick and run a particular mode 32/64 depending on a application requirement.

My question might be little confusing, but mostly I want to understand for what coding I should be worried for this change.

Regards
Amod

The big difference is the size of an address, 32 bits vs. 64 bit. What that and other differences mean to a programmer depends on the language. For example, in C and C++, a long is 32 bits in 32 bit x86 and 64 bits in 64 bit x86. So addresses, ints and longs are all the same size in x86, but addresses and longs are twice as big as ints in x86_64.

With 32-bit, there is no such thing as a (virtual) address over 2^32-1. With PAE, there can be physical addresses over 2^32, but only a small part of the kernel gets involved in physical addresses and that part usually would not use two registers for a larger than 32 bit physical address. Ordinary programming uses only virtual addresses.

Lots of C programmers accidentally or intentionally make assumptions such as
sizeof(int)==sizeof(void*)
and/or
sizeof(int)==sizeof(size_t)
because they only ever expected to use 32 bit architectures, or simply were using 32 bit architectures and didn't think through the consequences of some code.
When such code is recompiled in the native architecture of a 64 bit system, it will have bugs (sometimes subtle).

For C, I just described the common impact. Other languages may lead to fewer non portable constructs.

Not necessarily. Many programs using far less than 4GB are much faster when compiled in x86_64 than in 32 bit x86.

Typically, using 64 bit addresses is slower (on the same 64 bit CPU) than using 32 bit addresses.

The actual processing of each address by the CPU is identical in performance, but various caching effects make the larger addresses slower on average in practice.

But x86_64 also has twice as many 64 bit registers as x86 has 32 bit registers. The extra registers often allow the same source code to be compiled into fewer instructions. So x86_64 code may run significantly faster. There are other compiler issues that may give x86_64 additional performance advantages.

I'm not sure what you're asking.

You can run a 32 bit application on a 64 bit OS.

You might choose to do that if the program has portability bugs (such as I described above) and would work incorrectly if you simply recompiled it for 64 bit.

You might do that if the program is closed source and you only have the binary for 32 bit.

You might do that if this is one of the programs that runs significantly faster in 32 bit mode than 64 bit mode, AND you care that much about the performance of that program, AND you've taken the trouble to find out it runs faster in 32 bit mode. If you're using the GCC compiler, that gets pretty unlikely, because GCC doesn't compile very well for 32 bit x86 and does much better for x86_64. With the ICC compiler, you're more likely to get 32 bit code that runs faster than 64 bit.

Anyway, it is usually your choice whether to run 64 bit or 32 bit programs in a 64 bit OS.

No, your code *doesn't* necessarily need to change! In fact, it really *shouldn't* change. Unless you're doing "bad things" with pointer arithmetic, or practicing other naughty habits ;).

Yes, a 32-bit exe will run in a 32-bit environment (even on a 64 bit OS), and a 64-bit exe will run in a 64-bit environment (if you have a 64-bit OS. Otherwise, of course, it won't run at all ;)). You can recompile the SAME source of the SAME application for EITHER 32- or 64-bit.

Not in the slightest.

SUGGESTION: don't worry about it unless you're planning on learning assembly language.

If you really DO want the answer, do yourself a favor by focusing on learning assembly FIRST. And the differences between 32-bit and 64-bit assembly AFTERWARDS.

For whatever it's worth: DOS used a 16-bit registers (ax, bx, ..., si, etc). Intel 386 introduced 32-bit counterparts (eax, bax, ..., esi, etc). AMD/64 has 64-bit counterparts (rax, rbx, ...). They're all backwardly compatible: a 64-bit program can use eax; a 32-bit program can use ax, and any architecture can access the 8-bit portions ah or al.

PS:
My all-time favorite recommendation for anybody wanting to learn assembly is:

Programming from the Ground Up, Jonathan Bartlett