[erlang-questions] 64-bit erlang

[Joe Armstrong]

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
similar problem.
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?

/Joe Armstrong


On Nov 28, 2007 11:35 PM, jm <jeffm@REDACTED> 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?
>
> Jeff.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>