Greetings, That's very interesting (that ARM64 macOS is more optimized in function calls 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 GCC 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) release before the ARM64 macOS support is done? It would be even better if you can port the "libboot" patch and other necessary changes to GCL 2.6 branch. I think 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! > > This link spells out what is going on uniquely on this machine: > > https://cpufun.substack.com/p/what-about- > > Briefly, the regular arguments and the elipsis if any needs to be in the > 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. > > The basic changes needed in gcl are > > 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(!) > > 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. > > 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. > > Take care, > > "Chun Tian (binghe)" <binghe.l...@gmail.com> writes: > >> 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[=DIR] >>> interpret TEMPLATE relative to DIR; if DIR is not specified, >>> use >>> $TMPDIR if set, else /tmp. With this option, TEMPLATE must >>> not >>> be an absolute name; unlike with -t, TEMPLATE may >>> contain >>> slashes, but mktemp creates only the final component >>> >>> -t interpret TEMPLATE as a single file name component, relative >>> to a >>> directory: $TMPDIR, if set; else the directory specified via >>> -p; >>> else /tmp [deprecated] >>> >> >> I just figured out that I can install MacPorts' "coreutils" package, which >> 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 to use >> this >> package.) >> >> Therefore no more blocking issues on supporting GCL 2.7 in earlier macOS >> 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 >> >
signature.asc
Description: OpenPGP digital signature
