Re: Help with MIT/GNU Scheme 12.1 compiler on Intel Macs

[Kevin Lin]

Thanks David, that's useful to know.  I haven't been
able to build Scheme using gcc (Homebrew, gcc-14): the
configure script craps out, and I haven't had time to
figure out what goes wrong.  I'm traveling now but
will try again when I get home.
-Kevin

-----Original Message-----
From: David Gray <dgray@iesl.forth.gr>
Cc: mit-scheme-users@gnu.org

For what it's worth, it is a problem with the apple compiler. I managed to get 
a butchered version working by using gcc13 with macports.
I just chopped out the lines with errors in the source,
copied the all.com from the previous version. Unlikely as it
seems this compiles scheme code correctly even with the
usual-integrations. However I’m not expert enough to go
anywhere further with this information.

> On 10 Dec 2024, at 6:23 AM, Kevin Lin <kkylin@alum.mit.edu> wrote:
> 
> Thanks David.  I've been doing something similar to
> you, but using a version of the work-around in my
> first msg (despite my own disclaimers).  So far it
> seems to work fine and I can get by with it.
> -Kevin
> 
> 
> -----Original Message-----
> From: David Gray <dgray@iesl.forth.gr>
> Cc: mit-scheme-users@gnu.org
> 
> I think you are correct in that it is saving that is the
> problem. I really just want a couple of slow functions to be
> compiled, so after digging around in the source I found
> compile-procedure which does what I need for the
> moment. Just load up the function, compile-procedure, then
> run it.
> 
> 
> 
> 
>> On 4 Dec 2024, at 10:43 PM, Kevin Lin <kkylin@alum.mit.edu> wrote:
>> 
>> Sorry, two things I forgot to say:
>> 
>> - If scode that's been directly compiled (as in my
>> example, and as opposed to loading it from a .bin
>> file generated by SF) is then compiled into native
>> code via say compile-scode, it does seem to run just
>> fine.  But saving to file (via fasdump) and
>> reloading leads to the same problems.
>> 
>> - Not necessarily recommending these kludges as a
>> work-around for anyone else having similar issues --
>> I don't know MIT Scheme internals and haven't tested
>> these things; the kludges came about as an effort to
>> isolate the issue.
>> 
>> Kevin
>> 
>> -----Original Message-----
>> To: mit-scheme-users@gnu.org
>> 
>> Hi all,
>> 
>> I'm trying to build and run MIT/GNU Scheme 12.1 on an Intel
>> Mac running Sequoia (15.1).  I've had similar issues as
>> described on this thread:
>> 
>> https://lists.gnu.org/archive/html/mit-scheme-users/2023-10/msg00004.html
>> 
>> I've been digging around this for a bit, so this is long.
>> I've broken this into sections.  Details on how I built
>> Scheme on my machine come at the end.  Any insights or just
>> knowing that someone has managed to get 12.1 running on a
>> recent macOS would be great.
>> 
>> Thanks!
>> 
>> Kevin <kkylin@alum.mit.edu>
>> 
>> *MAIN SYMPTOMS*
>> 
>> Here is a little transcript of what I get:
>> 
>> #|
>> (cf "fact.scm")
>> 
>> ;Generating SCode for file: "fact.scm" => "fact.bin"... done
>> ;Compiling file: "fact.bin" => "fact.com"... done
>> ;Unspecified return value
>> 
>> 1 ]=> (load "fact.com")
>> 
>> ;Loading "fact.com"...
>> ;The object fact, passed as an argument to
>> return-address->stack-frame-type, is not in the correct
>> range.
>> ;To continue, call RESTART with an option number:
>> ; (RESTART 1) => Return to read-eval-print level 1.
>> |#
>> 
>> The file "fact.scm" is something more or less straight from
>> SICP:
>> 
>> #|
>> (declare (usual-integrations))
>> 
>> (define (fact n)
>> (if (> n 1)
>>     (* n (fact (- n 1)))
>>     1))
>> |#
>> 
>> Moreover, there appear to be issues affecting SF as well:
>> 
>> #|
>> 1 ]=> (sf "fact.scm")
>> 
>> ;Generating SCode for file: "fact.scm" => "fact.bin"... done
>> ;Unspecified return value
>> 
>> 1 ]=> (pp (fasload "fact.bin"))
>> 
>> ;Loading "fact.bin"... done
>> (define (fact n)
>> (if (%record n 1)
>>     (%record n (fact (%record n)))
>>     1))
>> ;Unspecified return value
>> |#
>> 
>> If I remove (declare (usual-integrations)) then it seems to
>> be ok:
>> 
>> #|
>> 1 ]=> (sf/system "fact.scm")
>> 
>> ;Generating SCode for file: "fact.scm" => "fact.bin"...
>> ;  This program does not have a USUAL-INTEGRATIONS declaration.
>> ;  Without this declaration, the compiler will be unable to perform
>> ;  many optimizations, and as a result the compiled program will be
>> ;  slower and perhaps larger than it could be.  Please read the MIT
>> ;  Scheme User's Guide for more information about USUAL-INTEGRATIONS.
>> ;... done
>> ;Unspecified return value
>> 
>> 1 ]=> (pp (fasload "fact.bin"))
>> 
>> ;Loading "fact.bin"... done
>> (define (fact n)
>> (if (> n 1)
>>     (* n (fact (- n 1)))
>>     1))
>> ;Unspecified return value
>> |#
>> 
>> but CF continues to fail:
>> 
>> #|
>> 1 ]=> (cf/system "fact.scm")
>> 
>> ;Generating SCode for file: "fact.scm" => "fact.bin"...
>> ;  This program does not have a USUAL-INTEGRATIONS declaration.
>> ;  Without this declaration, the compiler will be unable to perform
>> ;  many optimizations, and as a result the compiled program will be
>> ;  slower and perhaps larger than it could be.  Please read the MIT
>> ;  Scheme User's Guide for more information about USUAL-INTEGRATIONS.
>> ;... done
>> ;Compiling file: "fact.bin" => "fact.com"... done
>> ;Unspecified return value
>> 
>> 1 ]=> (load "fact.com")
>> 
>> ;Loading "fact.com"...
>> ;The object fact, passed as an argument to
>> return-address->stack-frame-type, is not in the correct
>> range.
>> ;To continue, call RESTART with an option number:
>> ; (RESTART 1) => Return to read-eval-print level 1.
>> |#
>> 
>> *IS FASDUMP THE PROBLEM?*
>> 
>> One thing I noticed is that if I took a .bin or .com file
>> compiled on my Linux box and loaded it on my Intel Mac, it
>> works just fine: this code (and more complicated programs)
>> runs without a hiccup, and pretty-printing the .bin file
>> looks fine to me.  It suggests the issue *might* be centered
>> around saving binary files.  Digging around more, I found
>> that if I bypass the FASDUMP defined in fasdump.c, SF
>> appears to be ok again.  Here's a little kludge that does
>> that.
>> 
>> (define *target-fasl-format*
>> (eval '(target-fasl-format) (->environment cbf)))
>> 
>> (define (fasdump-kludge obj file)
>> (portable-fasdump obj file *target-fasl-format*))
>> 
>> and what we find is this:
>> 
>> #|
>> 1 ]=> (define fact-scode
>>       ;; compile SCode without saving to file
>>       (eval '(sf/file->scode "fact.scm" "" #f '())
>>         (package/environment
>>           (find-package '(scode-optimizer top-level)))))
>> ;Value: fact-scode
>> 
>> 1 ]=> (pp fact-scode)   ;; looks ok to me
>> (define (fact n)
>> (if (&> n 1)
>>     (&* n (fact (-1+ n)))
>>     1))
>> ;Unspecified return value
>> 
>> 1 ]=> (fasdump-kludge fact-scode "fact.bin")  ;; now save to file
>> 
>> ;Unspecified return value
>> 
>> 1 ]=> (pp (fasload "fact.bin"))  ;; reload and look
>> 
>> ;Loading "fact.bin"... done
>> (define (fact n)
>> (if (&> n 1)
>>     (&* n (fact (-1+ n)))
>>     1))
>> ;Unspecified return value
>> 
>> |#
>> The kludge doesn't work for compiled expressions and I
>> didn't test it on a .com file.  I've also dug around
>> fasdump.c but I don't understand the microcode and don't
>> know where to start tracking down the issue.
>> 
>> Anecdotally, the native code compiler worked just fine in
>> Monterey and earlier versions of macOS.
>> 
>> *MORE SYMPTOMS*
>> 
>> 1. One can get different errors by (i) adding more
>>  definitions to fact.scm, and (ii) selecting which
>>  primitives (+, *, >) get integrated.  I didn't include
>>  all the cases.
>> 
>> 2. DISK-SAVE also fails, but bands saved on working
>>  installations (e.g., ScmUtils) work just fine.
>> 
>> *HOW I BUILT SCHEME*
>> 
>> I use Apple's "gcc", which (I think) is just an alias for
>> clang.  I massage various env vars (happy to share
>> config.log), but none of that seems super important.  What
>> *is* important is to set SDKROOT to
>> 
>> `xcrun --sdk macosx --show-sdk-path`
>> 
>> or clang won't compile the microcode.  This may have
>> something to do with my having GCC installed (via Homebrew).
>> Incidentally, I haven't tried uninstalling gcc as that would
>> break too many things, but I did try unlinking gcc and it
>> didn't make a difference to the behavior above.
>> 
>> In case it matters, all this is on a 2015 Intel MBP.  I get
>> the same behavior on an M2 Mac via Rosetta, and on older
>> Intel Macs on Sequoia + OCLP.
>> 
>> -- 
>> 
>> -- 
>> 
> 
> --

--