perm filename AIL.MSG[S,AIL] blob
sn#232499 filedate 1976-08-25 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00052 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 00051 ∂21-JUL-76 0022 TOB SAIL
C00129 00052 this file produces an ∞ loop in the compiler, symptom
C00130 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
∂21-JUL-76 0022 TOB SAIL
I encountered something I've run into before
but always went around it. It is a minor crock.
If I put an END in my file, prematurely,
SAIL blows up. IO to unassigned channel
AL dod,tob
load uscsub(27b,)
Tom
∂20-JUL-76 1021 JMG SAIL
SETBREAK would be nicer to me if it reset OMIT chars to NULL
when I specified NULL for a second use of the same table entry.
As the algorithm in the manual states, if OMIT_chars then
... Well, what if NOT OMIT_chars and I don't want them. Of
course, I could do a double BREAKSET, but it took me awhile
to discover that inconvenience.
∂14-JUL-76 1635 TOB SAIL
I noticed that SAIL puts out SYNTAX ERROR IN RECORD POINTER DECLARATION
instead of UNDEFINED RECORD CLASS if I say
RECORD_POINTER (UNDEFINED_CLASS) p
You may know about this and may not care to change the error message.
Tom
comment this file produces an ∞ loop in the compiler, symptom
push-down overflow;
begin "test"
ifcr equ(compiler!banner[
length(scanc(compiler!banner
[length(scanc(compiler!banner
[length(scanc(compiler!banner,'12,"","ia"))+1 for 100],
'11,"","ia"))+1 for 100],
'40,"","ia"))+1 for 1],"0")
thenc require "hi" message endc;
end "test"