> All 32-bit architectures have a 4GB address space, 64-bit architectures
> obviously have a much bigger one (depends on the arch how many bits are
> used for the address space).
>
> PPC obviously does not have the dumb physical memory limitations x86
> has, however.
As others have noted, the recent ia32 chips support 36 (or more) bits of
physical memory, and there is even code to use it AFAIK in the current
kernel. It would be possible to allow program access to this RAM, although
both Kernel and gcc support would be needed. M$ had "huge" memory models
to go over 64k in the old 8086 days, doing loads of segment registers.
> Anyhow, Rik's mmap trick will work on any arch, not just x86.
Rik's mmap trick is like the dancing elephant, "the wonder is not that he
does it well but that he does it at all." In the first place most
programmers could not get the code to work reliably in a realistic time
frame (if at all) due to complexity, and if they did the implementation
would not be usefully fast for random access, which is why you use memory
in the most cases.
Imagine *a++ = *b++ with four system calls per byte. Or imagine an FFT,
where even if you could do range checking to see if mmap() was needed you
would still add multiples to the integer portion, and probably beat the
cache to a pulp.
As a technique for special applications and programmers it works well, but
as a general solution it is totally impractical in both time to code and
time to run. Not to mention portability issues to 64 bit hardware, where
you need still other code unless you want to run multiples slower.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/