I do have a couple of scripts that would benefit a lot from this,
compiled
perl with 64-bit int support a couple of weeks ago and have been doing
fine so far. It is true, however, that I had to recompile a few stuff
from ports
(although the list is short). Can help with testing/building ports, in
fact, in
a week or two I could offer a 1.5Ghz powerbook g4 for bulk building and
testing, looking forward to getting involved
On 19.01.2022 06:45, George Koehler wrote:
On Sun, 9 Jan 2022 10:33:58 +0000 (UTC)
j...@posteo.dk 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
