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