Greetings! "Chun Tian (binghe)" <binghe.l...@gmail.com> writes:
> 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? > Just to report that I tried this, and it does not work -- the unique calling convention appears to be defined in the kernel or perhaps libc, not a gcc issue. Take care, > 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 >>> >> > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
