Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/dist/its-kcc.mail
There are no other files named its-kcc.mail in the archive.
19-Aug-87 13:08:08-PDT,2263;000000000011
Return-Path: <[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 13:07:48-PDT
Date: Wed, 19 Aug 87 15:51:07 EDT
From: Alan Bawden <[email protected]>
Subject: KCC meets ITS
To: [email protected]
cc: [email protected]
In-reply-to: Msg of Mon 17 Aug 87 12:02:10-PDT from Ken Harrenstien <KLH at SRI-NIC.ARPA>
Message-ID: <[email protected]>
Date: Mon 17 Aug 87 12:02:10-PDT
From: Ken Harrenstien <KLH at SRI-NIC.ARPA>
OK, you're on both lists now. Have you reached any conclusion as to the
best overall scheme for assembling and linking the compilation results?
Perhaps you, I, SRA, and anyone else that you know to be interested should
start a small offshoot mailing list to hammer out ITS-specific issues.
OK, I created an ITS-KCC mailing list here on AI. I put everybody on it
who has ever shown any interest in the project. (I also made Bug-KCC at
any ITS forward to the main Bug-KCC at NIC.)
I'm currently leaning towards having Midas do the assembly, especially
since I did an experiment last night and determined that Midas is perfectly
happy with code like:
GO: MOVE 1,FOO"END
FOO"END: 700.
So if KCC always prefixes the users symbols with: USER" (or something)
there shouldn't be any problem. I assume that KCC isn't -already- making
some use of the assembler's block structure?
(I haven't explored the possible bad interactions between symbol-table block
structure and .GLOBAL'ed symbols. It looks like such symbols are
automatically put in the toplevel symbol-table block, which might thwart
this prefixing scheme...)
I've been poking around inside STINK to see what we can do about the
library issue. I don't suppose any of you have experience with using
.LIBRQ, .LIBRA, and .LIFS in Midas and STINK, do you?... That's what I
thought.
I haven't at all ruled out the possibilities of (A) using an absolute
assembly and doing the linking and library stuff with a Midas macrology
that figures out what to .INSRT, or (B) writing a better STINK in C or
MacLisp. Option (A) has the advantage that its very close to the way
everything else on ITS works. Option (B) gets us a better utility in the
long run.
19-Aug-87 14:23:03-PDT,645;000000000001
Mail-From: KLH created at 19-Aug-87 14:22:36
Date: Wed 19 Aug 87 14:22:36-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC meets ITS
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Fine, could you tweak the ITS-KCC list so that [email protected] is
on it, and add a comment to the effect that this is where I see the mail.
(I check my ITS mail maybe only once a month nowadays). I also put Ian
and a log file on that local distribution list. Will send some comments
when that's done...
-------
19-Aug-87 14:25:03-PDT,818;000000000001
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 14:24:05-PDT
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 19 Aug 87 17:24:18 EDT
Date: Wed 19 Aug 87 14:22:36-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC meets ITS
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Fine, could you tweak the ITS-KCC list so that [email protected] is
on it, and add a comment to the effect that this is where I see the mail.
(I check my ITS mail maybe only once a month nowadays). I also put Ian
and a log file on that local distribution list. Will send some comments
when that's done...
-------
19-Aug-87 14:27:14-PDT,2718;000000000001
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 14:25:53-PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 19 Aug 87 17:24:27 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 216741; Wed 19-Aug-87 17:23:33 EDT
Date: Wed, 19 Aug 87 17:23 EDT
From: David A. Moon <[email protected]>
Subject: KCC meets ITS
To: Alan Bawden <[email protected]>
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Wed, 19 Aug 87 15:51:07 EDT
From: Alan Bawden <[email protected]>
I'm currently leaning towards having Midas do the assembly, especially
since I did an experiment last night and determined that Midas is perfectly
happy with code like:
GO: MOVE 1,FOO"END
FOO"END: 700.
So if KCC always prefixes the users symbols with: USER" (or something)
there shouldn't be any problem. I assume that KCC isn't -already- making
some use of the assembler's block structure?
Does it work to put the prefix on the built-in symbols instead of on the user
symbols, maybe something like
.BEGIN USER
GO: MOVE 1,END
END: 700.
.U"END
(I think .U is the right name, I could have misremembered). If this works the
assembler file will be shorter.
I've been poking around inside STINK to see what we can do about the
library issue. I don't suppose any of you have experience with using
.LIBRQ, .LIBRA, and .LIFS in Midas and STINK, do you?... That's what I
thought.
That stuff probably worked back in the 1960s, so there may be some chance
that it still works. I've never used it, as far as I know. I think PUB was
put together with STINK, and I did make a new PUB once or twice, but I don't
remember whether that involved libraries.
I haven't at all ruled out the possibilities of (A) using an absolute
assembly and doing the linking and library stuff with a Midas macrology
that figures out what to .INSRT, or (B) writing a better STINK in C or
MacLisp. Option (A) has the advantage that its very close to the way
everything else on ITS works. Option (B) gets us a better utility in the
long run.
I suspect for the initial pass you should use option A without the macrology,
just insert everything. This will get you on the air the quickest, I would
think. The library stuff is really just an optimization to make the object
code smaller by not including things you don't call, right?
19-Aug-87 16:22:22-PDT,1985;000000000011
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 16:11:50-PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Aug 87 19:12:18 EDT
Date: Wed, 19 Aug 1987 19:11 EDT
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
Subject: KCC meets ITS
In-reply-to: Msg of 19 Aug 1987 17:23-EDT from David A. Moon <[email protected]>
I agree with Dave that it would be better to prefix the built-in
symbols, but for different reasons. I think this is the only way to
get things to work right with globals and relocatable assembly in
MIDAS.
MIDAS actually has five and a half magic block names.
.INIT & .MAIN are predefined blocks. .INIT is where the predefined
symbols go, .MAIN is the highest available user block.
.M, .C, & .U are special cased. .M is an alias for .MAIN, unless it's
something else. .C is "current block". .U is "superior block".
Under certain conditions, MIDAS will rename .MAIN to GLOBAL before
punching (sic) the binary, because it thinks DDT wants this.
It would be a good idea to prefix all opcodes and such with a block
name. The length of the MIDAS code won't matter if we are serious
about using relocatable assembly.
Remember that we're trying to have a definition like
extern int move();
work as one would expect.
I still don't see why people are so gungho on using MIDAS for
everything. There's maybe five or ten modules that need to .INSRT
stuff, ok, those are done by hand in MIDAS, the rest can use FAIL.
For those who don't already know about it, there's some code in
XX:SRC:<KCC.MIDAS> which generates TWOSEG format files that work
correctly with Twenex KCC. Obviously some of this has to change for
STINK, but it gives an idea of what one should have in hand assembled
MIDAS modules that need to be linked with KCC-generated code.
19-Aug-87 19:11:07-PDT,9347;000000000001
Mail-From: KLH created at 19-Aug-87 19:10:38
Date: Wed 19 Aug 87 19:10:38-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC meets ITS
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hmm, guess I can't wait... here are some comments.
First, an extract from the KCC PORT.DOC file which pertains to ITS; I'm
including it for reference.
-------------------------
Thoughts on future port to ITS:
The main problem is that the only linking loader available on
ITS is STINK, which only understands STINK format REL files. There
may be an old version of the DEC linker available, but this is
non-supported and painful to use. Getting KCC to run on ITS is not
difficult; establishing a scheme for the C compilation environment (so
users can compile their C programs on ITS) is what needs to be figured
out.
Here is a map of the players. "..." marks links that don't currently
exist but could.
/.......................>|
| |
|-> MAC --[MACRO]------->|--> DECREL --[T20LINK]------> DECSAV
| /---->| | /..................|
C --[KCC]-->| | /->| | |
|-> FAI --[FAIL]-->| | | \...[CNV]...>|
| \---->| \.......[ITSLNK]...>|
| | | |
|-> MID --[MIDAS]-----|->|--> STKREL --[STINK]---->|--> SBLK
| |
\...........................> newREL ..[newLNK]...>|
As the diagram shows, both FAIL and MIDAS can produce either DECREL or
STKREL format. (The ITS version of FAIL uses a separate module called
STKTRN to achieve the latter).
If KCC is ever improved to bypass the assembler phase by outputting
relocatable files directly, it will almost certainly NOT know about
STKREL format. Using this on ITS will require either further
modifications to generate STINK format, or the ITS loader will have to
know about DECREL format. The latter is most general.
Two handy programs that could be created would be:
CNV (or whatever) to convert DEC format SAVE files into ITS SBLK files.
ITSLNK (or whatever) to gobble relocatable files in DECREL (or some
other, better, format) and produce ITS SBLK files.
Actual bootstrap of KCC itself:
Several different approaches can be used:
[1] Build KCC elsewhere (T20), dump in old DECSAV format.
FTP over and convert to SBLK executable format. Needs CNV program.
[2] Generate complete set of .FAI files and FTP them.
Run ITS FAIL to generate STINK format rels, then load with STINK.
[3] Generate complete set of .MID files and FTP them.
Run ITS MIDAS to generate STINK format rels, then load with STINK.
[4] Generate complete set of .REL files and FTP them.
Modify STINK (NEWLNK) to understand DECREL format, use that.
-------------------------
Quick and dirty approach:
(1) Fix up the C library code so it will run on ITS.
(see USYS.DOC for a list of routines that need fixing).
(2) Set up KCC on T20 for cross-compiling (see PORT.DOC for
cross-compilation instructions).
(3) Write the CNV program to convert DECSAV to SBLK.
Then, to bring up any C program on ITS, just cross-compile it
on a T20 system, dump the binary out with CSAVE, and use CNV to
convert DECSAV format to SBLK format. Copy to ITS and run.
The KCC program itself will need additional fixes (to do with
how the assembler and loader are invoked) before it can run on ITS.
But before you know what those fixes are, you have to decide what overall
C compilation scheme will be used (what assembler, what loader, etc). And
for various reasons, this implies a new loader.
About symbols:
From the assembler's viewpoint there are three kinds of
symbols. First there are assembler-specific symbols such as opcodes
and pseudo-ops, and these have to never, ever, conflict with
user-defined symbols. Second, there are external (global)
user-defined symbols; fortunately, ANSI is saying that unless such
symbols are monocasedly unique in the first 6 characters the code is
not conforming (ie not very portable), so we don't have to bust a gut
trying to achieve long external symbol names, although someday this
would be nice. These are the symbols the loader has to worry about.
Finally, there are "static" (internal, local) symbol names which are
local to the C file being compiled and should not be visible outside
of that module. Let's call these symbol types A, G, and L for the
moment.
KCC does not currently use block structure for anything. Symbols
of type A are known to the assembler via FAIL/MACRO opdefs and thus do not
conflict with labels. Unfortunately, pseudo-ops are not done this way,
which is why those pseudo-ops must be expunged from FAIL/MACRO at the start
of assembly (and thus cannot be used during assembly!)
Because $ and % cannot exist in C-defined symbols, those
characters can be used for special purposes (eg KCC prefixes compiler-
generated labels with $ as in $123). Static data labels (type L) are
also done this way; static function labels are not, which means it is
possible for some conflict to happen, but KCC could be fixed to remedy
this (at the price of making DDT debugging more difficult).
The suggestion of using a prefix like USER" is a good one, but only
if it works for global symbols.
It would be possible to generate a new variety of MIDAS such that
all type A symbols either had a % prefix, or were block structured (.INIT"),
or something like that.
Or we could just use FAIL. ITS FAIL includes a routine that
translates the output format into STINK format.
About STINK .LIBRQ etc:
The last time I looked, those pseudos weren't even implemented.
You can carefully specify each and every module you need loaded, and STINK
will load it. You can also say "load this module only if needed". But
you CANNOT say "search this library file for all modules needed". Gack!
Absolute assembly vs better linking loader:
Absolute assembly is one of those charming wild ideas that
for a moment makes you wonder "what if?" But I think the effort of trying
to set up such a scheme (and it would take some) would be much better
spent in getting a loader to search a library properly. The size of the
C library alone is considerable, and many C programs (KCC is a good example)
are so much easier to work with when you only need to recompile one or
two modules.
The reason for using relocatable files is not necessarily
because the binary only includes what is needed; it is mainly to save
time. Running a linking loader is much faster than re-compiling or
re-assembling lots and lots of code. The C library is about 80 T20
pages worth of relocatable code and that is an absolute minimum --
large programs are also split into many modules. For example, the KCC
source code is altogether about 370 T20 pages, not including standard
header files or library code. The .FAI files are somewhat bigger.
As far as I know, STINK knows nothing about libraries (ie
files which contain more than one module). An interesting strategem
for a new loader would be to parallel the UNIX use of archive files;
that is, make each module be a file in an ITS archive file, such as
AR13:C;FOPEN REL. The advantage of this is that you can use existing
tools to update such "libraries". There would be one special file in
the archive (on UNIX this is called __SYMDEFS, generated by a program
called "ranlib") which contains all of the external symbol table information
for the modules in the archive, so that the loader only needs to look at
that one file to know which of the archive files to load up. You can
invent your own format for this file.
MIDAS vs FAIL:
The choice of assembler is somewhat irrelevant. KCC can
generate either (although it is not yet known whether its MIDAS output
is completely winning -- assuredly a declaration like "int move;" will
fail). It would be safest to use FAIL at first. Either FAIL or MIDAS
can produce DECREL or STKREL files. FAIL is one-pass; it's not clear
if MIDAS can handle a one-pass relocatable assembly, but this is a
somewhat minor efficiency consideration. ITS FAIL is currently set to
only generate STKREL, but it would be trivial to add a switch or
pseudo to skip the translation and output just DECREL.
I see no real need to use MIDAS unless we intend to use its
block-structure features or something else I haven't thought of. It is
somewhat easier to maintain than FAIL, to be sure.
Finally...
One way or another we have got to have a new loader before KCC
itself can run on ITS. This can be done by:
(1) stealing and porting T20 LINK (use DECREL fmt)
(2) hacking up STINK to do what we want (use STKREL fmt)
(3) writing a new loader.
(3a) STKREL format
(3b) DECREL format
(3c) New portable format
The person who actually wants to do the work is probably the person who
will decide which of these gets done. I would just add that if a new loader
gets written, it should be written in C. Also, you may be able to start
with the GNU linking loader. If a new format is simple enough I'm willing
to consider making KCC output it, but not if it's ITS-specific.
-------
19-Aug-87 19:13:27-PDT,9520;000000000001
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 19:12:25-PDT
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 19 Aug 87 22:13:00 EDT
Date: Wed 19 Aug 87 19:10:38-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC meets ITS
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hmm, guess I can't wait... here are some comments.
First, an extract from the KCC PORT.DOC file which pertains to ITS; I'm
including it for reference.
-------------------------
Thoughts on future port to ITS:
The main problem is that the only linking loader available on
ITS is STINK, which only understands STINK format REL files. There
may be an old version of the DEC linker available, but this is
non-supported and painful to use. Getting KCC to run on ITS is not
difficult; establishing a scheme for the C compilation environment (so
users can compile their C programs on ITS) is what needs to be figured
out.
Here is a map of the players. "..." marks links that don't currently
exist but could.
/.......................>|
| |
|-> MAC --[MACRO]------->|--> DECREL --[T20LINK]------> DECSAV
| /---->| | /..................|
C --[KCC]-->| | /->| | |
|-> FAI --[FAIL]-->| | | \...[CNV]...>|
| \---->| \.......[ITSLNK]...>|
| | | |
|-> MID --[MIDAS]-----|->|--> STKREL --[STINK]---->|--> SBLK
| |
\...........................> newREL ..[newLNK]...>|
As the diagram shows, both FAIL and MIDAS can produce either DECREL or
STKREL format. (The ITS version of FAIL uses a separate module called
STKTRN to achieve the latter).
If KCC is ever improved to bypass the assembler phase by outputting
relocatable files directly, it will almost certainly NOT know about
STKREL format. Using this on ITS will require either further
modifications to generate STINK format, or the ITS loader will have to
know about DECREL format. The latter is most general.
Two handy programs that could be created would be:
CNV (or whatever) to convert DEC format SAVE files into ITS SBLK files.
ITSLNK (or whatever) to gobble relocatable files in DECREL (or some
other, better, format) and produce ITS SBLK files.
Actual bootstrap of KCC itself:
Several different approaches can be used:
[1] Build KCC elsewhere (T20), dump in old DECSAV format.
FTP over and convert to SBLK executable format. Needs CNV program.
[2] Generate complete set of .FAI files and FTP them.
Run ITS FAIL to generate STINK format rels, then load with STINK.
[3] Generate complete set of .MID files and FTP them.
Run ITS MIDAS to generate STINK format rels, then load with STINK.
[4] Generate complete set of .REL files and FTP them.
Modify STINK (NEWLNK) to understand DECREL format, use that.
-------------------------
Quick and dirty approach:
(1) Fix up the C library code so it will run on ITS.
(see USYS.DOC for a list of routines that need fixing).
(2) Set up KCC on T20 for cross-compiling (see PORT.DOC for
cross-compilation instructions).
(3) Write the CNV program to convert DECSAV to SBLK.
Then, to bring up any C program on ITS, just cross-compile it
on a T20 system, dump the binary out with CSAVE, and use CNV to
convert DECSAV format to SBLK format. Copy to ITS and run.
The KCC program itself will need additional fixes (to do with
how the assembler and loader are invoked) before it can run on ITS.
But before you know what those fixes are, you have to decide what overall
C compilation scheme will be used (what assembler, what loader, etc). And
for various reasons, this implies a new loader.
About symbols:
From the assembler's viewpoint there are three kinds of
symbols. First there are assembler-specific symbols such as opcodes
and pseudo-ops, and these have to never, ever, conflict with
user-defined symbols. Second, there are external (global)
user-defined symbols; fortunately, ANSI is saying that unless such
symbols are monocasedly unique in the first 6 characters the code is
not conforming (ie not very portable), so we don't have to bust a gut
trying to achieve long external symbol names, although someday this
would be nice. These are the symbols the loader has to worry about.
Finally, there are "static" (internal, local) symbol names which are
local to the C file being compiled and should not be visible outside
of that module. Let's call these symbol types A, G, and L for the
moment.
KCC does not currently use block structure for anything. Symbols
of type A are known to the assembler via FAIL/MACRO opdefs and thus do not
conflict with labels. Unfortunately, pseudo-ops are not done this way,
which is why those pseudo-ops must be expunged from FAIL/MACRO at the start
of assembly (and thus cannot be used during assembly!)
Because $ and % cannot exist in C-defined symbols, those
characters can be used for special purposes (eg KCC prefixes compiler-
generated labels with $ as in $123). Static data labels (type L) are
also done this way; static function labels are not, which means it is
possible for some conflict to happen, but KCC could be fixed to remedy
this (at the price of making DDT debugging more difficult).
The suggestion of using a prefix like USER" is a good one, but only
if it works for global symbols.
It would be possible to generate a new variety of MIDAS such that
all type A symbols either had a % prefix, or were block structured (.INIT"),
or something like that.
Or we could just use FAIL. ITS FAIL includes a routine that
translates the output format into STINK format.
About STINK .LIBRQ etc:
The last time I looked, those pseudos weren't even implemented.
You can carefully specify each and every module you need loaded, and STINK
will load it. You can also say "load this module only if needed". But
you CANNOT say "search this library file for all modules needed". Gack!
Absolute assembly vs better linking loader:
Absolute assembly is one of those charming wild ideas that
for a moment makes you wonder "what if?" But I think the effort of trying
to set up such a scheme (and it would take some) would be much better
spent in getting a loader to search a library properly. The size of the
C library alone is considerable, and many C programs (KCC is a good example)
are so much easier to work with when you only need to recompile one or
two modules.
The reason for using relocatable files is not necessarily
because the binary only includes what is needed; it is mainly to save
time. Running a linking loader is much faster than re-compiling or
re-assembling lots and lots of code. The C library is about 80 T20
pages worth of relocatable code and that is an absolute minimum --
large programs are also split into many modules. For example, the KCC
source code is altogether about 370 T20 pages, not including standard
header files or library code. The .FAI files are somewhat bigger.
As far as I know, STINK knows nothing about libraries (ie
files which contain more than one module). An interesting strategem
for a new loader would be to parallel the UNIX use of archive files;
that is, make each module be a file in an ITS archive file, such as
AR13:C;FOPEN REL. The advantage of this is that you can use existing
tools to update such "libraries". There would be one special file in
the archive (on UNIX this is called __SYMDEFS, generated by a program
called "ranlib") which contains all of the external symbol table information
for the modules in the archive, so that the loader only needs to look at
that one file to know which of the archive files to load up. You can
invent your own format for this file.
MIDAS vs FAIL:
The choice of assembler is somewhat irrelevant. KCC can
generate either (although it is not yet known whether its MIDAS output
is completely winning -- assuredly a declaration like "int move;" will
fail). It would be safest to use FAIL at first. Either FAIL or MIDAS
can produce DECREL or STKREL files. FAIL is one-pass; it's not clear
if MIDAS can handle a one-pass relocatable assembly, but this is a
somewhat minor efficiency consideration. ITS FAIL is currently set to
only generate STKREL, but it would be trivial to add a switch or
pseudo to skip the translation and output just DECREL.
I see no real need to use MIDAS unless we intend to use its
block-structure features or something else I haven't thought of. It is
somewhat easier to maintain than FAIL, to be sure.
Finally...
One way or another we have got to have a new loader before KCC
itself can run on ITS. This can be done by:
(1) stealing and porting T20 LINK (use DECREL fmt)
(2) hacking up STINK to do what we want (use STKREL fmt)
(3) writing a new loader.
(3a) STKREL format
(3b) DECREL format
(3c) New portable format
The person who actually wants to do the work is probably the person who
will decide which of these gets done. I would just add that if a new loader
gets written, it should be written in C. Also, you may be able to start
with the GNU linking loader. If a new format is simple enough I'm willing
to consider making KCC output it, but not if it's ITS-specific.
-------
19-Aug-87 19:21:28-PDT,3626;000000000001
Return-Path: <[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 19:17:43-PDT
Date: Wed, 19 Aug 87 22:18:07 EDT
From: Alan Bawden <[email protected]>
Subject: KCC meets ITS
To: [email protected]
In-reply-to: Msg of Wed 19 Aug 87 14:22:36-PDT from Ken Harrenstien <KLH at SRI-NIC.ARPA>
Message-ID: <[email protected]>
Date: Wed 19 Aug 87 14:22:36-PDT
From: Ken Harrenstien <KLH at SRI-NIC.ARPA>
Fine, could you tweak the ITS-KCC list so that [email protected] is
on it, and add a comment to the effect that this is where I see the mail.
(I check my ITS mail maybe only once a month nowadays). I also put Ian
and a log file on that local distribution list. Will send some comments
when that's done...
Done.
Date: Wed, 19 Aug 87 17:23 EDT
From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
...
Does it work to put the prefix on the built-in symbols instead of on
the user symbols, maybe something like
.BEGIN USER
GO: MOVE 1,END
END: 700.
.U"END
No, this kind of thing doesn't work. When Midas tries to assemble the
MOVE 1,END it complains that END returns no value, then it ends the
assembly right there. If instead of END you substitute an initial symbol
such as SETZ, it works, but you get a warning message.
I've been poking around inside STINK to see what we can do about
the library issue. I don't suppose any of you have experience with
using .LIBRQ, .LIBRA, and .LIFS in Midas and STINK, do you?...
That's what I thought.
That stuff probably worked back in the 1960s, so there may be some
chance that it still works. I've never used it, as far as I know. I
think PUB was put together with STINK, and I did make a new PUB once or
twice, but I don't remember whether that involved libraries.
Some experiments JTW performed this afternoon confirm that this does seem
to work. The problem is that it isn't -really- what you want. It will let
you construct a file that when processed by STINK will selectively load
bits of code based on undefined symbols. It won't let you do the
transitive closure of that operation.
Date: Wed, 19 Aug 1987 19:11 EDT
From: Rob Austein <SRA at XX.LCS.MIT.EDU>
...
Under certain conditions, MIDAS will rename .MAIN to GLOBAL before
punching (sic) the binary, because it thinks DDT wants this.
I always get a block named .MAIN, or if I use a TITLE statement I get a
block named after my title. (I am looking directly at the binary STINK files
output by Midas when I say this.) I -do- see that after STINK has linked
up a bunch of things, and passed the symbols on to DDT, somebody has
created a GLOBAL block, but I would expect that that is something that
STINK did.
There is code in Midas that outputs a block named GLOBAL in the case of an
absolute assembly, but I don't think it ever does it when it is making a
REL file.
I've been fooling around with what happens when you say things like
.GLOBAL C"MOVE,C"STDIO
and it looks like more-or-less the "right" things happens: Midas
manipulates the symbols in the block named C, and never confuses them with
any other symbols or pseudos. Then it writes a file for STINK that
contains no block information anywhere that STINK will be looking when it
does linking. In the final symbol table, the global symbols will all be
defined in a toplevel block named GLOBAL, and all the others will remain in
per-program sub-blocks named C!
19-Aug-87 20:13:49-PDT,993;000000000001
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 20:13:22-PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 19 Aug 87 23:13:37 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 216969; Wed 19-Aug-87 23:13:36 EDT
Date: Wed, 19 Aug 87 23:13 EDT
From: David A. Moon <[email protected]>
Subject: Re: KCC meets ITS
To: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Date: Wed 19 Aug 87 19:10:38-PDT
From: Ken Harrenstien <[email protected]>
Two handy programs that could be created would be:
CNV (or whatever) to convert DEC format SAVE files into ITS SBLK files.
....
I believe this is AI: ARC: MOON; 20XCSV >. Someone who knows 20X
should see if it still works.
19-Aug-87 23:13:12-PDT,1199;000000000001
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 19 Aug 87 23:12:57-PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 20 Aug 87 02:12:37 EDT
Date: Thu, 20 Aug 1987 02:12 EDT
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
Subject: KCC meets ITS
In-reply-to: Msg of 19 Aug 1987 23:13-EDT from David A. Moon <[email protected]>
Date: Wednesday, 19 August 1987 23:13-EDT
From: David A. Moon <[email protected]>
Date: Wed 19 Aug 87 19:10:38-PDT
From: Ken Harrenstien <[email protected]>
Two handy programs that could be created would be:
CNV (or whatever) to convert DEC format SAVE files into ITS SBLK files.
....
I believe this is AI: ARC: MOON; 20XCSV >. Someone who knows 20X
should see if it still works.
CSAVE format hasn't changed any. The Twenex EXEC can convert SSAVE
format to CSAVE format if needed.
20XCSV successfully converted a trivial program, I haven't tried
anything fancy. It throws away the symbol table.
10-Sep-87 08:32:33-PDT,787;000000000000
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 10 Sep 87 08:32:27-PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Sep 87 11:37:25 EDT
Date: Thu, 10 Sep 1987 11:27 EDT
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
Subject: Completely random KCC implementation note
I just came to the conclusion that argv[0] should be the XJNAME (not
the JNAME). This seems to be the way it works on unix, and is
certainly the way it works on Twenex.
If you're wondering why I care, I was just working on some code that
does crash dumps to different files depending on argv[0], which got me
wondering just what argv[0] is, anyway.
27-Feb-88 13:53:17-PST,2918;000000000000
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 27 Feb 88 13:53:00-PST
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 27 Feb 88 16:55:19 EST
Date: Sat, 27 Feb 88 13:52:01 PST
From: Ken Harrenstien <[email protected]>
Subject: [[email protected]: KCC]
To: [email protected]
Message-ID: <[email protected]>
Forwarded for posterity, reply follows.
---------------
Return-Path: <Alan%AI.AI.MIT.EDU.#[email protected]>
Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 26 Feb 88 15:53:37-PST
Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Feb 88 17:50-EST
Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 26 Feb 88 17:48-EST
Date: Fri, 26 Feb 88 17:49 EST
From: [email protected]
Sender: [email protected]
Subject: KCC
To: [email protected]
cc: [email protected], [email protected], [email protected],
[email protected]
Message-ID: <[email protected]>
So here we are thinking about porting KCC to ITS. For a change we even have
some people to work on it...(!)
A while back there was some discussion of teaching KCC to output some
relocatable format directly, and writing a linker for it. Now we're
thinking about this again, and wondering if you have the interest/time
to help.
It seems that the best thing would be to get KCC to output DEC REL format,
and do an ITS linker for it. The question is what, exactly, to support.
Ideally we could teach KCC about PSECTS and new long-symbol-format REL
blocks, and implement an ITS linker that can deal with them. A somewhat
easier thing would be to generate PSECTed code but use old REL blocks.
Presumably this has the advantage that we could get things started by
having KCC generate MACRO code, and linking that. At worst, we could
avoid PSECTED code altogether and just generate TWOSEG code, except
that I really do want the linker to do automatic relocation of the
code and data segments to contiguous memory, then PDUMP with pure code,
and PSECTS just seem a lot cleaner.
Alan points out that we will probably want to be able to link in assembly
code. The two choices seem to be to try and run MACRO under the simulator,
or to have midas generate DECTWO and teach the linker to do TWOSEG -> PSECT
mapping when required.
So:
a) Are you at all interested in teaching KCC to generate DEC REL directly?
b) If so, would you be interested in generating 'new' blocks so we could
use long names? (And what would you do about DDT? We're just going to
dump out the symbol table, maybe filtering out conflicts...)
c) How do you feel about generating PSECTed code instead of TWOSEG?
d) Anything else? (We-all 'r just sittin' here drinkin beers and such. We
may have missed something...)
JTW, Alan, and Chris Maeda
-------
27-Feb-88 14:40:34-PST,3337;000000000000
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 27 Feb 88 14:40:17-PST
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 27 Feb 88 17:40:12 EST
Date: Sat, 27 Feb 88 14:36:49 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC
To: [email protected]
cc: [email protected], [email protected], [email protected],
[email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Well, I have the interest, but I dunno about the time. If you have
some people to work on it, the best thing to tackle first is an ITS
DECREL linker. That's all you need to begin with.
I'll go over the arguments again. Here's how it would work in action:
User invokes KCC.
KCC generates FAIL code, invokes FAIL and ITS linker.
FAIL generates DECREL.
ITS linker gobbles DECREL, produces BIN.
(Of course, the link step is omitted for -c compiles.)
My reasons for staying with an assembler step:
I don't have much time at all for KCC hacking. Producing REL
files directly will be moderately painful.
Lots of library code has asm() statements in it. KCC would have
to parse those strings like an assembler would. More work.
It is much easier to debug things with the intermediate assembler
output available.
KCC can readily generate code for any of MACRO, MIDAS, or FAIL. But the
reasons for using FAIL on ITS are:
MIDAS has a problem with symbol conflicts between user labels and
opcodes, pseudos, etc.
MACRO on ITS might be a problem. If you can get permission from DEC
to use MACRO sources, fine. But I doubt it.
FAIL is one-pass; MACRO and MIDAS are two-pass.
Note that FAIL, like MIDAS, will assemble for ITS and can produce
either STINK or DECREL.
I recommend DECREL for reasons that you've probably also figured out:
It's well documented (unlike STINK).
It now has many more block types (unlike STINK).
It can be generated by any of the 3 assemblers.
It makes it much easier to cross-compile things in the initial stages.
Now, about PSECTs. They are not necessary initially. To make them
work it will suffice to fix up FAIL and the ITS linker. KCC can then
be trivially adjusted to make use of this feature. Let's not bust a
gut trying to do everything at once.
Similarly, you don't NEED long symbols to begin with. The ANSI C
draft standard mandates 6 char monocase uniqueness for externals, if
they are to be portable. It is easy to use long names for C code just
by putting #defines in the appropriate header files. We can worry
about this later.
Incidentally, if we are agreed on the need for a new linker (in other words,
forget about patching up STINK, and forget about stealing LINK), then we
will need a working moniker (although of course the lucky author will have
prerogative). Some candidates:
ILL (Incompatible Linking Loader) - my current favorite.
SINS (SINS Is Not Stink) Obviously, names are
SAINTS (SAINTS AIN'T Stink) a religious matter.
...
p.s. If someone is going to start completely from scratch I'd suggest writing
it in C, of course. Cross-compile on a 20. Most importantly, make it
use and create libraries, with an index.
-------
21-Mar-88 18:18:50-PST,1374;000000000000
Return-Path: <[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 21 Mar 88 18:18:29-PST
Date: Mon, 21 Mar 88 21:19:45 EST
From: Alan Bawden <[email protected]>
Subject: Until we have a linker...
To: [email protected]
Message-ID: <[email protected]>
In the minor hack department:
:KCC;GETSYM
Sucks the ITS official symbol definitions out of the running system (just
as MIDAS and FAIL do) and writes a file of definitions suitable for
insertion (by FAIL or MACRO). It writes a file named ITSSYM on your
directory. Probably the results of doing this should be available in some
standard place on 20X. (If anyone thinks it is worth it, I can modify it
to produce a file suitable for generating .UNV and .FUN files instead.
Is it worth it?)
In the major kludge department:
:KCC;EXECVT <input file>,<output file>
Converts a 20X SSAVE file into an ITS PDUMP file. (Including converting the
symbol table. Yuck!) The <input file> defaults to DSK:<you>;FOO EXE, and
the <output file> defaults to DSK:<you>;<input fn1> BIN, so doing:
:KCC;EXECVT XX:ZAP
converts ZAP.EXE from your directory on XX and writes the results into
ZAP BIN on your ITS directory.
Using these two, I have successfully assembled a program on 20X, linked it
using LINK, and then run the results on ITS.
20-Apr-88 17:45:04-PDT,4775;000000000000
Return-Path: <[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 20 Apr 88 17:44:38-PDT
Date: Wed, 20 Apr 88 20:50:18 EDT
From: Alan Bawden <[email protected]>
Subject: New sources
To: [email protected]
cc: [email protected]
In-reply-to: Msg of Wed 20 Apr 88 08:00:27 PDT from Ken Harrenstien <KLH at SRI-NIC.ARPA>
Message-ID: <[email protected]>
Date: Wed, 20 Apr 88 08:00:27 PDT
From: Ken Harrenstien <KLH at SRI-NIC.ARPA>
Well, you should have seen the message now about KCC-5. The bad news
is that there a number of changes in the source, particularly in CRT.C
and URT.C. The good news is that I have no plans to fiddle with
anything for at least the next couple of months, except for fixing
bugs. So now is an excellent time to integrate any ITS additions.
OK, I'll coordinate with SRA who will presumably pull a set of sources on
to XX soon. The changes I made to CRT and URT are still fresh enough in my
mind that I don't anticipate any pain doing the merge.
I'm wondering what, if anything, you have decided to do about some of
the thornier issues. For example, pathnames -- so many routines expect
that a filename is a string of nonblank characters....
There are two kludges for pathnames so far. First, there is a hack in
open() that treats unquoted "/" as if it were ";", and that treats unquoted
"." the same as space when it appears -embedded- in a name component. Thus
".mail.;names.259" is converted to ".mail.;names 259" before it is passed
to SOPEN, but nothing changes in ".mail.;.file. (dir)". (Although you do
have to write ".mail.;.file..(dir)".)
Second, there is a kludge in the ITS long filename parser that concatenates
multiple directory names together with "."s when parsing them into sixbit.
Thus ITS will treat "dsk:kcc;sys;foo h" the same as "DSK:KCC.SY;FOO H" (as
will all devices that only support sixbit filenames), while long filename
devices will still see a hierarchical directory name.
Together, these kludges should make most of the common assumptions about
pathnames work. For example, KCC itself can deal with #include
"sys/file.h" by passing "DSK:KCC;sys/file.h" to open(), which will convert
this to "DSK:KCC;sys;file h" and pass it to SOPEN, which will parse it into
sixbit as "DSK:KCC.SY;FILE H".
What's giving me trouble now is read(). The existing code relies on the
operating system to deliver a stream of bytes of the correct size (7, 8 or
9 bits), but on ITS 8 and 9 bit bytes can only be obtained by manually
unpacking 36 bit words (ignoring for the moment those devices, like network
connections, that only support byte streams). This introduces an
additional dimension into the space of different cases that read() already
deals with. I haven't figured out yet just how to control this complexity
while still keeping the common cases reasonable efficient.
There is also the ^C problem. Somebody has to protect higher level
routines from the ugly little fact that ITS pads out ascii files with ^C's
in the last word. I am undecided about just where this padding should be
stripped off. It -might- be that the right thing is to make it part of the
CRLF => LF conversion hack, but I wonder if there might be programs that
ask for unconverted input that would be suprised by those ^Cs? Perhaps it
should just be an orthogonal conversion that defaults on for 7 bit bytes?
(Yet another case!)
This manual byte unpacking also introduces additional complexity into
lseek(). For output, there is no reasonable way to position at other than
a multiple of four 8 or 9 bit bytes, since you can really on position at
word boundaries (and you can't have the file open for both reading and
writing so you can't compensate in the obvious way). For input, you can do
it by cooperating with read() a little.
Incidentally, can someone enlighten me about what is going on here? From
USYSIO.H:
/*
* The UIO buffer must be at LEAST twice the size of the higher-level
* STDIO buffer, for the ftell() crockery to work. See bufsiz() and
* ftell() for the gory details.
*/
#define UIO_BUFSIZ (BUFSIZ*2) /* lowest-level buffer size */
I can't find a routine named bufsiz() anywhere, and the positional hackery
in ftell() (using either the "old" method or the "new" method) doesn't seem
to depend on the size of the low-level uio buffer although I didn't read it
carefully enough to be 100% sure of that. So what goes? At the very least
I claim this needs to have a better comment explaining whatever the gory
details are so that people like me will be able to figure out if they are
in any danger of violating important constraints.
21-Apr-88 01:53:09-PDT,2806;000000000000
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 21 Apr 88 01:52:54-PDT
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 21 Apr 88 04:58:49 EDT
Date: Thu, 21 Apr 88 01:51:09 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: New sources
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Sounds like you have a good handle on the pathname stuff. Let me see
if I can shed any light on read() and friends...
I guess I thought SIOT was able to handle n-bit bytes. Evidently, you
only have a choice of 7- or 36-bit bytes from the system, although SIOT
will accept any byte pointer whether or not it is big enough. (Slowly
it all comes back to me...)
Let's see. The most common case is converted 7-bit I/O (that is, text
streams), so you want to make that efficient. You can just use SIOT
for that and use existing CRLF->LF conversion code. For devices that
take 8-bit bytes you can do the same thing. For disk bytesizes of 8 and 9
the simplest method seems to be a simulated SIOT level which does its
actual I/O using word buffers. read() and write() were originally intended
to always contain buffers of some size, but it turned out to be simpler
and safer to do away with buffers whenever possible. After all, on Unix
read() and write() ARE system calls, so it's reasonable for each invocation
to cause an actual system call. If you aren't going to allow simultaneous
read/write (even simulated) then the buffering isn't quite so hairy.
I don't think you need a special case for ^C. If I/O is being converted
then flush the ^Cs since you are dealing with a text stream. If not converted,
then don't. Doesn't ITS have a FILLEN return value that gives the file length
in 7-bit bytes? If it exists, use that; if not, whether trailing ^Cs are
flushed depends on the conversion flag.
Too bad about the lseek() problem. I thought there was a mode that
could be used for simultaneous read/write, though; COMSAT used that
for FAST-APPEND. Or perhaps I'm wrong and I just dodged the issue too by
writing a 5-char word of blanks. You too can dodge the issue by initially
only allowing lseek() to win for seeks to the right boundaries, and failing
otherwise.
What about page mapping? You could map in a file page and fiddle with
it as you please, and when done update the length info manually.
Might be overkill, though; not many programs do this, most just read or
just write.
That comment of Ian's about UIO buffer size is obsolete. I changed
the way ftell() worked so it no longer depended on that sort of crock.
Guess I missed that one.
-------
22-Jul-88 17:25:36-PDT,800;000000000000
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Fri, 22 Jul 88 17:25:21 PDT
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 22 Jul 88 20:22:11 EDT
Date: Fri, 22 Jul 88 17:19:59 PDT
From: Ken Harrenstien <[email protected]>
Subject: Archaelogical discovery - STINK format
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Buried in some ancient paper piles of mine I just found an old DM/CG
memo, SYS.03.02, dated 27-Mar-72 and titled: "STINKING-DYNAL
Relocatable Format" by Pitts Jarvis and Chris Reeve.
It seems to document all of the funny bits, block types, and stuff.
Anyone who still cares about it could probably find a copy in the
DM archives, I guess.
-------
13-Aug-88 12:51:31-PDT,15507;000000000000
Return-Path: <@AI.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Sat, 13 Aug 88 12:50:58 PDT
Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 11 Aug 88 20:14:14 EDT
Date: Thu, 11 Aug 88 17:08:57 PDT
From: Ken Harrenstien <[email protected]>
Subject: ITS changes merged
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
OK, I have merged in your stuff. I'll set up another distrib directory
or something soon so you can get back the new things. Here is a list of
the files, followed by some comments on your notes.txt:
Merge List of ITS C files:
- - ignored, not made part of distrib.
= - Same, no merging needed.
Mnn - Merged, new version is nn. Must get it.
! - New KCC version exists. Must get it.
PS:<C.ITS>
- 5.TAGS.2;P777700 5 11807(7) 23-Apr-88 17:12:32 ALAN
- INCLUDE.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:38:26 KLH
- LIB.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:39:18 KLH
? NOTES.TXT.42;P777700 2 4348(7) 22-Jul-88 13:24:04 ALAN
I'd like to retain this in the distrib but I'm not sure where to
put it. How about <.LIB>ITSNOT.DOC? Another name is fine, but
I do think <.LIB> is the right place, and the .DOC extension will
ensure that it is automatically snarfed into the distrib.
- SRCCOM.TECO.1;P777700 1 239(7) 18-Jul-88 19:11:20 ALAN
- TAGS.TECO.1;P777700 1 470(7) 2-Apr-88 23:03:28 ALAN
Total of 11 pages in 8 files
PS:<C.ITS.INCLUDE>
M20 C-ENV.H.1002;P775202 3 5451(7) 23-Apr-88 12:21:57 ALAN
? C-HITS.FAI.2;P775202 1 343(7) 25-Mar-88 12:29:03 ALAN
? .MAC.2;P775202 1 343(7) 25-Mar-88 12:29:03 ALAN
We should be able to make KCC generate the right headers
instead of using these. I don't think using XC: in the
.REQUEST is necessary, and everything else should be OK.
You know about the -L switch? Basically C: is used for
3 things, all of which can be set with the -I,-H, and -L switches.
M6 FCNTL.H.1005;P775202 1 1678(7) 18-Jul-88 18:20:55 ALAN
? ITSSYM.FUN.1;P775202 11 5361(36) 1-Apr-88 06:38:32 ALAN
? .UNV.1;P775202 4 1793(36) 1-Apr-88 06:38:05 ALAN
This is an odd place to have these files. Probably they should
be copied to UNV:. For distribution purposes, they could be kept in
the <.FAIL> directory. #asm code that needs the syms can explicitly
get them with a SEARCH ITSSYM, the same way T20/10X code does
SEARCH MONSYM -- this shouldn't be in the header.
- LIBC.REL.1048;P775202 47 24060(36) 22-Jul-88 13:04:29 ALAN
M31 STDIO.H.1005;P775202 3 6470(7) 23-Apr-88 12:01:23 ALAN
- SYS.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:39:01 KLH
M6 SYSITS.H.1018;P775202 4 8124(7) 11-May-88 15:30:54 ALAN
- XCC.PCL.11;P775202 1 456(7) 18-Jul-88 18:57:18 ALAN
Do you want to keep this? I could move it into the compiler
directory (already have a cross-compiler example there for 10X).
Total of 76 pages in 11 files
PS:<C.ITS.INCLUDE.SYS>
M15 FILE.H.1004;P775202 1 2026(7) 23-Apr-88 12:28:57 ALAN
? HUMBLE.H.1004;P775202 1 279(7) 11-May-88 22:13:17 ALAN
See comments about humble.c
- UIO.H.1007;P775202 2 3199(7) 29-Apr-88 20:34:35 ALAN
This file (uio.h) should be flushed completely. Nothing uses it.
M44 USYSIO.H.1007;P775202 2 3199(7) 29-Apr-88 20:34:35 ALAN
Total of 6 pages in 4 files
PS:<C.ITS.LIB>
= ABORT.C.9;P775202 1 250(7) 6-Sep-86 13:01:53 ALAN
- .REL.1;P775202 1 66(36) 22-Jul-88 12:32:21 ALAN
= CPU.C.10;P775202 2 4393(7) 27-Feb-87 11:12:46 ALAN
- .REL.1;P775202 1 179(36) 22-Jul-88 12:30:50 ALAN
M65 CRT.C.1020;P775202 13 31956(7) 21-Jul-88 19:54:33 ALAN
- .REL.1;P775202 2 1010(36) 22-Jul-88 12:31:08 ALAN
= CTYPE.C.3;P775202 4 8462(7) 25-Sep-86 18:27:34 ALAN
- .REL.1;P775202 1 333(36) 22-Jul-88 12:31:19 ALAN
- ITS.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:39:27 KLH
? ITSSYM.FAI.1604;P775202 6 13768(7) 1-Apr-88 06:36:40 ALAN
Move to <.FAIL> directory? I don't want any .FAI or .MAC files
in the C source dirs, because I often do DELETE *.FAI to flush
compilation leftovers.
- LIBC.COM.17;P775202 1 405(7) 22-Jul-88 13:03:11 ALAN
- .MAK.1026;P775202 1 561(7) 22-Jul-88 13:03:31 ALAN
- .TAGS.8;P775202 2 3247(7) 14-Apr-88 17:26:09 ALAN
Eventually these idiosyncratic files should be flushed. That is,
all files get compiled even if some of them are unsuitable for
the target system -- they just assemble into null modules.
Much easier to update a list within just one file rather than in
N different files (N = # systems supported).
M192 MALLOC.C.1001;P775202 8 18032(7) 23-Apr-88 12:12:04 ALAN
- .REL.1;P775202 3 1415(36) 22-Jul-88 12:32:15 ALAN
- MATH.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:40:46 KLH
! MEMSTR.C.9;P775202 10 23884(7) 11-Sep-87 00:33:46 ALAN
- .REL.1;P775202 2 991(36) 22-Jul-88 12:31:34 ALAN
= ONEXIT.C.2;P775202 1 760(7) 7-Apr-87 15:30:56 ALAN
- .REL.1;P775202 1 128(36) 22-Jul-88 12:31:43 ALAN
- STDIO.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:40:55 KLH
= STRERR.C.4;P775202 3 5570(7) 16-Mar-88 14:48:11 ALAN
- .REL.1;P775202 3 1458(36) 22-Jul-88 12:32:31 ALAN
= STRING.C.39;P775202 4 8365(7) 21-Mar-88 13:05:28 ALAN
- .REL.1;P775202 2 740(36) 22-Jul-88 12:31:53 ALAN
M5 SYSCAL.C.1004;P775202 1 2343(7) 23-Apr-88 12:01:07 ALAN
Some questions here:
Should ato6() and afrom6() be here? I'm not sure where
to put them; if we want to make them universally available
to all PDP-10 configs then they need a header file.
Should sysits.h be syscal.h and itssym.h?
I edited afrom6() to avoid using an ADJBP.
- .REL.1;P775202 1 146(36) 22-Jul-88 12:32:02 ALAN
- USYS.DIRECTORY.1;P20200 0 0(0) 5-Aug-88 18:41:02 KLH
Total of 74 pages in 28 files
PS:<C.ITS.LIB.ITS>
? HUMBLE.C.36;P775202 5 10719(7) 11-May-88 23:17:38 ALAN
- .REL.2;P775202 4 1601(36) 22-Jul-88 12:56:41 ALAN
This should be a separate package, not part of the C library.
It can be put into a <.ITS> subdir of the distrib.
Invent a library name for it, such as LIBINF or LIBKID.
Total of 9 pages in 2 files
PS:<C.ITS.LIB.MATH>
= FLOOR.C.8;P775202 1 421(7) 12-Apr-88 18:03:59 ALAN
- .REL.1;P775202 1 95(36) 22-Jul-88 13:03:01 ALAN
= MODF.C.87;P775202 2 4041(7) 12-Apr-88 18:27:27 ALAN
- .REL.2;P775202 1 104(36) 22-Jul-88 13:02:56 ALAN
Total of 5 pages in 4 files
PS:<C.ITS.LIB.STDIO>
= CLEANU.C.4;P775202 1 477(7) 16-Sep-86 13:56:56 ALAN
- .REL.1;P775202 1 127(36) 22-Jul-88 12:52:33 ALAN
= FCLOSE.C.22;P775202 1 475(7) 17-Sep-86 18:04:03 ALAN
- .REL.1;P775202 1 127(36) 22-Jul-88 12:52:21 ALAN
! FFLUSH.C.35;P775202 1 2125(7) 12-Apr-88 14:56:46 ALAN
- .REL.1;P775202 1 307(36) 22-Jul-88 12:51:06 ALAN
= FGETC.C.18;P775202 2 3582(7) 29-Feb-88 21:55:11 ALAN
- .REL.1;P775202 1 385(36) 22-Jul-88 12:51:15 ALAN
= FOPEN.C.27;P775202 2 3218(7) 11-Sep-87 17:19:28 ALAN
- .REL.1;P775202 1 302(36) 22-Jul-88 12:50:34 ALAN
= FPUTC.C.38;P775202 1 1764(7) 12-Apr-88 18:30:23 ALAN
- .REL.1;P775202 1 304(36) 22-Jul-88 12:51:25 ALAN
= FPUTS.C.14;P775202 1 573(7) 12-Apr-88 18:31:18 ALAN
- .REL.1;P775202 1 174(36) 22-Jul-88 12:51:33 ALAN
M52 FREOPE.C.1001;P775202 3 5145(7) 23-Apr-88 12:11:18 ALAN
- .REL.1;P775202 2 609(36) 22-Jul-88 12:50:41 ALAN
= FSEEK.C.25;P775202 2 2720(7) 27-Oct-87 15:20:07 ALAN
- .REL.1;P775202 1 230(36) 22-Jul-88 12:52:15 ALAN
! FTELL.C.22;P775202 1 2418(7) 27-Oct-87 12:08:20 ALAN
- .REL.1;P775202 1 186(36) 22-Jul-88 12:52:09 ALAN
= PRINTF.C.27;P775202 10 23373(7) 12-Apr-88 18:32:48 ALAN
- .REL.1;P775202 6 2914(36) 22-Jul-88 12:52:00 ALAN
! SCANF.C.187;P775202 6 13304(7) 30-Mar-87 14:55:04 ALAN
- .REL.1;P775202 4 1882(36) 22-Jul-88 12:51:45 ALAN
= SETBUF.C.30;P775202 2 2965(7) 27-Oct-87 13:46:37 ALAN
- .REL.1;P775202 1 305(36) 22-Jul-88 12:50:48 ALAN
! SOPEN.C.16;P775202 1 1202(7) 30-Sep-86 15:26:35 ALAN
- .REL.1;P775202 1 183(36) 22-Jul-88 12:52:27 ALAN
= UNGETC.C.22;P775202 1 946(7) 26-Mar-88 13:55:09 ALAN
- .REL.1;P775202 1 130(36) 22-Jul-88 12:50:56 ALAN
Total of 59 pages in 30 files
PS:<C.ITS.LIB.USYS>
M60 CLOSE.C.1010;P775202 1 2176(7) 8-May-88 00:12:29 ALAN
- .REL.1;P775202 1 350(36) 22-Jul-88 12:35:24 ALAN
= DUP.C.19;P775202 1 957(7) 5-Sep-87 18:56:01 ALAN
- .REL.1;P775202 1 186(36) 22-Jul-88 12:34:22 ALAN
= EXIT.C.2;P775202 1 1550(7) 24-Aug-87 15:39:31 ALAN
- .REL.1;P775202 1 172(36) 22-Jul-88 12:33:15 ALAN
= FCNTL.C.13;P775202 1 754(7) 5-Sep-87 18:56:06 ALAN
- .REL.1;P775202 1 175(36) 22-Jul-88 12:34:32 ALAN
M33 LSEEK.C.1007;P775202 2 3125(7) 29-Apr-88 21:19:25 ALAN
- .REL.1;P775202 1 370(36) 22-Jul-88 12:34:44 ALAN
M225 OPEN.C.1029;P775202 12 30714(7) 21-Jul-88 21:41:46 ALAN
- .REL.1;P775202 2 822(36) 22-Jul-88 12:34:12 ALAN
M101 READ.C.1041;P775202 10 25544(7) 2-May-88 13:42:44 ALAN
- .REL.1;P775202 3 1366(36) 22-Jul-88 12:34:58 ALAN
M30 SBRK.C.1002;P775202 3 6715(7) 10-May-88 13:18:18 ALAN
- .REL.1;P775202 1 309(36) 22-Jul-88 12:33:28 ALAN
M20 SIGDAT.C.1005;P775202 2 4100(7) 23-Apr-88 12:14:23 ALAN
- .REL.1;P775202 1 151(36) 22-Jul-88 12:33:37 ALAN
M145 STAT.C.1004;P775202 4 9518(7) 22-Jul-88 08:46:19 ALAN
- .REL.1;P775202 1 474(36) 22-Jul-88 12:33:57 ALAN
M18 UIODAT.C.1008;P775202 2 4834(7) 29-Apr-88 20:34:38 ALAN
- .REL.1;P775202 1 277(36) 22-Jul-88 12:33:45 ALAN
M120 URT.C.1019;P775202 15 36552(7) 22-Jul-88 12:10:28 ALAN
- .REL.1;P775202 5 2152(36) 22-Jul-88 12:33:00 ALAN
= URTSUD.C.6;P775202 1 223(7) 18-Aug-87 02:36:47 ALAN
- .REL.1;P775202 1 64(36) 22-Jul-88 12:33:06 ALAN
M33 WAIT.C.1004;P775202 2 4797(7) 23-Apr-88 12:21:56 ALAN
- .REL.1;P775202 1 118(36) 22-Jul-88 12:35:31 ALAN
M65 WRITE.C.1020;P775202 6 13157(7) 22-Jul-88 09:00:20 ALAN
- .REL.1;P775202 2 887(36) 22-Jul-88 12:35:12 ALAN
Total of 86 pages in 30 files
Grand total of 326 pages in 117 files
Some comments about NOTES.TXT:
Is uio.h old hat? But isn't this the file that you include to
declare open()?
[KLH: Yes, flush uio.h. Nothing should still use it. Did you find something
that does?]
There are a lot of other little details to be done, and no obvious
organized way to go about it.
[KLH: Well, one method is to pick a useful program or two you want to
port to ITS; it must be useful enough to stimulate you into converting
the USYS calls needed to support that program. More rewarding than just
trying to go down through them alphabetically and not really knowing whether
something NEEDS to be simulated. KCC itself is a good candidate, except
that you'll need an ITS linker.]
ERJMP definitions are output even for ITS.
[KLH: OK, fixed.]
ADJBP macro output for KA is incorrect.
[KLH: if you meant AC and MEM dummy args, this was already fixed.]
LSEEK: On block mode output (_UIO_HANDPACK is set) you can only position
from one word boundary to another. Doesn't know how to do L_XTND.
(Usual EOF screw.) ITS won't let you do any operations if you
position yourself beyond the end of the file anyway.
[KLH: hmm, should be able to position at byte boundaries. What you really
need to be able to do is based on STDIO -- binary streams should be able
to fseek to arbitrary places within a file (ignore beyond EOF), text
streams should be able to fseek to anyplace that they ftell'd from, plus
0 and EOF. This can be fixed up, right?]
Should support append mode. (How? No reasonable way to find the
end of a file...) Also overwrite? (Can't truncate!)
[KLH: don't worry about truncation, that's rarely used. append is
a lot more common, tho. Time to play with ITS? I thought the hack
I put into COMSAT for "FAST-APPEND" was reasonable.]
MALLOC: Removed test for extended addressing and call to EXTEND [XBLT] on
ITS (mostly) because FAIL didn't have XBLT predefined.
[KLH: KCC includes a definition of XBLT in the header it generates. You
may not have noticed this if you were already using your own header.]
There is a bug in _setup() that touches nonexistent memory. I did
not fix it, because the temptation to re-write the entire MALLOC
module would be too great. Instead I broke brk() to always keep at
least 4 extra words existent so that I wouldn't have to think about
problems like this unless they were really bad ones.
[KLH: Guess we'll look at _setup().]
Shouldn't _ERRNO_T20_LAST be ECLOSE?
[KLH: yeah, fixed.]
What do we do about ITS error codes? Add 400000?
[KLH: that would be OK. There isn't any good way to combine Unix error
numbers with OS errors. Having strerror recognize OS numbers is an
extension, but the actual strerror call in this case has to be conditionalized.
An argument of -1 (another extension) gets the last OS error; this lets me
define LASTERROR to be either "errno" (on a real Unix) or "-1" (for KCC)]
STDIO.H: On ITS SYS_OPEN is 16. Should perhaps set L_cuserid to 6?
[KLH: Seems reasonable.]
EXIT: The reasons for waiting for a subfork are different on ITS?
[KLH: Huh?]
CRT: Initialization of P is wrong everywhere but ITS.
[KLH: Huh?]
CPU: FAIL can't assemble this because $BADL6, $BADL7, $BADL8, $BADL9,
$BADLH are EXTERNals after ==.
[KLH: Yeah. Use MACRO for that. We use MACRO for most of the library,
just to avoid FAIL's meaningless barfing when SEARCH is used.]
-------
13-Aug-88 12:52:42-PDT,7858;000000000000
Return-Path: <@AI.AI.MIT.EDU,@REAGAN.AI.MIT.EDU:[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Sat, 13 Aug 88 12:52:15 PDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 12 Aug 88 14:45:34 EDT
Received: from MARLEY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 129231; Fri 12-Aug-88 14:40:28 EDT
Date: Fri, 12 Aug 88 14:40 EDT
From: Alan Bawden <[email protected]>
Subject: ITS changes merged
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Just some quick answers to a subset of your comments:
Date: Thu, 11 Aug 88 17:08:57 PDT
From: Ken Harrenstien <[email protected]>
OK, I have merged in your stuff. I'll set up another distrib directory
or something soon so you can get back the new things. Here is a list of
the files, followed by some comments on your notes.txt:
? C-HITS.FAI.2;P775202 1 343(7) 25-Mar-88 12:29:03 ALAN
? .MAC.2;P775202 1 343(7) 25-Mar-88 12:29:03 ALAN
We should be able to make KCC generate the right headers
instead of using these. I don't think using XC: in the
.REQUEST is necessary, and everything else should be OK.
You know about the -L switch? Basically C: is used for
3 things, all of which can be set with the -I,-H, and -L switches.
I forget now why I found it easier to generate my own header files
manually, I recall fighting with what KCC was generating for an afternoon
and just giving up. Certainly we should fix KCC to generate proper
headers and flush these. The XC: in the .REQUEST is just insurance that I
don't ever accidentally link in 20X rel files from C:. I'd be happy to do
this some other way if some 20X wizzard wants to straightem me out on the
proper combination of logical name and linking loader hackery. I just
found something that worked.
? ITSSYM.FUN.1;P775202 11 5361(36) 1-Apr-88 06:38:32 ALAN
? .UNV.1;P775202 4 1793(36) 1-Apr-88 06:38:05 ALAN
This is an odd place to have these files. Probably they should
be copied to UNV:.
Probably, but I don't have the access to put them there on XX.
For distribution purposes, they could be kept in
the <.FAIL> directory. #asm code that needs the syms can explicitly
get them with a SEARCH ITSSYM, the same way T20/10X code does
SEARCH MONSYM -- this shouldn't be in the header.
I suppose. The thing is that if this ever runs on ITS there won't need to
be a SEARCH anything because FAIL just gets the symbols from ITS. Thats
why I put the SEARCH ITSSYM in the common header, to simulate how it would
work on ITS. It wouldn't be hard to arrange for SEARCH ITSSYM to be a
no-op on ITS, and insert them explicitly where 20X FAIL needs them.
- XCC.PCL.11;P775202 1 456(7) 18-Jul-88 18:57:18 ALAN
Do you want to keep this? I could move it into the compiler
directory (already have a cross-compiler example there for 10X).
It's just for my convenience. You can ignore it.
- UIO.H.1007;P775202 2 3199(7) 29-Apr-88 20:34:35 ALAN
This file (uio.h) should be flushed completely. Nothing uses it.
Well, the man page for read() on a Unix I just checked told me to include
<sys/uio.h>, so aren't there compatible programs that are likely to look
for this?
M5 SYSCAL.C.1004;P775202 1 2343(7) 23-Apr-88 12:01:07 ALAN
Some questions here:
Should ato6() and afrom6() be here? I'm not sure where
to put them; if we want to make them universally available
to all PDP-10 configs then they need a header file.
Should sysits.h be syscal.h and itssym.h?
I edited afrom6() to avoid using an ADJBP.
I don't know of anyplace that uses ato6 and afrom6, so I would suggest that
we just flush them. I don't see any compelling reason to split this file
since I can't imagine wanting either half alone.
PS:<C.ITS.LIB.ITS>
? HUMBLE.C.36;P775202 5 10719(7) 11-May-88 23:17:38 ALAN
- .REL.2;P775202 4 1601(36) 22-Jul-88 12:56:41 ALAN
This should be a separate package, not part of the C library.
It can be put into a <.ITS> subdir of the distrib.
Invent a library name for it, such as LIBINF or LIBKID.
Yes. I just put it in the library for convenience while I was debugging
it.
Some comments about NOTES.TXT:
LSEEK: On block mode output (_UIO_HANDPACK is set) you can only position
from one word boundary to another. Doesn't know how to do L_XTND.
(Usual EOF screw.) ITS won't let you do any operations if you
position yourself beyond the end of the file anyway.
[KLH: hmm, should be able to position at byte boundaries. What you really
need to be able to do is based on STDIO -- binary streams should be able
to fseek to arbitrary places within a file (ignore beyond EOF), text
streams should be able to fseek to anyplace that they ftell'd from, plus
0 and EOF. This can be fixed up, right?]
I'm only talking about -binary- -output- here. Input streams work just
fine, as do 7-bit output streams. Positioning to an arbitrary byte in an
binary output stream requires you to read in the part of the 36-bit word
to the left of where you are going to write. ITS does not provide a
reliable way to do this.
Should support append mode. (How? No reasonable way to find the
end of a file...) Also overwrite? (Can't truncate!)
[KLH: don't worry about truncation, that's rarely used. append is
a lot more common, tho. Time to play with ITS? I thought the hack
I put into COMSAT for "FAST-APPEND" was reasonable.]
Yeah, I agree that append is important. I could just believe what ITS
tells me is the length of the file, and we could live with the fact that
spurious ^C's would appear when you append to a file that was written by
Emacs, or restored from tape.
I'll look at the COMSAT hack. The only thing I can imagine it doing is
page mapping in the last page of the file (which only works because you
know that the file has actually been written to disk because you just
opened it) so that it can get a look at the last word to count the ^C's. I
thought of doing that initially, but decided it was complicated enough that
I had more important things to do first.
Appending to a binary file can never work without a lot more work.
[ Before everybody starts jumping on me about this issue again. (You all
always do when this comes up.) Let me point out for the 100th time that
this is not a problem with ITS itself. It cannot just be -fixed- by
modifying ITS. The problem is caused by the zillion user programs that
"know" that they can write an ASCII file by writing a bunch of 36-bit
words with a bunch of ^C's for padding. I am not going to spend the rest
of my life tracking those programs all down and fixing them. I apologize
to everybody for these facts. I know that it sucks. ]
EXIT: The reasons for waiting for a subfork are different on ITS?
[KLH: Huh?]
Just a note to myself that the 20X code for EXIT was going to be very
different from the ITS code.
CRT: Initialization of P is wrong everywhere but ITS.
[KLH: Huh?]
P is initialized to contain -<length-of-stack>,,<first-location-of-stack>
everywhere except on ITS where I fixed it to be
-<length-of-stack>,,<first-location-of-stack>-1 so that you don't try to
write in the first word beyond the stack before getting the stack overflow
interrupt. (On ITS I wanted to get at %PIPDL instead of a %PIMPV.)