perm filename AIL.MSG[S,AIL]3 blob sn#223229 filedate 1976-07-04 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00050 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00007 00002	
C00008 00003	∂04-JUN-75  0540		CS,MJC
C00029 00004	∂6-DEC-74  1555		CMU SAIL optimizer
C00031 00005	∂27-DEC-74  1114	CMU Array origin problem
C00032 00006	∂28-DEC-74  1824	CMU =E1= Self-modifying code in FORTRAN calls
C00033 00007	∂11-FEB-75  1111	CMU HASHP string refitem bug
C00034 00008	∂17-FEB-75  1128	CMU grabbing SAIL
C00035 00009	∂21-FEB-75  0716	CMU Kudos for SAIL-8
C00037 00010	∂24-FEB-75  1456	CMU introduction to Hedrick
C00042 00011	∂25-FEB-75  0713	CMU Hedrick again
C00043 00012	∂27-FEB-75  1023	CMU =E3= LEPRUN bug, fix
C00044 00013	∂28-FEB-75  0740	CMU =E4= CVASTR not in FOO2
C00045 00014	∂07-MAR-75  1653	ECL desires Fortran-10 calling sequence
C00046 00015	∂08-MAR-75  0834	CMUA Library symbol problem
C00048 00016	∂09-MAR-75  1305	CMU =E5= DRYROT at EVAR
C00049 00017	∂11-MAR-75  2145	CMUA Ruven Brooks library symbols resolved
C00050 00018	∂28-MAR-75  1846	CMU =E6= storage management policy
C00055 00019	∂29-MAR-75  0202	RHT reply to SAIL library proposal
C00062 00020	∂02-APR-75  0813	Hedrick's diatribe
C00066 00021	∂02-APR-75  0847	Hedrick requests 20K SAIL
C00068 00022	∂02-APR-75  1602	RHT reply to 20K SAIL
C00073 00023	∂13-APR-75  0648	CMU Storage allocation policy measurements
C00075 00024	∂21-APR-75  1530	CMU =E8= LISTX should not be BILTIN
C00076 00025	∂06-AUG-75  1255	1,JED   network site OFF garbage message
C00077 00026	∂27-AUG-75  1244	1,JFR CHECK!TYPE(record class)
C00078 00027	∂22-SEP-75  1925	CMU =F1= =F2= LENGTH(PHI) EXTERNAL ARRAY in SIMPLE PROCEDURE
C00080 00028	∂07-OCT-75  1115	Glenn Ricart @ NBST  block names
C00082 00029	∂07-OCT-75  1121	Glenn Ricart @ NBST  UNTYPED ITEMVAR OUGHT TO BE TYPED
C00084 00030	∂03-NOV-75  0634	CLO,JMG   bounds check on case statement (?)
C00085 00031	∂26-NOV-75  2114	REM '400000 000000 problems in compiler
C00086 00032	∂28-NOV-75  1631	1,DON mysterious DRYROT from compiler
C00087 00033	∂26-JAN-76  2344	MJC  	"T" to error handler SNAIL interface
C00088 00034	∂14-FEB-76  1304	FTP:LEE ERMAN(A610LE03)@CMUB	snarfing SAIL.  
C00089 00035	∂24-FEB-76  1237	FTP:SAIL(A700SA00)@CMUB	S,AIL files.    
C00090 00036	∂05-MAR-76  1702	FTP:SAIL(A700SA00)@CMUB	=F3= SCB clobbered
C00093 00037	∂06-MAR-76  2220	DLB   response string to USERERR lost
C00095 00038	∂09-MAR-76  1941	FTP:RSMITH at SUMEX-AIM	SAIL Bugs  
C00098 00039	∂12-MAR-76  1435	JFR  	code generated for LOP  
C00099 00040	∂13-APR-76  1543	FTP:LOW at SUMEX-AIM	SAIL BUG REPORT AND FIX.
C00100 00041	∂17-APR-76  1539	JFR  	SAIL bug, CASE expr used as stmt  
C00101 00042	∂22-APR-76  0627	DGR   via MTRT	DECUS Sail
C00103 00043	∂10-MAY-76  1938	FTP:LOW at SUMEX-AIM	CONTEXT BUG AND FIX
C00108 00044	∂14-JUN-76  0701	FTP:SAIL(A700SA00) at CMUB[LDE]	SAIL -> CMU. 
C00113 00045	∂22-JUN-76  1555	FTP:SAIL(A700SA00) at CMUB	another little CMU tweak.   
C00115 00046	∂26-JUN-76  0235	KS  	Subfield indices, continued   
C00123 00047	∂28-JUN-76  1535	FTP:SAIL(A700SA00) at CMUB	CMU bug report =F8=     LDE 
C00124 00048	∂03-JUL-76  1509	JRL   via IMSSSS	SAIL bug
C00125 00049	∂04-JUL-76  1305	SYS  	Your message file exceeds 10K words.  Unless you delete some messages,    
C00126 00050	∂04-JUL-76  1603	JRL   via IMSSSS	Check!type bug    
C00127 ENDMK
C⊗;
∂04-JUN-75  0540		CS,MJC
 BEGIN
 COMMENT The program below I think contains a Sail bug;
 REQUIRE 50 NEW_ITEMS;
 EXTERNAL PROCEDURE BAIL;  REQUIRE "SYS:BAIL.REL" LOAD_MODULE;
 SET X;
 
 RECURSIVE SET PROCEDURE XXX(SET X);
 BEGIN
     INTEGER ITEMVAR U;
     BAIL;
               COMMENT Dialog at first Bail call (semicolons removed)
               1:U
                  ITEM!139198464			What is this, anyway?
               1:X
                  {ITEM!9, ITEM!10, ITEM!11}
               1:!!GO;
     U←LOP(X);
     BAIL;
               COMMENT Dialog at second Bail call
               1:U
                  ITEM!139198464			Replacement apparently not done.
               1:X
                  {ITEM!10, ITEM!11}
               1:DATUM(U)
                  
               1:!!GO;
     RETURN(X);
 END;
 
 X←{NEW(1),NEW(2),NEW(3)};
 X←XXX(X);
 END;
∂19-MAY-75  1459		100,100: HEDRICK@CMUA @ ILL1
 WE HAVE TWO POSSIBLE BUGS IN SAIL.  FIRST, TYPEIT SEEMS TO BE MISSING
 FROM LIBSA, BOTH VERSION 7 AND VERSION 8.  IT IS IN SAISG, SO THERE IS
 NO PROBLEM RUNNING PROGRAMS (WE JUST USE /Y IN LOADING).  SECOND, THE
 ARGUMENT LPARRAY FOR CHECK!TYPE SEEMS TO BE MISSING.  WE WANT TO
 SEE WHETHER SOMETHING IS AN INTEGER ARRAY ITEMVAR.  COMPARING IT
 WITH CHECK!TYPE(INTEGER ITEMVAR) IS OBVIOUSLY NOT QUITE RIGHT.  BUT
 INTEGER ARRAY ITEMVAR GIVES A SYNTAX ERROR.  WE ASSUMED THAT WHAT WAS
 REALLY NEEDED WAS INTEGER LPARRAY ITEMVAR.  THAT ALSO GIVES AN ERROR.
 WE HAVE TRIED VARIOUS THINGS AND FINALLY GIVEN UP.  WE NOW DO LOR OF
 [PLESE IGNORE LAST PARTIAL SENTENCE.]
 WE NOW DEFINE TWO DUMMY ITEMVARS, ONE INTEGER ARRAY ITEMVAR, AND THE
 OTHER REAL ARRAY ITEMVAR.  BY DOING LAND OF DECLARATION OF THEM, WE
 DERIVE THE BITS FOR ARRAY ITEMVAR.  THERE MUST BE A BETTER WAY!
 (I THOUGH LEAP!ARRAY MIGHT BE THE CORRECT VERSION OF LPARRAY. HOWEVER,
 INTEGER LEAP!ARRAY ITEMVAR HAS THE SAME BIT PATTERN AS INTEGER ITEMVAR.
 LEAP!ARRAY TURNS OUT TO BE THE SAME AS ITEMVAR TO CHECK!TYPE.)
 WE ARE USING THE CMU SAIL SYSTEM.  OUR VERSION 7 IS TAKEN DIRECTLY
 FROM THEM, VERSION 8 USES THEIR SOURCES WITH SOME MINOR MODIFICATIONS
 TO HANDLE ERROR PROCESSING APPROPRIATELY FOR OUR ENVIORNMENT.
 
 ALSO, IN MAKING THE SOURCE MODIFICATIONS I HAVE RUN INTO PROBLEMS FIGURING
 OUT HOW YOU GET VARIABLES IN THE RUNTIMES.  WHEN I TRIED TO ADD A NEW ONE
 IT ONLY GOT ADDED TO THE COMPILER, NOT THE RUNTIMES, OR SOMETHING LIKE THAT.
 IS THERE A DOCUMENT THAT DESCRIBES YOUR PROGRAMMING CONVENTIONS.
 (E.G. THE IMPLEMENTATION MANUAL.)  IF SO, I WOULD APPRECIATE GETTING A
 COPY (PREFERABLY) OR A FILE NAME.  I FINALLY ENDED UP USING AN EXISTING
 VARIABLE (PPMAX) THAT SEEMED TO BE USED ONLY IN THE EXPORT SAIL SOS
 LINKAGE.  IF YOU KNOW OF ANY TROUBLE THAT WILL BE CAUSED BY MY CODE
 PLAYING WITH THIS VARIABLE (I HAVE REPLACED THE EXPORT SOS LINKAGE),
 I WOULD APPRECIATE HEARING ABOUT IT.  
 
 THANKS,
 CHARLES L. HEDRICK
 COORDINATED SCIENCE LAB
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
 URBANA, ILL 61801
 $
 



∂12-MAY-75  0303		1,MJC
 PROFIL seems not to like lower-case switches.

∂07-MAY-75  1555		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report =E9=	LDE 7-May-75
 	In a construct like:
 		S←SAR[I]←SPROC;
 	where S is a string, SAR a string array with variable bounds,
 	and SPROC a string procedure, bad code gets generated for the
 	second store (S←SAR) which causes a PDL OV.  The address of SAR
 	gets stored in a temp (over the call to SPROC) with a HRRZM --
 	it is then moved back into a reg with a MOVE, then POPed into
 	S, which causes the PDL OV.
 		E9.SAI[CMU,AIL] and [A700SA00] is a simple example.
 -----
 

∂20-JUL-74  2037		MAP,RF
 IN SAIL, WHAT SHOULD I ← (J ← 3) + (J ← 4)
 RETURN FOR I?  I HAVE THE NASTY FEELLNG IT GETS 8.



∂28-JUN-74  2013		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 To:	SAIL types
 From:	ERMAN@CMU-10
 Re:	mods to GOGOL, IOSER, and PARSE
 Date:	28-Jun-74
 
 
 I have made some fairly trivial fixes to error handling, but
 would like to see them get into your S,AIL files so they
 won't get lost.
 The fixes are described below.  I'm sure that
 none could be objectionable.
 
 The sources can be found on CMU,AIL as follows:
 
 PARSE.PRT -- the change for PARSE.
 IOSER.PRT -- contains replacements for pages 6,7,&9 of IOSER.
 GOGOL.PRT -- gives the three changes for GOGOL.
 
 =C2=	[GOGOL/32] LDE (28-Jun-74)
 	Allow call SOS in RPG mode if no file-name specified.
 	(Totally within CMUSW.)
 
 =C3=	[GOGOL/29, PARSE/22] LDE (28-Jun-74)
 	Under NOSTANFO, when printing error messages, translate
 	under-bar into "!" and not-equals into "#".  This is much
 	better for non-stanford terminals (although could be
 	made more general).
 
 =C4=	[IOSER/6,7] LDE (28-Jun-74)
 	Allow null PPN within [] and allow nulls within PPNs, in
 	FILNAM.  (The second occurs frequently at CMU since CVSTRs
 	are often done on PPNs.)
 
 =C5=	[IOSER/9] LDE (28-Jun-74)
 	Allow lower-case "r" response when device not available in OPEN.
 
 =C6=	[GOGOL/31] LDe (28-Jun-74)
 	Allow lower-case file names when specifying an "E" response
 	in an error message.
 
 
∂25-JUN-74  0124		THE,JRL
 Ralph has complained about the fact that SAIL does not reduce
 CORE size between compilations.
 Also when we have $PDLOV cause an pdlov there is no indication
 as to which stack really overflowed. E. g in procedure entry
 sequence.
 		Add	p,[xwd mumble, mumble]
 		skipl	p
 		jsp	15,$pdlov

 $pdlov causes an overflow with 14 as stack pointer. User gets
 no indication that problem was really with p.


∂24-MAY-74  1125		NET,GUE AT TTY122 : C.BACON @  network site NBST
 SAIL COMPILER BUG:
 THE FOLLOWING SEQUENCE--
 BP ← POINT (6, FOO, -1);
 FOO ← GEORGE;
 IDPB (0, BP);
 GEORGE ← FOO;
 --  RESULTS IN NO APPARENT CHAGE TO FOO OR GEORGE.
 REASON SEEMS TO BE THAT SAIL 'KNOWS' THAT FOO IS STILL COPIED
 IN AN AC, AND DOESN'T NEED TO   MOVE  AC,FOO   BEFORE MOVEM'ING.
 OH, WELL, I CAN ALWAYS GET AROUND IT.
 
 FROM C. BACON, N.I.H. DCRT.  BETHESDA, MD.  INITIALS CRB.
 

 
∂25-MAY-74  1000		1,RS
 RUSSELL,
 	On your desk I have left a listing of SAILOW.SRC.
 it shows the effects of what we did.  As far as I can tell,
 all of the globals that are linked to from the user's program
 are ok.  P.S.  What happens when users declare things EXTERNAL
 and link to them when they are not in the HERE table -- it
 is just the user's own fault for being so dump??
 			bob

∂01-MAY-74  0221		1,JMG
 I seem to get "DRYROT AT EFORM" and cure it without any seeming rationality.
 If this is of further interest, mail me a mssg and I'll point to the file.
 				- jmg.

∂29-APR-74  1244		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report =B8=.   LDE 29-Apr-74
 	Bug fix #RN is not complete -- see short file
 	PROTAC.SAI[CMU,AIL] or [A700SA00] for a test case.
 	It complains about protecting AC's again.
 
∂24-MAR-74  0940		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report  =B5=.  LDE 24-Mar-74.
 	Can get "illegal real constant" errors inside an IFCR FALSE
 	with a construction like "..".  See IFCRBG.SAI[CMU,AIL].
 
∂19-MAR-74  1125		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 00100	RUSS AND OTHERS,
 00200		WHAT IS THE STORY WITH "A" AS AN ERROR RESPONSE  THE CODE
 00300	LOOKS LIKE IT MEANT TO INCLUDE "A", BUT THERE IS A CAILE A,15 THAT
 00400	ONLY LETS LINEFEEDS THROUGH (GOGOL 7400/27).  USING "A" HERE SETS
 00500	THINGS UP SO THAT ONE GETS THE EFFECT OF LINEFEED, BUT ONLY AFTER
 00600	BEING COMPLAINED AT, AND HAVING TO TYPE SOMETHING ELSE BACK FIRST.
 00700	WHAT'S THE CASE THERE?
 00800					PADDY

∂15-MAR-74  1654		network site MAXC
 Date: 15 MAR 1974 1656-PDT
 From: SPROULL at PARC-MAXC
 Subject: Another SAIL bug
 
 - - - -
 I have just received information from NIH to the effect that SAIL 
 crashes the new release of 5.07/6.01 (DEC system).  The rason,
 it appears, is that the first few locations of the high segment
 (the vestigial job data area) are all -1.  Glenn Ricart reports
 that making them '0'  (i.e. the first 8 locations in the high seg)
 cures the problem altogether.
 
 I think this should be put in.
 		bob
 -------

∂15-MAR-74  1652		network site MAXC
 Date: 15 MAR 1974 1654-PDT
 From: SPROULL at PARC-MAXC
 Subject: SAIL BUG
 
 - - - -
 The following program fucks up looking for a global value.
 The problem is that the 'move 2,1(2)' at d+2 should be 
 (I think....) a 'move 2,(2)' to look back up the stack.
 See what you think.
 
 00100	begin "bug"
 00200	procedure a(integer i;reference procedure p);
 00300	p(i);
 00400	
 00500	procedure t(integer i);
 00600	begin procedure d(reference integer i);
 00700		outstr("i="&cvs(i));
 00800	
 00900	a(i,d);
 01000	end;
 01100	
 01200	t(22);
 01300	end
 
 
 By the way, I would appreciate acknowledgement of my bug reports
 so that II know that they have been received.
 
 Good luck.
 			Bob
 -------
 


∂11-MAR-74  1957		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 Continuing bug report.  CMU LDE 11-Mar-74
 	There is still a problem with expanding string space in
 the compiler.  Unfortunately, we only seem to get it in our
 humongous HEARSAYII compilations, which use about 20 or 25
 different source files.  Our compiler has all the purported bug
 fixes for this -- in fact we brought over a complete set of
 source files from S,AIL within the last two weeks.  If we find
 a more compact program that pokes at it, we'll ship it over
 and let you know.  If someone there gets ambitious and wants to
 poke at our thing over the net, we will be glad to give assistance.
 I suspect that DCS has some ideas on what the problem might be
 (see his message along with a bug that he set up for it -- about
 QF, I think).
 		cheers,
  
∂06-MAR-74  1144		CMU,AIL
 How much of feats if honest?  Specifically, %AG, which is in the files, but
 has no OK, and isn't in the documentation.
 PB01

∂5-MAR-74  1040		network site CMU
 CMU BUG REPORT, WITH FIX.  LDE=B2=	[GOGOL/46] LE03 5-Mar-74
 	In STRNGC, when releasing old string spaces, DCS was accessing
 	the header of the space after he released it (with a CORREL) --
 	this caused ILL MEM REF when the core happened to have really
 	gone away.  Fix required no more code.
 
 RELLUP:	MOVEI	B,-.HDRSIZ(A)		;Release any spaces which are
 ;;=B2=	LDE CMU 5-MAR-74	BETTER NOT ACCESS IT AFTER IT GOES AWAY
 ;	PUSHJ	P,CORREL		; apparently no longer necessary.
 ;	SKIPE	A,.NEXT(A)
 ;	 JRST	 RELLUP
 	MOVE	A,.NEXT(A)
 	PUSHJ	P,CORREL
 	JUMPN	A,RELLUP
 ;;=B2=
  
∂05-MAR-74  0804		CMU,AIL
 PEOPLE:
 	IF YOU ARE BRINGING OR HAVE BROUGHT UP A SAIL MANUAL UPDATE, I
 WOULD APPRECIATE KNOWING ABOUT, AS I AM DOING THE SAME.  SEND MAIL TO
 BANWELL OR SAIL ON THE CMU/B.
 				PB01
 
∂25-FEB-74  1525		R,AJT
 HOW ABOUT A BETTER ERROR MSG FOR "APPLY(ITM,LST)"
 (NEED DATUM(ITM) HERE).   RHT
 

∂22-FEB-74  1034		network site CMU
 Poke from CMU re two bugs that were reported and seemingly ignored:
 (LDE 22-Feb-74)
 
 =A1=
   This is the fact that once a break table is put into "K" (convert
 to upper case) mode, there is no way to reset it.  The fix is simple
 enuff:
   Add a new mode, "F" (Full character-set mode), which is the
 "default" and add the following three lines of code needed:
 
 [IOSER/25]
 1)  change  	XWD NOLINS,ILLSET	;n,,-
     to		XWD NOLINS,LCASE	;n,,f
 
 2)  add at the bottom of the page (following UCASE code):
 	LCASE:	MOVSS  B
 		ANDCAM B,BRKCVT(USER)
 		JRST  RESTR
 
 
 
 =A7=
 	At SGSORT, it is not(!) checking for null strings, thank you.
 It  used to  before DCS  put in dynamic  string space.  Some run time
 routines do create null strings  that are not marked as constants and
 which do not have legal addresses.  (In particular, Realscan seems to
 do this.) In addition, the old manual used to state that if the count
 is zero, then the address is ignored. In any case, something needs to
 be done to this.
 
∂05-FEB-74  1412		THE,RHT
 REG SENT ME SOME BUGS IN THE MANUAL.  THE MESSAGES WERE SENT TO MSGLOG[S,AIL]
 

∂5-FEB-74  0816		network site CMU
 CMU Sail bug report (low priority)	=A6=	LDE 5-Feb-74
 	A NEEDNEXT block with no NEXT in it gets a dryrot at FBOUT.
 	(Joe Newcomer bug.)
 
∂29-JAN-74  0746		CMU,AIL
 THE FIX FOR CMU =A1= IS:
 	XWD	NOLINS,LCASE	;N,,F
 IN PLACE OF WHAT IS NOW 3000/25 IN IOSER, AND
 	LCASE:	MOVSS 	B
 		ANDCAM	B,BRKCVT(USER)
 		JRST	RESTR
 AFTER UCASE, AT THE END OF /25 IN IOSER.   PADDY

∂28-JAN-74  1539		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 00100	BUGS IN IOSER
 00200		=A1=: ONCE TURNED ON, UPPER CASE CONVERSION CAN'T BE TURNED
 00300	OFF.  USE OF LCASE GIVES AN ERROR MESSAGE OF UNDEFINED.  THIS IS ON
 00400	PAGE 26 OF IOSER.
 00500		=A5=: WHEN SIMIO INDICES WERE CHANGED BACK TO THEIR OLD
 00600	ORDER, THE USBTST TABLE WAS NO LONGER CORRECT.  OUR FIX WAS TO ADD
 00700	A DUMMY WORD BETWEEN THE TWO ENTRIES.   LE03 & PB01
 00800	
  
λ
∂6-DEC-74  1555		CMU SAIL optimizer
 ***** FTP mail from [A610LE03] (ERMAN)
 Russ,
 
 There are some noises here about creating a post-SAIL code
 optimizer along the lines of FINAL in BLISS.  The claims here
 are that it should be fairly trivial to program.  The input
 it needs are pointers to all the pieces of code and a description
 of all points that are "labels" (i.e., jump receive locations).
 The guess is a saving of about 30% in code space and probably
 about the same (or slightly less) in runtime.
 
 The hope is that the .REL file and the output produced for BAIL
 should be sufficient to drive the beast (possible names:
 DINGY, TRIM, CRANK, WINCH, STERN, BILGE, BOUY ?).
 
 We seem to have a real need of it for HearsayII -- it's growing
 ridiculously big and any significant help would be great.
 
 Anyhow, I thought I'd let you know that something might be up.
 If you or anyone there has any interest, we would appreciate
 hearing from you.  There is some possibility that we would be
 interested in "commissioning" some non-CMU SAIL expert to produce
 such a goody.
 
 thanx,
 	Lee
 -----
 


∂27-DEC-74  1114	CMU Array origin problem
 ***** FTP mail from [A610LE03] (ERMAN)
 Russ,
 
 We have one program that generates the following compile-time
 error msg at several array declarations:
 "VIRTUAL ORIGIN OF OUTER-BLOCK OR OWN ARRAY BEFORE START OF REL FILE
 PROCEED AT YOUR PERIL".
 We can't figure out what this means.  Can you give us a clue?  (We
 proceed and our peril does not seem to be compromised.)
 
 thanks,
 	Lee
 -----
 
∂28-DEC-74  1824	CMU =E1= Self-modifying code in FORTRAN calls
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report =E1=   LDE 28-Dec-74
 	SAIL generates self-modifying code for Fortran calls with
 	reference arguments when an array element is passed.  Does
 	not work very well when compiled with /H and tries to run
 	in write-protected hi-segment.  In the very least, it could
 	put out a warning msg.  See FORTR.SAI[CMU,AIL] & [A700SA00]
 	for an example.
 ------
 
∂11-FEB-75  1111	CMU HASHP string refitem bug
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report (and fix) =E2= [LEPRUN/32] LDE 10-Feb-75
 	When returning string ref-items to the HASHP list, was
 	not zeroing out the first word of the string pointer.
 
 At DLSREF in LEPRUN, there should be a
 	SETZM -1(C)
 
 Being somewhat insecure about such matters, I would appreciate
 a confirmation of this.
 	thanx.
 -----
 
∂17-FEB-75  1128	CMU grabbing SAIL
 ***** FTP mail from [A610HS12] (HSII)
 We are ready to grap the S,AIL files to make a new SAIL at CMU.
 Any reason this is not a good time to do it (in terms of instabilities
 of those files)?
 
 thanx,
 	Lee Erman (ERMAN @ CMU-10B)
 -----
 
∂21-FEB-75  0716	CMU Kudos for SAIL-8
 ***** FTP mail from [A610LE03] (ERMAN)
 To:	Sail maintainers @ SU-AI
 From:	Lee Erman & Brian Reid @ CMU-10B
 Re:	Bringing up SAIL-8 at CMU
 
 Gentlemen:
 
 Never in our five years experience with bringing up SAIL systems at
 CMU have we had an easier time.  We grabbed the S,AIL files and the
 total time, including the several hours of FTP'ing did not really
 amount to very much.  Other than turning on the CMU switch and
 appropriately editing the comments in FOO2, there were no other mods
 we had to make.  We now have it up on SYS and, so far, there have
 been no problems.
 
                       THIS IS UNPRECEDENTED!!!!
 
 It can only be due the extreme care that you folks have been
 exercising recently at your end.  For that, we say THANK YOU and KEEP
 UP THE HIGH QUALITY.
 
 	your most humble and grateful servants,
 		Lee & Brian
 ------
 
∂24-FEB-75  1456	CMU introduction to Hedrick
		100,100: HEDRICK@CMUA @ ILL1
 LEE ERMAN HAS ASKED ME TO TELL YOU THAT THE COORDINATED SCIENCE LAB
 AT THE UNIVERSITY OF ILLINOIS (CSL) IS NOW USING SAIL.  WE HAVE
 
 SEVERAL USER, AND NOW THAT WE HAVE GOTTEN 25 MANUALS I EXPECT EVEN
 MORE.  OUR CURRENT VERSION WAS SHIPPED FROM CMU AS A FAILSAFE TAPE.
 I DID THIS RATHER THAN GET ONE OF YOUR EXPORT VERSIONS BECAUSE I
 UNDERSTAND THE PROCESS OF GENERATING A SAIL SYSTEM IS NOT TO BE
 UNDERTAKEN BY THE UNINITIATED.  I HAVE MODIFIED THE OBJECT CODE
 (USING MONITOR D COMMAND!) SO IT WRITES REGISTERS 11-16 INTO A
 TMPCOR:FILE WHEN TRANSFERRING TOT SOS (SINCE OUR MONITOR DOESN'T
 SAVE AC'S OVER A RUN, AND WE HAVEN'T IMPLEMENTED SRUN).  WE
 ALSO HAVE SOS PRETENDING TO BE LINED.  IF YOU WOULD LIKE TO MAIL
 MAGTAPES AROUND THE COUNTRY, I WOULD BE WILLING TO GET SAIL FROM
 YOU DIRECTLY, BUT OUR ARPANET CONNECTION IS NOT ABLE TO HANDLE
 SUCH LARGE AMOUNTS OF DATA (OR INDEED TO DO ANYTHING OTHER THAN
 CONTROL TTY'S UNLESS THE SENDER FOLLOWS THE UCLA CCN PROTOCOL.)
 IF YOU WANT TO DO THAT I WOULD LIKE YOU TO GIVE US AN ASSEMBLY
 SWITCH THAT BEHAVES LIKE CMU EXCEPT FOR USING TMPCOR: (AND
 NNNFOO.TMP IF THAT FAILS) TO PASS THE INFORMATION USUALLY PASSED
 IN THE AC'S.  (ALSO THE CMU PPN STUFF CAN GO, THOUGH IT DOESN'T
 CAUSE ANY TROUBLE.)  I AM PERFECTLY HAPPY WITH THE PRESENT ARRANGEMENT,
 HOWEVER, AND I CERTAINLY DON'T WANT TO GET MYSELF INTO A MAJOR JOB
 TO GENERATE NEW SYSTEMS.  IF YOU WANT TO TAKE US ON, I AM ALSO
 MAINTAINING A LOCAL SOS (CMU'S WITH A FEW BUG FIXES AN FEATURES
 PECULIAR TO THE LOCAL ENVIORNMENT, I.E. CASE INVERSION FOR
 THE LPT: SINCE WE DON'T HAVE LC AND SFD'S.) AND PUB (TO WHICH I
 HAVE MADE THE SAME PATCHES FOR TRANSFERRING TO SOS, AND FAIL
 (DITTO).  IF YOU WANT THE SOURCE FOR OUR SOS IN ORDER TO
 MAINTAIN A COMMON FILE, I WILL BE HAPPY TO GIVE IT TO YOU.  THE
 LOCAL FEATURES ARE UNDER A SWITCH.
 
 I AM CHARLES HEDRICK.  MY OFFICIAL APPOINTMENT IS IN BUSINESS
 ADMINISTRATION (AS ASST. PROF.), BUT MY THESIS IS IN AI, AND I
 AM DOING MOST OF MY RESEARCH AT CSL.  PLEASE USE THE ADRESS
    CHARLES L. HEDRICK
     COORDINATED SCIENCE LAB
    UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
    URBANA, ILL  61801
 MAIL TO HEDRICK@CMUA (ACTUALLY YOU MAY NEED TO USE [A350CH05]@CMUA,
 I'M NOT SURE) WILL GET TO ME EVENTALLY, AS I STILL LOG ON OFTEN
 ENOUGH TO KEEP SOME COMMUNICATION GOING.  I HOPE CSL WILL
 EVENTAULLY GET ON THE ARPANET, BUT SEE NO DEFINITE IMMEDIATE HOPE.
 
 CHARLES HEDRICK



∂25-FEB-75  0713	CMU Hedrick again
		100,100: HEDRICK@CMUA @ ILL1
 TWO ADDITIONS TO YESTERDAY'S MESSAGE.  FIRST, MY TELEPHONE NUMBER HERE IS
 (217) 333-4515 [OFFICE] AND (217) 356-8425[HOME].  SECOND, CSL CAN COMMUNICATE
 WITH THE OUTSIDE WORLD ONLY BY 9-TRACK MAG TAPE AND PAPER TAPE.  IN A PINCH
 WE CAN ALSO READ DECTAPES VIA A CHEWING-GUM AND SCOTCH TAPE HOOKUP WITH A
 PDP-11, BUT THIS ISN'T GOOD.  
 
 CHARLES L. HEDRICK

∂27-FEB-75  1023	CMU =E3= LEPRUN bug, fix
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report (and fix) =E3= [LEPRUN/32] LDE 27-Feb-75
 	At NOBRACK+7, should be  POINT 6,C,12  instead of  POINT 6,(C),12.
 	At DLSTREF, the HLRZ D,(C) should be replaced by
 		HRRZ D,(C)
 		HLRZ D,(D)

∂28-FEB-75  0740	CMU =E4= CVASTR not in FOO2
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report =E4=  LDE 28-Feb-75
 	CVASTR is not in FOO2.
 
∂07-MAR-75  1653	ECL desires Fortran-10 calling sequence
 Date:  7 MAR 1975 1653-PDT
 From: NEVATIA at USC-ECL
 Subject: SAIL
 To:   RHT at SU-AI
 
 Russ, Is there an easy way of calling Fortran-10 subroutines
 from Sail. The current Sail calls seem to be for F40.
 Is there a switch or different procedure declaration that
 will work?
 Ram.
 -------

∂08-MAR-75  0834	CMUA Library symbol problem
 ***** FTP mail from [A310RB09] (BROOKS)
   Thanks for the prompt reply to my query.  If both those symbols are defined
 in the SAIL segment and in LIBSA8.REL, then we should have had no problems.
 We used the Carnegie SAIL seg and LIBSA8.REL, and I can't find
 any obvious reason why just those two symbols should have gotten lost.
 We also have a Stanford copy of LIBSA8.REL, so it may pay to try again with that.
 The loader string was TEST.REL,LIBSA8.REL/L$ to a copy
 of Carnegie's AILOAD.  
 I haven't yet gotten around to trying
 it out at Carnegie yet, but I will.
   Is there any possibility of converting SAIL to work with FOROTS instead of
 LIB40?  We have serious problems - people accidently getting the wrong thing -
 with keeping a copy of LIB40 around.
   
 Many thanks!
   Ruven Brooks
 

∂09-MAR-75  1305	CMU =E5= DRYROT at EVAR
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report =E5=  LDE 9-Mar-75
 	Compiler gets DRYROT AT EVAR in EVAR.SAI[CMU,AIL] & [A700SA00].
 (which is a very short test case).
∂11-MAR-75  2145	CMUA Ruven Brooks library symbols resolved
 ***** FTP mail from [A310RB09] (BROOKS)
 I am happy to report that SAIL is alive and well at UC-Irvine.  The unresolved
 symbol problem turned out to be a bad copy of LIBSA8, probably caused
 by my ineptitude with ISI-TENEX and DECtapes.
 	The LIB40 problem was solved by FUDGE2ing it onto LIBSA8;
 maybe the people at ECL can do the same.  (I'd be interested
 in knowing what SAIL needs LIB40 for besides the arithmetic routines.)
   Thanks for the help.
 	Ruven Brooks
 


∂28-MAR-75  1846	CMU =E6= storage management policy
 ***** FTP mail from [A700SA00] (SAIL)
 =E6=	CMU Feature [GOGOL/36] LDE (28-Mar-75)
 	Have RELINK put things back onto the free space list in
 	memory address order.  This can cut done memory fragmentation
 	significantly.  The debugged code follows below.
 
 For example, some configurations of HearsayII were getting up to
 20K of fragmented free space -- this fix cuts it down by an
 order of magnitude.
 
 The cost is in time:  1) to sort it onto the list in RELINK and 2),
 potentially, a longer access time in CORGET.  Both of the inner loops
 are on the order of 4 instructions.  Our experience indicates that
 even with huge HearsayII jobs, the free list now doesn't get much
 bigger than 6-10 long.
 
 My preference is that this algorithm be adopted as the standard.
 If you are unhappy with it, then please just put it in under
 a CMUSW.
 
 I also thought about the possibility of allowing the choice to be
 settable by the user.  One can get the old FIFO, the "new"
 address-order, or a size-order by just changing the one instruction
 at RELKNX:
 	FIFO:	JRST RELKDN
 	ADDR:	CAIG THIS,(NEXT)
 	SIZE:	CAMG SIZ,1(NEXT)
 Thus, this instruction could be set up in an XX or user-table
 location and then XCT'ed out of there from RELKNX. 
 (By the way, I also played with the size-order algorithm and
 it doesn't seem to be quite as good.  I also think the addr-order
 would be more generally useful.)
 
 RELINK:
 	HRRZM	THIS,-1(LAST)		;X-BIT ← 0, RH ← PTR TO HEAD
 	MOVEM	SIZ,1(THIS)		;GREATER 0 SIZE FIELD then FREE BLOCK
 ;;=E6= CMU FEATURE -- LDE 28-MAR-75	TRY TO KEEP FRELST IN ADDRESS-ORDER
 ;	SKIPE	NEXT,FRELST(USER)	;PLACE NEW BLOCK ON FRONT OF FRELST
 ;	 HRLM	 THIS,(NEXT)		; IF THERE IS ONE
 ;	HRRZM	NEXT,(THIS)		;POINT TO NEXT FROM THIS
 ;	HRRZM	THIS,FRELST(USER)	;UPDATE FRELST POINTER
 	PUSH	P,PREV			;NEED ANOTHER AC (FOR PREV)
 	MOVEI	NEXT,FRELST(USER)	;ADDRESS OF THE ANCHOR
 	JRST	RELKIN
 
 RELKNX:	CAIG	THIS,(NEXT)
 	 JRST	RELKDN			;THIS IS WHERE IT GOES
 RELKIN:	MOVEI	PREV,(NEXT)		;COPY NEXT INTO PREV
 	HRRZ	NEXT,(NEXT)		; AND GET THE NEXT NEXT
 	JUMPN	NEXT,RELKNX		;IF NOT END-OF-LIST, TRY AGAIN
 	SKIPA				;END OF LIST, SO DON'T
 RELKDN:	HRLM	THIS,(NEXT)		;PT TO THIS FROM NEXT
 	HRRM	THIS,(PREV)		;PT TO THIS FROM PREV (OR FRELST(USER))
 	HRRZM	NEXT,(THIS)		;PT TO NEXT FROM THIS
 	CAIE	PREV,FRELST(USER)	;THIS IS PROBABLY SUPERFLUOUS....
 	HRLM	PREV,(THIS)		;PT TO PREV FROM THIS
 	POP	P,PREV			;AND RESTORE THE AC
 ;; =E6= ↑
 	POPJ	P,			;RETURN
 
∂29-MAR-75  0202	RHT reply to SAIL library proposal
 To: Scott Daniels
 From: Russ Taylor
 Re: SAIL library
 CC: AIL, RS%SU-AI
 
 I have read your proposal for a SAIL library.  I believe that this is
 a very good idea.  It will stand or fall on the willingness of someone to
 be the librarian.  Beyond that, I have a number of programs that I could
 contribute (as one might suspect).  Also I have a few observations:
 
 (1) Why restrict the switches to one only?  We have not done this for
 SAIL itself.  I agree with the principal that it is good to keep things
 as standard as possible from site to site.  However, this is not always
 possible, especially in view of idiosyncracies in local operating systems.
 Frequently, you NEED switches to achieve a uniform external behaviour.
 While we are on the subject, I suggest that the same names be used as
 in the SAIL compiler.
 
 (2) In my experience, it is a very bad idea to encourage the use of 
 SIMPLE procedures, which are much abused and can cause some funny
 bugs.  Most SAIL programmers make things SIMPLE that should not be than
 do the other thing.  The savings they achieve just do not pay for the
 increased fragility.  I agree that it is ok to make truly simple things
 SIMPLE, but ...
 
 (3) What are all those magic words like "BFAIL", and why are they taboo?
 
 (4) Some control must be made over macros.  In particular, I suggest that
 obscenities like "UPTO" should be banned.  I suggest that library 
 contributors be encouraged to steer completely away from macros or else
 to adopt a standard header file of abbreviations (I suggest ABBREV.SAI[S,RHT]
 and MACROS.SAI[S,RHT] as good starting points) which everyone in the library
 uses.  The SAIL compiler can be used to produce macro-expanded listings
 that (with a little editing) can be used as source files.
 
 (5) more attention should be given to whether this a source-file library
 or a .REL file library.  If the latter, some suggestion should be given to
 providing modular .HDR files.
 
 (6) I suggest that there be a central "master" library kept somewhere.
 For distribution purposes, this should reside at SU-AI, since we
 send out SAIL systems.  If you people are going to be doing most of the
 maintainence on the beast, I suggest that some arrangement like that
 adopted for the system files be adopted.  See Bob Smith for details
 on how this works.  The point here is that it is very important for
 there to be a single set of files that defines "SAIL"; otherwise, chaos
 can result.  I am frankly a bit worried that, with SUMEX on the network,
 the tenex sail files may not be kept up here at SU-AI.  This will eventually
 come home to roost, as changes are made in the language.  Perhaps I
 am wandering a bit from the subject of a library.  Anyhow, I strongly
 believe that SU-AI should be the source for distribution to the ARPA
 net.  I.e., if you guys want to "publish" a library, put the updated copy
 here.  This will prevent many headaches.  
 
 (7) I haven't checked, but I'm sure Lester will spring for some file
 space.  If there is trouble, I can perhaps twiddle the AIL accounts
 to make a bit of room.  By the way, how big a library is intended?
 
 (8) Lean on Bob Smith to finish the generalized print primitives.  Also,
 some attention should be given to I/O conventions.  At the very minimum,
 I suggest BANNING fixed channel & break table conventions.  Either
 a function should do its own GETBREAK & GETCHAN (Must do OPEN, too, to maintain
 compatibility) or else should refer to global integer variables of integer
 value parameters.  Also, people should make use of $PRINT where appropriate.
 
 (9) Default parameters are a good idea for library routines.
 
 (10) One very important aspect of such a library is a catalogue.  This
 should be updated regularly and distributed to customers.
 
 (11) I'd kind of like to get together with you and Bob Smith to discuss
 all this.  Libraries have a way of becoming a part of a language.  I.e., 
 the language implementors seem to acquire a certain responsibility
 toward not doing anything that affects the routines in the libraries.
 We need a way of handling this.  Could you get ahold of me so that
 we can set up a meeting?  I'm usually at the AI Lab in the afternoon
 & evening.  The phone here is 497-4971.

∂02-APR-75  0813	Hedrick's diatribe
 I SUGGEST YOU MODIFY FILES[X,AIL] TO INCLUDE THE FILES FOR BAIL
 CONTAINING THE DECLARATIONS FOR THE SAIL PROCEDURES, OR THE FILES
 NECESSARY TO MAKE SUCH A FILE.   SINCE I HAVE ALREADY MOVED MY
 TAPE TO ILLINOIS IT IS TOO LATE FOR ME TO GET THESE NOW, BUT OTHER
 PEOPLE WON'T FIND THEMSELVES WITH AN UNUSABLE BAIL SYSTEM AT LEAST.
 (IF SOMEBODY AT SAIL IS FEELING IN A PARTICULARLY FRIENDLY MOOD,
 I WOULD BE HAPPY TO ACCEPT A DECTAPE CONTAINING A WORKING VERSION OF
 THE BAIL SYSTEM, I.E. ONE THAT WILL WORK WITH MY PATCHED VERSION
 OF THE CMU SAIL, OR ALL THE FILES NEEDED TO GENERATE ONE, INCLUDING
 JFR'S MODIFIED RTRAN, FOO2, ETC.  WE CAN READ DECTAPES HERE, ALTHOUGH
 NOT EASILY.)
 
 ALSO, JUST TO KEEP YOU INFORMED, I HAVE GENERATED VERSION 8 OF SAIL
 AT ILLINOIS.  IT SEEMS TO WORK.  I HAVE MODIFIED FAIL.FAI, GOGOL, AND
 COMSER IN TWO WAYS:
   (1)  WHEN AN ERROR OCCURS, I SIMULATE AUTOMATIC CONTINUING WHEN THE
        JOB IS CONTROLLED BY A PTY (MY PROXY FOR KNOWING WHETHER IT IS
        A BATCH JOB)
   (2)  BEFORE LINKING TO LINED (YES, IT'S CALLED THAT HERE, TOO), I
        WRITE A TMPCOR OR DSK:.TMP FILE CONTAINING AC'S 11 THROUGH 16.
        ALSO, IF "T" IS TYPED, I WRITE A EDT FILE AN LINK TO TECO.
 OTHERWISE I PRETENDED I WAS AT CMU IN THE ASSEMBY PROCESS.  (AND USED
 THE CMU FAIL IN CASE ANYTHING CHECKS TO SEE IF CMUDEC IS DEFINED.)
 (OH YES, I ALSO TURNED ON THE KI10SW IN FAIL, SINCE WE HAVE ONE.)
 I WILL SEND YOU FILCOM OUTPUT WHEN I GET AROUND TO IT.  I WOULD BE
 HAPPY TO HAVE YOU INCLUDE MY STUFF UNDER A SWITCH IF YOU WANTED TO.
 IF YOU NEED TO SET IT AUTOMATICALLY, TRY LOOKING FOR A COMBINATION
 OF CMUDEC AND THE KI10 OPCODES BEING DEFINED.  THE REASON I USE THE
 CMU VERSIONS IS THAT THEY SEEM TO HAVE MORE OF YOUR NICE FEATURES
 (SUCH AS RECORDS) THAN THE REGULAR EXPORT VERSION.  THE CMU PPN'S
 DON'T CAUSE ANY PROBLEM SINCE IT CHECKS FOR OCTAL FIRST.
 
 THANKS.
 C. HEDRICK
 CSL, U OF ILLINOIS
 URBANA  61801

∂02-APR-75  0847	Hedrick requests 20K SAIL
 IS IT POSSIBLE TO ASSEMBLE A SAIL COMPILER THAT WILL RUN IN 20K?
 I WOULD BE WILLING TO GIVE UP ANYTHING EXCEPT THE MOST BASIC ALGOL
 AND I/O, AS LONG AS IT IS COMPATIBLE WITH REAL SAIL.  THE PROBLEM
 IS THE CSO HERE (A DIFERENT ORGANIZATION THAN MINE, WITH ITS OWN
 KI10) HAS A CORE LIMIT OF 20K DURING PRIME HOURS.  EVEN 30K WOULD
 BE A HELP, SINCE IN THE MORNING ONE CAN USE THAT MUCH CORE.
 I WOULD BE WILLING TO EXCEPT VERSION 1 OF SAIL IF NECESSARY, ALTOUGH
 I WOULD CERTAINLY PREFER TO BE ABLE TO LOAD REL FILES PRODUCED
 BY A FULL VERSION 8 COMPILER (AT NIGHT WHEN WE CAN USE 60K).
 
 THANKS AGAIN



∂02-APR-75  1602	RHT reply to 20K SAIL
 
 (1) Re 20K SAIL.  This presents real difficulties, since the various
 features are really intermingled.  I.e., an eviscerated version
 is a lot of work to make. Your problems are political & not really
 technical, so perhaps some sort of "deal" with the computer center would
 be better & easier.  If the segment size counts against the core
 limit, you might consider loading from a library.  In any event,
 the compiler tends to like a good bit of buffer & free storage space.
 You can cut down the initial program size a bit, but don't gain
 much, since the compiler will then just core up.  As to loading SAIL
 compiled programs: if the segment counts, load with the library.
 If not load with the segment.  what more can I say.
 
 (2)Re BAIL: BAIL has not yet been "released" to the public. So we 
 are unwilling to undertake ANY commitments on export yet.  I poked
 a preliminary copy at Lee Erman to get some technical feedback from
 him, in view of the close working relationship we have had with
 CMU on past SAIL development; this did not constitute release, however.
 If we take any action, it will be to expunge all mention of BAIL
 from X,AIL.
 
 (3)Re: a switch.  Well, we have installed a number of special site-dependent
 switches in the past, but always with great reluctance.  It is not
 very clear to me what exactly you want done, so I cannot comment in
 much detail, either.  One general point is: SU-AI is NOT a software
 house. We do export a fair amount of software, which we endeavor to
 keep correct -- ie we fix bugs when someone tells us about them.  It is
 also true that we have spent a fair amount of effort making our programs
 run on a wide variety of systems.  However, we really don't want to
 get into a position of being responsible for idiosyncracies at a dozen
 different sites, especially since this detracts from the transportability
 of programs and makes modifications and improvements much more difficult.
 Also, we just don't have the manpower to do it.  As to your specific
 changes, they may be useful.  Send a FILCOM & we'll look at them.
 The general problem is to make the various systems features more modular,
 so that various sites can select which ones they want.  (Ie. we may
 want to introduce a BATSW that says this compiler should act in some
 funny way if called from a batch monitor, and so forth)  If you hve some
 suggestions along these lines, ...  As to ILL1-specific things, the
 problem is (as I mentioned) one of available manpower here.  Perhaps
 you can persuade the cmu people to provide you with a local switch
 inside CMUSW; then they are responsible for maintaining things --
 Ie the burden on us here is less (we generally have to "bless" any
 contributions sent in for local switches & worry some about damaging
 pieces on non-stanford code) -- By the way, your PTY kluge may be
 more appropriately implemented by getting the batch monitor to type
 ahead a <lf> to SAIL compilations; this will make SAIL continue
 to work properly when used "normally" through a PTY, as sometimes
 happens.
 				Russ Taylor
∂13-APR-75  0648	CMU Storage allocation policy measurements
 **** FTP mail from [A610LE03] (ERMAN)
 uss,
 
 e the newer CORSER RELINK algorithm that I implemented to keep
 he freelist in memory-address order:  On ten or twelve runs of
  3-minute PUB compilation, the new algorithm does marginally 
 etter -- about 2% faster and about the same on total core
 sage (kilo-core-sec).  Thus, at the very least it seems not to
 e harmful.  The HearsayII runs show it can, in some cases, be
 ery beneficial.  I think the number of cases in which it would
 e harmful would be no more likely than the number of cases in
 hich the current scheme is bad.  
 
 hus, I ask that the new algorithm be put up as standard.  If you
 re still not sure, then please put it up under CMUSW.
 
 hanx,
 Lee
 ----
 

∂21-APR-75  1530	CMU =E8= LISTX should not be BILTIN
 ***** FTP mail from [A700SA00] (SAIL)
 CMU bug report =E8=	LDE 21-Apr-75
 	LISTX is in FOO2 as BILTIN.  Unfortunately, it clobbers A, B, and C.
 	I think the best fix is to just not declare it BILTIN.
 -----
∂06-AUG-75  1255	1,JED   network site OFF garbage message
 (πX$_↓`⊃↔*fλ α ∧ ε
⊃<+	x∧+ @`βx⊂+λp⊃β2β`&⊂S(0Zx+2βx- H/⊃3 "'λ⊃;\"3⊃∨+0Z~xSH⊂ε∨633⊂∩∀e∨0⊂⊃*≥[⊃3⊂⊂)∪}⊃∨⊂λl&z⊃;⊗x
∂27-AUG-75  1244	1,JFR CHECK!TYPE(record class)
 Hedrick was complaining that check!type(record class) failed in a bad way,
 also that delete(record!pointer itemvar) gave ill UUO.

∂22-SEP-75  1925	CMU =F1= =F2= LENGTH(PHI) EXTERNAL ARRAY in SIMPLE PROCEDURE
 From: SAIL,(A700SA00)@CMUB
 Date: 22 Sep 1975 2223 EDT
 Subject: two SAIL buggies.
 To:   SUSAIL.DST
 cc:   SAIL
 - - - -
 CMU bug report =F1=  LDE 22-Sep-75
 	LENGTH(PHI) returns garbage.  example:
 begin "F1"
 require 100 new!items;
 itemvar GRIZ;
 set FAP;
 GRIZ←NEW;
 outstr("Length(FAP←phi) = "&cvs(length(FAP←phi))&'15&'12);
 outstr("Length(PHI) ="&cvs(length(phi)))
 end "F1"
 
 F1 1K CORE
 EXECUTION
 Length(FAP←phi) = 0
 Length(PHI) =-39918
 End of SAIL execution
 
 
 
 CMU bug report =F2=  LDE 22-Sep-75
 	Can't declare EXTERNAL ARRAYS in a SIMPLE PROCEDURE, even if
 	declare it OWN:
 begin "f2"
 simple procedure foo;
 begin "foo"
 	own external integer array ISOWN[1:2];
 	external integer array NONOWN[1:2];
 	outstr("a");
 end "foo";
 end
 SAIL: F2.SAI 1
 SIMPLE PROCEDURES MAY NOT ALLOCATE!
 F2, PAGE 1
    	own external integer array ISOWN
                                         [1:2];
 ↑
 SIMPLE PROCEDURES MAY NOT ALLOCATE!
 F2, PAGE 1
    	external integer array NONOWN
                                       [1:2];
 ↑
 
 
 -------
 
∂07-OCT-75  1115	Glenn Ricart @ NBST  block names
That seemsed to go OK, so here is what's happening:  Marvin
Shapiro who wrote the "Beginners Guide to SAIL" widely used
around here as a SAIL tutorial, is going to update it for,
among other things, LEAP.  He ran into the following problems:

	Begin
		String Item Y;
		Datum(Y)←"ABC"
	End

gets ?Ill mem ref at user PC 000154.  If the program is expanded to include
an unrelated itemvar assignment from NEW, then everything works.
I caught Les Earnest on-line about this, and he suggested that string items
don't work.  Marv wants to be sure that this is a restrition since they
do seem to work OK very often when there is more program around it.

Marv's second problem in next message.
∂07-OCT-75  1121	Glenn Ricart @ NBST  UNTYPED ITEMVAR OUGHT TO BE TYPED
	Begin
		Require 10 New!items;
		String array itemvar array X[1:2];
		Preload!with "A"; String array Y1[1:10];
		X[1]←New(Y1);
		Outstr(Datum(X[1])[1])
	End

This program gets the message "UNTYPED ITEM OR ITEMVAR OUGHT TO BE
TYPED" just before the second [ in the Outstr line.  Les had
no idea on this one and ferred me to you.

Unfortunately, I have no network mailbox for your reply, but I'll
leave you my address and telephone number and offer to call you back
if you make the first telephone contact (I don't have your number).
Also, I'm asking Russ Taylor to send a "latest" SAIL and BAIL to
me in case that proves useful.

Glenn Ricart	Marv Shapiro
12A/1039	12A/3041
NIH		NIH
Bethesda, Md.	Bethesda, Md. 20014
(301)496-4823	(301)496-6037
				. . . Thanks....Glenn
∂03-NOV-75  0634	CLO,JMG   bounds check on case statement (?)
Another esoteric (desireable) SAIL feature: why couldn't the
compiler notice upper and lower bounds and write a conditional
test of bounds before attempting the case statement?  If the
run-time index was out of bounds, the statement would be skipped.
hmmmmm...

∂26-NOV-75  2114	REM '400000 000000 problems in compiler
Please foreward to whoever is mantaining SAIL currently.

DEFINE LEFTBIT=(1 LSH 35);
MUMBLE←MUMBLE LOR LEFTBIT;     INTEGER CONSTANT TOO LARGE

DEFINE LEFTBIT="(1 LSH 35)";
MUMBLE←MUMBLE LOR LEFTBIT;     COMPILES OK
∂28-NOV-75  1631	1,DON mysterious DRYROT from compiler
I don't know whether you give a hoot about DRYROT messages from SAIL
when fixing other errors in the source eliminates the DRYROT errors
as well, but if you're interested, the program shown here causes
first an UNDECLARED IDENTIFIER error, then a DRYROT error.

begin "BUG"

simple string procedure upper (value string S);
begin	C ← S[1 for 1];
	if C≥"a" ∧ C≤"z" then
	    S ← (C-'40) & S[2 to ∞];
	return (S)
end;

    outstr (upper ("hi there!"))
end "BUG"
∂26-JAN-76  2344	MJC  	"T" to error handler; SNAIL interface
To:   JFR, AIL    
I answered "T" to an execution error message in a Sail program, and I received
a "*" from Snail indicating that it had been started at other than the start+1
entry.  Is this Snail's fault?  Why shouldn't a reply of "T" swap to E instead 
of Snail?

∂14-FEB-76  1304	FTP:LEE ERMAN(A610LE03)@CMUB	snarfing SAIL.  
From: LEE ERMAN(A610LE03)@CMUB
Date: 14 Feb 1976 1603 EST
Subject: snarfing SAIL.
To:   JFR@SU-AI, AIL@SU-AI, RS@SU-AI
- - - -
I think we are finally ready to bring up a new SAIl (we haven't touch
it much since JFR's stuff this summer).  My main motivations are the
new improved record stuff and also any little bug fixes that have
come along.

Is there any reason why the next few weeks would be a bad time to do
it?  I presume that S,AIL is the right place.

thanx,
	Lee

-------

∂24-FEB-76  1237	FTP:SAIL(A700SA00)@CMUB	S,AIL files.    
From: SAIL(A700SA00)@CMUB
Date: 24 Feb 1976 1533 EST
Subject: S,AIL files.
To:   RHT@SU-AI, AIL@SU-AI
- - - -
Russ,

We are in the midst of FTPing the S,AIL files to finally become
up-to-date here.  But I now notice that you seem to be freebing with
the files.  Should we abort our thing?  And start over when?  Or is
it okay to go on?

thanx,
	Lee

-------

∂05-MAR-76  1702	FTP:SAIL(A700SA00)@CMUB	=F3= SCB clobbered
From: SAIL(A700SA00)@CMUB
Date: 5 Mar 1976 1956 EST
Subject: CMU SAIL bug report -- CMU bug =F3=
To:   RHT@SU-AI, JFR@SU-AI, AIL@SU-AI
- - - -
CMU SAIL bug report =F3=	(LDE 5-Mar-76)
	Symptoms:  If a procedure contains a FOREACH which contains a
       block with a dynamic array, and a return from the proc is done
       from within the block, and if the proc was called from within
       another FOREACH, the SCB of the original (calling) FOREACH
       does not seem to get restored, which causes LEAP to return
       into the already exited FOREACH when the calling FOREACH does
       its next DOAG.
	For a half-page example (which blows both at CMU and Stanford),
	see FORBAD.SAI[1,LDE] and [A700SA00].



begin "forbad"
require "[]()" delimiters;
define tell(foo)=[outstr(foo&('15&'12))];

internal integer procedure wpchk(set phrhyps);
begin "VWPCHK"
	ITEMVAR PH;	integer nsons;
	tell("into WPCHK");
	FOREach PH such that ph IN PHRHYPS DO
		BEGIN	"TRY"
		INTEGER NODE,PHRDEX;
			tell("into TRY");
		NSONS←10;
		IF NSONS > 0 THEN
		BEGIN "TEST"
		 INTEGER ARRAY SONSARY[1:NSONS];
		 NSONS←4;
			tell("leaving TEST");
			return(1 MAX nsons);
		 END "TEST";
		END	"TRY";
	return(0);
END	"VWPCHK";

integer procedure callit;
return(wpchk({new,new,new}));

procedure doall;
begin "doall"
	itemvar ls;	set SSET;
	SSET←{new,new,new,new};
	foreach ls such that ls in sset do
		  BEGIN "ONESYL"
			tell("into ONESYL");
		    callit;
			tell("out of ONESYL");
		  END "ONESYL";
end "doall";

require 100 new!items;

doall;

end;
-------
∂06-MAR-76  2220	DLB   response string to USERERR lost
If you are in the mood to fix a bug in a SAIL runtime, look at BUG.SAI[2,DLB].
It is self-explanatory and short.  I got around the bug by asking Russ Taylor,
who showed me EDFILE;  he didn't feel like fixing the bug, however.
BEGIN "BUG"
DEFINE ↓ = "'15 & '12";
USERERR(0,1,"SHOULD TAKE ME TO TV EDITOR NOW","T BUG.SAI" & ↓);
COMMENT What actually happens is that the filename gets lost somewhere,
so the thing waits for tty input.  If the filename is typed, the right
thing hapens.  If a <cr> is typed, SNAIL is invoked! ;
END "BUG"

[Reply from JFR 7-MAR-76]
Re: response strings in USERERR
The problem has been noted, but is likely to remain in the current state for
a while.  Invoking SNAIL after T<cr> is exactly the right thing.  The old
RPG would rerun the last edit command when invoked by the SAIL runtimes.
MJC did not see fit to retain this feature in the new SNAIL.  Complain
to him.
∂09-MAR-76  1941	FTP:RSMITH at SUMEX-AIM	SAIL Bugs  
Date:  9 MAR 1976 1940-PST
From: RSMITH at SUMEX-AIM
Subject: SAIL Bugs
To:   taylor at SAIL, reiser at SAIL

Russ,
	Here are several bugs in the SAIL system, I know you are
busy.
	(1)  Iterations thru lists of arbitrary string expressions
does not work, e.g.:

FOR S ← "HI " & T1, "HI " & T2, "HI " & T3 DO PRINT(S);

doesn't compile.

	(2)  Conditional expressions of RECORD!POINTER don't
seem to work--they uniformly get an RCLASS=0 error from EMIT.
(E.g.:

RP1 ← IF boole THEN RP2 ELSE RP3;

)

	(3)  An example of a string assignment that doesn't work
(gets a pushdown overflow because forgets to put -1 in lh of the
phoney push-down pointer).  (Error is in label marked BUG LOOP).

!BEGIN "DUMMY"

DEFINE	!! = "COMMENT";

STRING ARRAY	Exceptions[1:10];

STRING ARRAY	Crud!Ext[1:10];		!! works without this;

STRING ARRAY	Project!Name[1:20],	!! works without this;
		User!Name[1:20,1:60],	!! works if swapped with below;
		Names!Sort[1:100];


INTEGER	Top,
	I,
	J;
!I ← 5;
Top ← 60;

FOR J ← 1 STEP 1 UNTIL Top DO
BEGIN "Bug Loop"
	Names!Sort[J] ← User!Name[I, J];
END "Bug Loop";


END "DUMMY";
!
	If you can suggest anything it would be appreciated.
I would especially like to have the RECORD bug fixed.

			Bob Smith
			RSMITH@SUMEX

-------
[JFR. RECORD!POINTER bug fixed, #WO.  Could not duplicate string pushdown
overlflow problem 4-1-76.]
∂12-MAR-76  1435	JFR  	code generated for LOP  
Currently string LOP is 
	HRRZ	T,-1(SP)
	JUMPE	T,.+4
	HRROI	T,-1
	ADDM	T,-1(SP)
	ILDB	T,(SP)
whereas the following is shorter and faster:
	HRRZ	T,-1(SP)
	JUMPE	T,.+3
	SOS	-1(SP)
	ILDB	T,(SP)
Should be easy to change.

∂13-APR-76  1543	FTP:LOW at SUMEX-AIM	SAIL BUG REPORT AND FIX.
Date: 13 APR 1976 1541-PST
From: LOW at SUMEX-AIM
Subject: SAIL BUG REPORT AND FIX.
To:   AIL at SU-AI


IN!CONTEXT CAUSES COMPILER TO GIVE ADEPTH, SDEPTH DRYROT
ERROR MESSAGE. FIX IS TO INSERT:

            SOS  ADEPTH
            SOS  ADEPTH

AFTER THE CALL
            XCALL (.INCON)

AT APPROXIMATELY LINE 80 OF PAGE 26 WITHIN THE EXEC ROUTINE INCNTX.
IN THE FILE LEAP.
-------
#WR JFR 4-17-76
∂17-APR-76  1539	JFR  	SAIL bug, CASE expr used as stmt  
A CASE expression used as a statement causes the comiler to quit compiling
immediately, acting as if it had reached the end in a proper fassion.
Problem is in grammar, a botched attempt to use same productions for
scanning CASE stmts and CASE exprs.  New grammar is HEL.NEW[S,AIL].

∂22-APR-76  0627	DGR   via MTRT	DECUS Sail
I sent DECUS a tape of the SAIL you left me.  It was sent on 4/2/76
in 1600 bpi FAILSAFE format (9-track) and I checked with the DECUS office
to make sure this was OK.  In addition to editing GEN per your instructions,
I made up saved versions of the compiler in different configurations.
This should enable the casual SAIL site to put up SAIL immediately without
having to understand TELLEM and re-make the parts.

I've also sent copies of the DECUS tape to University of Illinois,
University of Western Ontario, the Brookings Institution,
and Cornell University Laboratory for Nuclear Studies upon their requests
for an earlier copy.

I don't know how to send a copy of this message to RHT, so if you could
pass it on, I'd appreciate it...........................Glenn

∂10-MAY-76  1938	FTP:LOW at SUMEX-AIM	CONTEXT BUG AND FIX
Date: 10 MAY 1976 1937-PDT
From: LOW at SUMEX-AIM
Subject: CONTEXT BUG AND FIX
To:   AIL at SU-AI
cc:   JFR at SU-AI

THE IDENTIFIERS USED BY CONTEXT VARIABLES CANNOT BE REUSED
FOR OTHER VARIABLES AT ANOTHER BLOCK LEVEL. GET MESSAGE:
   BOGUS IDENTIFIER...

FIX IS TO ADD ICTXT TO CLASSES @I AND @IDQ IN FILE HEL.

                   JIM LOW
-------
∂09-APR-76  1113	FTP:HS-PTY(A610SP00) at CMUB	Hedrick's DDT.  
From: HS-PTY(A610SP00) at CMUB
Date: 9 Apr 1976 1411 EST
Subject: Hedrick's DDT.
To:   JFR at SU-AI
- - - -
I think Chuck mentioned that you were interested in his version of DDT.
The source is currently PRVE:DDT.MAC[A610SP00].  You might also look
at DDT.DOC and READ.ME (on the same area).
	Lee
p.s., still have not gotten a chance to bring up the new SAIL here....
-------

∂06-JUN-76  1018	FTP:CHARLES HEDRICK(A350CH05) at CMUB	sail bug    
From: CHARLES HEDRICK(A350CH05) at CMUB
Date: 6 Jun 1976 1317 EDT
Subject: sail bug
To:   LEE ERMAN, JFR at SAIL
- - - -
I have another SAIL runtime fix.  When INCHWL reads more than
141 characters (or some such magic number) it replaces the
141'st (etc) with control-A.  The problem is at INCHWL+21.
When the magic number is reached instead of jrst'ing back to
the loop, it calls a subroutine and then goes back to the loop.
Alas, it has the last character in AC 14, and the subroutine
garbages AC 14.  I fixed the problem by doing PUSH 17,14 before
the PUSHJ and POP 17,14 after it.  You may know of a more
elegant solution.

[JFR #UI# ?]
-------


∂06-JUN-76  1027	FTP:CHARLES HEDRICK(A350CH05) at CMUB	sail versions    
From: CHARLES HEDRICK(A350CH05) at CMUB
Date: 6 Jun 1976 1326 EDT
Subject: sail versions
To:   JFR at SAIL
- - - -
We are using CMU's SAIL, as you may know (patched minimally for the
standard TOPS-10 monitor).  Thus any bugs I report are from the CMU
code.  I'm sorry if that means that you have fixed them long since.
It may be we should reevaluate using CMU as our source.  They seemed
a good compromise, as they keep more up to date than DECUS.  The
problem with X,AIL is that it is a pain for us to transfer all those
files over the ARPAnet.  Magtape is better for us.  Please tell me
if (1) you think using DECUS would be better, or (2) you would be
willing to write 9-track magtapes whenever you have a new version
you think we should have.

By the way, it turns out the effect of the Stanford USETI and USETO
can be gotten by having the next INPUT or OUTPUT use an explicit
buffer address in the address field.  The monitor will use that
buffer directly, releasing all others that may have data.  It will
continue from that buffer in the usual way.  This is far safer than
mucking around with the in use bits yourself, according to
Tony Wachs.  We haven't tried this, but Wachs says if it doesn't
work, send him an SPR and he will fix it.  I highly recommend
fixing SAIL's USETI and USETO to work this way, next time you are
making export changes (if ever! I know you have real work to do).

-------

∂14-JUN-76  0701	FTP:SAIL(A700SA00) at CMUB[LDE]	SAIL -> CMU. 
From: SAIL(A700SA00) at CMUB[LDE]
Date: 14 Jun 1976 958 EDT
Subject: SAIL -> CMU.
To:   RHT at SU-AI, JFR at SU-AI, AIL at SU-AI
- - - -
Well, I'm finally actually bringing up the "new" SAIL at CMU.  Am I
right in assuming that the standard files on S,AIL are, to the best
of peoples' knowledge, in OK shape?

I noticed that a STRSER.KL is beginning to exist.  Whenever you get a
chance, I'd appreciate hearing about it.  In particular, will it use
only standard KL-10 features, and how will SAIL decide when to create
KL10 code rather than KA10?

thanx,
	Lee

-------
[JFR 6-15-76]
SAIL
Use the standard file list FILES[X,AIL], except BAIL[1,JFR] replaces
BAIL[X,AIL] (disk space problems here; redefine DEC and STANFO macros
on p. 4).

STRSER.KL is a dream at this stage.  I was planning on using the
new instructons ADJBP and EXTEND (principally MOVSO) to speed up
CAT and string garbage collection; but there are noises that the
microcode to support EXTEND will be gobbled to fix a race condition
in context swapping in the monitor.  (The problem is that priority
interrupts are slow, and the processor can sneak in a few instructions
while the system wants to get out of channel 3 and into channel 7.)
ADJBP is still a win, especially for CAT.  I also found a small coding
change which will speed up string garbage collection even on a KA10.
PUB and most user programs will benefit; the compiler uses aligned
strings (SGLIGN) and will not run any faster.  EXTEND MOVSO was
20% faster than ILDB-IDPB-SOJG in my tests. [CAT, string GC, OUT]

In any event, all of this was in the runtime routines.  As for the
compiler, the only changes contemplated are ADJSP for procedure
exit (and recursive procedure entry) and FLTR/FIXR/KIFIX (opcodes
127/126/122) for real/integer conversion.  All features will be
controllable via commandline switches and REQUIREs.  ADJSP and FLTR
will be initially set via installation switch when the compiler is
assembled, since these instructions are functionally equivalent
to current code/UUOs.  FIXR and KIFIX are not equivalent, so the
default will be to perform real to integer conversion via the current
UUO.  Here is a table of the differences:

    	real	UUO	KIFIX	FIXR
	 1.4	 1	 1	 1
	 1.5	 1	 1	 2
	 1.6	 1	 1	 2
	-1.4	-2	-1	-1
	-1.5	-2	-1	-1
	-1.6	-2	-1	-2

SAIL UUO is the floor (greatest integer) function [contrary to what
it says in the manual].  KIFIX is "move towards zero until you hit
an integer".  FIXR is "add 0.5 and take the greatest integer".
DEC blew it with FIXR; note that FIXR(-1.5) NEQ -FIXR(1.5).


There will be a revised, integrated SAIL manual soon.  I am doing it
this summer, so it really will get done this time.

∂22-JUN-76  1555	FTP:SAIL(A700SA00) at CMUB	another little CMU tweak.   
From: SAIL(A700SA00) at CMUB
Date: 22 Jun 1976 1852 EDT
Subject: another little CMU tweak.
To:   AIL at SU-AI, JFR at SU-AI, RHT at SU-AI, HJS at SU-AI, 
      RS at SU-AI
- - - -
CMU feature =F7= LDE 22-Jun-76	IOSER/32,34, SPARES
	The new SAISG8.SHR ended up being about 30 words over 13K, so
we decided not to put TMPIN and TMPOUT in the segment.  Done under a
NOSTAN (but make it CMUSW if you prefer).

	IOSER/32:
IFN STANSW!<<¬SEGS>&1>, <
;; =F7=  LDE 22-Jun-76  Let's keep the hiseg to 13 K.
;			(for SAISG only)
COMPIL(TMP,<TMPIN,TMPOUT>
		 ,<GOGTAB,STRNGC,INSET,CORGET,CORREL,X22,X44>
		 ,<Tmpcor input and output routines>)

	IOSER/34:
ENDCOM(TMP)
>; IFN STANSW!<<¬SEGS>&1>  =F7=↑

	SPARES:
NOTENX<
IFN STANSW!<<¬SEGS>&1>, <;;=F7= LDE  -- keep hiseg at 13 K
HERE(TMPIN)
	JRST	TMPIN.
HERE(TMPOUT)
	JRST	TMPOU.
>; IFN STANSW!<<¬SEGS>&1> =F7= ↑
>;NOTENX

-------

∂26-JUN-76  0235	KS  	Subfield indices, continued   
 ∂21-JUN-76  0436	KS  	SAIL Records   
Is there any simple way to symbolically represent or determine the
integer offset corresponding to a named field of a record class?  And
if not, it would be useful to define such a correspondence.  For example,
let "ClassX:FieldY" without following brackets represent the integer
indexing FieldY in ClassX.  This would allow one to, say, pass a
procedure a collection of records along with a field specification.  As
matters stand now, I know of no reasonable way to do the above.

Sigh.  I reiterate my final remark; to whit: " ... I know of no REASONABLE
way to do the above."  Naturally I had already read all the relevant sections
of the manual before I bothered you with the problem.  My understanding of
what would be required at present is that: (1) I have a particular instance
of class FOO in my hand, that is, a pointer to word 0 of such a record.
(2) I have a string in my hand which is supposed to name a subfield of FOO.
(3) I follow the right half of word 0 of the instance of FOO that I have a
pointer to yielding word 0 of the class descriptor.  This with MEMORY etc.
(4) I move a couple of words further along in memory to get a pointer to
an array descriptor for FOO:TXTARR.  (5) I write myself a little search
loop using EQU() to find the string I have in the array.  The index of the
string in the array (assuming it is there) is at LONG LAST the number I was
looking for.  And all along the compiler had to know that number at that
point in the program to generate code to access that subfield; and I had to
go thru all this shit to get it just because nobody bothered to give me
what I was asking for in the first place.  Namely, a REASONABLE way to
symbolically refer to the integer corresponding to a subfield.  Is that too
much to ask?  After all, the compiler does know everything I want.  Or is
there some more philosophical reason why it shouldn't tell me?

Incidentally, I believe there is a typo on line 33 of page 22 of SAIL.UPD[AIM,DOC].
It says " i.e., xwd(loc(FOO)+2,loc(FOO)+22)>   "; I believe it should say
" ... ,loc(FOO)+2)> ".

[reply by JFR 6-26-75]
SAIL records
If you could determine the integer offset corresponding to a named field
of a record class, what would you do with it?  THE WHOLE POINT OF RECORDS IS
THAT FIELDS ARE REFERENCED BY NAME, NOT BY INTEGER OFFSET.  The fact that
integer offsets exist at all is merely a peculiarlity of the current
implementation. It is conceivable that records could be implemented using a large
associative memory.  Thus the compiler resists attempts to deal with fields
except by class and field name.  Those who want to fool around with integer
offsets are presumed to know the implementation and understand what they are
doing, and the implementation information given in the manual is provided for
these "experts" (hackers).

Just to show you that even hacking is reasonable in SAIL, here is the code which
BAIL uses to decode field references.

	EXTERNAL RECORD!CLASS $CLASS(INTEGER RECRNG,HNDLER,RECSIZ;
	    INTEGER ARRAY TYPARR; STRING ARRAY TXTARR);

	SIMPLE INTEGER PROCEDURE FNDSBFLD(RECORD!POINTER($CLASS)C; STRING NAM);
	BEGIN INTEGER I;
	FOR I←1 STEP 1 UNTIL $CLASS:RECSIZ[C] DO
	  IF !!EQU($CLASS:TXTARR[C][I],NAM) THEN RETURN(I);
	RETURN(-1) END;

	DEFINE PCLASS(Q)=⊂MEMORY[MEMORY[LOCATION(Q)],RECORD!POINTER]⊃;

If FOO is a RECORD!CLASS and FLD is the name of a field of FOO then
FNDSBFLD(FOO,FLD) is the integer offset (with -1 as an error flag).
If PTR is a RECORD!POINTER and STR is a string, then FNDSBFLD(PCLASS(PTR),STR)
is the integer offset of the field for the class to which PTR currently points.
The only "dirty" aspect of this code is the creation of a pointer to the proper
record in case the pointer is not already of class $CLASS.
[Here !!EQU is the same as EQU except that the characters "_" and "!" are
considered equal, since the compiler translates "!" into "_" before doing
anything.]

Incidentally, the compiler goes through the process which you described in order
to find the integer offset.  That is, it has a (homomorphic image of a) record class
descriptor and a string which is supposed to be the name of a field of that class.
The compiler locates the TXTARR information, performs a search loop using EQU,
and uses the index of the string in the array as the integer offset, issuing
a spritely error message if the string is not in TXTARR.

∂28-JUN-76  1535	FTP:SAIL(A700SA00) at CMUB	CMU bug report =F8=     LDE 
From: SAIL(A700SA00) at CMUB
Date: 28 Jun 1976 1835 EDT
Subject: CMU bug report =F8=     LDE
To:   AIL at SU-AI, JFR at SU-AI, RHT at SU-AI
- - - -
CMU bug report  =F8=	LDE 28-Jun-76
	Seems related to =C1= #SP which is claimed to be fixed:
begin
require "[]()" delimiters;
define int(a)=[assignc a=0; integer gar; outstr(cvps(a))];
begin int(); end;
end
	gets a compiler err msg.  See ASSING.SAI[CMU,AIL] or
[A700SA00].



-------

∂03-JUL-76  1509	JRL   via IMSSSS	SAIL bug
To:   RHT, JFR, AIL    
CHECK!TYPE does not know about RECORD!POINTER. See CHKTST.SAI[LEP,JRL].
         Jim low
[#XH JFR 7-4-76]
∂04-JUL-76  1305	SYS  	Your message file exceeds 10K words.  Unless you delete some messages,    
To:   SGK, RWG, RHT, AIL, ALS, JP, TVR, RH, JMC 
or BURP your mail file, or move your mail into your own disk allocation, your
entire message file will be purged.

∂04-JUL-76  1603	JRL   via IMSSSS	Check!type bug    
To:   RHT, JFR, AIL    
CHECK!TYPE(RESERVED), CHECK!TYPE(LEAP!ARRAY) don't work.
Reason is that @RSTDC given as parameter to exec routine but
@RSTDC was defined after @RESERVED so class-indexing doesn't work.
Fix is to move definition of @RSTDC before  @RESERVED in HEL.

Manual typo. Page 49 bottom of right column. LPARRAY should be
LEAP!ARRAY.

		Jim low