*start*
04028 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 4 Aug 83 9:16:33 PDT
From: Satterthwaite.pa
Subject: Cross Compilers and Friends
To: Rovner
cc: Levin, Maxwell, Sweet, Lampson, Satterthwaite
Here's the state of the Rubicon-to-Trinity cross-software, which currently runs in Cedar 4 and produces
- byte code compatible with SDD's Trinity instruction set
- there are the usual extensions to support AssignRef, etc.
- this is Trinity, not the current SDD instruction set (which uses 32 bit control links)
- BCD's compatible with nothing (change the version id in BcdDefs before rebuilding this stuff)
- symbol tables compatible with Cedar 4 (but catch phrases have body table entries)
There are cross versions of the Compiler, Binder, PGS, TableCompiler, BL (bcd lister), CL (code lister) and SL (symbol lister). As far as possible, these programs share sources with the corresponding programs on [Indigo]<CedarLang>*. Source modules that must be different, command files, and assorted boilerplate are stored on [Indigo]<CedarLang>Trinity>*.
To make these programs, Bringover
[Indigo]<CedarLang>Trinity>Compiler>CrossCompiler.df
[Indigo]<CedarLang>Trinity>Binder>CrossBinder.df
[Indigo]<CedarLang>Trinity>PGS>CrossPGS.df -- PGS and TableCompiler
[Indigo]<CedarLang>Trinity>Lister>CrossLister.df -- BL, CL and SL
and run the command files
BuildCrossCompiler.cm
BuildCrossBinder.cm
BuildCrossPGS.cm
BuildCrossLister.cm
Note that the current .df files do not store any of the .bcd's for the cross components. Since building the compiler produces various bits and pieces needed by each of the other programs, BuildCrossCompiler.cm must be run first. The other command files can be run in any order.
I have tested these .df and command files by erasing my disk, installing a standard Cedar 4.4, getting the compiler and binder from [Indigo]<CedarLang>, and running the command files in the order listed above.
I have not tried to run the cross software (because the BCD formats are incompatible with current versions of both Cedar and SDD Mesa). Using fairly recent versions of all these programs that produced BCD's compatible with SDD's Mesa system, I was able to build a test compiler that successfully recompiled itself as well as a number of test programs from SDD.
All these programs will presumably require conversion to run in a Cedar 5.0 environment before the bootstrap to Trinity opcodes. I will be giving Paul hardcopies of Waterlily output showing the differences between CedarLang and CedarLang>Trinity for the modules in the front end of the compiler. The command file
[Indigo]<CedarLang>Trinity>Compiler>CompareCrossCompiler.cm
will reproduce this output (assuming that both sets of sources are on the local disk). I periodically bring these modules into synch by updating the modules on CedarLang>Trinity until only the differences shown on those listings, or equivalent ones, remain. (Unfortunately, Waterlily is of limited help with this because the line numbers are usually different). You might want to keep this procedure in mind before doing any massive reformatting or gratuitous editing.
The code generator modules on [Indigo]<CedarLang>Trinity>Compiler, some of which differ significantly from their CedarLang counterparts, were effectively brought into synch with SDD's versions thereof late last year; you should probably check with Dick Sweet to find out about significant bug fixes or improvements made since then. Note that none of SDD's changes to support 32 bit control links have been made to any of the sources on [Indigo]CedarLang>Trinity.
P.S. to Roy:
There is also a set of sources for a cross packager on [Indigo]<CedarLang>Trinity>Packager>*. At one point, this compiled and executed, successfully packaging the test compiler. It uses SDD's BCD formats, and I have made no efforts to update it since last December. It may be entirely inappropriate for the Cedar 5 OS. Salvage what pieces you can.
*start*
10634 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Aug 83 12:51:38 PDT
From: Satterthwaite.pa
Subject: Directories, Subsystems
To: Sweet, Elliott, BLewis
I should have copied you on this too, in case you want to look at any of the sources or to know where things stand in Cedar.
-------------------------------------
Date: 16 Aug 83 10:46:19 PDT
From: Satterthwaite.pa
Subject: Re: programs
In-reply-to: "Maxwell's message of 27 Jul 83 10:34:22 PDT"
To: Levin, Maxwell, Rovner
cc: Satterthwaite, Lampson
Here's a short list of the programs that I both maintain and use in producing successive versions of the compiler, binder, etc., organized according to exported components of the DF files. New versions of all of these are built on subdirectories of CedarLang. See my message of 4 August for information about cross compilers (for Trinity opcodes) and their friends.
-- Compiler.df: Cedar Compiler
-- BCD.df is released separately but generally managed as part of the compiler
Exports [Indigo]<CedarLang>Compiler> ReleaseAs [Indigo]<Cedar>Top>
+Compiler.bcd!103 8-Jul-83 14:23:04 PDT
--+PilotCompiler.bcd!15 24-Sep-82 9:42:04 PDT
The Cedar compiler, normally produced by
bind Compiler ← CedarCompiler.config
In the past, I have also built and released PilotCompiler, a version of the compiler capable
of running with fewer Cedar interfaces, produced by
bind PilotCompiler.config
During certain stages of development, it is essential to use a compiler that does NOT import
the interface SymbolTable (and hence SymbolPack) from the system. When that happens,
I find it convenient to make a compiler using PilotCompiler.config, i.e.,
bind Compiler ← PilotCompiler.config
The current compiler on CedarLang was produced this way.
Finally, when Eric and I were developing the modeller and compiler in parallel, the
CompilerOps exported by the compiler and imported by the modeller could get out of phase;
the commands
bind InnerCompiler.config/-c
bind Compiler ← BridgeCompiler.config
will accomplish the fancy footwork necessary to reconcile this (or can serve as a guide to
doing similar things for another interface).
-- Binder.df: Cedar Binder
Exports [Indigo]<CedarLang>Binder> ReleaseAs [Indigo]<Cedar>Top>
+Binder.bcd!17 13-May-83 8:47:36 PDT
--+PilotBinder.bcd!5 8-Oct-82 10:33:55 PDT
The Cedar binder, normally produced by
bind Binder ← CedarBinder.config -- boot or rollback afterward
There is also a PilotBinder.config, which uses a private SymbolTable interface and is
useful for the same purposes as PilotCompiler.config. (This is less critical, however,
because the binder uses symbol tables only for producing error messages and can fall back
to version stamps and entry numbers if things go wrong.)
-- PGS.df: Cedar PGS and TableCompiler
Exports [Indigo]<CedarLang>PGS> ReleaseAs [Indigo]<Cedar>PGS>
+PGS.bcd!10 10-May-83 11:56:45 PDT
+TableCompiler.bcd!10 10-May-83 11:56:50 PDT
PGS is the LALR parser generator. It takes a Cedar source file in which a grammar has
been embedded in the form of stylized comments attached to the arms of a SELECT and
produces:
- a new version of the Cedar source file, with the case arms renumbered sequentially.
- an encoding of the parsing tables, formatted as a Cedar bcd file
- a Cedar DEFINITIONS file, in source form, defining the format of the parsing tables
and providing a collection of constants needed by the scanner and parser.
- optionally, a summary of the extracted grammar
- a log file with statistics and any error or warning messages.
See the notes left by Jim Eve for details of LALR parsing theory, table generation
algorithms, debugging grammars, etc. See PGS.bravo for a somewhat sketchy description
of command line conventions, etc.
NOTE: do NOT convert the stylized comments to Tioga comment nodes.
Recent files containing embedded grammars have the appropriate PGS command line as
an initial comment. Here are the commands for the older files without such comments:
Compiler: [grammar: Cedar] ← Pass1T.mesa
needs CBinary.bcd
produces Pass1T.mesa, MesaTab.bcd, ParseTable.mesa
exports MesaTab as a PROGRAM in the interface CBinary
Binder: [defs: BcdParseTable, grammar: CMesa] ← BcdTreeBuild.mesa
produces BcdTreeBuild.mesa, BcdParseData.bcd, BcdParseTable.mesa
exports BcdParseData directly (no interface)
PGS: [defs: PGSParseTable, grammar: PGS] ← PGSScan.mesa
produces PGSScan.mesa, PGSParseData.bcd, PGSParseTable.mesa
exports PGSParseData directly (no interface)
TableCompiler is a program to convert assorted inputs to Cedar .bcd files that can be bound
into configurations and managed as code segments. If the source file name has extension
.mesa, it extracts string literals from string array declarations and gives the skeleton of a
DEFINITIONS file describing the resulting structure; otherwise, it just wraps a bcd header
around a collection of bits.
SDD has some documentation of the TableCompiler; the commands used to build components
of the compiler are
TableCompiler ErrorTab.mesa CBinary/i -- makes a new table of error messages
TableCompiler DebugTab.mesa CBinary/i -- makes new tables for printing trees, symbols
Both commands read CBinary.bcd and export PROGRAMs to it. Its a good idea to compile
ErrorTab and DebugTab first using the standard compiler; this checks that the number of
elements in each array matches the corresponding enumeration. Then run TableCompiler
to produce .bcd's with the same name but different contents.
-- Lister.df: Cedar Lister
Exports [Indigo]<CedarLang>Lister> ReleaseAs [Indigo]<Cedar>Lister>
+Lister.bcd!8 12-May-83 12:49:04 PDT
+BL.bcd!10 12-May-83 12:49:11 PDT
+CL.bcd!10 12-May-83 12:49:15 PDT
+GL.bcd!10 12-May-83 12:49:19 PDT
+SL.bcd!10 12-May-83 12:49:24 PDT
+OpDefsGenerator.bcd!5 10-May-83 12:54:55 PDT
Lister is SDD's crufty old Lister, modified in minimal ways to run in a Cedar environment.
SDD probably has some documentation of all the wierd and wonderful options, although I
think our lister corresponds to a quite old version of theirs. For each of the last several
releases, I have intended to withdraw this program but have found that it can be recompiled
with little or no effort. I do not recommend converting it to the new OS interfaces without a
thorough overhaul.
BL, CL, GL and SL are somewhat cleaned up pieces of the lister, packaged separately for
separate functions (they share several utility modules). They list bcd's, code, global frame
information, and symbols respectively. Details of their use have appeared in the various
release messages (but apparently got lost in compiling the Cedar Reference Manual?).
OpDefsGenerator is used to generate various summaries, DEFINITIONS modules used by the
compiler, tables used by the lister, etc., from an encoded definition of an opcode set. I use
this program very infrequently (only when the opcodes change); Dick Sweet has agreed to
advise when necessary.
-- CodeCompare.df: Cedar Code Compare
Exports [Indigo]<CedarLang>CodeCompare> ReleaseAs [Indigo]<Cedar>CodeCompare>
+CodeCompare.bcd!1 16-Aug-83 8:55:20 PDT
CodeCompare is useful for doing regression tests on the compiler. It is not in the current
release; I have just moved it from my private directory to CedarLang. The command
CodeCompare Host Directory/d file1.bcd file2.bcd
will compare the code of file1.bcd, file2.bcd, etc., with the code of [Host]<Directory>file1.bcd,
[Host]<Directory>file2.bcd, etc., writing summaries into the executive's typescript. To see if
a new compiler can successfully recompile itself, the usual ritual is:
-- build a new compiler, iterating recompilation, etc., until you believe that
-- compiling should be idempotent
SModel BCD.df; SModel Compiler.df
@compile.compiler -- from Compiler.df
@compare.compiler -- ditto
-- if there are no differences, or only expected differences:
Bringover /a BCD.df; Bringover /a Compiler.df -- get create dates back in synch
CodeCompare relies heavily on STP and may require extensive revision for
Cedar 5.0. When I last checked, Loretta was SDD's expert on CodeCompare.
Note that all the above programs share use of <CedarLang>BCD> (released using BCD.df) and <CedarLang>LangSupport>, a repository for source files shared by more than one component. In general, those source files are parameterized, so the bcd's are not shared; the source is released by the "highest" DF file that uses it.
Not (still/yet) in the mainstream:
-- Modeller.df
No longer on <CedarLang> but still on <Cedar>. This is the old modeller. I see no reason to
keep it. Models written in the old modelling language (available in many of the
DF files above) are fairly easy to convert to (inelegant) SML and are probably worth
keeping as starting points.
-- ReplacementTool.df
This was left by Eric. I know nothing about it.
-- SML.df
Directory [Indigo]<CedarLang>SML>
SML.bcd!17 15-Aug-83 12:19:16 PDT
SML is the new Cedar system modeller. This is an incomplete DF file, containing all the
required sources and system interfaces (I hope), some examples, and some command files.
I have been using SML itself to build new versions, but the following should work:
pgs [defs: SMParseTable, bcd: SMParseData, grammar: SML] ← SMTreeBuildImpl.mesa
pgs [defs: CtoSParseTable, bcd: CtoSParseData, grammar: CtoS] ← CtoSTreeBuildImpl.mesa
@CompileSML.cm
bind SML.config
------------------------------------------------------------
*start*
01274 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Aug 83 15:48:03 PDT
From: Satterthwaite.pa
Subject: Required Source Listings
To: Rovner
cc: Levin, Sweet, Taylor, Wick
cc: Satterthwaite
To advise on maintaining or developing the Mesa and Cedar compilers, I would need listings of the source files (those with extension .mesa or .model) named in the following DF files (all currently on /Indigo/CedarLang/):
BCD/BCD.df
Compiler/Compiler.df
Compiler/CompilerSource.df
For this purpose, the sources of the code generators, those modules named in the DF file
between CodeDefs.mesa and VarUtils.mesa inclusive, would be desirable but not essential.
PGS/PGS.df
PGS/PGSSource.df
To similarly advise on the binder, I would additionally need listings of the source files named in
Binder/Binder.df
Binder/BinderSource.df
Finally, to advise on the new system modeller, if that is desired, I would need listings of the source files named in
SML/SML.df
Subject to informing Tartan Laboratories of such an arrangement and securing their consent and approval, I would agree to treat these listings as information proprietary to Xerox and to observe the provisions of an applicable non-disclosure agreement.*start*
03175 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 17 Aug 83 8:50:29 PDT
From: Satterthwaite.pa
Subject: Re: Ropes vs String Literals in Cedar
In-reply-to: "Your message of 16 Aug 83 16:10:59 PDT (Tuesday)"
To: Sandman
cc: Satterthwaite, Sweet
Jim,
In Cedar, a string literal (quoted text) can turn into a value with one of three types:
- a STRING (ordinary lengthening coercions can make this a LONG STRING)
- a REF TEXT
- a Rope.Text, which happens to be a discriminated variant of Rope.ROPE and thus
assignable to a Rope.ROPE variable.
STRING and REF TEXT are predeclared; that is, a complete description of these types is entered into the initial symbol table. Rope.ROPE (and Rope.Text) are treated more or less opaquely by the compiler. It knows the interface and type names, and it assumes that the actual bits representing the referent of a Rope.Text happen to be identical to the bits for representing TEXT. (Ropes have lots of other fancy variants, and for all the obvious reasons we didn't want to build the details of the other cases into the compiler.)
When the compiler sees a string literal in pass 3, it looks at the target type. If one of the three cases it knows about can be coerced to that target type, it chooses that case and enters the literal into its string literal table with that type. (At one point, I had to extend the entries in the literal table to include a type code.)
If the target type doesn't help, the compiler makes a somewhat arbitrary choice; currently STRING if there are no REFs floating around, REF TEXT otherwise. It's possible to construct examples in which this strategy gives unfortunate error messages, but there's only one that I've seen in practical programs. If the target type is REF ANY, the compiler chooses REF TEXT. Now that Cedar has pretty much settled on Ropes, this is unfortunate, especially since people usually don't notice until they try to do a REF ANY discrimination and can't understand why the Rope.ROPE cases isn't executed. The obvious "fix" is to make Rope.Texts when the context is ambiguous; unfortunately, this requires wiring Rope.ROPE into the compiler more tightly than I'd like. (Note that if Ropes are only created when the target type is Rope, then the required symbol table entry for the type of that literal must already exist, having been copied from some included module's symbol table.)
Global STRING literals, local STRING literals, and REF text literals require somewhat different initialization; the code generators make several passes through the string literal table to find each case and generate the appropriate code. In our implementation, the bodies of REF text literals are actually put into an extension of the BCD header (another code segment, in essence) and moved to garbage-collected storage by the loader, which also fills in an area in the global frame (much like the code links area) with the corresponding REFs. The binder (and loader?) merge these bcd extensions to avoid multiple copies of the same literal.
Ed
Dick: Look at StringRef in Pass3Xb and TextRep in Pass3M of the Cedar compiler to see the details.*start*
01499 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 23 Aug 83 17:12:14 PDT
From: Satterthwaite.pa
Subject: Final Status
To: Rovner
cc: Sweet, Maxwell, Levin
Paul,
My best shot at documenting the tree nodes is now stored on
/Indigo/CedarLang/Compiler/TreeDoc.tioga
Caution: this file is NOT currently part of any DF file.
I'm afraid that I spent more time the last two days on exit interviews and saying goodby to people than I had planned, so I didn't make a whole lot more progress. In particular, the section describing the expression nodes may be a bit thin. I hope that I have gotten the number and nature of the sons of those nodes right; I know that some attribute bits are missing, especially on the oddball nodes, because I didn't get all the way through Pass3X* and Pass4X* checking on use of attr and info fields. At worst, you should have something worth correcting and updating as you have to trace through the use of a particular node.
I have removed the protection from my Dorado disk, so any of you should feel free to browse through my Cedar volume before it is erased. I think everything of value has been saved, but check and also consider it a transient resource for recovering from blunders or catastrophes on the file servers.
In the absence of a definitive consulting agreement, feel free to send questions about things I have overlooked or misrepresented by electronic mail. If all goes well, I should be back online in a week or so.
Ed
*start*
01003 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 16 SEP 83 06:23:38 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 16 Sep 83 09:23:59-EDT
Received: ID <SATTERTHWAITE@TL-20B.TARTAN>; Fri 16 Sep 83 09:23:33-EDT
Date: Fri, 16 Sep 83 09:23:32 EDT
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Status
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Dick,
We arrived safely. Things have been hectic, but most of the move, starting
school, starting work, etc. has gone fairly smoothly. Thanks for the
cookbook; Ruth will be writing soon.
How are things in Palo Alto, especially at Xerox. I've heard very little
from anyone at Parc. In fact, Paul Rovner has ignored my messages about
the state of the consulting agreement we were working on so that I could
have compiler listings, so I don't know what the state of all that is. I
trust that nothing serious in the front-end has broken yet.
Ed
-------
*start*
00662 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 16 Sep 83 14:17:26 PDT (Friday)
From: Sweet.PA
Subject: Re: Status
In-reply-to: Your message of Fri, 16 Sep 83 09:23:32 EDT
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
Things are going ok here. We're a little late on getting Klamath out, so I
have been debugging the loader for the last week while Dale Knutsen went to
his brother's wedding.
Did the van arrive with your things on time? How is the house?
Are you sure Paul is ignoring you? Maybe our mail software has trouble
getting back to you (if you get this, at least the SDD software works).
Dick
*start*
02380 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 13 Oct 83 16:18:55 PDT (Thursday)
From: Sweet.PA
Subject: Tricky bug fix
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
I'd like to fix a bug that caused bad code in the Pilot Kernel without destroying a feature that is used several places. Any suggestions about how to procede would be appreciated.
Consider the declarations:
Link: TYPE = RECORD [x, y: CARDINAL];
pLink: POINTER TO Link = LOOPHOLE[200b];
prev: Link = pLink↑;
Pass 3 looks at prev, and decides it's not constant because of the uparrow. Pass 4 decides there are no free variables, so stores the tree instead of generating any code for initializing prev.
Pass3:
prev [301], type = Link [264] [init only], # refs: 2
Pass4:
prev [301], type = Link [264] [const]
uparrow[40] info=283
cast[124] info=296
128
This leads to incorrect code if you say something like
pLink↑ ← new value;
xx ← prev; -- unfortunately this gets the new value.
Now, fixing Pass 4 so that it turns off noFreeVariables when it encounters uparrow is easy enough (there may be code inside index processing that deals directly with pointers to arrays, I know this to be the case for Pass 3), but what will this do to
p: POINTER TO CARDINAL = @ptr.y;
where some of the RPC code relies on this being a constant
p [316], type = ref [326] [const], value: 129
in order to get around the absense of a construct in Mesa for getting the offset of a field within a record.
====================
Changing the subject, I ran across another case of this construct
ENABLE ObjAlloc.Error[insufficientSpace] => GOTO needMoreWindows;
Fortunately, it now blows up the compiler rather than generating the unsuspected code of raising the ERROR to get the value to test.
Can you think of a reasonable way to flag as a warning any ERROR ... used in an expression context other than ENDCASE => ERROR ... which motivated us to allow ERROR in an expression context?
====================
Changing again, how are the kids liking school? Emilie seems to be having her best year yet from a standpoint of getting along with classmates and enjoying school. I believe that she is learning things, as well. Marjorie is doing great in kindergarten, as I suspected she would.
Tell Ruth hi from all of us.
Dick
*start*
02515 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 13 OCT 83 17:41:45 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 13 Oct 83 20:42:07-EDT
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Thu 13 Oct 83 20:41:27-EDT
Date: Thu, 13 Oct 83 20:41:26 EDT
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Tricky bug fix
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Thu 13 Oct 83 16:18:55-EDT
Hi.
The letter from Paul with the agreement that let's me have source listings
just arrived on Monday, so Bill and/or his lawyers are still looking it
over and I don't have listings yet.
Off the top of my head ...
When you think about the semantics, it seems quite clear that uparrow and
dot (not to be confused with dollar) should turn off the no-free-variable
bit. (I vaguely recall fixing this or a similar bug in the Cedar front
end at one point.) Actually, things would be ok for a POINTER TO CONST T.
This is what a quoted string literal really should be (have you even dared
to make it READONLY), but you can't say so.
I think there is special code to make @NIL[T].f have a constant value that
does not depend on the no-free-variable attribute. (It's likely to be
in Pass4's processing of the @ node.) Fixing the bug might not kill
that feature, at least if the constant pointer value is NIL. And non-nil
values get you into the problem of whether the constant is MDS relative
or not.
I don't have any good ideas on the ERROR as expression problem -- the code
to allow an ERROR to match any type is already pretty messy as I recall.
The boy's seem to be adjusting to their new school. Robbie has been
enthusiastic from the beginning, but Willie was slow to adjust. Their
school (Falk) is associated with the Univ. of Pittsburgh, and we're
getting the feeling that we'd like a little less experimentation and
jargon and a little more emphasis on the basics. Robbie can read anything
he wants to and has pretty solid math skills, so he's enjoying the freedom
and lack of structure. Willie doesn't have those skills yet, and we're
afraid he'll manage to slip through first grade without making much
progress on them.
Say hello to Janet and your girls from all of us. Any more interesting
rumors from Parc yet? I've talked to Eric Schmidt and Chuck Geschke
recently, but haven't gotten hold of Paul Rovner or anyone else from
CSL yet.
Ed
-------
*start*
00468 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 14 Oct 83 13:50:57 PDT (Friday)
From: Sweet.PA
Subject: Re: Tricky bug fix
In-reply-to: Your message of Thu, 13 Oct 83 20:41:26 EDT
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
Considering the problem of errorx, suppose I use a spare attr bit on the errorx node that I explicitly set from ENDCASE (and maybe ELSE), and then complain if the bit isn't turned on?
Dick
*start*
01172 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 16 OCT 83 17:19:42 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 16 Oct 83 20:19:42-EDT
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Sun 16 Oct 83 20:18:50-EDT
Date: Sun, 16 Oct 83 20:18:49 EDT
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Tricky bug fix
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Fri 14 Oct 83 13:50:57-EDT
On errorx: I suppose such a scheme would work. The coding will probably
come out to be a bit kludgy and inelegant, however, at least for ENDCASE.
The various case drivers are set up to take item processing routines that
don't know whether they are working on the ENDCASE, so you will have to
reparameterize all this or put the special test for errorx in the case
drivers, not the expression processing routines.
If you are going to muck with the case stuff, why not add some logic to
test whether all possibilities have been exhausted and invent a new
construct similar to ERROR that can occur at compile time?
Ed
-------
*start*
01003 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 18 Oct 83 11:09:44 PDT (Tuesday)
From: Sweet.PA
Subject: Type checking in pass 4
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
I recall your saying the Pass4 has to redo some of the type checking to handle cases where Pass3 doesn't have enough knowledge to make a proper check, such as subrange bounds, array ranges, etc.
I have the case
oneWord: ARRAY [0..1) OF CARDINAL;
pointerToFourWords: LONG POINTER TO ARRAY[0..4) OF CARDINAL;
pointerToFourWords ← @oneWord;
Pass 3 agrees that as far as it knows, they are assignable, so it calls Lengthen to lengthen the pointer to oneWord. This stores into the info field of the lengthen node the type of FourWordsRef. Pass 4 gets the type out of the info but doesn't ever recalculate the type in light of increased knowledge as far as I can see. Is there some other node for which this is done that I could look at to see what to do for lengthen?
Dick
*start*
01580 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 1 DEC 83 06:26:50 PST
Received: from TARTAN by CMU-CS-C with TLnet; 1 Dec 83 09:27:24-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Thu 1 Dec 83 09:25:35-EST
Date: Thu, 1 Dec 83 09:25:34 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Status
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Dick,
How are things? The rumor mill has been starting to churn again concerning
the fate of CSL. If what I hear is correct, it sounds like Cedar doesn't
have much future, at least in its current incarnation. I assume that is
why the compiler listings, etc., that Paul was going to send never arrived.
Have you managed to keep the Mesa compiler together? Whatever happened with
the Mesa Development Environment as a product? Before I left Palo Alto,
John Wick and Tim Townsend were talking about going outside for Fortan,
Pascal and/or C compilers, possibly from Tartan, but I've heard nothing since.
What's been the reaction to the appearance of McGregor's window package
from Microsoft?
I hope everything is going well for you. The weather here has turned cold,
and we've had some snow. That's all ok, except that it appears to be a
mistake to move an 11 year old car that's never seen cold into such a climate.
We're being nickel-and-dimed to death, and the local dealer is obviously
none too interested in such an old car (by salt-on-the-roads Pittsburgh
standards).
Our regards to Janet and the girls.
Ed
-------
*start*
04094 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 2 DEC 83 06:57:42 PST
Received: from TARTAN by CMU-CS-C with TLnet; 2 Dec 83 09:58:32-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Fri 2 Dec 83 09:56:40-EST
Date: Fri, 2 Dec 83 09:56:39 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Status
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Thu 1 Dec 83 16:19:21-EST
Dick,
Thanks for your message. It pretty much confirms rumors that I have been
hearing for a while. In fact, Forrest Baskett happened to be visiting
Tartan on Wednesday afternoon and, without ever quite saying anything
definite, managed to communicate that the rumors were indeed true. I
guess the interesting question now is how many people will follow. As
you say, Butler's leaving seems to be a real blow. Given the extent
that Butler and I had worked together the past few years, I would certainly
have a hard decision to make if I were still there.
By the way, given the strong feelings on both sides, it wouldn't surprise
me if Butler loses his access to Xerox pretty quickly. If it's not too
late, you or someone in SDD ought to copy [Ivy]<Lampson>CLRM*.press and *.bx
to some safe place. Even if the text has to be rekeyed (or maybe you
have a BrovoX translator), a lot of it would be a good start on a Mesa
reference manual.
On the problem with ORD: I think the tree produced by pass 1 looks like
\
ord
\
x
whether you use dot (x.ORD) or bracket (ORD[x]) notation. If so, the
dot is irrelevant, and you should trace the ord node through Exp in
pass 3. I suspect that I forgot to do a CanonicalType on the type of
x before seeing if it was of a class that had an ORD operation (I think
CanonicalType is the one that peels single component records). VAL was
added at the same time and might need the same fix.
Paul has never sent me any listings. He did send a form for me to
sign and return so that I could have them legitimately, but I don't know
what happened after that. I tried to call him at home one evening and
got no answer; maybe I should try again. In any case, I have no burning
desire to have the listings, but would be happy to receive them if you
and/or Paul want me to have them available. If you do send listings,
you should probably send hardcopies of CLRM too -- I believe that the
final two chapters really are the statement of the intended semantics
that Butler and I converged upon.
Here at Tartan, I am working on what amounts to pass 4 and parts of
passes 3 and 5 for the compiler of our propietary implementation language.
Since we haven't done our bootstrap yet, I am actually doing most of my
programming in Bliss, which Geschke found pretty amusing. I'm even using
a debugger of which one Richard Johnsson is listed as a coauthor.
Ruth and the kids are fine. It took Willie much longer to adjust to the
move and the new school than it did Robbie, but he seems to have made the
transition ok. We have had some snow, which the kids have really enjoyed.
Also, we were able to drive to eastern Penna. for Thanksgiving with the
families this year, which was a lot less hassle than flying even if it is
a 6 hour drive.
Buying a house has turned out to be more complicated than we had expected.
I guess we have the usual problems of people who sell a house in California
and move elsewhere. For the amount of money that the IRS would like us
to spend (which is more than I would choose to spend otherwise), the
choice seems to be a huge but aging house with no yard in a convenient
location or a nice suburban house with a lot of land and a horrible
commute. If we still had a good kitchen designer, etc., in the neighborhood
and the right temperment to deal with contractors, remodelling, etc., I
think the right move would be to buy an older house in one of the city
neighborhoods that's being rediscovered and redo it, but I suspect we'll
end up in the suburbs instead.
Ed
-------
*start*
00829 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 3 Jan 84 15:43:02 PST (Tuesday)
From: Sweet.PA
Subject: Comparing constant opaque values
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
With a loophole, it is possible to define constant values of lengthKnown opaque types (like null values, for example). If you try to compare two of these, pass 4 blows up. I have played around with it a bit to see what's going on and have the following question.
Pass4D.RepForType returns a Repr of other+both for lengthKnown opaques. It seems to me that comparison of constant ones would work properly if it just returned other. Can you remember for what reason it also calls them both?
How was your Christmas? I assume it was white. It was nice to get Ruth's note in the card.
Dick
*start*
02492 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 4 JAN 84 07:16:09 PST
Received: from TARTAN by CMU-CS-C with TLnet; 4 Jan 84 10:15:07-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Wed 4 Jan 84 09:02:53-EST
Date: Wed, 4 Jan 84 09:02:51 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Comparing constant opaque values
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Tue 3 Jan 84 15:43:02-EST
You are right that assigning a Repr of other to opaques would seem more
sensible. I suspect that the code in RepForType was copied from UNSPECIFIED,
which does use this representation (to allow, misguidedly I think, the
< and > operations on UNSPECIFIED, with the other operand forcing the
representation).
I don't know why this causes pass 4 to blow up though (unless comparing two
UNSPECIFIED constants does too). I'm assuming that you are talking about
= and #; < and > should not work on opaque types (is the pass 3 predicate
right?).
My advice would be to change RepForType to return other; maybe you will
blow away somebody's bug fix, but it seems right conceptually.
As you might guess from my vagueness, I'm still without listings and
probably likely to remain so. I've gotten only deafening silence from
Paul. I don't know what his plans are, but I spent a day with Butler in
Philadelphia over the vacation and got the impression that a lot of the
CSL folks were about to announce their departure for DEC. I understand
that Phil Petit did so yesterday. This raises a lot of questions about
whether even the existing hardware and software base can be maintained --
it's probably pretty hard to hire a Dorado repair person off the street,
not to mention a Cedar repair person.
By the way, Butler did say that the Cedar Language Reference Manual is
about to come out as a blue & white despite his departure -- I am looking
forward to having it publicly available.
How is the Mesa Development Environment doing by now?
Our holidays were very cold (-14 and windy on Christmas morning, with a
wind chill factor of -59 at one point). It had snowed a few days earlier,
and nothing melted so we did have a white Christmas. We spent Christmas
here and then went to Phila the week between Christmas and New Years to
visit the families, which we enjoyed.
Best wishes for the New Year. Please keep in touch.
Ed
-------
*start*
01298 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 10 Jan 84 13:39:38 PST (Tuesday)
From: Sweet.PA
Subject: General things
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
The fix for opaque types worked fine. The reason it blew up is that it was calling TreeLiteralValue for things with rep both, which was only willing to deal with single word values.
I made a listing of the Mesa compiler for you, but decided to make a listing of the Cedar compiler and send you both in the same package. Do you remember what df files I should list the sources of?
I have a narrow question.
in defs:
Object: TYPE [size];
Rec: RECORD [...f: Object, ...];
in impl:
Object: PUBLIC TYPE = ...;
t: Defs.Rec;
One can say NARROW[t.f, Object], and pass 3 doesn't complain. On the other hand, it doesn't put in a cast node, so that the dot code in pass 5 blows up if you then take a field of f based on the fields of the public type. Is there any reason that it shouldn't?
Also, I can remember a discussion about why NARROW can't appear on the left of an assignment, but can't remember the reason. Is it easy to recall?
Tell Ruth that Janet will be wearing her square dance dress a week from Saturday. We'll miss you at our annual Koinonia square dance.
Dick
*start*
03390 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 11 JAN 84 07:31:54 PST
Received: from TARTAN by CMU-CS-C with TLnet; 11 Jan 84 10:32:04-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Wed 11 Jan 84 10:30:39-EST
Date: Wed, 11 Jan 84 10:30:32 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: General things
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Tue 10 Jan 84 13:39:38-EST
Dick,
Thanks for your message. Assorted answers:
According to the letter from Paul, the source listings I am allowed to have
are the ones named by the following DF files (all on [Indigo]<CedarLang>):
BCD>BCD.df
Compiler>Compiler.df
Compiler>CompilerSource.df
PGS>PGS.df
PGS>PGSSource.df
Binder>Binder.df
Binder>BinderSource.df
SML>SML.df
I assume that you won't have any questions about the code generators, so
there's no point in your sending them. Ditto with Brian on the binder.
I'm neutral on PGS.
I'd be interested in making sure that the SML stuff doesn't get lost,
since the immediate heir (Butler) has already left, and I hear rumors that
the heir apparent (Roy) is about to. On the other hand, I'm not sure I want
the listings right now, because I'm currently trying to design something
similar for Tartan and would like to avoid the appearance of a conflict of
interest. Do Brian and Dave have any plans to go beyond DF files?
Whatever you decide, you should probably send Rich a memo saying exactly
what you have sent, since he is the SDD person actually named in the
agreement I signed.
On NARROW[t.f, Object].field, I think the NARROW should turn into a cast
node when it is otherwise a no-op, as you suggest. As I recall, there is
a pass 3 routine used by NARROW and friends (ISTYPE, WITH..SELECT) that
returns a bunch of bools indicating how the narrow is to be implemented.
The opaque <-> concrete and identity maps are legal but require no code,
so I guess the node disappears (in pass 4?). It shouldn't be too hard to
make this a cast, since I had planned to have some narrows turn into
shorten, etc.
Actually, the real problem in this particular example is that pass 5
has to compute the type of the left operand of dot or dollar to
figure out the padding. I think it would have been better to get
pass 5 out of the type-computation business entirely, by having
pass 4 (which is in the type -> representation business) insert
tree nodes with the padding information. But that's not a quick fix.
As hinted above, Cedar has long viewed NARROW as a value-to-value
operation, which therefore doesn't make sense on the lhs. You can
write something like
NARROW[@v, POINTER TO Foo.red] ← x
but that's only slightly safer than LOOPHOLE (and doesn't work if the
tag of v is not already set to red). In Cedar, this is exactly what
you do for REFs; I guess the safe analog of the @ construct would be
something like
NARROW[v, VAR Foo.red] ← x,
which isn't quite right because v is normally evaluated in this context.
It snowed most of yesterday, then turned cold. I couldn't get the Mazda
started this morning and couldn't have gotten it up the driveway anyway,
so I walked to work. I'd forgotten how much fun walking in relatively
fresh snow can be.
Regards to all,
Ed
-------
*start*
01602 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 19 JAN 84 16:09:56 PST
Received: from TARTAN by CMU-CS-C with TLnet; 19 Jan 84 19:08:49-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Thu 19 Jan 84 19:08:57-EST
Date: Thu, 19 Jan 84 19:08:54 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Listings and Woks
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Jim Donahue just sent a long list of people who have recently resigned from
CSL. I assume you folks have been following all this and know that, among
others, Paul Rovner and Roy Levin are leaving. I assume that this puts
whatever agreements I had re Cedar listings in limbo, and that I certainly
won't get them from Paul. You and Rich (and John or whoever) can decide
how you feel about all this; unless SDD feels that I should have listings
of part or all of the Mesa compiler, I am inclined to write a letter to
Paul, with copies to Parc's lawyers, pointing out that I never received
the listings and terminating the agreement (to avoid later questions or
problems for me or Tartan). I basically consider the whole thing very sad.
I'm glad I'm not still at Parc, because I'd feel very strong loyalties to
people on both sides.
On a completely different subject, do you have any advice on buying a
good wok. We have a gas stove now (standard consumer, low output type)
and with high probability will have one in whatever we buy in this area --
until recently, gas has been much cheaper than electricity for such things.
Ed
-------
*start*
01784 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 22 JAN 84 10:27:14 PST
Received: from TARTAN by CMU-CS-C with TLnet; 22 Jan 84 13:26:34-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Sun 22 Jan 84 13:25:52-EST
Date: Sun, 22 Jan 84 13:25:49 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Listings
To: Sweet.PA
cc: Wick.PA, Johnsson.PA, Satterthwaite%TARTAN@CMU-CS-C.ARPA
I have no objections to receiving listings of the Mesa compiler and associated
programs if you think it would be useful.
I would, however, like to have a clear understanding with the legal department
(Doug Carrothers, I think) that Paul has not sent me anything, and I'd like
to have this understood before Paul leaves. This is partly so that the
legal types understand that Paul is not the primary contact on Xerox' end
and partly because the current agreement has a clause requiring that listings
be returned upon termination of the agreement and also implies that I have
a lot of listings that I never got and currently never expect to get.
I don't want to make a big deal of all this, but I don't want any surprises
for Tartan or myself at some later time either. I think that, at the least,
any listings sent at this point should be accompanied by a letter from
Xerox acknowledging the changed circumstances and personnel. It's even
possible that someone in CSL will want to be a contact for the Cedar variants,
but that probably won't be known until the dust settles a bit more. (As far
as I know, the only person in CSL with no announced plans to leave who knows
anything about the internals of the Cedar compiler is Jim Donahue, and I
know he is not anxious to try maintaining it.)
Ed
-------
*start*
00883 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 27 FEB 84 06:54:19 PST
Received: from TARTAN by CMU-CS-C with TLnet; 27 Feb 84 09:53:15-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Mon 27 Feb 84 09:55:39-EST
Date: Mon, 27 Feb 84 09:55:38 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Things
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Any interesting news yet?
Given recent events in SDD, I am again wondering if it's time to write a
letter to the Xerox lawyers terminating the consulting arrangments that
Paul and I never quite got set up. As I said before, I'm still willing to
be flexible on this, but I don't want to get a letter from Xerox demanding
the return of some listings I never got, especially after everyone else
involved has left Xerox.
Ed
-------
*start*
00994 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 28 FEB 84 11:37:36 PST
Received: from TARTAN by CMU-CS-C with TLnet; 28 Feb 84 14:27:19-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 28 Feb 84 14:29:47-EST
Date: Tue, 28 Feb 84 14:29:33 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Things
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Mon 27 Feb 84 10:26:49-EST
Dick,
I don't see any problem with your coming for a weekend or so. At the moment,
I don't know of any that are better or worse than others, although we are
likely to be away part of the boys' spring vacation (late April, I think).
Alternatively, I wouldn't mind an excuse to spend a long weekend in California.
(Our predicted blizzard went mostly north and turned into a slush storm
here -- I think I would have preferred a nice blizzard.)
Ed
-------
*start*
00673 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 21 MAR 84 12:21:23 PST
Received: from TARTAN by CMU-CS-C with TLnet; 21 Mar 84 15:19:07-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Wed 21 Mar 84 15:20:47-EST
Date: Wed, 21 Mar 84 15:20:33 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Status
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Any further thoughts on if/when you want to visit Pittsburgh or on what you
expect to be doing for the next while? April, June and early July are
starting to fill up pretty well on this end.
Regards to all.
Ed
-------
*start*
03589 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 3 APR 84 07:06:24 PST
Received: from TARTAN by CMU-CS-C with TLnet; 3 Apr 84 10:04:24-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 3 Apr 84 09:43:59-EST
Date: Tue, 3 Apr 84 09:43:55 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Types.Assignable (or Equivalent)
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@PARC-MAXC.ARPA" of Mon 2 Apr 84 11:20:05-EST
Dick,
If you are really thinking in terms of a month or two, I'm not sure it's a
good idea to change anything. The bulk of the recoding to support
UNSPECIFIED[n] would probably take just a few days, but then there's the
problem of integration and the fact that glitches and unexpected consequences
continue to dribble in for quite a while.
First, a question on the design. I think we discussed this, but I don't
recall the resolution.
One of the more reasonable uses of UNSPECIFIED is to get the unsafe
analog of Cedar's REF ANY, as in [LONG] POINTER TO UNSPECIFIED.
Interpreting the UNSPECIFIED here as UNSPECIFIED[1] seems certain to
cause great consternation. It seems to me you need at least something
like UNSPECIFIED[ANY] to use in such contexts (it would be similar to
an opaque type with unknown size; i.e., no decl, assign, etc. operations).
Can you force people to change sources? If so, POINTER and/or
POINTER TO ANY seem like better ways of writing this. If not, it seems
to me that you are going to have a delicate problem interpreting
UNSPECIFIED without a length according to the context in which it appears.
On the type system. I don't recall the details, but you probably want to
use subranges as your models for CSE's. Since the length is significant in
the type equivalence test, you should have a length field, a lengthKnown
field and (perhaps) a lengthAny field. The lengthKnown bit is set by
Pass4D, or copied from an included symbol table, when the length field
becomes valid.
The equivalence test would be something like
(t1.lengthAny = t2.lengthAny) and
(t1.lengthAny or
(t1.lengthKnown and t2.lengthKnown and t1.length = t2.length))
This is probably the assignability test too unless you want to do automatic
lengthening, which seems like a bad thing to generalize.
This will be too permissive when the lengths are unknown, but the effect
is just to delay error detection until pass 4. To make the last statement
true, the Pass 3 procs that use hints to make new types (MakeRefType comes
to mind) have analogs in Pass 4 to check that the hints gave the right
answers. (If the hint gave the wrong answer, there was a type error, so
it's not a matter of redoing the hints -- this is not true in Cedar's
TypeLiteralPack however.)
I believe that omitting this check caused the previous failures to detect
type errors with POINTER TO ARRAY, etc. and that the details and possible
fixes were discussed in a previous message (which I can probably find if
you need it). The situation with UNSPECIFIED[n] shouldn't be any better
or worse in this respect; POINTER TO UNSPECIFIED[n] (or POINTER TO [m..n))
potentially give problems until the loophole is closed.
Are your intentions generally known yet? I'm again thinking about a letter
terminating the consulting arrangement I have with Parc, but I will give
Jim Donahue or Russ Atkinson a chance to keep it alive first. Asking them
about this might be a strong hint about your plans.
Ed
-------
*start*
02417 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 3 APR 84 07:08:22 PST
Received: from TARTAN by CMU-CS-C with TLnet; 3 Apr 84 10:07:16-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 3 Apr 84 10:08:05-EST
Date: Tue, 3 Apr 84 10:08:01 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: UNSPECIFIED[n] - PS
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Oops. I guess the whole point is to allow UNSPECIFIED[n] to match anything
of size n, so my statement about the assignability test is nonsense.
I would guess that the assignability test should return true when either
type is UNSPECIFIED[n] for any n. Then there must be a check on compatible
sizes for any binary operators taking two UNSPECIFIEDs, e.g., assignment
and comparison. I think there is code in Pass4 (Xa perhaps?) that takes
care of this for variant records and could be upgraded to make a special case
of UNSPECIFIED also, but I'd really need listings to check the details.
There's also the problem of operators that really shouldn't be defined for
UNSPECIFIED but currently are, e.g., "+". For compatibility, I guess these
need to verify in Pass 4 that any UNSPECIFIED operands really do have
size 1 (or were LONG UNSPECIFIED[1]). You might want to allow UNSPECIFIED[2]
for symmetry (using long arithmetic), but that causes problems in the current
scheme of things because it's Pass 3 that does balancing of sizes by inserting
LENGTHEN operators, and it can't be sure of the size of an UNSPECIFIED (ugh!).
Finally, I suspect that you don't want to allow UNSPECIFIEDs to get through
the equivalence test except with other UNSPECIFIEDs of the same size.
Otherwise, I fear that there will be all sorts of subtle size checking
loopholes. On the other hand, I believe that the current Types.Equivalent
does make UNSPECIFIED equivalent to anything, and I'm not sure I can
predict all the consequences of changing this, especially on recovery from
type errors. This problem can probably be solved (and the world improved)
by making a different kind of CSE for the error-recovery-flavored typeAny,
but that may have some subtle implications itself.
I guess UNSPECIFIED[n] is now sounding like a much bigger and more subtle
deal to me unless you can sacrifice some backward compatiblity. Are you
sure you want to tackle this?
Ed
-------
*start*
00854 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 3 APR 84 07:45:49 PST
Received: from TARTAN by CMU-CS-C with TLnet; 3 Apr 84 10:39:54-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 3 Apr 84 10:40:41-EST
Date: Tue, 3 Apr 84 10:40:36 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: UNSPECIFIED[n] - PPS
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Well, what I really intended was something more like
(t1.lengthAny = t2.lengthAny) and
(t1.lengthAny or
(~t1.lengthKnown or ~t2.lengthKnown or t1.length = t2.length))
which might still be wrong, but you get the idea. (I'm still not very good
at composing or proofing on a 24 x 80 display with, at most, another 24
lines accessible by scrolling in a local buffer.)
Ed
-------
*start*
01804 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 3 Apr 84 10:32:15 PST (Tuesday)
From: Sweet.PA
Subject: Re: UNSPECIFIED[n] - PS
In-reply-to: Your message of Tue, 3 Apr 84 10:40:36 EST
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
I was planning to leave the current typeAny for error recovery and create CSE for unspecified that has a length field (perhaps it should be bits rather than words, to allow them in records without having to make subranges of them legal). Programs would clearly have to be edited, since LONG UNSPECIFIED would no longer be a legal construct. Likewise, a POINTER TO UNSPECIFIED would only match another POINTER TO UNSPECIFIED, but POINTER would still be POINTER TO ANY (not explicitly stateable).
One major motivation for this type is to have a fallback type for other language processors (FORTRAN, e.g.) to create enough of a symbol table to allow some debugability with the Mesa debugger. For that purpose, I could add it to the symbol table and only have the debugger know about it.
I plan to disallow all arithmetic on UNSPECIFIED of any size (but it would be nice to be able to say INTEGER[u] if u is not larger than an INTEGER). If I don't do arithmetic, I don't have to worry about lengthening. Can the mark4 bit be used to determine lengthKnown?
I don't recall a previous message that was too specific about how to retest things in Pass4, but may have been at the point of a release where I couldn't actually do anything, and just filed it away (a cursory search of my mail file doesn't find anything, we may have talked by phone before you left, instead).
As you suggest, it might be best to drop the idea, but I can probably do it more successfully than anyone likely to come along for a while.
Dick
*start*
04770 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 3 APR 84 13:15:55 PST
Received: from TARTAN by CMU-CS-C with TLnet; 3 Apr 84 16:14:01-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 3 Apr 84 16:14:49-EST
Date: Tue, 3 Apr 84 16:14:36 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: UNSPECIFIED[n]
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Dick,
I'm surprised that you are allowed even to consider a change that would
require existing programs to be edited, especially at this point in the
game. Has all the old guard left already?
Mark4 is probably a good approximation to the lengthKnown bit. It's not
quite right though, because there are two mark bits and three interesting
states for pass 4 decl processing. I finally put something like the
lengthKnown bit in subrange CSEs because of this -- there were certain
recursive type definitions that caused the bounds to be believed while
they were still garbage (can't reconstruct the details though; maybe
only in erroneous programs). Anyway, an extra bit is cheap and makes the
intent clearer.
Here is the only message I could find dealing with rechecking hints in Pass 4.
If you don't recall doing anything about this, the bugs are probably still
there. Despite all the talk about ternary logic for Types.*, the message
is really saying that the current binary logic is ok if you put a few more
checks in Pass4, namely in those places where a new type must be constructed
for a result (@, DESC, etc.) and it might have used an incompletely filled
hint.
Any thoughts on what I should say to Jim Donahue about listings/consulting?
Ed
---------------
Date: Thu 20 Oct 83 11:45:06-EDT
From: Ed Satterthwaite <SATTERTHWAITE@TL-20B.TARTAN>
Subject: Type Checking in Pass4
To: Sweet.PA@PARC-MAXC.ARPA
cc: Rovner.PA@PARC-MAXC.ARPA, Satterthwaite@TL-20B.TARTAN
Re no complaint about:
oneWord: ARRAY [0..1) OF CARDINAL;
pointerToFourWords: LONG POINTER TO ARRAY[0..4) OF CARDINAL;
pointerToFourWords ← @oneWord;
Types.Assignable, Types.Equivalent, etc. should probably be rewritten to
return {yes, no, maybe} instead of BOOL, since they can't complete the
type check if invoked in pass 3 but can't signal a type error either.
For type checking, pass 3 should accept 'maybe' but pass 4 should probably
reject it (?? if this arises at all, it will be in conjunction with
recursive type definitions that are probably nonsensical.) For deciding
whether two type expressions are interchangable, pass 3 should insist on
'yes'. This decision is made in two general contexts that I can recall:
1) The pass 3 routines that make new types for the results of operator
applications usually accept a 'hint' (typically the target type of the
application) that can be used instead of building a new type. MakeLongType
and MakeRefType are the procedures that come to mind.
2) (Cedar only) In accumulating the entries for the RTType table, there
is code that tries to avoid making duplicate entries. I noticed some time
ago that Types.Equivalent potentially gave the wrong answer for arrays
(and refs thereto, etc.), so I put a more conservative version of
Equivalent in SymLiteralPack. (As I recall, it relies on eq tests, the
uniqueness of painted types, and the validity of Types.Equivalent if both
types already have mark4 set.)
Here's my long-distance analysis of the situation:
1) SymLiteralPack must be conservative in deciding equivalence; changing
Types.Equivalent to return 'maybe' would clean it up, but its current
ad hoc substitute should be good enough in practice.
2) MakeRefType, etc., need not be conservative, since if the 'maybe' case
turns out to be 'no', there is a type error, and the fact that a new
symbol table entry wasn't created doesn't matter. If these procedures
accept 'maybe' for the hint (which is what they in effect do now), then
pass 4 must recheck that the operand of the type constructor is
equivalent to the type of the operand of the value constructor, e.g.,
for @x, the code for Addr in pass 4 must check that the referent type
of the info on the 'addr' node is equivalent to the type of x (else report
an error). Note that this needs to be done only for operators where the
type of the result is not taken from the type of one of the operands.
The operators that come to mind are @, DESCRIPTOR, LONG, and NEW, but
you can check by seeing which MakeXXXType's take hints and then seeing
where they are called with a hint different from typeANY. In particular,
there may be some uses of MakeRefType in conjunction with VAR types that
are not obvious without a careful look.
Hope this information is of some help.
Ed
-------
-------
*start*
00682 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 24 APR 84 06:04:51 PST
Received: from TARTAN by CMU-CS-C with TLnet; 24 Apr 84 09:05:47-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 24 Apr 84 09:04:00-EST
Date: Tue, 24 Apr 84 09:03:59 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Testing...
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Are you still there? Did this message get to you? Our version of the CMU
mailer seems to insist on "Parc-Maxc" as the host, although I understand it's
supposed to be "Xerox" now.
Anything interesting happening?
Ed
-------
*start*
01056 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 24 Apr 84 09:29:44 PST (Tuesday)
From: Sweet.PA
Subject: Re: Testing...
In-reply-to: Your message of Tue, 24 Apr 84 09:03:59 EST
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
I'm still here. There are widespread rumors that I am leaving in another month or two. Things are a little uncertain due to internal politics at DEC. I got the impression I would hear from them before now and told SUN to make me an offer. SUN did, but I still haven't heard from DEC. I should know more by the end of this week when Smokey and Richard get back from Boston.
I decided that it was silly to make any major language changes if I were leaving soon, so haven't done anything about UNSPEC[n]. I am, however, working on a procedural interface for constructing object files with enough symbol tables to get loaded and not blow up the debugger (maybe even set breakpoints).
How are things at Tartan? Don't you folks have a new product coming out sometime soon?
Dick
*start*
01476 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Return-Path: @CMU-CS-C.ARPA:SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA
Received: from CMU-CS-C.ARPA by Xerox.ARPA ; 24 APR 84 10:54:14 PST
Received: from TARTAN by CMU-CS-C with TLnet; 24 Apr 84 13:55:21-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Tue 24 Apr 84 13:53:34-EST
Date: Tue, 24 Apr 84 13:53:33 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: Testing...
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@XEROX.ARPA" of Tue 24 Apr 84 09:29:44-EST
Well, since you ask, I'm not sure how things are at Tartan. We have
announced a whole series of compiler products to become available between
very soon and the end of the summer. These are roughly all the marketable
combinations of C, Modula-2 and Pascal for the VAX, 16032 and 68000, with
DEC 20 available by special request (Maxc's being retired a bit too soon?).
In addition, we are developing a series of Ada compilers with Gensoft (formerly
Western Digital), who have a validated front end.
There's no lack of technical expertise to make all this happen, and some of
the optimized code I've been seeing is pretty impressive. But getting
good technical management seems to be a universal problem, and I wouldn't
be surprised by some slips and/or product realignment. Time will tell. In
any case, watching it all happen is fascinating and very educational.
Ed
-------
*start*
00503 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Received: from CMU-CS-C.ARPA by PARC-MAXC.ARPA; 25 APR 84 06:16:14 PST
Received: from TARTAN by CMU-CS-C with TLnet; 25 Apr 84 09:14:29-EST
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Wed 25 Apr 84 09:15:13-EST
Date: Wed, 25 Apr 84 09:15:12 EST
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Earthquake
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Any serious problems in Palo Alto?
Ed
-------
*start*
00939 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Return-Path: @CMU-CS-C.ARPA:SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA
Received: from CMU-CS-C.ARPA by Xerox.ARPA ; 04 MAY 84 13:00:00 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 4 May 84 11:36:31-EDT
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Fri 4 May 84 11:35:50-EDT
Date: Fri, 4 May 84 11:35:45 EDT
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: 3COM
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
Do you know who the people at 3COM that we know are these days and what
they are currently doing? Tartan needs a favor in the form of an expedited
delivery date, and we seem to have exhausted normal channels. I've realized
that I'm pretty out of date; in fact, I have even heard a rumor that Metcalfe
has left.
And speaking of Ethernets, does anyone know where Dave Boggs resurfaced?
Any leads would be appreciated.
Ed
-------
*start*
01261 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 4 May 84 13:48:38 PDT (Friday)
From: Sweet.PA
Subject: Re: 3COM
In-reply-to: Your message of Fri, 4 May 84 11:35:45 EDT
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
Pitts Jarvis is there. I haven't heard the Metcalfe rumor, but I don't keep up on rumors very well. I think Ron Crane is also there, did you know him?
The last word I heard on Boggs is that he plans to work on his car (the "kit" that he bought a few years back), and hasn't started looking yet.
On a related subject, my decision making is still creaking slowly along. There are political obstacles to getting a DEC offer, so I'm not sure whether that option will be real. I'm unsure how I would like SUN, so am considering the option of going to CSL (not Taylor's but the one down the street). There are still a few good people left, and they're starting to get new people as well. I may do something completely different and work on Dragon, or voice, or something. I'm meeting with Richie tomorrow to discuss things. I've already talked to Dan, Jim Donohue, Russ Atkinson, Ed McCreight, and everyone seems enthusiastic about the idea of my joining them.
I'll keep you posted.
Dick
*start*
00896 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Return-Path: @CMU-CS-C.ARPA:SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA
Received: from CMU-CS-C.ARPA by Xerox.ARPA ; 09 MAY 84 12:53:44 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 9 May 84 15:52:50-EDT
Received: ID <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>; Wed 9 May 84 15:53:21-EDT
Date: Wed, 9 May 84 15:53:19 EDT
From: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
Subject: Re: 3COM
To: Sweet.PA
cc: Satterthwaite%TARTAN@CMU-CS-C.ARPA
In-Reply-To: Message from "Sweet.PA@XEROX.ARPA" of Fri 4 May 84 13:48:38-EDT
Dick,
I'll be interested in hearing what you decide about CSL. In a recent
exchange of messages with Jim Donahue, he asked me not to cancel the
Cedar/Mesa consulting agreement just yet; maybe you already know about this.
Any truth to the rumor that the Star is about to be renamed the Sunset?
Ed
-------
*start*
01942 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 20 Jan 84 14:32:12 PST (Friday)
From: Sweet.PA
Subject: Re: Listings and Woks
In-reply-to: Your message of Thu, 19 Jan 84 19:08:54 EST
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
On the subject of listings, I suspect it would make it easier for you to answer and occasional (but hopefully not too frequent) question from me if you had a listing of at least the Mesa compiler. The main reason that I was going to send you a Cedar listing was to enable you to say "I thought I fixed that...yes, here it is fixed in Cedar...'here is the fix.'" The listings (both Mesa and Cedar) are sitting on my table, but I won't send it to you until we work things out. John is definitely in favor of keeping the agreement in force if it's ok with you. I personally can't think of any future trouble that it might cause Tartan or you.
I would buy a wok no bigger than 14" and would be sure that it had a round bottom. Flat bottomed woks make some sense if you have an electric stove, but gas was one of the ground rules. A larger one might fool you into cooking things in batches that will cool down the oil too much.
Most of the woks sold around here are made by Atlas Metal Spinning of South San Francisco. Taylor and Ng sell them under their name in stores in Houston, and probably in Pa. as well. I have one with two metal handles, but have thought from time to time that a single wooden handle would be preferable. If you have trouble finding what you want, I'd be glad to buy if for you and mail (or UPS) it to you.
I agree that it is very sad. Dan Swinehart used the analogy of a supersaturated solution, where once precipitation starts, it is extensive. I believe that Dan plans to stay at PARC at least for the couple of years that it will take to finish up his phone ideas, and who knows what will be the state at that point.
Dick
*start*
01099 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 27 Feb 84 10:26:49 PST (Monday)
From: Sweet.PA
Subject: Re: Things
In-reply-to: Your message of Mon, 27 Feb 84 09:55:38 EST
To: Ed Satterthwaite <SATTERTHWAITE%TARTAN@CMU-CS-C.ARPA>
cc: Sweet
Things are slowing down around here.
Richard, Loretta, and Smokey are going to work for Forest's DEC lab. My current leaning is not to leave at this time, in order to keep critical mass so the place won't fall completely apart. I'm keeping my options open, though, and think it might be fun to join Richard, et. al. in a year or so.
One of the major things I want to do in the next year is some language cleanup. I would appreciate your input on this if possible. Would it be possible to come visit you some weekend (not necessarily right away) and plot out some changes? I'm sure that Ma X would spring for my travel, and I would enjoy seeing you folks. I still have the listings on my table, but have been waiting for the world to stabilize before doing anything with them.
Tell Ruth and the kids hello from us.
Dick
*start*
00919 00071 UU
@00045 01536 ftffffffffffffffffffffffffffffff
@Date: 2 Apr 84 11:20:05 PST (Monday)
From: Sweet.PA
Subject: Types.Assignable (or Equivalent)
To: Satterthwaite%TARTAN@CMU-CS-C.ARPA
cc: Sweet
I'm trying to make some changes to the symbol table machinery, using allocated objects instead of global frames. While doing this I'm wondering if I can at least put in some hooks for UNSPECIFIED [n]. I seem to recall your saying that TypePack carefully doesn't depend on information that isn't there during pass 3, like the size of things. It doesn't look at the mark3 or mark4 bits, I notice. Remembering the problem with assignable tests for different sized arrays, I can imagine similar problems for UNSPEC. In the absense of listings, can you give 25 words or so on the pitfalls?
Things are looking more like I'm going to leave in a month or two, so I don't want the world too torn up.
Dick