WEDNESDAY DEC 26,1973 NM+2D.6H.21M.49S. LISP 707 - GLS -
BRIEF SYNOPSIS:
[1] "APPLY FRAMES" ARE PUSHED BY APPLY AND UUO HANDLER
[2] NEW VARIABLE IN BLISP: *PURE CONTROLS PURE FREE STORAGE
[3] RPLACA/RPLACD NOW DO SOME ARGUMENT CHECKING
[4] IN BLISP, GC-OVERFLOW IS WHAT USED TO BE GC-LOSSAGE (MAX)
[5] (STATUS NEWLINE) RETURNS ASCII VALUE OF NEWLINE CHARACTER
[6] LISP NOW KNOWS ABOUT (INIT) DIRECTORY; STANDARD INIT FILES
[7] GETCOR SUBROUTINE TO ALLOCATE CORE FOR HAND-CODED LAP USERS
----------------------------------------------------------------
[1] THERE ARE NOW TWO VARIETIES OF EVALFRAMES: ONE IS THE USUAL
EVAL FRAME, AND THE OTHER IS CALLED AN "APPLY FRAME".
THE FORMER IS PUSHED BY ENTRIES TO EVAL, THE LATTER BY
ENTRIES TO APPLY. ALSO, THE UUO HANDLER WILL NOW PUSH ONE
OR THE OTHER KIND OF FRAME IF IT CAN (USUALLY AN APPLY
FRAME); THUS COMPILED CODE CALLS CAN BE BETTER DEBUGGED WITH
BAKTRACE AND EVALFRAME ALSO (PROVIDING *RSET AND NOUUO ARE
BOTH ON, OF COURSE).
THE DIFFERENCE BETWEEN AN EVAL FRAME AND AN APPLY FRAME IS
THAT AN EVAL FRAME CONTAINS A FORM, WHILE AN APPLY FRAME
CONTAINS A FUNCTION AND A LIST OF (PRESUMABLY ALREADY
EVALUATED) ARGUMENTS. THE EVALFRAME FUNCTION HAS BEEN
ALTERED ACCORDINGLY; IT NOW RETURNS A 4-LIST INSTEAD OF
A 3-LIST. THE CAR OF THIS LIST IS ONE OF THE SYMBOLS
"EVAL" OR "APPLY"; THE CADR IS THE FRAME POINTER (THE
CAR OF THE OLD 3-LIST); THE CADDR IS A FORM FOR AN EVAL
FRAME (AS BEFORE), BUT FOR AN APPLY FRAME IS A 2-LIST OF
THE FUNCTION AND THE LIST OF ARGUMENTS; AND THE CADDDR IS
THE A-LIST POINTER (THE CADDR OF THE OLD 3-LIST).
EXAMPLE: IF AN EVAL FRAME WERE CREATED FOR (FOO 'A 'B)
THEN EVALFRAME WOULD RETURN
(EVAL <FRAME PTR> (FOO (QUOTE A) (QUOTE B))
<A-LIST PTR)
BUT IF AN APPLY FRAME WERE CREATED (SAY BY THE
UUO HANDLER), THEN EVALFRAME WOULD RETURN
(APPLY <FRAME PTR> (FOO (A B)) <A-LIST PTR>)
NOTE THAT IN EITHER CASE CAADDR OF THE 4-LIST GIVES YOU
THE FUNCTION THAT WAS INVOKED.
OF COURSE, ALL THIS STUFF HAPPENS ONLY IN *RSET MODE, AND
FOR THE UUO STUFF TO WORK NOUUO SHOULD BE NON-NIL ALSO.
[2] IN BLISP, THE CONTROL OF AUTOMATIC USE OF PUR FREE STORAGE
HAS BEEN TRANSFERRED FROM THE VARIABLE "PURE" TO THE
VARIABLE "*PURE". "PURE", AS BEFORE, STILL CONTROLS THE
PURE CODE GENERATION AND XCT PAGES HACKERY SUPPORTED BY
FASLOAD. *PURE SHOULD BE NON-NIL ONLY WHEN LOADING UP A
SYSTEM TO BE SUBSEQUENTLY :PDUMP'ED; IT CAUSES CERTAIN
KINDS OF THINGS TO BE PLACED IN PURE FREE STORAGE SO THAT
THEY WILL BE SHARED IN THE NEW SYSTEM. AMONG THE THINGS THAT
WILL BE AUTOMATICALLY PURIFIED:
CONSTANT LIST STRUCTURE USED BY COMPILED CODE
PNAMES OF ALL INTERNED ATOMIC SYMBOLS
VARIOUS OTHER THINGS MAY OR MAY NOT BE PURIFIED; I AM STILL
EXPERIMENTING WITH THIS HACK. HOWEVER, ITS ACTIONS WILL
ALWAYS BE CONSISTENT WITH THE IDEA OF LOADING UP AND
:PDUMP'ING A LARGE SYSTEM (E.G. MACSYMA). AGAIN, THE CORRECT
USE IS:
(SETQ *PURE T) ;MAYBE ALSO SETQ PURE
--- LOAD UP SYSTEM ---
(SETQ *PURE NIL) ;HOWEVER, NEEDN'T CHANGE PURE
(MACDMP ':PDUMP/ <WHEREVER>/
)
[3] RPLACA, WHEN CALLED INTERPRETIVELY, OBJECTS TO CLOBBERING
ANYTHING BUT AN IMPURE LIST CELL. RPLACD OBJECTS TO
CLOBBERING ANYTHING BUT AN IMPURE LIST CELL OR AN ATOMIC
SYMBOL. (RECALL THAT THESE ARE OPEN-CODED BY COMPLR.)
[4] THE GC-LOSSAGE INTERRUPT NOW RECEIVES NOT A LIST, BUT
ONLY THE NAME OF A SPACE (AS NON-BIBOP USED TO, AND NOW
DOES AGAIN). THIS CORRESPONDS TO WHAT FORMERLY WAS
INDICATED BY (<SPACE> MIN). THE MAX CASE IS NOW FIELDED
BY A NEW USER INTERRUPT (NUMBER 13.) CALLED GC-OVERFLOW.
THIS IS NOT AN ERROR BREAK INTERRUPT, THOUGH THE DEFAULT
HANDLER DOES DO A ;BKPT GC-OVERFLOW. INSTEAD, IT IS MORE
AKIN TO THE GC-DAEMON, THE DIFFERENCE BEING THAT GC-DAEMON
RUNS AFTER EVERY GC, WHILE GC-OVERFLOW RUNS ONLY WHEN
A GCMAX PARAMETER HAS BEEN EXCEEDED. .INFO.;BIBOP (MEMO)
REFLECTS THESE CHANGES, IN EFFECT AS OF BIBOP LISP 696.
NOTE THE GREAT SIMILARITY OF GC-OVERFLOW TO PDL-OVERFLOW;
IN PARTICULAR, SINCE GC-OVERFLOW IS NOT AN ERROR BREAK,
SAYING $P DOES NOT ERROR OUT TO TOP LEVEL, BUT RATHER
CONTINUES THE COMPUTATION. YOU MUST USE ^G OR SOMETHING
TO QUIT. NOTE THAT IF YOU SAY (SETQ GC-OVERFLOW NIL)
YOU WILL NEVER SEE ANYTHING WHEN A GCMAX IS EXCEEDED,
AND GC WON'T COMPLAIN; HOWEVER, MEMORY WILL BE EXPANDED
IN AN INCREDIBLY INEFFICIENT MANNER. THE FILE
ML:GLS;BIBOP GCOVER CONTAINS A SAMPLE GC-OVERFLOW HANDLER
(A REWORKED COPY OF THE OLD GC-LOSSAGE EXAMPLE).
NOTE THAT ALL THIS SHOULD CORRECT THE PROBLEM OF GC-LOSSAGE
INSIDE AN ERRSET.
[5] (STATUS NEWLINE) RETURNS 13. IN PDP-10 LISP, BUT 10. ON
MULTICS; THAT IS, IT RETURNS THE ASCII VALUE OF THE NEWLINE
CHARACTER FOR WHATEVER SYSTEM YOU'RE ON. THIS SHOULD RELIEVE
SOME INCOMPATIBILITIES.
[6] LISP WILL NOW USE THE (INIT) DIRECTORY TO FIND LISP INIT
FILES. THERE ARE TWO CASES:
[A] IF YOU GAVE THE LISP JCL, BUT LEFT THE SECOND FILE
NAME TO BE (INIT), AND THE SPECIFIED FILE DOESN'T
EXIST, THEN LISP PERMUTES FOO;BAR (INIT) TO BE
(INIT);FOO BAR AND LOOKS FOR THAT FILE. IF THIS
FAILS, LISP GETS UNHAPPY AND REVERTS TO THE TTY.
EXAMPLE:
:LISP FOO;
WOULD FIRST LOOK FOR FOO;.LISP. (INIT),
AND THEN FOR (INIT);FOO .LISP.
NOTE THAT IF YOU GIVE TWO FILES NAMES FOR JCL, LISP
WILL NOT LOOK AT THE (INIT) DIRECTORY, SINCE THE SECOND
FILE NAME WILL NOT BE (INIT). THUS
:LISP FOO BAR
WOULD NOT LOOK AT THE (INIT) DIRECTORY IF FOO BAR
DIDN'T EXIST, BUT
:LISP FOO;BAR
WOULD (IT WOULD LOOK FOR (INIT);FOO BAR, PROVIDED
THAT FOO;BAR (INIT) DIDN'T EXIST).
[B] IF YOU GAVE LISP NO JCL, BUT TYPE ^Q OR ^W AT
THE ALLOC? QUESTION, THEN LISP LOOKS FIRST FOR
<YOUR SNAME>;.LISP. (INIT), AND IF THAT FAILS, FOR
(INIT);<YOUR SNAME> .LISP.
FOR CONVENIENCE THERE ARE TWO FILES ON (INIT) CALLED
"DOCTOR .LISP." AND "INDEX .LISP.". THUS TO GET A
DOCTOR YOU NEED ONLY SAY TO DDT
:LISP DOCTOR;
AND TO GET AN INDEX (WITH CORE=60)
:LISP INDEX;
NOTE: THE SEMICOLONS ARE IMPORTANT!
[7] THERE IS A LITTLE ROUTINE INTERNAL TO LISP FOR THE BENEFIT
OF HAND-CODED LAP LOSERS TO GOBBLE UP BLOCKS OF CORE. IT IS
INVOKED AS FOLLOWS (NATURALLY, YOU SHOULD HAVE LISP SYMBOLS
LOADED INTO DDT WHEN YOU LOAD UP THE LAP):
(MOVEI TT <NPAGES>) ;NUMBER OF 1K PAGES DESIRED
(PUSHJ P GETCOR) ;RESERVES A BLOCK OF CORE
(JUMPE TT LOSE) ;RETURNS 0 IN TT IF LOST
... ;ELSE TT HAS LOW ADDRESS OF BLOCK
ACCUMULATOR TT SHOULD HAVE THE AMOUNT OF CORE DESIRED,
MEASURED IN 1K PAGES. IF GETCOR WINS IT WILL RETURN THE
LOW ADDRESS OF A CONTIGUOUS BLOCK OF THE SPECIFIED SIZE
IN TT; OTHERWISE IT WILL RETURN 0 IN TT. GETCOR RESERVES THE
RIGHT TO SMASH ANY ACCUMULATORS IT WANTS TO, SO BE CAREFUL!
NOTE WELL: GETCOR MERELY RESERVES ADDRESS SPACE; IT DOES NOT
ACTUALLY CAUSE THE CORE TO APPEAR. THUS IT IS UP TO THE
CALLER TO DO *CBLK'S TO GET THE CORE, OR MAP IT INTO PDP-6
OR PDP-11 MEMORY, OR WHATEVER. GETCOR MERELY CAUSES LISP TO
PROMISE NOT TO USE THAT SECTION OF THE ADDRESS SPACE FOR
ANY OTHER PURPOSE. SUCCESSIVE CALLS TO GETCOR WILL RETURN
DISJOINT AND NOT NECESSARILY CONTIGUOUS BLOCKS OF CORE.
THERE IS NO PROVISION FOR RETURNING A BLOCK OF CORE WHEN
YOU'RE DONE WITH IT. THIS ROUTINE EXISTS IN BOTH NON-BIBOP
AND BIBOP LISPS; THOSE PEOPLE WHO HAVE JUST BEEN GRABBING
PAGES OF HIGH CORE IN NON-BIBOP LISP SHOULD CHANGE THEIR CODE
TO USE GETCOR SO THAT IT WILL RUN IN BIBOP LISP.
EXAMPLE:
(MOVEI TT 10)
(PUSHJ P GETCOR) ;GET CORE
(JUMPE TT LOSE) ;LOSEY LOSEY
(MOVEI D 10) ;SO MAP 8. PAGES
(MOVE R (% 0 0 001777 600030)) ;MAGIC NUMBER
(MOVEI F 0 TT) ;F GETS LOW ADDRESS OF BLOCK
(LSH F -12) ;NO, MAKE THAT THE PAGE #
LOOP (*CALL 0 11MAP) ;MAP A PAGE
(*VALUE)
(ADDI F 1) ;INCREMENT STUFF
(ADD R (% 0 0 0 4))
(SOJG D LOOP)
...
11MAP (SETZ) ;MAGIC CALL TO MAP A PAGE
(SIXBIT T11MP)
(F)
(SETZ 0 R)
THIS EXAMPLE MAPS THE MEMORY OF THE PDP-11 DISPLAY INTO AN
8K BLOCK OF MEMORY IN LISP SO THAT OTHER ROUTINES CAN MUNG
THE DISPLAY, PRESUMABLY. THE ADDRESS OF THE LOW END OF THE
8K BLOCK IS STILL IN ACCUMULATOR TT.