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: [email protected] 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 <[email protected]> *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. -- --
