Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!cambridge.apple.com!gb From: gb@cambridge.apple.com (Gary Byers) Newsgroups: comp.lang.lisp Subject: Re: Apple CL incompatible with Radius accelorater Message-ID: <136@brazil.cambridge.apple.com> Date: 22 Oct 89 00:51:58 GMT References: <856woodl@yvax.byu.edu> <4812@internal.Apple.COM> <1989Oct21.155107.13876@paris.ics.uci.edu> Reply-To: gb@cambridge.apple.com (Gary Byers) Organization: Apple Computer Inc, Cambridge, MA Lines: 59 In article <1989Oct21.155107.13876@paris.ics.uci.edu> Michael Pazzani writes: >In article <4812@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >>In article <856woodl@yvax.byu.edu> woodl@yvax.byu.edu writes: >>> I just installed a Radius 16 mhz accelorater board in my SE and >>find that >>> Apple Allegro CL will not boot. I get the bomb!, error=11. >> >>Yup, it's our problem. Put this patch in your INIT.LISP file: > >I just bought a DayStar 40MHz Accelerator for my MAC-II and Allegro CL 1.2.1 >Seems to have the same problem. I've also experienced problems on a IIcx. >Since both the Accelerator an IIcx use a 68030, I'm beginning to suspect >that this version doesn't work with that chip. Will the posted patch work? >Will upgrading to 1.2.1 help, or shoould I wait for 1.3 which should >be out soon? > >Thanks, >Mike Pazzani This is all somewhat confusing, so please bear with me: 1) Versions of the lisp older than 1.2.2 would not run on 68030-based machines. This incompatibility was caused by an incredibly stupid little piece of code in the lisp kernel, which said "If it's not a 68020, it must be a 68000 ...". The 1.2.1 and 1.2.2 kernels differ only in that the latter recognizes 68030-based machines correctly. It is possible to patch the 1.2.1 kernel to make it into the moral equivalent of the 1.2.2 kernel with ResEdit; send me mail if you want to do this. 2) All released versions fail to handle floating-point exceptions (such as divide-by-zero) properly on systems equipped with a 68882 (vice 68881) floating-point coprocessor. This bug (and a patch for it) were reported in Tech Note #231; sadly, the patch in TN 231 contained a typo which caused the stack pointer to sail off into the ozone. Paul Snively of Mac DTS (chewy@apple.com) recently posted a corrected version of this patch to comp.lang.lisp in response to a question about MACL's interaction with Radius Accelerators which are not equipped with FPUs. 3) All versions of the lisp try to emulate floating-point instructions on systems that don't have floating-point coprocessors by catching the "F-Line" exception which should occur in such cases and using SANE to perform the floating-point operation. It seems to be the case that, on Macs equipped with Radius Accelerators without FPU chips, attempts to address the floating-point coprocessor yield "Coprocessor Protocol Violation" exceptions instead of the expected "F-Line" exception; this seems to be the reason why the lisp bombs on invocation on such machines. If anyone who's been trying to use the lisp on such a hardware configuration (Radius 68020 w/o 6888x) is willing to do some remote debugging of this situation, I'd be very interested in trying to resolve this problem that way: send me mail if you want to pursue this. Likewise, we've asked Radius what (if anything) users might be able to do or have done to their accelerator boards to remedy this problem and will continue to pursue that approach. Gary Byers gb@cambridge.apple.com