amanda@visix.com (Amanda Walker) (01/18/91)
The canonical source for Oaklisp is DOGHEN.BOLTZ.CS.CMU.EDU. There is also a fairly recent copy on UUNET.UU.NET. The Oaklisp virtual machine is extremely portable, and will probably work "out of the box" on the NeXT. It is extremely cool. All someone needs to do is write a Self-style incremental compiler for it... -- Amanda Walker Visix Software Inc.
yu@math.harvard.edu (Jiu-Kang Yu) (01/23/91)
> Article 12345 of comp.sys.next: > From: kirchner@cs.umn.edu (Roger B. Kirchner) > > T can be put in scheme mode by executing (scheme-reset). It works > fine with 2.0. A next specific version of T 3.1 is available, but I > forget where. > > MIT-Scheme 7.1 has just been released and NeXT specific executables > and lib files are on altforf.ai.mit.edu in archive/scheme-7.1/next.tar.Z. > It runs in either 1.0 or 2.0. And it supports X11! Now we need X11 > for 2.0! > > Roger Kirchner In a later posting, "altforf.ai.mit.edu" is corrected to "altdorf.ai.mit.edu". I got this Scheme-7.1 from the above mentioned site. But it doesn't run on my NeXTstation. In fact it killed the whole system. I could not even enter NMI. I had to reboot the machine. What is wrong? I think that I correctly installed it and set the right parameters, because I did so and ran it well on a SUN 4. Jiu-Kang Yu yu@math.harvard.edu yu@huma1.bitnet
max@Neon.Stanford.EDU (Max Hailperin) (01/24/91)
In article <5436@husc6.harvard.edu> yu@math.harvard.edu (Jiu-Kang Yu) writes: >I got this Scheme-7.1 from the above mentioned site. But it doesn't >run on my NeXTstation. In fact it killed the whole system. ... What is wrong? [Another poster had also mentioned to this behavior.] The scheme-7.1 I have runs fine under 2.0 on an 030, but (using same file, same paramaters, etc.) on the 040 does unpredictable things. I have yet to have the processor halt, but I have had varying amounts of grinding followed by varying traps: segmentation violation, bus error, illegal instruction. In each case, the grinding happens after the part of the system written in C is running, but before the part in (compiled) scheme is finished being loaded and initialized. I would lay very large odds that the problem concerns the cache architecture. On the 040, like most modern processors, there are seperate instruction and data caches without automatic consistency control. So, if you write out some instructions and then jump to them, you can wind up executing garbage. (There are some variations on this. If the D-cache is pure write-through and you haven't earlier executed instructions from that address, you may be ok, at least if there is enough delay between writing and jumping. But, then you get into trouble when you do a GC, for example, rather than when loading. The 040 D-cache can be set to be either write-through or copy-back, I don't know which NeXT does. More on this at the end.) This is a standard problem to bite native-code-compiled lisp, ML, etc. implementors when moving to "upward compatable" architectures. If you execute random bits, usually you get the kind of behavior I noticed. However, sometimes you can trip over an OS or chip bug and crash the system. (In fact someone--I believe gjs--was circulating a program which tried to do just that.) The solution is to take advantage of the hooks that are already in Cscheme-7.1 to do appropriate cache flushing (some of the other supported architectures need such magic too.) This would mean defining the macros FLUSH_I_CACHE and FLUSH_I_CACHE_REGION in the cmpint-mc68k.h file. Of course, if the 040 magic is inappropriate for 020's and 030's (likely) some way to conditionalize on the specific member of the 68k family will need to be found. I hope this sheds some light. I also hope it is right; the observant reader will have noticed that it is based on speculation: I don't know much about how NeXT uses the 040 cache architecture. As I mentioned earlier, the D-cache can be set up either for copy-back or write-through. Also, the I and D caches can be disabled, etc. Does anybody know (or know where its documented) what NeXT does with this stuff (the "CM" field of the "transparent translation" registers controls the write-through/copy-back behavior, the "cacr" (cache control register controls enable/disable etc.)? Further, does anyone know what magic you have to do to flush (selectively or completely) the I-cache? And, if the D-cache is copy-back, do you then have to manually cause it to be copyed-back? How? Thanks.