Re: 32-bit vs. 64-bit x86 Speed

glen herrmannsfeldt <gah@ugcs.caltech.edu>
18 Apr 2007 13:51:41 -0400

          From comp.compilers

Related articles
[7 earlier articles]
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)
Re: 32-bit vs. 64-bit x86 Speed jon@ffconsultancy.com (Jon Harrop) (2007-04-28)
| List of all articles for this month |
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 18 Apr 2007 13:51:41 -0400
Organization: Compilers Central
References: 07-04-031 07-04-035 07-04-054
Keywords: 386, architecture
Posted-Date: 18 Apr 2007 13:51:41 EDT

Hans-Peter Diettrich wrote:


> glen herrmannsfeldt wrote:
(snip)


>>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.


Actually, only 8192 segments, selectors are 16 bits, and then you
subtract the ring and local/global bits.


(snip)


> 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.
(snip)


In 16 bit days, I always ran either large or small, never finding an
advantage to the mixed size medium and compact models.


> [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]


Yes, that is the "if intel had done things right" part that I
mentioned above. Well, it would only be awful it if happened to
often, otherwise it is just bad. Also, I was never sure if any
processors had a segment descriptor cache to speed up reload of
recently referenced segment descriptors. Also, the overhead of
changing the page tables is probably less than the swapping that it
may also be doing at about the same time.


Otherwise, I would have liked to see a mode that bypasses the MMU for
addresses >4GB after doing the segment origin/offset calculation. I
believe the valid bit is still there, so the OS could remap the
addresses as appropriate.


-- glen


Post a followup to this message

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