Re: What does 32 bit application mean?

"Jatin Bhateja, Noida" wrote:


> My question might sound trivial but I am not able to get an satisfying
> answer yet. Question is what do one understand when we say that an
> application is 32 bit or 64bit. Does this means that the compiler is
> compiled for 32 bit machine. If so this means that the application
> will use 32/64 bit registers. I have got two answers with me but I
> don't know exactly which one is correct. Kindly clear my doubt :
>
> Answer 1: When an application is compiled for and if the assembly
> generated by the compiler uses 32 bit register then we say that an
> application is 32 bit application. Thus it corresponds to the register
> size of an architecture.
>
> Answer 2: An application which contains 32 bit (virtual) addresses in
> its assembly is called an 32 bit application.


When addresses (pointers) can be stored in registers, then both
answers are somewhat equivalent. Provided an appropriate language and
compiler, the same source code can be compiled for machines of any
word size.


> If my logical understanding is correct then can we make some tool
> such that if the compiler produces 64 bit code (contain 64 bit
> register) the tool will convert the 64 bit instructions to 32 bit
> instructions. Thus this 32 bit code can then be processed by
> assembler for 32 bit architecture.


The handling of proper computational data can be translated in a
straight forward manner. But the translation of addresses IMO requires
much more efforts. Consider what has to be done when a 32 bit address
is stored in a 64 bit pointer variable, and then 64 bit arithmetic is
applied to such a value - what should happen when such a value later
again is used as a memory address? Can the high 32 bits be safely
ignored, or must they be checked for zero, or for sign extension of
the low 32 bits?


BTW, how do you intend to obtain the assembly code? From object files
or from linked applications?


> [On all the modern machines I know, the register size and the address
> size are the same, so your two definitions are equivalent.
>
> As to whether you can run 32 bit code on a 64 bit machine or v/v, any
> compiled program requires a particular hardware instruction set. For
> 64 bit machines that evolved from 32 bit machines such as IBM zSeries
> and AMD 64, there is usually a compatibility mode that emulates the 32
> bit predecessor. In the other direction, forget it, 32 bit machines
> don't run 64 bit code. You can indeed program a 32 bit machine (or
> for that matter an 8 or 16 bit machine) to handle 64 bit data, but
> that doesn't make it 64 bit code. -John]


As I understand the OP, the mentioned translator tool shall statically
convert native 64 bit applications into native 32 bit
applications. Such a transformation can make the program run slower,
due to the inefficient handling of 64 bit data items, but AFAIK even
64 bit compilers will typically use 32 bit "int" values, with no
performance penalty on 32 bit processors. IMO the really critical
point is the translation of 64 bit address values and pointer
arithmethic, that will not only introduce computation overhead, but
also requires appropriate checks and possibly a mapping into 32 bit
addresses.


IMO it will be possible to statically convert 64 bit assembly code
into 32 bit code, but the result will be considerably different from a
direct compilation of the same source code into a 32 bit application.


Better results could be obtained by a decompilation of the 64 bit
code, followed by a (manual) tweaking of the pointer variables and
arithmetic. In this process it also will be possible to identify and
substitute RTL or other standard library procedures in the assembly
code and, more important, it will be possible to replace all calls to
external code (OS API, DLLs...), together with all the related data
structures and values. Without such substitutions it would be more
efficient to write an emulator for both the target machine and the
target OS, and leave the application code as it is ;-)


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.