Related articles |
---|
[6 earlier articles] |
Re: 32-bit vs. 64-bit x86 Speed meissner@the-meissners.org (Michael Meissner) (2007-04-13) |
Re: 32-bit vs. 64-bit x86 Speed georgeps@xmission.com (George Peter Staplin) (2007-04-13) |
Re: 32-bit vs. 64-bit x86 Speed tmk@netvision.net.il (Michael Tiomkin) (2007-04-13) |
Re: 32-bit vs. 64-bit x86 Speed dot@dotat.at (Tony Finch) (2007-04-13) |
Re: 32-bit vs. 64-bit x86 Speed kenney@cix.compulink.co.uk (2007-04-13) |
Re: 32-bit vs. 64-bit x86 Speed DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-14) |
Re: 32-bit vs. 64-bit x86 Speed DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-14) |
Re: 32-bit vs. 64-bit x86 Speed gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-04-18) |
Re: 32-bit vs. 64-bit x86 Speed haberg@math.su.se (2007-04-23) |
Re: 32-bit vs. 64-bit x86 Speed haberg@math.su.se (2007-04-23) |
Re: 32-bit vs. 64-bit x86 Speed anton@mips.complang.tuwien.ac.at (2007-04-25) |
Re: 32-bit vs. 64-bit x86 Speed haberg@math.su.se (2007-04-26) |
Re: 32-bit vs. 64-bit x86 Speed haberg@math.su.se (2007-04-27) |
[1 later articles] |
From: | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
Newsgroups: | comp.compilers |
Date: | 14 Apr 2007 20:43:29 -0400 |
Organization: | Compilers Central |
References: | 07-04-031 07-04-035 |
Keywords: | architecture, performance |
Posted-Date: | 14 Apr 2007 20:43:29 EDT |
glen herrmannsfeldt wrote:
> There is probably some demand for 64 bit integer arithmetic,
> though likely much smaller than for large address space.
> Addition and subtraction are not hard to do on 32 bit machines,
> but multiply and divide are significantly harder.
The introduction of wider data types can speed up certain calculations,
of course. But this is not a special compiler issue, instead it's
sufficient to introduce according data types into the programming
languages. Ansi C specified an "long long" datataype years ago.
A harder restriction is not related to 32/64 bit machines: the size of
floating point numbers. Many algorithms will perform better (faster
convergence...) with more precise floating point calculations.
Somewhat new is the decision to stay with 32 bit integers by default, in
new compilers, even on 64 bit machines, because 32 bits still are
sufficient for most purposes.
> If intel had done things rights so that one could use the 36
> bit physical address of its processors, it would be a few more
> years before 64 bit was needed.
The 32 bit segment32:offset32 addressing already allows for an logical
address space of up to 4 G segments, of 4 GB each. The restriction to a
single segment (in the flat memory model) is an OS convention, not
related to hardware. Other manufacturers can provide more address lines,
and allow access to more physical RAM, than Intel did.
In so far I was a bit inconsequent in my preceding comment, that 64 bit
machines are needed for making use of more than 4 GB of physical RAM. As
you said, the availability of more than 32 address lines is not a really
new requirement.
From the time of NEAR and FAR pointers we should have learned, that
such a distinction is not desireable in source code. It's acceptable
when a compiler allows to mix pointers of different size, when the
details are not reflected in the source code. I.e. a compiler could
allow for arrays of 4 GB each, so that more than 4 GB of logical address
space become available immediately, without special coding. This would
have been sufficient for some time, before machines with considerably
more than 4 GB of physical RAM become the de-facto standard. At that
time a smooth move from 32 bit pointers to all 64 bit pointers is
desireable, so that 64 bit machines should become available *before*
segment registers have to become visible in source code again.
DoDi
[Actually, the entire address space for an x86 process has to fit into
4GB because the segments are mapped into a 32 bit linear address space
for paging. You can imagine various tricks to map segments in and out
of the linear space, but the performance hit would be awful. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.