On Wednesday 26 February 2003 03:33 pm, civileme wrote: > On Wednesday 26 February 2003 01:31 pm, Tom Brinkman wrote: > > On Wednesday February 26 2003 11:23 am, Seedkum Aladeem wrote: > > > > While there's already 64 bit production machines, that use > > > > gigs of ram, there's also already Linux performance optimized
[Deleted] > > just 32 bits to work with. > > > > BTW, I believe filesystems are also governed by the same > > mathematical laws and bits ;) I'm mostly doin some educated guessing > > about all the above, Civileme, Juan, Warly, or Todd probly knows. > > Yep > > 1G requires 30 bits (plus a sign bit) to address properly.. since address > arithmetic should be unsigned, this represents the easiest way to implement > address arithmetic using 32-bit signed arithmetic registers. > > 2G is as high as one is likely to go with 32-bit addressing using signed > arithmetic in the registers, unsigned comes extra, unless the hardware > also supports unsigned arithmetic (the C compiler supports unsigned arith > whether the architecture does or not, which means subroutines to add > subtract multiply and divide unsigned 32 bit numbers if the architecture > does not offer such arithmetic) > > C compilers have target memory models as well, so that the compile is > efficient for the expected runtime environment. This is where the sizing > of 32-bit CPU kernels comes into play as well as the optimizations of the > kernel itself. > > Now the more recent Windows systems supposedly support a file size of 2 > Terabytes... I think that is 2 to the power 41 bytes which indicates a 41 > bit address if unsigned and 42 if signed. 64-bit linices generally address > either 8 or 16 exabytes (2 to the power 63 or 64 bytes), and file sizes are > at least that large, potentially. > > One compiler, xbasic, which works on any 386 using windows or linux with X, > actually offers a 64bit signed fixed-point data type. Some interpreters > offer arbitrary number sizes in fixed point (like the Python BIG=1L). > > Limits are limits only because there are performance hits associated with > size, given the architectures available. > > Civileme As suspected, the memory management performance penalty is due to architectural limitations and not sloppy software. Because the registers used for address employ signed ariithmetic, using more higher order bits or increasing the size of the registers would introduce compatibility issues. AMD will not do that. Seedkum
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
