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

[Kevin Lin]

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.

-- 

--