This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: compressed pointer type implementation in gcc
- From: Andi Kleen <andi at firstfloor dot org>
- To: "Yair Lifshitz" <luna dot starlight at gmail dot com>
- Cc: gcc at gcc dot gnu dot org, "Yair Lifshitz" <yair dot lifshitz at intel dot com>
- Date: Sun, 20 Jul 2008 00:33:30 +0200
- Subject: Re: compressed pointer type implementation in gcc
- References: <9D3FF9CB8AF1694AB811321FF6378F3603849741@hasmsx415.ger.corp.intel.com> <b90c57030807190825s55fb452ct755617b4e017d0a1@mail.gmail.com> <b90c57030807190829h5e8c097fyf3d0bd436b0f419c@mail.gmail.com>
"Yair Lifshitz" <luna.starlight@gmail.com> writes:
>
> Basically, as long as the application is in the 32G range (2^32*2^3),
Seems like a strange assumption. If the application can use 32GB
what stops it from using 40GB or 64GB? Systems with that much
memory are readily available these days.
> Would be nice to get your opinions on it.
It's a common optimization in the JVM world where the Just in time
compilers do it based on the configured heap sizes and because
there's no fixed ABI.
But on the C compiler level the problem is that you'll have an
completely own ABI and won't be able to use any standard libraries
unless you recompile them. And no system calls without a translation
layer or some way to tag all system interfaces to the the standard
ABI. Java avoids that by having clearly defined interfaces to the
outside world, but that's not the case in C. Or you annotiate all
structures where this translation should happen.
It is essentially the same problem as the common "32bit ABI
in long mode" proposals have.
-Andi