develooper Front page | perl.perl5.porters | Postings from December 2000

Re: [8095] HP-UX 11.00 / cc / 64bitint & 64bitall / perlio

Thread Previous | Thread Next
Nicholas Clark
December 15, 2000 16:25
Re: [8095] HP-UX 11.00 / cc / 64bitint & 64bitall / perlio
Message ID:
On Fri, Dec 15, 2000 at 10:52:12PM +0000, Nicholas Clark wrote:
> On Wed, Dec 13, 2000 at 02:01:37PM +0100, H . Merijn Brand wrote:
> > I've been experimenting with -Duse64bit and -Duse64bitall on HP-UX 11.00. After
> > some fight with libdb-3.0 (perl/64/HP-UX wants it to be shared ELF 64 bit which
> > in turn requires libpthread in libswanted (patch to hints/ included)). I
> > managed to build two working bleadperls. Below are the results from the Dutch
> > jury. What strikes me is that the times are *slower* for all tests in 64bit
> > mode than in 32 bit mode.

> What's going to happen is that some sick person is going to suggest that
> they'd like 64 bit UVs so that they can deal with large file offsets and
> complicated device numbers, but 32 bit IVs for fast integer arithmetic.
> (and still dropping back to NVs when needed)
> Without going any slower than current for numbers in the IV range.

> I think it would be possible.

Sorry, that sounded arrogantly like one of those "amazing patch that won't
fit in the margin of my monitor" type messages.

The reason I think it might be possible is that the integer preserving
versions of all the arithmetic ops make four assumptions

1: that the system uses 2s complement arithmetic (it made overflow detection
   more simple and therefore faster by simply looking for a wrapped result)
2: that all positive IVs can fit into a UV, and that the negation of all
   negative IVs also fits into a UV.
   (coupled with the 2s complement assumption this leads to a few [more]
   UV foo = (UV)IV_MIN; [more because we already had some in the source])
3: that only UVs >=0 and <= (UV)IV_MAX will fit back into an IV
4: that IV [OP] IV is more common than any other pairing. The IV IV code
   is tried first, and sv_setuv attempts to set an IV if the UV is small

sizeof(UV) == sizeof(IV) is consistent with this assumption.
As is sizeof(UV) > sizeof(IV)

And two scalars that are valid as IVs arriving at the start of an operator
will never reach the UV code, so will never hit larger, slower integer maths.

but I think it would be a good idea to make the 64 bit UV/IV stuff work
first, and have a break.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About