On Sun, 9 Jan 2022 10:33:58 +0000 (UTC)
[email protected] wrote:

> I was wondering if there is a reason to avoid -Duse64bitint in macppc, 
> seems to be working fine and it's certainly convenient to be able to 
> pack quads. I am certain G4's and up can handle it, can't seem to find 
> concrete information regarding G3 processors. In case all supported 
> machines are capable, would the project be ok with enabling this flag?

The C compiler supports 64-bit integers on all platforms where OpenBSD
runs.  Perl now uses 32-bit integers if and only if the platform has
32-bit pointers (like macppc); we might want -Duse64bitint on all
these platforms.

In the short term, we can't -Duse64bitint because this would break all
XS modules: sizeof(IV) and sizeof(UV) change from 4 to 8.

You are correct that Perl on macppc can't pack quads,

amd64:
| $ perl -MConfig -E 'say $Config{uvsize}'
| 8
| $ perl -E 'say join(", ", unpack("C*", pack("Q>", 12345)))'
| 0, 0, 0, 0, 0, 0, 48, 57

macppc:
| $ perl -MConfig -E 'say $Config{uvsize}'
| 4
| $ perl -E 'say join(", ", unpack("C*", pack("Q>", 12345)))'
| Invalid type 'Q' in pack at -e line 1.

This looks bad, because off_t and time_t are 64-bit values in OpenBSD,
so we would need 'Q' to pack or unpack them.  So far, I have not
needed to pack or unpack 'Q's.

Also, Perl on macppc can't do bitwise ops in 64-bit,

| $ perl -E 'say 111222333444 | 0'
| 111222333444  # amd64
| 4294967295    # macppc

Ops like '111222333444 + 1' work, because Perl uses double floats,
which are a superset of 53-bit integers.

--George

Reply via email to