[MLton] MLton rules! (was: filedes = int)

Adam Goode adam@evdebs.org
Sat, 16 Jul 2005 22:06:37 -0400


--=-U/z6XGuw36wIVtQHEzuu
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2005-07-16 at 12:51 -0700, Stephen Weeks wrote:
> > I think that you REALLY want to have the full 64-bits of address
> > space. =20
>=20
> We will certainly give that option.
>=20
> > If you don't, you might run into other problems like: where shared
> > libraries live in the address space; where files get mapped in
> > (which, after all, could be huge and also spread out so that they
> > can grow); etc.
>=20
> I don't see why it would be so hard for the OS to find us a contiguous
> 16GB somewhere.  After all, it does have 64 bits of address space.
>=20


Actually, current x86-64 implementations only give you 48-bit virtual
addressing, but still use 64-bit pointers. (High bits of pointers must
be cleared, or the processor generates a fault.) So you don't get all of
64-bits of address space (on current processors), but 256TiB (48 bit) is
still pretty good.


References:

See section 2.2.2 "64-bit Canonical Addresses" on page 18, which talks
of implementations supporting "fewer bits" of addresses:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/245=
92.pdf

And see the current Athlon 64 datasheet for that processor's address
size (40-bit physical, 48-bit virtual):
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/246=
59.PDF

I know Intel processors currently have the same 48-bit virtual limit,
see section 3.3.7.1 "Canonical Addressing", page 3-12:
ftp://download.intel.com/design/Pentium4/manuals/25366516.pdf



Thanks,

Adam


--=-U/z6XGuw36wIVtQHEzuu
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBC2b0tlenB4PQRJawRAtk1AJ9Pd060x5rokvIgLCrYliftoTYHhwCeJolo
Hx9GSAG+PElShuopqGCO3i0=
=5BSo
-----END PGP SIGNATURE-----

--=-U/z6XGuw36wIVtQHEzuu--