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

[Kevin Lin]

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.
> 
> -- 
> 
> -- 
> 

--