Re: What does 32 bit application mean?

On 2005-08-03, Marco van de Voort <marcov@stack.nl> wrote:
> On 2005-08-01, Florian Weimer <fw@deneb.enyo.de> wrote:
>> Most operating systems supporting AMD64 do not currently offer such a
>> choice, which is a bit disappointing. The extended register set would
>> benefit ILP32 applications as well (which generally run faster because
>> smaller pointers result in a smaller working set).
>
> I also noted this. And it seems the AMD64 architecture indeed supports
> it. Another advantage is simpler PIC support (one can move from EIP
> in native mode, and not in x86 mode).
>
> [No, on an AMD64 a process is either in long mode that has the extra
> registers and address modes and 64 bit addresses, or in compatibility
> more which is just like ia86 protected mode. You can't mix and match.


I vaguely remembered there be a near model too. I think I saw the
originhints in the sysv abi document, but that was related to
jumps(the below document has some reference to that in 3.7.4.), so in
retrospect my original remark was based on a near model for code, not
data, so wrong.


Meanwhile I quickly looked into the
AMD64 docs. (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33047.pdf)


For data/stack I could only find


- in paragraph 2.2.4 that with db 67; prefixes you can do 32-bit stack
access in long memory mode.


- RIP relative addresses also use a 32-bit displacement (but I assume
this only works for compiletime known addresses, iow global vars, not
general data segment pointers)


- page 20 says "in long mode, 16 and 32-bit addresses are
zero-extended". However 2.2.4 says that 16-bit mem references don't
exist in longmode.


.. Of course you could, if 32-bit displacements are possible,
handcraft a near model by assigning a register to a 64-bit base
pointer, and access with 32-bit displacements.


> The comments I've seen say that the code savings from the extra
> registers and IP-relative addressing about cancel out the code bloat
> from the bigger pointers, but 64 bit apps still run slower because
> the tools are less mature and so much code has been heavily
> optimized to run fast on x86. -John]


That's because they don't try to use a near memory model (AMD arch
pre-cooked or handcrafted) in 64-bit mode. Aside from above
references, I don't know how feasible that is though, in general and
performancewise.

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