Re: New intermediate release?

Greetings!

"Chun Tian (binghe)" <[email protected]> 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)" <[email protected]> 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			     		    [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah