Re: 32-bit vs. 64-bit x86 Speed
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: 18 Apr 2007 13:51:41 -0400
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(snip)
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.
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
.
- References:
- 32-bit vs. 64-bit x86 Speed
- From: Jon Forrest
- Re: 32-bit vs. 64-bit x86 Speed
- From: glen herrmannsfeldt
- Re: 32-bit vs. 64-bit x86 Speed
- From: Hans-Peter Diettrich
- 32-bit vs. 64-bit x86 Speed
- Prev by Date: Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.
- Next by Date: Parser generators which implemented Burke-Fisher error correction
- Previous by thread: Re: 32-bit vs. 64-bit x86 Speed
- Next by thread: Re: 32-bit vs. 64-bit x86 Speed
- Index(es):
Relevant Pages
|
|
