On 20 Jan 2003 at 6:06, Ron Johnson wrote:
> On Mon, 2003-01-20 at 03:59, Shridhar Daithankar wrote:
> > On 20 Jan 2003 at 3:52, Ron Johnson wrote:
> > I work on an application which is 32 bit on HP-UX 64 bit. It handles more than
> > 15GB of data at some sites pretty gracefully..No need to move to 64 bit as
> > yet..
>
> Maybe you wouldn't get a speed boost on HP-UX, but I bet you would on
> x86-64. Why? 64 bit programs get to use the new registers that AMD
> created just for 64 bit mode. Thus, the compiler should, hopefully,
> be able to generate more efficient code.
Well, that is not the issue exactly. The app. is commercial with oracle under
it and it si going nowhere but oracle/HP-UX for its remaining lifecycle.. I was
just quoting it as an example.
> Also, since (at least on the gcc-3.2 compiler) a "long" and "int" are
> still 32 bits (64 bit scalars are of type "long long"), existing
> programs (that all use "long" and "int") will still only fill up 1/2
> of each register (attaining the speed that HP alleges), but, as I
> mentioned above, would be able to use the extra registers if recompiled
> into native 64-bit apps...
I am not too sure, but most 64bit migration guides talk of ILP paradigm that is
integer/long/pointer with later two going to 8 bits. If gcc puts long at 4
bytes on a 64 bit platform, it is wrong.
Bye
Shridhar
--
Painting, n.: The art of protecting flat surfaces from the weather, and
exposing them to the critic. -- Ambrose Bierce
