New intermediate release? (was: Re: Mac arm port)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bne5o0keHqQnDTDgj7kN1F8CslA0tFRv0
Content-Type: multipart/mixed; boundary="pu0L0J1pdiSwXiKtyedNb6dxCLKuIhyS2";
 protected-headers="v1"
From: "Chun Tian (binghe)" <[email protected]>
To: Camm Maguire <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Subject: New intermediate release? (was: Re: Mac arm port)
References: <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>

--pu0L0J1pdiSwXiKtyedNb6dxCLKuIhyS2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Greetings,

That's very interesting (that ARM64 macOS is more optimized in function c=
alls of
variable arguments), and it seems that GCL's source code becomes more
standard-compliant with these fixes.

But I wonder if this issue can be avoided (for now) if we use MacPorts GC=
C 13
(or 14) to compile GCL on ARM64 macOS?

On the other hand, MacPorts maintainers do not like that I included GCL
pre-release patches (~3000 lines since 2.7.1 release) as part of the port=

definitions. Is it possible that you can make a new (intermediate) releas=
e
before the ARM64 macOS support is done?  It would be even better if you c=
an port
the "libboot" patch and other necessary changes to GCL 2.6 branch. I thin=
k it's
definitely not needed to support ARM64 macOS for GCL 2.6.x, but it would =
be nice
if GCL 2.6.15 (if it's the last 2.6.x release) can run on macOS 15.

--Chun

On 12/05/25 04:51, Camm Maguire wrote:
> Greetings!
>=20
> This link spells out what is going on uniquely on this machine:
>=20
> https://cpufun.substack.com/p/what-about-
>=20
> Briefly, the regular arguments and the elipsis if any needs to be in th=
e
> right location in the prototype for function calls through pointers to
> succeed.  One can call a regular function through a variadic pointer if=

> the prototype has at lease enough regular arguments in its prototype to=

> match the fixed arguments of the function.
>=20
> The basic changes needed in gcl are
>=20
> 1) h/apply_n.h -- our 64 entry switch table for function calls needs
> expanding to ~ 64^2 entries at least in the naive approach.  About 2Mb
> of code for this table(!)
>=20
> 2) The function prototypes in C files produced by the compiler need to
> be rewritten.  Thankfully one accurate prototype can be used here with
> the fast-link mechanism falling back to the apply_n.h table in case of
> signature incompatibilities.
>=20
> I'm sure there is a better way -- no doubt there are many interpreters
> already ported to Mac/arm, and they all have some sort of generic
> funcall mechanism.
>=20
> Take care,
>=20
> "Chun Tian (binghe)" <[email protected]> writes:
>=20
>> Greetings,
>>
>> On 01/05/25 12:54, Chun Tian (binghe) wrote:
>>> Greetings,
>>>
>>> I found another (minor) issue when building GCL in macOS. The system =
command
>>> "mktemp" of macOS doesn't support "-p" option (in "xbin/mktmp"). How =
to rewrite
>>> this script by using, e.g., "-t" instead:
>>>
>>>       -p DIR, --tmpdir[=3DDIR]
>>>               interpret TEMPLATE relative to DIR; if DIR is not speci=
fied,  use
>>>               $TMPDIR  if  set, else /tmp.  With this option, TEMPLAT=
E must not
>>>               be an  absolute  name;  unlike  with  -t,  TEMPLATE  ma=
y  contain
>>>               slashes, but mktemp creates only the final component
>>>
>>>        -t     interpret TEMPLATE as a single file name component, rel=
ative to a
>>>               directory:  $TMPDIR, if set; else the directory specifi=
ed via -p;
>>>               else /tmp [deprecated]
>>>
>>
>> I just figured out that I can install MacPorts' "coreutils" package, w=
hich
>> provides the GNU version of "mktemp".
>>
>> Furthermore, by using MacPorts' "legacy-support" package, the missing
>> "readlinkat" system call will be provided. (I will need to learn how t=
o use this
>> package.)
>>
>> Therefore no more blocking issues on supporting GCL 2.7 in earlier mac=
OS
>> versions. You don't need to do anything here.
>>
>> In general, I think it's totally reasonable for GCL to depend on some =
other GNU
>> tooling packages (on macOS), including GCC (if necessary).
>>
>> --Chun
>>
>=20


--pu0L0J1pdiSwXiKtyedNb6dxCLKuIhyS2--

--bne5o0keHqQnDTDgj7kN1F8CslA0tFRv0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEES+aY+4laoC0TwmVKFUkg2jrYR8gFAmgr6toACgkQFUkg2jrY
R8gPcQ//Q6ckXMmkNRMvbto/vmhuiS3YlRM09b7smdb90VZ57BljO3iUsvRtOltP
6HOLWL0DSM2gUMCnj3WBq8gVuv9OxliBOIVmRE6w2Cx/cAdn1DdRFxPXOEQwfVht
rwPw9jh1pTncGqPt8G7/CHV4yJBSKJQZZ2W9qwqZvLw79+QohiUZs1h8G0x9ve/w
kZT07HYvXOfERfRezB+LHI1cOkbgNDbFSqm8E2aCRgQaLU8b1GPKXg3Z8gZZoGBG
QHJQdjpl3zWSO3sLsXvqjFHQs1YdMOaQ01Ph+WLLMhOj0XINwyfHFXRsCXp0uqtA
4mQ8VrBCkSjam6ANOBUZdCY90VRzwXGFKsMiI/cZ2GYR9M1HNCKWycOruR86PvNN
67m2UcpuNvtvHSfFm0oZwGO77SZXP/Px3yIhkiR7kJNKBaigJxEK04YthDjfxG66
POWKhki4WxYaMPpnkAv7yDVGEYeuWodiAhO/S9/w1zRFzL0ZrZAxxzmUAHMNx1Tp
qXQhvOOtqjc7VkL5hXPrdx1+81tuQXq5sp8HXOz5dA+CneZfdcBZzDHDc5Q9h3pn
9GHd4iDxrbPLVhwz/v8UiDSTuXmxIEdia4nGyA3HvSKR6nQN1gmPcW/s72kbmjTS
H0HGHyQ7wspoZ9IL48BGCRRzIeSvtlgmu7kzh00KsKEbxRcxMKI=
=nRGT
-----END PGP SIGNATURE-----

--bne5o0keHqQnDTDgj7kN1F8CslA0tFRv0--