[erlang-questions] 64-bit erlang
Thu Nov 29 11:06:48 CET 2007
There's something I don't really understand here - It seems to me that
having fixed word lengths
is in general a good idea - so aligning instructions on a 32 or 64 bit
boundary makes life easy.
But why the sudden hop from 32 to 64 bits? if 32 bits can address 4G
then 40 bits could address 1TB.
<< I just don't get this - 32 bits can distinguish 4G different
addresses, 64 bits can distinguish 16 exabytes
given that a hardware designer will use some of the bits in a register
and the rest for an address
then a 22 bit instruction and 42 bit pointer would allow access to 4
TB of data - in this case
the "natural size" of a pointer and an integer should be 42 bits.
Compiler writers should allow the size
of an integer to be any reasonable value and not just a power of two -
can somebody explain this
"power of two fetish" to me so I can understand >>
Is it possible to change the emulator to work with 40 bit integers -
you might have to be a bit
devious. If P points to a struct that is 40 bits long (say a byte + a
32 bit integer) then *(P+1)
would point to the next struct. Is this less efficient than a 64 bit
program? - who knows -
caching might make this more efficient.
Are there no "memory expanders" in the good ol' DOS days there was a
Most C programs could only access the first 640K of memory - to access
over 640K you used a
memory extender, that allowed access to memory over 640K.
Are there no memory extenders that allow a 32 bit application to
address memory outside
the 4G address space?
On Nov 28, 2007 11:35 PM, jm <> wrote:
> Bjorn Gustavsson wrote:
> > It could also be possible to somewhat shrink the Beam code to
> > better use the larger word size (packing more operands into one word).
> > The savings would probably be minor, but could be still be worthwhile
> > as it is relatively straight-forward to do.
> Would this be something like ARM's thumb code
> (http://en.wikipedia.org/wiki/ARM_architecture#Thumb) or more like lzw
> compression of blocks of code?
> erlang-questions mailing list
More information about the erlang-questions