KL-10 (especially TOPS-10) incompatibilities for MacLISP

[JONL at MIT-MC (Jon L White)]

I think I've finally fixed that old "snag", the lack of compatible
double-precision floating-point instructions on most KL-10's.  I've
CC'd this note to several people, since  Mark Miller made a rather
long comment about this problem last month:
    Date: 23 September 1980 23:27-EDT
    From: Mark L. Miller <MILLER at MIT-AI>
    Subject: MacLISP's Floating point
    cc: KEN at MIT-AI, GJS at MIT-AI, PHW at MIT-AI, TBlocker at BBNA,
	MMiller at BBNA, ben at MIT-ML, BUG-LISP at MIT-MC,
	BRoberts at BBNC
    .  .  .
So in reply to Bob Meacham's note:
    Date: 16 Oct 1980 0542-PDT
    From: Cjohnson at SUMEX-AIM
    Subject: MAClisp installation at ORNL
    .  .  .
    I almost immediately got the message "?KA10 floating point instruction at
    user PC 441351"  DDT examination revealed the command "FADL  7,10".
    Our 3 CPUs are KL-10s, and we are currently running version 7.01 of the
    TOP-10 monitor.  Under this version, the monitor command "set float on"
    will translate the FADL instruction to something acceptable, but under
    the 7.02 monitor whose pre-release version we will receive in January
    even this temporary fix will disappear.  So that's snag #1, I guess - I
    need to get the FADL (which I guess MIDAS puts in there?) replaced by
    something legal.
    .  .  . 
Finally! This is just the information I needed to find out what was
wrong -- its only the lack of a true FADL, FDVL, etc on most KL-10s which
cause thhe problem.  So I've just assembled a new lisp here at MIT-MC which
has a run-time test for being on a KL-10, and uses appropriate versions of
double-precision instructions.  Likely, by tomorrow this time, I'll have
the TOPS-10 and TOPS-20 versions updated, and hoopefully some redistribution
can begin.  As for your other complaint:
    Now snag #2 is more mysterious to me.  When I did "set float on" and then
    .  .  . 
    ?Illegal UUO at user PC 436207
    DDT revealed 436206 was HRRZ  12,0(12)  and 436207 was just 0,,436211
    .  .  .
	    Cordially, Robert Meacham
Most likely this is due to an administrative limit on the maximum size of 
"core" (really, "address space") used by a job on your TOPS-10 system -- 
many system managers set a ridiculously low limit, which makes it impossible 
to load up any significant application into MacLISP; but it shouldn't matter
since you are no doubt running the VM system.  True, it is a bug that MacLISP
doesn't die more gracefully, but there are so many more important things
to work on first ....