Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/dist/csikcc.mail
There are no other files named csikcc.mail in the archive.
13-Mar-89 14:23:59-PST,1739;001000000001
Mail-From: KLH created at 13-Mar-89 14:23:52
Date: Mon, 13 Mar 89 14:23:52 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Possible work: KCC
To: kuo@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12477774755.18.KLH@SRI-NIC.ARPA>
I just got a call from someone (not sure where from; Compuserve?) who is
very interested in getting our C compiler (KCC) to run on their TOPS-10
systems. One key issue is whether KCC is ANSI compatible. I told him
that it wasn't fully ANSI compatible yet, but that I was on the C standard
committee and thus was well aware of what was going on & knew what would
be involved. I also confirmed that KCC was considered a research tool and
thus while we had it copyrighted we provided it for basically the cost of
the tape and handling.
They would like to take it, bring it up to ANSI level, and port it to TOPS-10.
I said fine, any sharp programmer could probably do it, but that I could
probably do it a lot faster and in a much more integrated way, and was quite
interested in the idea, but didn't have much support here at SRI. So he
bit and asked for an estimate. I said probably 2 months of work, but couldn't
give him a ballpark of $ without checking some papers. He was running out
of time (5pm their time) so said he'd check with his manager and call back
tomorrow about 1pm.
This is something I've wanted to do for awhile, but wasn't sure whether it
could be justified on overhead or not. If we can get SOME money in for
this task, I'd jump for it even if they can't cover all of the costs
themselves. If either of you would like more info about all this I'd be
happy to give a little background talk or something.
--Ken
-------
14-Mar-89 14:09:45-PST,621;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 14 Mar 89 14:02:53 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA11328; Tue, 14 Mar 89 17:01:08 EST
Date: Tue, 14 Mar 89 17:01:08 EST
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903142201.AA11328@tut.cis.ohio-state.edu>
To: klh@sri-nic.arpa
Subject: Greetings
Ken - I may figure this out yet. This is my first message on Internet.
I hope you get it. If I hear from you, I'll be in touch again via this
net. Otherwise, I'll be in touch via voice. -- Benny Jones
14-Mar-89 14:20:33-PST,416;001000000001
Mail-From: KLH created at 14-Mar-89 14:20:11
Date: Tue, 14 Mar 89 14:20:10 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Greetings
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8903142201.AA11328@tut.cis.ohio-state.edu>
Message-ID: <12478036225.18.KLH@SRI-NIC.ARPA>
Got it! Works fine, would you like me to send you some of the documentation
files for KCC?
--Ken
-------
14-Mar-89 14:53:11-PST,576;001000000001
Mail-From: KLH created at 14-Mar-89 14:53:01
Date: Tue, 14 Mar 89 14:53:01 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC Enhancement(?)
To: S.SNELSON@MACBETH.STANFORD.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12477778998.28.S.SNELSON@MACBETH.STANFORD.EDU>
Message-ID: <12478042206.18.KLH@SRI-NIC.ARPA>
By the way, the name of the person I talked with was Benny Jones of
Compuserve, I didn't get that info the first time I talked with him but
did today. He plans to contact you fellows also. We should all be able
to figure something out.
-------
14-Mar-89 15:16:16-PST,2584;001000000001
Mail-From: KLH created at 14-Mar-89 15:16:06
Date: Tue, 14 Mar 89 15:16:05 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: More KCC news
To: kuo@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12478046406.18.KLH@SRI-NIC.ARPA>
The guy called back today. His name is Benny Jones and he indeed is from
Compuserve. They have a whole bunch of machines running their version of
TOPS-10, basically KLs plus Systems Concepts clones (SC-30s).
We agreed it would make the most sense to have them do the port to
TOPS-10 as that mostly involves adding some code and conditionals to
existing library functions, and can be done separately from the
ANSI-ization of the compiler. Re the latter, he asked again whether
they could do that part, I said it was possible but would be much
harder. I already knew all about the compiler and knew what had to be
done. I said standard SRI fee would probably amount to 20K per
man-month for my time. He didn't think 2 months of that would would
make it through higher channels. I said I understood that and that
since SRI would stand to benefit from this as well, I was pretty sure
I could arrange for some SRI support, given the existence of partial
outside support. I mentioned Systems Concepts as another party of
interest who might be willing to help, and he thought that was worth
pursuing too; he had already planned to contact them (they are
long-time KCC users and I've talked with them frequently).
Then we arranged to keep in touch via e-mail if possible (and a few minutes
later he succeeded in sending me a message, so we're set). The address he
has is "hbj@cis.ohio-state.edu" -- not Compuserve, but a guest account.
Phone is 614/457-8600.
I have some questions for you:
* To what extent would it be reasonable for SRI to support bringing
KCC up to ANSI conformance? My conservative estimate was 2 man-months for
a good job. I could probably do it in 1 depending on how many other things
were distracting me during whatever real-time period it takes. I didn't
promise anything, but it seemed reasonable enough to me.
* If SRI (i.e. NISC) decides it isn't cost-effective for us to
support any KCC development, would you have any objection to my doing
this task as an independant consultant on my own time? It would
require the use of the NIC machine after hours, but the NIC (and all
PDP-10s everywhere, govt owned or otherwise) will benefit from the
results.
One way or another, someone is going to do it, and I'd like to be the
one to do it.
-------
14-Mar-89 15:30:57-PST,2078;001000000001
Mail-From: KLH created at 14-Mar-89 15:30:24
Date: Tue, 14 Mar 89 15:30:23 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Initial KCC blurb - KCCDIST:OBTAIN.DOC
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8903142201.AA11328@tut.cis.ohio-state.edu>
Message-ID: <12478049009.18.KLH@SRI-NIC.ARPA>
Rather than wait for a response, I'll just send you the stuff you'll need
to bootstrap yourself. The following is the file KCCDIST:OBTAIN.DOC;
it makes reference to KCCDIST:INSTAL.DOC which you should try to retrieve
(other files of particular interest to you would be C:CC.DOC, C:LIBC.DOC,
and C:USYS.DOC). If you've never used FTP before to transfer files, now's
your big chance to learn. Let me know if you need help or have any
questions.
--Ken
------------------------------
HOW TO OBTAIN KCC
There are two ways to get a copy of the KCC PDP-10 C compiler: FTP and tape.
FTP:
If you are fortunate enough to be able to make an Internet
TCP/IP connection to SRI-NIC.ARPA, you can transfer the distribution
files directly. Establish a FTP connection to SRI-NIC, log in as
"anonymous" with a random password, and then retrieve the file
KCCDIST:INSTAL.DOC. This will explain the rest of what you need to
know. If you have problems, send electronic mail to
<BUG-KCC@SRI-NIC.ARPA>.
Tape:
If you do not have access to SRI-NIC via TCP/IP then the
alternative is to ask for a magnetic tape. A distribution tape
normally consists of a 9-track 1600 bpi tape with a single saveset
written by TOPS-20 DUMPER, and includes all of the sources and
documentation. A charge is necessary to cover the cost of the
materials, postage, and time. Mail your request, with a check for
US $100 payable to "SRI International", to:
Network Information Center, Room EJ291
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025
If you have further questions or encounter problems, you can contact:
Ken Harrenstien <KLH@SRI-NIC.ARPA>
Phone: 415/859-6552
(postal address same as above)
-------
14-Mar-89 17:04:56-PST,657;001000000001
Mail-From: KUO created at 14-Mar-89 17:04:47
Date: Tue, 14 Mar 89 17:04:46 PST
From: Frank Kuo <KUO@SRI-NIC.ARPA>
Subject: Re: Possible work: KCC
To: KLH@SRI-NIC.ARPA
cc: joaquin@SRI-NIC.ARPA, KUO@SRI-NIC.ARPA
In-Reply-To: <12477774755.18.KLH@SRI-NIC.ARPA>
Message-ID: <12478066189.24.KUO@SRI-NIC.ARPA>
Ken: I would be happy for your to do the job on your own time as an
independent consultant. I think we might somehow arrange for
reimbursement of TOPS 20 time you use for this job. The DCAA auditors
would catch any unauthorized usage, so we need to put this on a
pay-as you go basis. I'll check with Barbara Camph.
Frank
-------
14-Mar-89 22:47:55-PST,1552;001000000005
Return-Path: <joaquin@sri-nic.arpa>
Received: from bear.nisc.sri.com by SRI-NIC.ARPA with TCP; Tue, 14 Mar 89 22:47:49 PST
Received: from localhost by bear.nisc.sri.com (3.2/SMI-3.2-LIM.5)
id AA00509; Tue, 14 Mar 89 18:12:29 PST
Message-Id: <8903150212.AA00509@bear.nisc.sri.com>
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Cc: kuo@SRI-NIC.ARPA, joaquin
Subject: Re: More KCC news
In-Reply-To: Your message of Tue, 14 Mar 89 15:16:05 -0800.
<12478046406.18.KLH@SRI-NIC.ARPA>
Date: Tue, 14 Mar 89 18:12:25 PST
From: joaquin@sri-nic.arpa
Ken:
Given our current budget constraints, I think we could not use SRI
overhead to our best interest if we were going to pay for all the
work. From your message, it sounds like you are discarding the
possibility of Compuserve paying for most of the work together with
another company...am I right? How much money are they willing to pay?
What type of deadlines do they have?
I am a bit vague on the potential benefits for SRI of supporting (at
least part of) your work on making KCC ANSI conformant. Could you
elaborate a bit on this?
At any rate, I think it is a really nice project for you, given your
interest. In the worst case, you could do the work on your own time as
an indep. consultant. I don't know the implications on computer usage,
though......before deciding to simply go ahead this way, which would
put a lot of pressure on you, I'd like us three to think of
alternative avenues for non-overhead funding....provided that
Compuserve can wait.
JJ
15-Mar-89 11:51:05-PST,1003;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 15 Mar 89 11:50:10 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA26719; Wed, 15 Mar 89 14:49:17 EST
Date: Wed, 15 Mar 89 14:49:17 EST
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903151949.AA26719@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC
Cc: HBJ@cis.ohio-state.edu
Ken -- I've gotten the assorted DOC files for KCC. Thanks. The network
becames painfully slow when I tried to get CC.EXE and friends. I may
try early tomorrow. I've also passed on to my management the notion
of having you bring KCC up under TOPS-10 maybe in collaboration with
Systems Concepts. I'll keep my fingers crossed. I think I recall
a conservative estimate of 2 months for that. And that doesn't include
work on the library or work on bringing the compiler up to the ANSI
standard. Right? I'll let you know if anything develops. -- Benny Jones
15-Mar-89 13:58:14-PST,4358;001000000001
Mail-From: KLH created at 15-Mar-89 13:54:52
Date: Wed, 15 Mar 89 13:54:52 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8903151949.AA26719@tut.cis.ohio-state.edu>
Message-ID: <12478293764.17.KLH@SRI-NIC.ARPA>
Hi. Let me elaborate a bit on the estimate, and tell you about the results
of some discussion here.
2 KLH-months (~300 hrs) would be my estimate for doing everything --
both ANSI upgrade and basic TOPS-10 port. How long that would take in
real time depends on the urgency. The work breaks down into 4 parts
as follows:
ANSI upgrade
KCC: Most complicated.
Requires complete preprocessor rewrite, changes to internal
data structures and parser.
LIBC: Straightforward, but tedious. Many small changes and additions
to the library routines.
TOPS-10 port
KCC: Easiest. No changes needed except for the mechanics of invoking
assembler/linker. (KCC can write TMPCOR/PRARG files)
LIBC: Straightforward, depending on how far you want to go towards
emulating the Unix environment.
To my mind, the ANSI upgrade is the thorniest part, because it
involves changing a very large and complicated program with lots of
interconnections, to meet the specifications of a not-yet-final
standard that is still not well understood by many people. I am on
the X3J11 committee trying to get the dpANS out; if you've seen any of
the standards documents (draft or comment responses) you'll know what
I mean.
Porting to TOPS-10 has its own pitfalls, but is actually much more
straightforward, because KCC itself merely uses the C library, and the
C library is divided into many small functions with a reasonably
well-defined interface to each. The KCC/LIBC code is completely
conditionalized so that it is easy to see what OS-dependent code needs
to be added; in fact, just compiling it with the SYS_T10 flag should
identify most or all of the places that need work. Some OS-dependent
routines already have T10 code in place (although it hasn't been
tested).
It is definitely possible to separate out the upgrade and the port;
they can proceed independently, in the sense that the port can be done
right now without waiting for the upgrade, and vice versa. Given the
fact that I now have less experience with TOPS-10 than I do with ITS and
TOPS-20 (my last T10 manual dates from 1973!), someone who is a T10
wizard can probably do it more quickly. It's hard to say, because
ideally you want someone who is familiar with C (to code in), UNIX (to
realize how things were meant to work), and TOPS-10 (to know the
limits of what possible and what monitor calls to use).
Now, the news about support.
As I expected, my upper management at SRI (which changed recently and
is questioning everything) is very reluctant to support the entire
upgrade. I MAY be able to get 50% support out of them, which I think
is fair, if it doesn't take too long. However, they did make an
unusual concession -- it's fine if I want to do this particular task
as an independent consultant, outside of SRI.
There would be some advantages to doing it this way. The most
important one is that it would be a LOT cheaper -- no atrocious
institutional overhead. I would also get somewhat more personal
benefit out of it (modulo taxes), which would help compensate for the
strain on my free time. I can even arrange to take some vacation time
away from SRI work, if the project has a tight deadline.
The primary complication would be getting reasonable access to CPU and
disk; the SRI-NIC T20 is government owned and I would need permission
to use it so the auditors don't get upset. I know it's slightly weird
because KCC already lives on that T20, but these days we have to be
careful. SRI owns another KL which I can use without hassle as long
as I pay for CPU and disk usage -- unfortunately rather high. I'm
looking into both of these now. Other less convenient options are to
use a Systems Concepts machine (they may not have much else to offer,
but they do have that) with a high-speed modem, or even to hook into
Compuserve, although I assume the network tolls would kill the latter
idea.
That's it for now. Glad you were able to retrieve the doc files.
Keep me posted...
--Ken
-------
15-Mar-89 14:15:50-PST,643;001000000001
Mail-From: KLH created at 15-Mar-89 14:09:53
Date: Wed, 15 Mar 89 14:09:53 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KL rates?
To: vivian@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12478296498.17.KLH@SRI-NIC.ARPA>
By the way, do you know what the current KL rates are (for CPU and for disk)?
I'm contemplating a project that would require some outside crunching and
I'm wondering how much it would cost to avoid the hassle of asking the govt
for permission to use the NIC 20.
Tried calling the KL numbers (x4000, x6199, etc) and nobody answers except
some poor sec'y who doesn't know where anyone is.
-------
15-Mar-89 20:11:31-PST,4807;001000000011
Return-Path: <@KL.SRI.COM,@CRVAX.SRI.COM:TONI@GIZMO.SRI.COM>
Received: from KL.SRI.COM by SRI-NIC.ARPA with TCP; Wed, 15 Mar 89 20:11:27 PST
Received: from CRVAX.SRI.COM by KL.SRI.COM with TCP; Wed, 15 Mar 89 15:47:42 PST
Date: Wed 15 Mar 89 15:45:21-PST
From: Satomi Masuda <TONI@GIZMO.SRI.COM>
Subject: Rate Sheet
To: klh@KL.SRI.COM
Cc: toni@GIZMO.SRI.COM
Message-ID: <606008721.0.TONI@GIZMO.SRI.COM>
Mail-System-Version: <VAX-MM(216)+TOPSLIB(128)@GIZMO.SRI.COM>
Computing Systems and Services
Computer Facilities Rate Sheet
for SRI Internal Accounts Nov. 1986
_______________________________________________________________________________
System Name SRI-KL VAX CLUSTER SRI-UNIX
SRI-STRIPE (SRI-VAX/SRI-GIZMO)
-------------------------------------------------------------------------------
TC= terminal connect $3.30/hr | $3.00/hr | $3.00/hr
time | |
CP= Central processor $300.00/hr | $685.00/hr VAX | $150.00/hr
| $195.00/hr GIZMO |
| |
MEM= Memory used while $3.00/page/hr| |
computing | |
| |
IO= Input-Output disk $.003/page | |
file transfer | |
| |
WS= Working set |.004x(PWS-500)/100 VAX |
premium* | |
(PWS=peak working set) |.004x(PWS-300)/100 GIZMO
| |
IOD= Direct I/O | $.20/1000 operations |
operations | |
| |
IOB= Buffered I/O | $.40/1000 operations |
operations | |
| |
PF= Page faults | $.035/1000 pages |
| |
PP= Pages produced | |
(see below) | |
D= Shift discount | |
(see below) | |
----------------------------------------------------------------------------
Pages Produced (PP):
Line Printer $.03/page $.03/page $.03/page
Laser Printer $.15/page(text) $.15/page
$.375/page(impress)
Print request charges $.30 each $.30 each
-----------------------------------------------------------------------------
Tape Mounts $5.00 each $5.00 each $5.00each
-----------------------------------------------------------------------------
Disk storage/megabyte $5.40/wk $7.00/wk $7.00/wk
-----------------------------------------------------------------------------
Minimum charge $1.00/wk $1.00/wk $1.00/wk
-----------------------------------------------------------------------------
Part II
Shift Discount Factors(D)
-----------------------------------------------------------------------------
| % Charged
Shift from to | Dec 20 VAX PYRAMID
-----------------------------------------------------------------------------
Prime time 8am 6pm | 100% 100% 100%
Evening 6pm midnight | 50% 70% 50%
Grave midnight 8am | 25% 25% 50%
Weekend midnight midnight | 25% 25% 50%
(friday) (Sunday) |
-----------------------------------------------------------------------------
JOBS CHARGES ARE CALCULATED USING THE FOLLOWING FORMULAS:
DEC-20 = PP + D x [TC + CP + MEM + IO]
VAX = PP + D x [(CP x{1 + WS}) + TC + IOD + IOB + PF]
PYRAMID= PP + D x [CP + TC]
*WS is a multiplier for CPU
-------
16-Mar-89 13:33:50-PST,823;001000000011
Return-Path: <vivian@Sri-Nic.Arpa>
Received: from ws1.NISC.sri.com by SRI-NIC.ARPA with TCP; Thu, 16 Mar 89 13:33:42 PST
Received: by ws1.NISC.sri.com (4.0/SMI-4.0/LIM.1.3)
id AA02685; Thu, 16 Mar 89 13:33:24 PST
Date: Thu, 16 Mar 1989 13:33:22 PST
From: Vivian Neou <vivian@sri-nic.arpa>
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Cc: vivian@sri-nic.arpa
Subject: Re: KL rates?
In-Reply-To: Your message of Wed, 15 Mar 89 14:09:53 PST
Message-Id: <CMM.0.88.606087202.vivian@>
I just called and they're putting a rate sheet in the mail to me now.
The KL is going away in August, so if your project needs cycles after that
you may want to think about getting permission to use the NIC's 20 (although
our system is overloaded). Another possibility might be to buy some time
from MKL's F4 that runs TOPS20.
16-Mar-89 13:40:27-PST,986;001000000001
Mail-From: KLH created at 16-Mar-89 13:40:00
Date: Thu, 16 Mar 89 13:39:59 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KL rates?
To: vivian@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <CMM.0.88.606087202.vivian@>
Message-ID: <12478553200.31.KLH@SRI-NIC.ARPA>
Sigh, naturally this is just after I finally got my own copy via e-mail!
What this is about is arranging to do a KCC upgrade (to ANSI standard level)
independent of SRI project work. It won't take more than a few months.
Camph is looking into the hassles involved with using our 20. I didn't
realize that the other F4 was still around, who should I contact for info?
MKL?
Frank doesn't seem to think it's reasonable to spend overhead money to
upgrade KCC, and I'm very reluctant to do it on govt money even if we
could convince DCA/Wix it is a good idea. So I may end up doing it as
an independent (overworked) consultant. If you want more details I can
give you a dump...
-------
16-Mar-89 13:40:55-PST,318;001000000001
Mail-From: KLH created at 16-Mar-89 13:40:48
Date: Thu, 16 Mar 89 13:40:48 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Rate Sheet
To: TONI@GIZMO.SRI.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <606008721.0.TONI@GIZMO.SRI.COM>
Message-ID: <12478553346.31.KLH@SRI-NIC.ARPA>
Got it, thanks...
-------
16-Mar-89 13:49:35-PST,782;001000000011
Return-Path: <vivian@Sri-Nic.Arpa>
Received: from ws1.NISC.sri.com by SRI-NIC.ARPA with TCP; Thu, 16 Mar 89 13:49:25 PST
Received: by ws1.NISC.sri.com (4.0/SMI-4.0/LIM.1.3)
id AA02724; Thu, 16 Mar 89 13:49:11 PST
Date: Thu, 16 Mar 1989 13:49:08 PST
From: Vivian Neou <vivian@sri-nic.arpa>
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Cc: vivian@sri-nic.arpa, mkl
Subject: Re: KL rates?
In-Reply-To: Your message of Thu, 16 Mar 89 13:39:59 PST
Message-Id: <CMM.0.88.606088148.vivian@>
MKL just bought the old CSL so he owns it personally now. I'm temporarily
letting him keep it in our machine room until we have too much equipment
to afford the floor space. If this is something you may have to do on your
own MKL might be willing to give you time on his machine...
16-Mar-89 13:51:06-PST,387;001000000001
Mail-From: KLH created at 16-Mar-89 13:50:59
Date: Thu, 16 Mar 89 13:50:59 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KL rates?
To: vivian@SRI-NIC.ARPA
cc: mkl@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA
In-Reply-To: <CMM.0.88.606088148.vivian@>
Message-ID: <12478555202.31.KLH@SRI-NIC.ARPA>
Which is being powered and housed by SRI, huh? Boy, this gets messy...
-------
17-Mar-89 12:20:30-PST,1759;001000000001
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 17 Mar 89 12:20:07 PST
Received: by tut.cis.ohio-state.edu (5.61/3.890314)
id AA25429; Fri, 17 Mar 89 15:00:28 -0500
Date: Fri, 17 Mar 89 15:00:28 -0500
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903172000.AA25429@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: CompuServe account
Ken -- I've FTP'd a few source files over to the Ohio State host, but
I haven't gotten them down to CompuServe yet to look at them. I've
forwarded your note about the breakdown of the jobs and your possible
involvement to my upper management. I expect they'll be getting back
to me. Getting CPU and disk will be no big problem if you can put
up with 2400 baud access. I've set up a guest account for you on
CompuServe. This is not a CompuServe Information Service account, but
rather a regular user account. With it, if you want to, you can log
in and "experience" our operating system. It's based on TOPS-10, but
our people have modified it somewhat. If you have questions or problems
please let me know. I'll assume you can call San Mateo (?sp) without
incurring LD charges. If not, I'll get you another number. 1200 baud
access is 415-595-8830. 2400 baud access is 415-591-5415. Once you get
carrier, hit RETURN. You should be prompted for Host Name. Enter CPS.
Now you should be prompted for User ID. Enter 525,5. The password is
the same as the room number used in ordering your tape. You can change
it using a program call CHGPAS. Simply enter R CHGPAS. I'm becoming
swamped in other issues, but we are still strongly interested in the
C compiler. I'll chat with you later.
-- Benny
20-Mar-89 14:02:58-PST,515;001000000011
Mail-From: KLH created at 20-Mar-89 14:02:55
Date: Mon, 20 Mar 89 14:02:55 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Rate Sheet
To: TONI@GIZMO.SRI.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <606008721.0.TONI@GIZMO.SRI.COM>
Message-ID: <12479605950.23.KLH@SRI-NIC.ARPA>
Oh, by the way, I just noticed that the rate sheet you sent me is for SRI
Internal accounts. What would the rates be for external accounts? Say, if
I wanted to purchase some time for personal (non-project) use?
-------
20-Mar-89 14:06:11-PST,657;001000000001
Mail-From: KLH created at 20-Mar-89 14:05:32
Date: Mon, 20 Mar 89 14:05:31 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KL rates
To: guthary@tsca.istc.sri.com, camph@KL.SRI.COM
cc: klh@SRI-NIC.ARPA
Message-ID: <12479606424.23.KLH@SRI-NIC.ARPA>
Hmmm, I just noticed that the rates I received were for "SRI Internal accounts".
If I were to do this project as an independent consultant paying with real
money for KL time (!), would the rates be different? If so, what are they?
(I already asked the CSS people this but don't expect to hear from them for
awhile, was hoping you might already have a sheet made up or something).
-------
20-Mar-89 14:11:14-PST,749;001000000001
Mail-From: KLH created at 20-Mar-89 14:11:12
Date: Mon, 20 Mar 89 14:11:12 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Rate Sheet
To: TONI@GIZMO.SRI.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12479605950.23.KLH@SRI-NIC.ARPA>
Message-ID: <12479607459.23.KLH@SRI-NIC.ARPA>
Oh, and what is the relationship between a "megabyte" on the rate sheet, and
a "disk page" on the KL?
One could argue that a disk page amounts to 512, 2048, or 2560 bytes, depending
on your definition of "byte". Since I am contemplating the use of quite a
lot of disk space, the distinction becomes important. I assume that on the KL
pricing is done on a per-page basis rather than per-byte, hence rounding is done
upwards for each file.
-------
21-Mar-89 11:43:26-PST,612;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 21 Mar 89 11:42:28 PST
Received: by tut.cis.ohio-state.edu (5.61/3.890314)
id AA22844; Tue, 21 Mar 89 14:20:38 -0500
Date: Tue, 21 Mar 89 14:20:38 -0500
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903211920.AA22844@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Try this
Ken -- You might try carbon-copying mail to me to
BEN@csi.compuserve.com
This isn't fully functional yet, but there's a good chance that
I'll eventually get anything sent here. Thanks.
21-Mar-89 12:01:38-PST,411;001000000001
Mail-From: KLH created at 21-Mar-89 11:57:11
Date: Tue, 21 Mar 89 11:57:10 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Try this
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA, BEN@csi.compuserve.com
In-Reply-To: <8903211920.AA22844@tut.cis.ohio-state.edu>
Message-ID: <12479845203.28.KLH@SRI-NIC.ARPA>
Okay, trying it with this message. I'll have another one coming shortly.
-------
21-Mar-89 12:23:22-PST,1746;001000000001
Mail-From: KLH created at 21-Mar-89 12:22:47
Date: Tue, 21 Mar 89 12:22:46 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Additional thoughts
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA, BEN@csi.compuserve.com
In-Reply-To: <8903211920.AA22844@tut.cis.ohio-state.edu>
Message-ID: <12479849862.28.KLH@SRI-NIC.ARPA>
I've been thinking about things a bit more, and have two main questions.
First, do you have a TOPS-20 available to work on?
Second, do your systems support extended addressing? If so, how are monitor
UUOs handled -- e.g. how are I/O buffers linked? Do you want to use
C programs with extended addressing or not?
Unless you have a T20 system for cross-compiling, it won't be possible
for you to bootstrap anything. In that case, I think the best course of
action would be for me to do the initial TOPS-10 port -- just enough
so that the compiler can compile itself on T10. This shouldn't take
too long (a week or two, real time) and I can do it on SRI's commercial
KL without hassle ($300 to $150 per CPU hour, depending on time of
day). Once it is running with the PA1050 simulator, it can be copied
over to CPS and you can flesh out the rest of the library routines if
you want to do those (or improve on the basic I/O code).
I tried using KERMIT to bring a small file over to CPS and poked at it
a bit with FINE. In theory, I guess using those resources is do-able,
but in practice it is pretty slow. I would probably prefer to do most
of the ANSI-upgrade editing here (I now have permission to use
SRI-owned SUNs for that, so that shouldn't cost anything), and transfer
the files when they're as ready as possible.
Hope things are moving at your end...
--Ken
-------
21-Mar-89 12:57:57-PST,985;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 21 Mar 89 12:57:20 PST
Received: by tut.cis.ohio-state.edu (5.61/3.890314)
id AA22636; Tue, 21 Mar 89 14:18:46 -0500
Date: Tue, 21 Mar 89 14:18:46 -0500
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903211918.AA22636@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC development
Cc: BEN@csi.compuserve.com
Ken -- Do you think you could make a cost/time estimate regarding
the effort to give us an ANSI C compiler running on TOPS-10 and the
I/O library? If you could break down the project into subtasks with
dollar figures on each, we (my managers) could decide what portions
they may prefer that we do inhouse. Thanks.
Did you notice any particular peculiarities with our operating system?
Did you have any problems or questions?
Assuming all goes well, when do you think you could begin work on this
project?
-- Benny
21-Mar-89 13:32:41-PST,1329;001000000001
Mail-From: KLH created at 21-Mar-89 13:32:27
Date: Tue, 21 Mar 89 13:32:26 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC development
To: hbj@cis.ohio-state.edu
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903211918.AA22636@tut.cis.ohio-state.edu>
Message-ID: <12479862545.28.KLH@SRI-NIC.ARPA>
Just got your question about development cost estimate. I'm not sure
whether you sent it before you received my questions or not; it would
help to know the answers before I put a real estimate together. I
assume you'll want a standard consultant (a) cost-per-day $, plus (b)
estimated # days, to accomplish specific things. Roughly how detailed
a breakdown do you want? Say, 4 subtasks?
As far as OS peculiarities go, it is a little disconcerting not to
have a command prompt of some kind, and FINE's default key bindings
are different enough from EMACS that I finally had to print out
FINE.DOC. I'd mostly be concerned about UUO level differences,
however, and for that I'd need to see an uptodate monitor manual
before I could say anything.
I could start work anytime since this would be independent of my real
work, and I can use some vacation time to get over the tough spots.
If you missed my previous msg (re T20 & multi-section), I'll re-send.
--Ken
-------
21-Mar-89 13:40:34-PST,2178;001000000015
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 21 Mar 89 13:40:09 PST
Received: by tut.cis.ohio-state.edu (5.61/3.890314)
id AA06521; Tue, 21 Mar 89 16:36:45 -0500
Date: Tue, 21 Mar 89 16:36:45 -0500
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903212136.AA06521@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC
Cc: BEN@cis.compuserve.com
Ken --
First the answer to your questions. We MAY have a TOPS-20
system available to work on. And NO we do not support
extended addressing - we do not want to use C programs with
extended addressing.
There's a myriad of alternatives here. I fear I'll make us
sound like tightwads, and for that I apologize. We've been
burned on a previous endeavor for getting C for the 10s and
we might be overly cautious here.
We're still interested in your fees and your estimated time-
frame for deliverables.
We could perhaps give you 9600 baud access, no one seems sure
about this right now. We'd probably set up a dedicated TOPS-20
system and provide you with a Hayes 9600 baud modem. It's not
clear how much cost would be racked up if the development were
done on the SRI machines. But then, if you were to do the job
on the SRI machines (even the ANSI upgrade), and we were to then
"buy" the product from you, it would be a capital expense and
we could write it off. If you were to do the work on our machines,
it might appear you're working as a consultant and then it wouldn't
be a capital expense. I don't think this is a big deal with us,
IF we can put together 9600 baud access to a TOPS20 system. I
agree 2400 baud access from Calif. is slow.
Let's try to look at it this way. What's the cost and time if
you were to do it on your machines vs the cost and time of doing
it using our equipment. Let me run that by the folks upstairs.
I appreciate your time in studying this.
Although Ohio State speaks fairly well of KCC, I've been advised
to visit them and get a copy of the compiler, and look at it from
an implemenation standpoint. Prudence, I suppose.
21-Mar-89 19:42:08-PST,1506;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 21 Mar 89 19:42:00 PST
Received: by tut.cis.ohio-state.edu (5.61/3.890314)
id AA12095; Tue, 21 Mar 89 22:41:59 -0500
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA06578; 21 Mar 89 22:29:28 EST (Tue)
Received: by loquat.cis.ohio-state.edu (smail2.5)
id AA01622; 21 Mar 89 22:27:34 EST (Tue)
Date: 21 Mar 89 19:43:06 EST
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Hope you get this
Message-Id: <"CSI 5540-11970"@CompuServe.COM>
to: Ken
fr: Benny Jones
I'm in CompuServe's electronic mail system, InfoPlex, now.
I'm somewhat more comfortable here than on the Ohio State
machine, but I think the interface to Internet isn't
quite as reliable. However, your carbon copies are showing
up over here, so that's encouraging. Here's hoping you
get this message.
I trust you got my message discussing the myriad of
alternatives we could take. Given that the compiler runs
well, generates reasonable code and appears to be written
in a manner that is maintainable, my manager is VERY
interested in doing business with you. I've tried to convey
to him that you seem to have a personal interest in main-
taining the integral quality of the compiler. I've also
pointed out that having you do the work, would probably
result in a finished product substantially sooner than if
I or one of my minions do it.
More later.
22-Mar-89 11:55:13-PST,3501;001000000001
Mail-From: KLH created at 22-Mar-89 11:55:04
Date: Wed, 22 Mar 89 11:55:03 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC proposal
To: camph@kl.sri.com, kuo@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12480106961.28.KLH@SRI-NIC.ARPA>
OK, I've talked with CSS about their KL rates, and have exchanged a few
more messages with Mr. Jones at Compuserve. Here's how I'd like to
see things work in a nutshell:
I'll do the KCC upgrade and port to TOPS-10 on my own time, either after
hours or using vacation/LOP. In return for the results of this work,
Compuserve will contribute money and SRI will permit the use of its
facilities.
The exact arrangement with Compuserve (per hour consulting, or software
purchase, etc) will be something I'll have to negotiate with them myself.
All SRI has to do is support my use of the KL for what I estimate to
be at most a two month period. If in the meantime SRI wants to and
can get government permission to use the NIC machine, I'll shift to
that.
My rationale for doing things this way is as follows:
* Time is likely to be critical. I can't wait for DCA to approve the
use of SRI-NIC. I have already attempted to use Compuserve's system
(they gave me an unlimited account) and overall it is pretty slow
going. The KL is the most attractive alternative to the NIC 20.
* The KL rates for outside users (such as I would be) are, however,
ridiculously high -- $600 per CPU hour prime time, 50% and 25% at
off-hour and weekend times. If I tried to have Compuserve pay for
this, I am pretty sure they would balk completely and do things some
other way. They have mentioned the possibility of using a dedicated
DEC-20 and loaning me a 9600 baud modem.
* SRI is one of the prime potential beneficiaries of the KCC upgrade
since the NIC project will rely on this compiler for at least another
18 and perhaps 24 months. Having our software coded at ANSI C standard
level is good for quite a few brownie points in contract negotiations
and gives us more flexibility. Accordingly it seems somewhat unfair
to stick Compuserve with the sole burden of support for the upgrade,
and if SRI were to let Compuserve provide all of the facilities (even
if not an ideal setup), SRI has no leverage and could well end up with
no upgrade (unless SRI coughs up "real" $).
* Allowing the use of SRI facilities seems like an ideal way for SRI
to "contribute". It is also much easier than going through an
excruciating mess of contractual & licensing agreements. Charges
for KL usage are "funny money" in the sense that they remain
completely within SRI; granted, if the method of "support" were
to involve having NISC pay for KL charges at SRI-internal rates,
then the NISC budget might be affected, but SRI as an institute
would not. This could be worked out within SRI; CSS might
be persuaded to waive these charges or write them off to "system
support".
Other points to note are that I would only use the KL during
off hours (hence won't affect "real" users) and can also use
our own SUNs for a good deal of offline edit work.
How's that? I'm trying to get this cleared up as soon as possible,
since Compuserve is pressing for an estimate. If you see any problems
with this, let me know what they are. And if anything more is needed
(if Frank agrees) to ensure "official" SRI approval.
Thanks!
--Ken
-------
22-Mar-89 11:57:32-PST,2040;001000000001
Mail-From: KLH created at 22-Mar-89 11:57:22
Date: Wed, 22 Mar 89 11:57:22 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re-trying failed message
To: hbj@cis.ohio-state.edu
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
Message-ID: <12480107381.28.KLH@SRI-NIC.ARPA>
Hmmm, very odd; this message seemed to get through to compuserve but not
to ohio-state! Did they flush your account?? --KLH
------------------------------------------------
Date: Tue, 21 Mar 89 21:14:02 PST
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: KLH@SRI-NIC.ARPA
Subject: Message of 21-Mar-89 13:32:27
Message failed for the following:
hbj@cis.ohio-state.edu.#Internet: 550 <hbj@cis.ohio-state.edu>... User unknown
------------
Date: Tue, 21 Mar 89 13:32:26 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC development
To: hbj@cis.ohio-state.edu
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903211918.AA22636@tut.cis.ohio-state.edu>
Message-ID: <12479862545.28.KLH@SRI-NIC.ARPA>
Just got your question about development cost estimate. I'm not sure
whether you sent it before you received my questions or not; it would
help to know the answers before I put a real estimate together. I
assume you'll want a standard consultant (a) cost-per-day $, plus (b)
estimated # days, to accomplish specific things. Roughly how detailed
a breakdown do you want? Say, 4 subtasks?
As far as OS peculiarities go, it is a little disconcerting not to
have a command prompt of some kind, and FINE's default key bindings
are different enough from EMACS that I finally had to print out
FINE.DOC. I'd mostly be concerned about UUO level differences,
however, and for that I'd need to see an uptodate monitor manual
before I could say anything.
I could start work anytime since this would be independent of my real
work, and I can use some vacation time to get over the tough spots.
If you missed my previous msg (re T20 & multi-section), I'll re-send.
--Ken
-------
-------
-------
22-Mar-89 12:12:59-PST,625;001000000001
Return-Path: <joaquin@sri-nic.arpa>
Received: from bear.nisc.sri.com by SRI-NIC.ARPA with TCP; Wed, 22 Mar 89 12:12:49 PST
Received: from localhost by bear.nisc.sri.com (3.2/SMI-3.2-LIM.5)
id AA01900; Wed, 22 Mar 89 12:12:43 PST
Message-Id: <8903222012.AA01900@bear.nisc.sri.com>
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Cc: camph@kl.sri.com, kuo@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA, joaquin
Subject: Re: KCC proposal
In-Reply-To: Your message of Wed, 22 Mar 89 11:55:03 -0800.
<12480106961.28.KLH@SRI-NIC.ARPA>
Date: Wed, 22 Mar 89 12:12:41 PST
From: joaquin@sri-nic.arpa
Its fine with me.
JJ
22-Mar-89 13:01:13-PST,579;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 22 Mar 89 12:56:59 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA21734; Wed, 22 Mar 89 15:57:02 EST
Date: Wed, 22 Mar 89 15:57:02 EST
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903222057.AA21734@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Re: Re-trying failed message
I noticed that I got the message on CompuServe but not on the Ohio
State machine. My account is still working though. Don't know what
happened.
22-Mar-89 13:03:49-PST,480;001000000001
Mail-From: KLH created at 22-Mar-89 13:03:27
Date: Wed, 22 Mar 89 13:03:26 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Re-trying failed message
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA, BEN@cis.compuserve.com
In-Reply-To: <8903222057.AA21734@tut.cis.ohio-state.edu>
Message-ID: <12480119408.28.KLH@SRI-NIC.ARPA>
OK, I'm putting together a longer message in response to your recent ones.
I'll keep sending to both addresses just in case.
-------
22-Mar-89 13:59:46-PST,5809;001000000001
Mail-From: KLH created at 22-Mar-89 13:59:18
Date: Wed, 22 Mar 89 13:59:17 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC prop comments
To: BEN@csi.compuserve.com
cc: hbj@cis.ohio-state.edu, KLH@SRI-NIC.ARPA
Message-ID: <12480129576.28.KLH@SRI-NIC.ARPA>
Hi...
Thanks for your answers. Here's a hodgepodge of comments and stuff.
Not having to deal with extended addressing certainly simplifies some
things. It will also permit some tweaks to the code generation, which
currently is forced to produce code that can run either extended or
non-extended, using regular byte pointers or OWGBPs, and so on. No
problem there!
... We've been
burned on a previous endeavor for getting C for the 10s and
we might be overly cautious here.
Hmm, just out of curiousity, what happened? I know of only 3 other C
implementations for the PDP-10. One is PCC-20 from Utah, based on AT&T PCC
(thus restricted to very wealthy or educational institutions); the other is
something called "Sargasso C" (I think), which I've never actually
seen but was told about by some people at NIS (Nat'l Info Systems,
they sell a DBMS called Accent-R), who tried it and punted in favor of KCC.
There is (was?) another offshot of KCC from New Mexico Tech with some
philosophical differences, but I think they lost their 20 and I
haven't heard anything since.
<various ideas for resource access>
Let's try to look at it this way. What's the cost and time if
you were to do it on your machines vs the cost and time of doing
it using our equipment. Let me run that by the folks upstairs.
Rather than try to figure this out, I'm working on having SRI agree to
provide all of the facility support. I've put together a pretty
convincing rationale and so far it's gone up the chain without
problems. I'll let you know as soon as I get official approval. The
result of this would be optimal resources for no cost to you. I don't
know how anything could beat that.
Although Ohio State speaks fairly well of KCC, I've been advised
to visit them and get a copy of the compiler, and look at it from
an implemenation standpoint. Prudence, I suppose.
Good idea, and that would save you the time/$ of getting a tape from
SRI. If you want to check with other people, two that come to mind
are (1) Peter Samson @ Systems Concepts (obvious) and (2) Nelson H.F.
Beebe at Utah, I don't know his phone # but his Internet address is
<Beebe@SCIENCE.UTAH.EDU>. Nelson has a numerical analysis background
and has a very impressive range of knowledge about C portability and
performance on his various machines and compilers. For example, they
use both PCC-20 and KCC on their 20. He also tried the New Mexico
variant at one time.
I'm in CompuServe's electronic mail system, InfoPlex, now.
I'm somewhat more comfortable here than on the Ohio State
machine, but I think the interface to Internet isn't
quite as reliable. However, your carbon copies are showing
up over here, so that's encouraging. Here's hoping you
get this message.
Got it!
... I've tried to convey
to him that you seem to have a personal interest in main-
taining the integral quality of the compiler. I've also
pointed out that having you do the work, would probably
result in a finished product substantially sooner than if
I or one of my minions do it.
Yes, you've summarized my thinking exactly.
.... But then, if you were to do the job
on the SRI machines (even the ANSI upgrade), and we were to then
"buy" the product from you, it would be a capital expense and
we could write it off. If you were to do the work on our machines,
it might appear you're working as a consultant and then it wouldn't
be a capital expense. I don't think this is a big deal with us,
Well, I'm certainly open to whatever arrangement is most reasonable. For
example, which of the following would be best for you?
1. Hourly rate - we agree to a rate, I keep you posted on actual
hours worked, payment on regular basis.
2. Daily rate - ditto, except in units of days.
3. Fixed cost - we agree on what is to be delivered and how much it
should cost, before starting. Perhaps partial advance payment.
4. Product purchase - we agree on approx final cost, I do work, then
you "buy" it (perhaps with adjustments depending on how much
effort was actually used).
I don't know which of these (or combo thereof) your internal
accounting would favor, but any is probably okay with me. Obviously
the first two are safest for me and riskiest for you, vice versa for
the latter two. For #3 (fixed cost) I'd probably want to play it safe
and make a higher quote than I think is really necessary (we all know
how notoriously hard it is to estimate software effort). Your mention
of #4 ("buying" a product, as capital expense) is interesting, because
it might make it easier for people to accept one of my conditions,
which is that I want to be able to keep the copyright to the resulting
work, so I can continue to distribute the upgraded KCC for universal
benefit.
Of course there's the risk that after I do it, Compuserve will have
changed its mind. And one advantage of having a consulting agreement
instead is that it's easier to reactivate it should any further work
be needed (bug fixing, extra features, or the like); I have always
responded to bug reports as soon as I could get around to them, but
without official sanction they sometimes get lower priority.
I'm sure we can get a workable agreement with any of those methods, so
I guess the choice will be up to you.
This has gotten a bit long, so I'll send a second message in a while with
my initial task breakdown & estimate.
-------
22-Mar-89 17:42:37-PST,4776;001000000001
Mail-From: KLH created at 22-Mar-89 17:42:31
Date: Wed, 22 Mar 89 17:42:31 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC estimate
To: hbj@cis.ohio-state.edu
cc: BEN@cis.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903212136.AA06521@tut.cis.ohio-state.edu>
Message-ID: <12480170215.20.KLH@SRI-NIC.ARPA>
OK, here's my breakdown for the task of porting a full ANSI C compiler
and environment to TOPS-10. This shouldn't be considered a formal
quote, but it represents my best estimate at this time. I am assuming
the (free) use of SRI facilities, including a SRI-owned TOPS-20.
My overall strategy will be to first do a basic port of KCC to TOPS-10,
followed by the ANSI upgrade and a more complete TOPS-10 port. This
gives us the most flexibility and provides for two possible paths:
Path A: (KLH does everything)
1. Do basic port to TOPS-10, at SRI. 40 hrs
2. Do upgrade to ANSI C, at SRI. 240 hrs
3. Do enhanced port, at SRI. 80 hrs (or 160??)
4. Send tape of complete compiler & library to Compuserve.
5. Do final testing &c on CPS, with 2400(9600?) baud access. 40 hrs (?)
Total KLH time: ~400 hrs (more if port is really extensive)
Path B: (Compuserve helps)
1. KLH does basic port to TOPS-10, at SRI. 40 hrs
2. KLH sends tape to Compuserve.
3. KLH does ANSI upgrade at SRI, while 240 hrs
Compuserve does enhanced port on CPS.
4. Compuserve sends tape to KLH.
5. KLH merges everything, sends tape back to Compuserve. 25 hrs
6. Both do final testing & fixing on CPS. 40 hrs (?)
Total KLH time: ~345 hrs
If Compuserve wants to help, Plan B seems to be the most efficient
way to combine our talents. I'll explain further why this is so.
"KCC" actually encompasses two major components: the C compiler
itself, and its associated C library. The C library has a fairly
well-documented external interface and is composed of many small
modules which are easily separated and debugged, whereas the compiler
is a very large and complex program that requires great care least it
begin producing subtly incorrect code (which, if it gets into the
compiler itself, really makes life interesting). Hence it is much
easier and safer for newcomers to deal with the library than with the
compiler. Furthermore, the TOPS-10 port mostly affects the C library
(about 95%); the ANSI upgrade affects both (about 80% compiler, 20%
library).
By "basic port" is meant the addition of just enough TOPS-10 support
to permit KCC to compile both itself and the library on TOPS-10. This
is not exactly trivial since it involves providing TTY and file I/O
support in the library, plus assembler/linker support in the compiler;
however, it is straightforward. The emphasis here is on conforming to
the existing KCC runtime I/O environment.
The "enhanced port" refers to providing as much TOPS-10 support as
seems reasonable. There are many library routines which are not
needed for KCC to run, but may be needed by user programs. Not all of
them can even be implemented on TOPS-10; some will be a real
challenge, and we'll have to mutually decide whether those particular
capabilities are worth providing. Doing this part may involve the use
of "new" or Compuserve-specific monitor UUOs that I've never heard of,
as well as subtleties of TOPS-10 beyond the basic functions I've used in the
past. I'm certainly eager to learn new things, but if Compuserve
wants to take on some of the effort, this would be the logical place
to do so; it can proceed in parallel with the ANSI upgrade.
Of course, in practice things will not be quite as neat regardless of
which overall plan is used; you may want interim tapes to play with,
I'll have TOPS-10 questions, you'll have C/KCC questions, completely
unforeseen bugs will pop up, the seemingly difficult will actually be
simple, and so on. While I hope the actual time needed will be much
less than what I've estimated, bitter experience has taught me to
play it safe whenever possible.
It seems appropriate to reserve the bottom line for the bottom lines.
I have to admit that, not having done this before, I have no idea what
independent consultants normally charge; SRI itself has a flat rate of
$1000 per day, but the whole point of doing it independently is to cut
this rate down to something reasonable. I'll start by proposing
$60/hour if we do this on a consulting basis. (Be sure to let me know
if you start giggling... :-) If it turns out that you'd rather go
for a fixed price or a "purchase", I'll go out on a large limb and
propose something on the order of $20K to give you a specific target.
Hope this is what you need. I'd be happy to provide any more details
that you want.
--Ken
-------
22-Mar-89 18:20:27-PST,13943;001000000011
Mail-From: KLH created at 22-Mar-89 18:20:18
Date: Wed, 22 Mar 89 18:20:18 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCCDIST:<KCC-5.KCC>SEQNCE.DOC
To: hbj@cis.ohio-state.edu
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903212136.AA06521@tut.cis.ohio-state.edu>
Message-ID: <12480177094.20.KLH@SRI-NIC.ARPA>
I just checked, and noticed that the last read date for this file was
9 March, although you were trying to FTP stuff on 15 March or
thereabouts, so I figure you haven't seen it yet. There are a few
other doc files that are in this directory instead of C: because they
aren't considered of interest to most users.
It occurred to me that if you were trying to evaluate KCC you'd
probably be interested in seeing it, particularly if you come from a
MACRO background and wince when you think about how much pointless
extra cruft a high-level language adds. KCC has its defects (e.g. no
register variables, sigh) but I'm rather pleased with the hacks I came up
with for dealing with pointers.
--Ken
----------------------------------------------------------------------
KCC CODE GENERATION SEQUENCES
There are certain constructs in C that do not correspond to
any direct PDP-10 machine instruction equivalents, and require KCC to
generate a code sequence to implement the construct properly. Since
the most efficient sequence is often a quite subtle and non-obvious
collection of instructions, this file exists to document the sequences
and the reasons why they look like they do. There is no guarantee
that these are optimal, of course; some of them may well be
susceptible to improvement by very clever programmers.
UNSIGNED ARITHMETIC
It is most unfortunate that the PDP-10 does not include any
unsigned arithmetic instructions; they would be easy to do. Anyway,
here is the code generated for all the possible unsigned operations,
where those operations are DIFFERENT from those for signed arithmetic.
Note that all logical and bit-wise operators use exactly the same
code, and because the PDP-10 uses twos-complement arithmetic, the
addition and subtraction instructions also work for both signed and
unsigned ints.
!,^,~,|,& (logical and bit-wise ops) SAME.
+,- (addition & subtraction) SAME (ADD, SUB).
<< (left-shift) SAME (LSH).
==,!= (equality) SAME (CAME/CAIE, CAMN/CAIN).
/,% (divide,remainder) DIFFERENT: see next page (very hairy).
Casts (cast conversions) DIFFERENT: see int->float and int->double pages
>> (right-shift) DIFFERENT:
Uses LSH instead of (signed) ASH.
<,<=,>,>= (inequality ops) DIFFERENT:
Unsigned CAMx of A,B becomes:
MOVE R,A ; Can optimize if A or B are constants.
TLC R,400000 ; Toggle sign bit
MOVE S,B ; Same thing for other operand, sigh.
TLC S,400000
CAMx R,S ; Now can compare.
* (multiply) DIFFERENT:
Unsigned MUL of A,B becomes:
MOVE R,A ; R is a double-word register pair
MUL R,B ; Do long multiply
TRNE R,1 ; Check low bit in high-order word of result.
TLOA R+1,400000 ; Copy it into high bit of low word.
TLZ R+1,400000 ; Whether 1 or 0.
<result in R+1>
Alternative sequences, which take less space but are
slower (MUCH slower on non-KLs):
MUL R,B or MUL R,B
LSH R+1,1 LSH R+1,1
LSHC R,-1 LSHC R,-35.
result in R+1 result in R
UNSIGNED ARITHMETIC - INTEGER DIVISION:
This is the hairiest unsigned operation, particularly when
the divisor has its high bit set; for that case we currently do the
division by hand. The other cases are more amenable but still need
to be distinguished.
Dividend / Divisor
Case 1: + / +
Case 2: - / +
Case 3: + / -
Case 4: - / -
What KCC currently outputs for the pseudo-instruction P_UIDIV, which
leaves its quotient in RQ and the remainder in RQ+1:
UIDIV RQ,MEM: /* RR = RQ+1 */
SKIPGE 16,MEM ; Get mem ref first before clobbering RQ or RR!
JRST $1 ; Negative divisor (case 3 or 4)
JUMPGE RQ,$3 ; If both operands positive, just do IDIV!
; Case 2: Negative dividend, positive divisor
CAIG 16,1 ; Dividend negative. Is divisor 2 or greater?
JRST $2 ; No, is 1 or 0, must special-case this as
; result must still have high bit set!
MOVE RR,RQ ; Set up dividend
MOVEI RQ,1 ; High bit copied into high-order word.
DIV RQ,16
JRST $4 ; Done.
; Case 3&4: Negative (very large) divisor. Manual division.
$1: MOVE RR,RQ
MOVEI RQ,0
JUMPGE RR,$4 ; All done if case 3 (positive dividend)
CAMGE RR,16 ; Case 4: both neg, compare.
JRST $4 ; Divisor is greater, result is <0 ? dvdend>
SUB RR,16 ; Dividend is >=, divide once!
AOJA RQ,$4 ; Result is <1 ? dvdend-divisor>
$2: TDZA RR,RR ; Divisor is 1 or 0, just clear remainder
$3: IDIV MQ,16 ; Both operands positive, normal IDIV!
$4:
Note that when the divisor is a constant, KCC attempts to use this information
to output a much smaller code sequence (the appropriate subset of the above
full-fledged sequence). The only really odd variant is for divisors that
are a power of 2, in which case KCC outputs an LSHC and LSH instruction
to shift the dividend properly.
Other alternatives that came up:
(1) CAIL MQ,0
SKIPGE MQ+1,MEM
PUSHJ P,$UIDIV ; Some kind of grossness
IDIV MQ,MQ+1
(2) Convert to double float, then DFDV, then back to uint???
Gross, gross, gross!
(3) KL-10s could use DDIV, but requires 4 sequential ACs!
(4) Code from Peter Samson at Systems Concepts:
(not used directly as MEM ref can conflict with AC refs)
; Reg MQ/
; Reg AC=MQ+1/ dividend
; Addr MEM/ divisor
SKIPGE MQ,MEM
JRST $1
SOJN MQ,$2
EXCH AC,MQ
JRST $3
$1: MOVEI MQ,0
JUMPGE AC,$3
CAMGE AC,MEM
JRST $3
SUB AC,MEM
AOJA MQ,$3
$2: TLNN AC,400000
TDZA MQ,MQ
MOVEI MQ,1
DIV MQ,MEM
$3:
; MQ/ quotient
; AC/ remainder
"if the compiler knows in a given case that the divisor doesn't have
the sign bit on, and that the divisor isn't 1, it need only compile
the four instructions starting at $2. Since divisors are frequently
constants, this simplification should help in a lot of cases."
POINTER ARITHMETIC - COMPARISON:
For == and != the CAME and CAMN instructions can be used just
as for integer comparison. For relative inequalities a few more instructions
are necessary. These will work for any size byte pointer, subject to
the following constraints:
(1) the pointers must have the same bytesize.
(2) Neither pointer may be NULL (C leaves the result undefined).
(3) Local-fmt BPs cannot have a P (position) field of 40-44 inclusive.
General case (works for both 0-section and N-section)
This is what KCC outputs when the code must run in either context.
In fact, this is what is always output anyway.
SKIPL R,A ; Fetch A, test sign bit.
TLC R,770000 ; If OWGBP, invert P&S bits.
ROT R,6 ; Get byte position into low-order bits.
SKIPL S,B ; Repeat for B.
TLC S,770000
ROT S,6
CAMx R,S ; Now can compare.
If the code will never run multi-section (no OWGBPs) then this will work,
for all values of P. KCC does not currently test for or output this.
MOVE R,A
MOVE R+1,B ; Set up A and B close together
ROTC R,6 ; Rotate both at once, swapping P fields!
CAMx R,R+1 ; Then compare.
If the code is multi-section only (just OWGBPs) then this can be used.
KCC does not currently test for or output this.
MOVE R,A
ROT R,6 ; Must get and shift each operand separately.
MOVE S,B
ROT S,6
CAMx R,S
POINTER ARITHMETIC - ADDITION/SUBTRACTION:
Addition is done with ADJBP and so works with any size byte.
For KA-10s there is an ADJBP simulation routine which likewise works
for any bytesize. It is not efficient, but then it is unlikely to be
needed nowadays.
Subtraction is much trickier. There are four possible situations
depending on whether the format (OWGBP or local) and byte size are known
or unknown.
Known format/size Unknown format/size
SKIPL 16,A
LSH 16,6
LSH 16,-30. ; Get size or PS
SUB A,B SUB A,B
MULI A,bpw<<bits MUL A,$BPMUL(16) ; 64-wd table
LSH A+1,-bits LSH A+1,@$BPLSH(16) ; 64-wd table
ADD A,$BPADD(16) ; 64-wd table
ADD A+1,<table>(A) ADD A+1,(A)
Unknown format/Known size Known format/unknown size
LDB 16,[$$BPSZ,,A] ; get PS from A
SUB A,B SUB A,B
MULI A,$$BPMn MUL A,$BPMUL(16)
LSH A+1,$$BSHF LSH A+1,$$BSHF
ADD A,$BPTAB(16)
ADD A+1,$BPTBn(A) ADD A+1,(A)
Currently KCC implements the latter two. The unknown-size algorithm is
used except in such cases (such as subtracting a pointer constant) where
the byte size is definitely known. Byte sizes 6, 7, 8, 9, and 18 are
supported, but no others. The actual values of the symbols used will
vary depending on whether the program is loaded for 0-section or N-section
operation.
The program PARITH.C, found in the KCC source directory, is
used to test various algorithms for pointer subtraction, and to
compute the values in the various magic tables.
POINTER ARITHMETIC - CAST CONVERSIONS:
These are a bit tricky since in some cases the actual instruction
that results is not known until load time. We defer this by assembling
special symbol references which are defined one way by the 0-section
runtime, and a different way by the N-section runtime; resolving those
references at load time thus produces either 0-section or N-section code
sequences. Naturally both forms for an operation must occupy the same
number of words! (Hence the JFCLs in some cases.)
Conversion of a byte pointer (any kind) to a word pointer is done with:
TLZ R,$$BPPS ; 770000 if multi-section, -1 if 0-section.
Conversion of a word pointer to a byte pointer is done with:
TLO R,$$BPmn
where m = byte size, and n = byte position. These symbols are set
appropriately for the section being loaded into.
Conversion of an 18-bit to 9-bit pointer:
Local Extended
TLZE R,007700 TLZA R,050000
TLO R,111100 JFCL
Conversion of a 9-bit to an 18-bit pointer:
Local Extended
TLZE R,117700 TLZ R,010000
TLOA R,002200 TLON R,060000
JFCL TLC R,030000
Naturally, the JFCLs could be eliminated if it was known at compile time
which section the code would run in.
Casts from other byte pointers to other byte pointers are done by
first converting to a word pointer and then to a byte pointer; no attempt
is made to preserve alignment in those cases.
STRUCTURE COPYING
The code sequence constructed depends on the size of the structure
(number of words) and whether the section number is known at compile time;
that is, whether KCC knows the result will run only in section 0, or section
N, or (as is normal) must be capable of running in either.
** P_SMOVE reg,addr+offset(idx) [plus Pbsize set to # words]
** reg = register containing destination word address
** addr+offset(idx) = source address
** Pbsize = # words to copy
If there are 3 words or less, this sequence is used:
XMOVEI 16,-1(R) ; Get destination address
PUSH 16,address ; Copy source words there.
PUSH 16,address+1
...
If there are 4 or more, and we know we will be 0-section:
MOVEI 16,(R) ; Get dest address
HRLI 16,address ; Make <source>,,<dest>
BLT 16,size-1(16) ; Use BLT to copy words!
If there are 4-10 inclusive, and we know we will be N-section:
<simple PUSHes as before>
If there are more than 10, known N-section:
PUSH P,14
PUSH P,15
MOVEI 14,size ; XBLT arg 1: <# words>
XMOVEI 15,address ; XBLT arg 2: <source>
XMOVEI 16,(R) ; XBLT arg 3: <dest>
EXTEND 14,[XBLT]
POP P,15
POP P,14
A combination of these is normally put together for the general case
(either 0-section or N-section) using JUMPGE 17, tests to jump if
multi-section or not. The resulting pastiches are not beautiful, but
they work as efficiently as possible.
FLOAT <-> INT CAST CONVERSIONS:
Casts from (float) to and from (int) are normally done using
the FIX and FLTR instructions.
(float)->(int):
FIX R,R ; For both signed and unsigned int.
(int)->(float):
Signed int Unsigned int (note R is a register pair!)
FLTR R,R LSHC R,-1 ; Shift sign bit down
FLTR R,R ; Float the shifted value
FSC R,1 ; Float-shift back up
CAIGE R+1,0 ; If low bit was lost,
FADRI R,(1.0) ; add it back.
NOTE: For the KA-10, which does not have FIX or FLTR, simulations of
these are used.
FIX simulation (R is a register pair!):
MUL R,0400 ; Get exponent in R, rest in R+1 */
TSC R,R ; If negative, make positive exponent */
ASH R+1,-243(R) ; Shift "rest" by right amount */
<result in R+1>
FLTR simulation:
FSC R,233
FSC has the disadvantage of losing high-order bits if attempting to
float an integer which has more than 27 significant bits, but there
doesn't seem to be any good alternative.
DOUBLE <-> INT CAST CONVERSIONS:
There are no instructions however for casting integers to double
precision floating point, so a code sequence must be used:
(int)->(double):
Signed int Unsigned int
ASHC R,-8 LSHC R,-9 ; Get integer into low word
LSH R+1,-1
TLC R,243000 TLC R,244000 ; Set proper exponent
DFAD R,[0 ? 0] DFAD R,[0 ? 0] ; Normalize the result
double->int:
; The internal pseudo-instruction P_DFIX R,M expands into:
DMOVE R,M
HLRE 16,R ;This mattered when shifts were bit-at-a-time
ASH 16,-11 ;Get just exponent (9 bits)
JUMPGE 16,.+3 ;Positive?
DMOVN R,R ;No, negate, orig sign still in 1B0[A]
; For KA-10 format this is DFN R,R+1.
TRC 16,777777 ;Watch for diff between twos and ones comp
TLZ R,777000 ;Bash exponent and sign ... now positive
; For KA-10 format, LSH R+1,10 goes here.
ASHC R,-233(16) ;Make an integer (may overflow)
CAIGE 16, ;Original negative? Check its sign.
MOVN R,R ;Yup, negate result.
-------
24-Mar-89 11:38:43-PST,2630;001000000001
Mail-From: KLH created at 24-Mar-89 11:38:30
Date: Fri, 24 Mar 89 11:38:30 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Biog stuff
To: hbj@cis.ohio-state.edu
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <12480177094.20.KLH@SRI-NIC.ARPA>
Message-ID: <12480628236.47.KLH@SRI-NIC.ARPA>
I thought this might be useful. Normally any SRI proposal includes biogs
of the people involved, to help the client evaluate things. We're not
dealing with a SRI prop here of course, but the principle seems sound. So,
in case you or your mgt can use it, here's mine. Keep or toss.
------------------------------
KENNETH L. HARRENSTIEN
Senior Computer Scientist
Network Information Systems Center
Computer and Information Sciences Division
SPECIALIZED PROFESSIONAL COMPETENCE
C language (portability, implementation, standardization); database
management systems; computer message systems; network protocols and
communication standards; terminal software support; text processing;
electronic document production, deaf telecommunications.
REPRESENTATIVE RESEARCH AT SRI (since 1976)
DDN-NIC (Network Information Center) - Software architect for all
aspects of NIC services, including DBMS, network servers, data
retrieval and processing.
KCC C - Provided a full implementation of C for TOPS-20. Member of
the ANSI X3J11 committee to standardize the C language.
MIT TCP/IP - Designed and implemented TCP, UDP, IP for the MIT ITS
PDP-10 systems.
DEAFNET project - Research in computer telecommunications for the
deaf, including configuration, installation, maintenance of
on-site & off-site systems, creation of Unix-based message system
and simplified user interfaces.
DN-IM - Specified and developed the Deafnet "Intelligent Modem"
(Baudot/ASCII compatible) for use by local communities during the
Deafnet dissemination project.
UNIX systems programming - kernel overlays; device drivers for
disks, terminals, network interfaces; file system mods.
ELLE - Created a widely portable UNIX-based display text editor.
NLS (AUGMENT/L10) systems programming - data handling and document
formatting programs for Network Information Center (NIC),
design/implementation of ARPANET identification system database
and programs.
PREVIOUS PROFESSIONAL EXPERIENCE
Systems programming at MIT A.I. Laboratory; design and implementation
of ITS COMSAT message system, user data base, real-time graphics,
network servers.
ACADEMIC BACKGROUND
B.S. Computer Science (1976), Massachusetts Institute of Technology.
HONORS
Eta Kappa Nu, Sigma Xi
-------
25-Mar-89 08:41:22-PST,1642;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sat, 25 Mar 89 08:41:14 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA17422; Sat, 25 Mar 89 11:41:27 EST
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA05352; 25 Mar 89 11:33:16 EST (Sat)
Received: by loquat.cis.ohio-state.edu (smail2.5)
id AA09448; 25 Mar 89 11:34:17 EST (Sat)
Date: 24 Mar 89 16:34:42 EST
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC
Message-Id: <"CSI 5541-9767"@CompuServe.COM>
to: Ken Harrenstein
fr: Benny Jones
Thanks for the breakdown of tasks and cost estimate. It's
probably desirable for CompuServe to help in some way
although based on your estimate such help would not decrease
the cost very much. Maybe we could play that by ear for
now.
You estimated 40 hours to do the port to TOPS-10. That
sounds pretty reasonable to me. At $60/hour that gives us
a TOPS-10 C compiler for around $2400. The person who holds
the pursetrings is on vacation until next Wednesday, but
the general concensus is that he'll accept this. We'd probably
like this as soon as we can get it. I'll get back to you
Wednesday or Thursday with a more definite yes or no.
The 240 hours at $60/hour represents an expense that we'd like
to look at more closely. Could we simply get the TOPS-10 port
and then assess our options?
Questions:
Does / will the compiler generate two-segment code? A lot of
our programs use the pure high segment and volatile low segment.
Sources are included with everything aren't they?
25-Mar-89 14:47:23-PST,1874;001000000001
Mail-From: KLH created at 25-Mar-89 14:47:22
Date: Sat, 25 Mar 89 14:47:22 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5541-9767"@CompuServe.COM>
Message-ID: <12480924762.47.KLH@SRI-NIC.ARPA>
Does / will the compiler generate two-segment code? A lot of
our programs use the pure high segment and volatile low segment.
Yes, everything is two-segment.
Sources are included with everything aren't they?
Yes, absolutely.
The 240 hours at $60/hour represents an expense that we'd like
to look at more closely. Could we simply get the TOPS-10 port
and then assess our options?
Well, yes. That is one other reason for doing a basic T-10 port
first. It might make things a bit sticky for me if the ANSI upgrade
were completely dropped, however, because I've been selling SRI on
that part of the work, as a package deal -- they don't need the
TOPS-10 port. Partial support would still be better than nothing.
... It's
probably desirable for CompuServe to help in some way
although based on your estimate such help would not decrease
the cost very much. Maybe we could play that by ear for
now.
It would still help some, and perhaps more importantly, would allow
your people to become familiar enough with the T-10 code portions to
quickly fix any bugs in them that surface later. You may be the only
people to ever use that code (I've had other queries in the past about
a T-10 version of KCC, but nobody was willing to help, and I assume
they're gone now).
Playing it by ear is fine. I think this only makes a difference if you
are thinking about buying a "product" in a lump sum. But then, I guess
you can always buy different pieces at different times. Whatever.
Will be waiting to hear from you...
--Ken
-------
29-Mar-89 08:49:44-PST,1521;001000000015
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 29 Mar 89 08:49:30 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA01339; Wed, 29 Mar 89 11:49:10 EST
Date: Wed, 29 Mar 89 11:49:10 EST
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903291649.AA01339@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC work
Cc: BEN@csi.compuserve.com
Ken, hello. We've been given a green light for the port of
KCC to TOPS-10. We will probably opt for the ANSI upgrade as
well. That's it in a nutshell.
The detail stuff. We will put together a contract describing
what we are after. It will probably be a two part deal. Part
A being the port to TOPS-10 to the extent that we can run it
on our systems. We'll probably ask that the compiler meet some
criteria (I'm not sure what yet). Part B is the ANSI upgrade.
Work on part B is contingent on acceptance by us of part A. And
the contract will probably state (in some fashion) what is
meant by ANSI. Do you have any ideas as to how this might be
treated?
I set about having the contract drawn up right away, but it'll
probably be some days before it's done. I'll run a draft by you,
of course.
We are looking forward to this relationship, and we appreciate
the opportunity you are providing us for getting an ANSI C compiler
on our mainframes.
Please let me know of any questions and concerns. Thanks.
-- Benny Jones
29-Mar-89 12:43:44-PST,2233;001000000001
Mail-From: KLH created at 29-Mar-89 12:43:31
Date: Wed, 29 Mar 89 12:43:30 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: [H Benny Jones <hbj@cis.ohio-state.edu>: KCC work]
To: joaquin@SRI-NIC.ARPA, kuo@SRI-NIC.ARPA, camph@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12481950789.27.KLH@SRI-NIC.ARPA>
Latest news. Sounds like it will happen, after all. I know this isn't a
SRI project, but I'll keep you posted anyway. Do you suppose there might be
some kind of follow-up angle where Compuserve could eventually use SRI for
some other work? If so, how to manuever into position? (I'll be sure to
try and impress them in the meantime... :-)
---------------
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 29 Mar 89 08:49:30 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA01339; Wed, 29 Mar 89 11:49:10 EST
Date: Wed, 29 Mar 89 11:49:10 EST
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903291649.AA01339@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC work
Cc: BEN@csi.compuserve.com
Ken, hello. We've been given a green light for the port of
KCC to TOPS-10. We will probably opt for the ANSI upgrade as
well. That's it in a nutshell.
The detail stuff. We will put together a contract describing
what we are after. It will probably be a two part deal. Part
A being the port to TOPS-10 to the extent that we can run it
on our systems. We'll probably ask that the compiler meet some
criteria (I'm not sure what yet). Part B is the ANSI upgrade.
Work on part B is contingent on acceptance by us of part A. And
the contract will probably state (in some fashion) what is
meant by ANSI. Do you have any ideas as to how this might be
treated?
I set about having the contract drawn up right away, but it'll
probably be some days before it's done. I'll run a draft by you,
of course.
We are looking forward to this relationship, and we appreciate
the opportunity you are providing us for getting an ANSI C compiler
on our mainframes.
Please let me know of any questions and concerns. Thanks.
-- Benny Jones
-------
29-Mar-89 13:29:00-PST,811;001000000001
Return-Path: <joaquin@Sri-Nic.Arpa>
Received: from bear.NISC.sri.com by SRI-NIC.ARPA with TCP; Wed, 29 Mar 89 13:28:58 PST
Received: from localhost by bear.NISC.sri.com (4.0/SMI-4.0/LIM.1.3)
id AA02058; Wed, 29 Mar 89 13:29:06 PST
Message-Id: <8903292129.AA02058@bear.NISC.sri.com>
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: [H Benny Jones <hbj@cis.ohio-state.edu>: KCC work]
In-Reply-To: Your message of Wed, 29 Mar 89 12:43:30 -0800.
<12481950789.27.KLH@SRI-NIC.ARPA>
Date: Wed, 29 Mar 89 13:28:59 PST
From: joaquin@Sri-Nic.Arpa
Great!.....I guess any area dealing with user-oriented services and
software development could be of interest for nisc involvement. You
will know better than anyone if theer is a potential market when you
interact with them more.
JJ
29-Mar-89 13:41:19-PST,3952;001000000001
Mail-From: KLH created at 29-Mar-89 13:40:29
Date: Wed, 29 Mar 89 13:40:28 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC work
To: hbj@cis.ohio-state.edu
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903291649.AA01339@tut.cis.ohio-state.edu>
Message-ID: <12481961159.27.KLH@SRI-NIC.ARPA>
Great! I'll start lining up my schedule...
The detail stuff. We will put together a contract describing
what we are after. It will probably be a two part deal. Part
A being the port to TOPS-10 to the extent that we can run it
on our systems. We'll probably ask that the compiler meet some
criteria (I'm not sure what yet).
That's OK. I might have to revise my estimate depending on what your
criteria are. Remember, when I talked about the "basic port" I meant
just enough that KCC could compile and build itself and the C library.
If Part A is to include some of the "extended port" as well, you'll need
to somehow specify the degree of functionality you want. For this, the
doc files (LIBC.DOC, USYS.DOC, etc) should be handy, since you can see
exactly what functions are currently furnished and what their port status is.
Part B is the ANSI upgrade.
Work on part B is contingent on acceptance by us of part A. And
the contract will probably state (in some fashion) what is
meant by ANSI. Do you have any ideas as to how this might be
treated?
You mean, if the port actually does work? That sounds sensible. As
for what ANSI means... well, the most recent draft standard is the
December 7, 1988 version, but I am not sure if that is publicly
available yet from their standard distributor (Global Eng. Documents).
At this point there are no plans to change this draft, but it will
probably take ANSI some more time to chew it over before it becomes an
official standard. If you already have a previous draft copy, try to
get a more recent one. If that doesn't work, I could have mine copied
-- it's about 330 pages.
While this draft is pretty specific about how a conforming C compiler
should behave, there are, of course, many places in the standard where
the behavior is "undefined" or "implementation defined". We should
probably have a clause to the effect that what KCC should do in such
cases will be determined by mutual agreement, with the understanding that
this may impact the amount of effort required (i.e. if the way KCC currently
does it isn't suitable). As one example, what floating-point format
do you want the "long double" type to correspond to? (Don't answer now, just
using that as an example!)
Please let me know of any questions and concerns. Thanks.
Let's see, I have just a couple to start with.
One concern is that it be understood in the contract that the
resulting code doesn't belong to Compuserve; I want to keep the
copyright. The AGREE.TXT file tries to explain my thinking here
(similar to what FSF does for its GNU software). You are of course
free to use it on as many machines as you wish, give copies away,
charge users for time spent maintaining/debugging, and so on. Sorry
to belabor something I already mentioned before, just being careful.
The main questions I have right now pertain to the target of the port.
As I mentioned, my TOPS-10 documentation is probably a bit out of date,
although I'd be surprised if the basic monitor calls changed much. What
standard DEC monitor release do your systems most closely correspond to?
The doc I have is for release 5.05. I can probably rustle up some more
recent stuff, but need to know what I'm looking for. Do you maintain any
on-line doc on CPS, akin to Unix man pages?
Do your machines implement all the non-KA/KI user-mode KL instructions,
e.g. ADJSP, ADJBP, and EXTEND string instrs?
That's it for now... I'm sure there will be a lot more later! I'm looking
forward to this, it should be fun.
--Ken
-------
30-Mar-89 08:43:02-PST,852;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 30 Mar 89 08:42:05 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA16861; Thu, 30 Mar 89 11:40:36 EST
Date: Thu, 30 Mar 89 11:40:36 EST
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903301640.AA16861@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC
Cc: ben@csi.compuserve.com
Ken -- With respect to keeping the copyright to the code, I have a
question or concern. Since we use a variant of TOPS-10 and may make
changes to monitor calls, are we allowed to change the source code
to suit our needs? What restrictions are we looking at? I guess,
I'd like a better understanding of what having you keep the copyright
to the code means in terms of what we can or cannot do with it. Thanks!
30-Mar-89 13:51:19-PST,6451;001000000001
Mail-From: KLH created at 30-Mar-89 13:48:19
Date: Thu, 30 Mar 89 13:48:19 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903301640.AA16861@tut.cis.ohio-state.edu>
Message-ID: <12482224732.33.KLH@SRI-NIC.ARPA>
Well, the feeling behind this copyright business is simple, but it can
be hard to put into "legal" words. The GNU Emacs licensing agreement
that Stallman's Free Software Foundation uses is a good example of how
baroque the expression of this feeling can get.
The reason why I brought this up is because when a programmer writes
software for hire and there are no explicit provisions otherwise, by
default the resulting work (and copyright thereof) belongs to the
employer, not the author. This of course can be avoided simply by
prior agreement, and that's what I have in mind.
My retaining the copyright just means that I can ensure that the
existing KCC policies are continued. This policy is what allows you
(and anyone else) to get the compiler, sources and all, essentially
for free. If you wish to enhance the compiler or existing library
routines to make it more suitable for your purposes, that is fine with
me, but I also expect that you will make these changes available in
return so I can make them part of the standard distribution. This
doesn't apply to any separate private applications libraries you may
write or acquire, of course. You can charge for using KCC on your systems,
but you can't sell copies (you can give them away, however).
Just on the off chance you haven't already seen the KCCDIST:AGREE.TXT
file, I'll include it in this message. If you still have questions,
please keep firing away!
--Ken
-------------------------------------------
KCC DISTRIBUTION POLICY
This file describes the general KCC distribution policy --
licensing, restrictions, and that sort of thing. If you're not sure
how it applies to your particular situation, just get in touch.
First, note that the files are copyrighted. However, we
consider them "quasi-public" and distribute them freely; the problem
is that sometimes true public-domain stuff is acquired by private
parties and modified slightly to produce a licensed, costly product.
We wish to prevent this by keeping the sources available to everyone
who wants to use KCC, but unavailable to those who have ideas of
selling it; hence the copyright. This applies to all modifications as
well.
Second, since the software is provided free of charge, there
is absolutely NO WARRANTY on anything in this distribution, nor any
obligation to provide maintenance, and all of the usual software
disclaimers apply to everything. If we were to be held responsible
for any problems, we could not distribute KCC at all.
The situation with respect to including KCC as a component of
commercial software packages is fuzzy. Our current inclination is to
allow this as a convenience to the ultimate end users, provided they
are given ALL of the distribution, including sources and this notice.
However, certain cirumstances may force re-assessment of this
position; e.g. extensive modifications, huge numbers of users,
time-consuming maintenance requirements... people with such
applications in mind should contact us.
People may be tempted to modify and "improve" the software.
This is natural and to some extent desirable, but can quickly lead to
chaos without some rules governing these additions and modifications.
So we simply state that the use of KCC automatically implies agreement
with the following policies:
General:
1. KCC is maintained as a primary software tool for SRI-NIC,
and ensuring that it remains reliable and useful for this purpose must
necessarily have our highest priority.
2. Next most important is conformance to the C language
defined by Harbison and Steele, plus the forthcoming ANSI C standard
(currently a X3J11 committee draft). This includes library functions.
3. Software portability, particularly to 4.3BSD-type UN*X,
is slightly more important than TOPS-20 efficiency.
4. Licensed UN*X software sources will never be used or
distributed, and such contributions cannot be accepted.
People making changes to KCC or the library should:
1. Retain the copyright notice for each module, and add a
history notice comment describing the change.
2. Relay your improvements to the maintainers of the canonical
version, so that they can be incorporated into new releases!
Otherwise both you and the rest of the world will lose.
3. Realize that your changes may not be adopted exactly as
provided, if they conflict with one of the general policies. New
library functions are particularly prone to this problem. As a
solution we will probably collect such things into a separate library
or two (e.g. for TOPS-20 specific functions).
Finally:
If at all possible, ask people who want copies of KCC to
get it from the canonical source. If you must give
them a copy, keep all of the original distribution
intact in some form so that the baseline is constant.
KCC is still under active development, and new releases (with
all accumulated bug fixes, improvements, or new features) can be
expected frequently. At all times there will exist only one canonical
version of the software, from which all distributions are made. If
you can make an Internet FTP connection to SRI-NIC.ARPA, you can
retrieve it whenever you wish.
Canonical version: KCCDIST: directory on SRI-NIC.ARPA
Maintainer mailbox: <BUG-KCC@SRI-NIC.ARPA>
Information list: <INFO-KCC@SRI-NIC.ARPA>
(to get on:) <INFO-KCC-REQUEST@SRI-NIC.ARPA>
BUG-KCC is for bug and problem reports and is sometimes used for
discussion of esoteric internal issues. INFO-KCC members basically
receive announcements of new releases and developments, and every site
which has installed KCC should have at least one representative on
that list. If enough users express interest, a user discussion group
could also be started (probably this would deal with C on TOPS-20 in
general rather than just KCC).
Good luck! Feel free to contact me about any problems or questions
you have.
Ken Harrenstien Internet: <KLH@SRI-NIC.ARPA> Phone: (415) 859-6552
Room EJ200
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
-------
30-Mar-89 16:53:35-PST,1073;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 30 Mar 89 16:51:12 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA07609; Thu, 30 Mar 89 19:50:07 EST
Date: Thu, 30 Mar 89 19:50:07 EST
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903310050.AA07609@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Sponsored CSI account?
Cc: ben@csi.compuserve.com
Thanks for the clarification on that copyright business Ken. I don't
believe I had seen the AGREE.TXT document before. And your elaboration
on the subject seems perfectly agreeable as well.
Do you have any interest in having a free CompuServe account? I'll
apply for sponsorship if you like. Besides offering business services,
CompuServe runs something called the CompuServe Information Service.
It's hard to explain, but it might have some purely recreational
benefits. I'll try and send you some literature on it.
I haven't forgotten your other technical questions. I'll get to them
tomorrow I hope.
30-Mar-89 17:07:45-PST,935;001000000001
Mail-From: KLH created at 30-Mar-89 17:07:26
Date: Thu, 30 Mar 89 17:07:25 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Sponsored CSI account?
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903310050.AA07609@tut.cis.ohio-state.edu>
Message-ID: <12482260978.33.KLH@SRI-NIC.ARPA>
Having a CSI account does sound interesting and I'd like to see the
literature, but it might be best to wait for a while before actually
starting anything up. I'd feel guilty if I didn't get some use out of
it, and I'm not likely to have much time for "recreational use" in
the near future. How about waiting until this project is comfortably
winding down?
By the way, while you're catching up on questions, I'm still curious
what the story was with the "other" C implementation you mentioned,
especially if it encountered unexpected technical problems.
Thanks,
--Ken
-------
31-Mar-89 11:16:09-PST,1127;001000000015
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 31 Mar 89 10:59:08 PST
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA18225; Fri, 31 Mar 89 13:59:12 EST
Date: Fri, 31 Mar 89 13:59:12 EST
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8903311859.AA18225@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Our operating system
Cc: ben@csi.compuserve.com
Ken - Our machines implement all the non-KA/KI user mode KL instructions,
e.g. ADJSP, ADJBP, and EXTEND string instructions. It will be safe to
assume the the compiler cannot and will not run on a KI.
The closest DEC monitor release would probably be version 6.03 of TOPS-10.
Let me know if you need a DEC monitor calls manual. The FILOP call is one
that may have some relevance and was not around in release 5.05.
There is some internal documentation. Grab a copy of [525,6]COUGH.USR.
I believe this describes many of our "new" system calls. It's about
200K bytes or so.
That's about it for now. Let me know if there's anything more you need.
Benny
31-Mar-89 15:27:03-PST,1735;001000000001
Mail-From: KLH created at 31-Mar-89 15:26:26
Date: Fri, 31 Mar 89 15:26:26 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC proposal
To: milunovic@kl.sri.com
cc: larson@kl.sri.com, klh@SRI-NIC.ARPA
Message-ID: <12482504736.23.KLH@SRI-NIC.ARPA>
Hi... Frank Kuo, our org director at NISC (685), suggested I contact you
about this.
Basically, I plan to soon start working on an independent project that
may use some KL resources, supported by internal SRI overhead. Frank,
however, is concerned about our org budget and would really like to
eliminate this if possible. Because the results could be beneficial to
KL users, and the "money" never leaves SRI anyway, we'd like to see if
the KL charges for this could be waived or filed under general system
support.
The project is an upgrade of the KCC TOPS-20 C compiler to conform to
the ANSI C standard (I participate on the X3J11 committee and the final
draft has recently been forwarded to ANSI for approval). My estimate
is that it would require about 8 weeks, using 10K disk pages and
roughly 5 to 8 CPU hours per week. I have no problem restricting my
use to off-hours. This would not interfere with the existing KCC
implementation on the KL, although you would be free to install the new
version when it is complete.
We are also negotiating with DCA for permission to use the
government-owned SRI-NIC TOPS-20 for development, although there is no
telling how long this will take, which is my rationale for resorting to
the KL. Of course, if this is eventually approved, KCC work can be
shifted back to the NIC machine.
Does this seem reasonable? I'd be glad to provide more details if you
need any.
Thanks,
--Ken
-------
1-Apr-89 10:23:13-PST,597;001000000001
Mail-From: KLH created at 1-Apr-89 10:23:10
Date: Sat, 1 Apr 89 10:23:10 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New KCC for WAITS?
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12482711673.23.KLH@SRI-NIC.ARPA>
I have embarked on a project to bring up KCC on TOPS-10. Obviously, given
a TOPS-10 port, refining it for WAITS is trivial. If I produced a version
cross-compiled for WAITS, would you be interested in bringing it over
and trying it out?
I will probably have a basic version (ie will compile itself & library) ready
within a week.
-------
2-Apr-89 23:58:33-PDT,354;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Sun, 2 Apr 89 23:58:30 PDT
Message-ID: <sIE4I@SAIL.Stanford.EDU>
Date: 02 Apr 89 2358 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: New KCC for WAITS?
To: KLH@SRI-NIC.ARPA
Sure, I'll give a revitalized KCC a try out on WAITS.
3-Apr-89 00:49:14-PDT,775;001000000001
Mail-From: KLH created at 3-Apr-89 00:49:10
Date: Mon, 3 Apr 89 00:49:10 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: New KCC for WAITS?
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <sIE4I@SAIL.Stanford.EDU>
Message-ID: <12483120544.21.KLH@SRI-NIC.ARPA>
Great! I'll have some questions about WAITS, of course, before it's
done. I'm working from a copy of the 2nd edition UUO manual (July
1975); have there been new editions since, or any significant new
features? My TOPS-10 doc is even more ancient -- June 1972. If
anyone has an unused pile of more recent manuals, either variety, I'll
gladly help reduce the clutter...
p.s. incidentally, I find the UUO manual a lot easier to understand
than the DEC stuff!
-------
3-Apr-89 08:04:46-PDT,590;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 3 Apr 89 08:04:32 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA10338; Mon, 3 Apr 89 10:47:55 EDT
Date: Mon, 3 Apr 89 10:47:55 EDT
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904031447.AA10338@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Previous msg
Ken -- Did you receive my message referring to, among other things,
[525,6]COUGH.USR? Apparently there was some problem with the Ohio
State machine about the time I sent it.
3-Apr-89 11:42:09-PDT,942;001000000015
Return-Path: <MILUNOVIC@KL.SRI.COM>
Received: from KL.SRI.COM ([10.1.0.2]) by SRI-NIC.ARPA with TCP; Mon, 3 Apr 89 11:24:11 PDT
Date: Mon, 3 Apr 89 10:41:01 PDT
From: Stevan Milunovic <Milunovic@KL.SRI.COM>
Subject: Re: KCC proposal
To: KLH@SRI-NIC.ARPA
cc: larson@KL.SRI.COM, Milunovic@KL.SRI.COM
In-Reply-To: <12482504736.23.KLH@SRI-NIC.ARPA>
Message-ID: <12483228289.12.MILUNOVIC@KL.SRI.COM>
Ken,
I don't see any problem using the KL for KCC development work if you can
finish or move to the NIC system before September when we plan to decommission
the KL. Since we will begin moving users to other systems very soon, I expect
there will be sufficient capacity available until then. Let me know when you
plan to begin your work and we can establish a system support account
(presuming the benefits of your development effort will be available to KL
users for the short time the system will be here).
=Steve=
-------
3-Apr-89 14:06:00-PDT,762;001000000001
Mail-From: KLH created at 3-Apr-89 13:57:55
Date: Mon, 3 Apr 89 13:57:55 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC proposal
To: Milunovic@KL.SRI.COM
cc: larson@KL.SRI.COM, KLH@SRI-NIC.ARPA
In-Reply-To: <12483228289.12.MILUNOVIC@KL.SRI.COM>
Message-ID: <12483264132.28.KLH@SRI-NIC.ARPA>
Great! Yes, September is not a problem -- I'm expecting it to take
at most 8 weeks, as I mentioned, and the new ANSI version should be
available at that point, so anyone who wants to use it for porting,
conversion, etc. should have at least 3 months.
I've already started work (using SUNs for editing the files) and can
begin using the KL as soon as the account is available. Let me know
when it's ready...
Thanks!
--Ken
-------
3-Apr-89 14:17:34-PDT,826;001000000001
Mail-From: KLH created at 3-Apr-89 14:05:10
Date: Mon, 3 Apr 89 14:05:10 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC work on KL
To: joaquin@SRI-NIC.ARPA, camph@KL.SRI.COM
cc: kuo@SRI-NIC.ARPA, klh@SRI-NIC.ARPA
Message-ID: <12483265453.28.KLH@SRI-NIC.ARPA>
I asked Steve Milunovic about doing the KCC work on the KL using a system
support account (instead of charging it to NISC overhead) and he said OK.
I'll start as soon as the account is set up.
So, it isn't absolutely essential that we get govt permission to use the
NIC machine for this, but it's still a good idea to get them on record as
approving that use, because when the KL goes away we won't have anything
but the NIC 20 and we'll need to maintain KCC for the NIC software for
a while yet.
--Ken (rolling up sleeves)
-------
3-Apr-89 14:30:32-PDT,684;001000000011
Return-Path: <joaquin@Sri-Nic.Arpa>
Received: from bear.NISC.sri.com by SRI-NIC.ARPA with TCP; Mon, 3 Apr 89 14:26:20 PDT
Received: from localhost by bear.NISC.sri.com (4.0/SMI-4.0/LIM.1.3)
id AA03887; Mon, 3 Apr 89 14:25:50 PDT
Message-Id: <8904032125.AA03887@bear.NISC.sri.com>
To: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Cc: joaquin@SRI-NIC.ARPA, camph@KL.SRI.COM, kuo@SRI-NIC.ARPA, joaquin
Subject: Re: KCC work on KL
In-Reply-To: Your message of Mon, 03 Apr 89 14:05:10 -0700.
<12483265453.28.KLH@SRI-NIC.ARPA>
Date: Mon, 03 Apr 89 14:25:47 PDT
From: joaquin@Sri-Nic.Arpa
Ken:
Does this mean NISC does not have to pay for any computer time????
JJ
3-Apr-89 14:36:44-PDT,379;001000000001
Mail-From: KLH created at 3-Apr-89 14:36:29
Date: Mon, 3 Apr 89 14:36:29 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC work on KL
To: joaquin@SRI-NIC.ARPA
cc: camph@KL.SRI.COM, kuo@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA
In-Reply-To: <8904032125.AA03887@bear.NISC.sri.com>
Message-ID: <12483271154.28.KLH@SRI-NIC.ARPA>
Right, at least not on the KL.
-------
3-Apr-89 15:19:16-PDT,474;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Mon, 3 Apr 89 15:19:05 PDT
Message-ID: <eIyJY@SAIL.Stanford.EDU>
Date: 03 Apr 89 1515 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: New KCC for WAITS?
To: KLH@SRI-NIC.ARPA
There is one later edition of the UUO Manual, the third edition,
November 1977. I can probably dig one up. Can I sent it via ID mail
to SRI? If so, what's your address?
3-Apr-89 15:34:08-PDT,870;001000000001
Mail-From: KLH created at 3-Apr-89 15:30:45
Date: Mon, 3 Apr 89 15:30:45 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: New KCC for WAITS?
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <eIyJY@SAIL.Stanford.EDU>
Message-ID: <12483281033.28.KLH@SRI-NIC.ARPA>
Gee, I don't know if Stanford and SRI have "interdepartmental" mail -- they're
supposedly separate entities, but there are lots of "agreements". You'll
have to find out at your end what the Stanford mail service is willing to
do. My address would be "SRI International, room EJ200".
If you do find one, and delivery is a problem, I could probably just pick it
up physically at some agreed time. (If my housemates JOS and KS still
frequent SAIL at all, you could hand one to them -- but come to think of it
they probably stuck with CCRMA).
Thanks...
-------
3-Apr-89 16:45:11-PDT,972;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Mon, 3 Apr 89 16:45:07 PDT
Message-ID: <EIzyk@SAIL.Stanford.EDU>
Date: 03 Apr 89 1644 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: New KCC for WAITS?
To: KLH@SRI-NIC.ARPA
Yup, Stanford and SRI have some arrangement for sharing ID mail, so I've
put a UUO Manual into ID mail for you. Since you mentioned CCRMA, it
occurred to me that CCRMA may have some UUO Manuals that JOS or KS could
get hold of, but yours is already in the mail from here.
There are some 220 documented changes in the system since the 3rd edition
of the manual, although most are probably irrelevant to you. If there's
anything particular you want to know about WAITS, feel free to ask me.
One thing that would be nice to have in KCC is the display of the input
file status on the wholine. This is done with the SHOWIT UUO, described
in the printed manual.
4-Apr-89 00:42:39-PDT,847;001000000001
Mail-From: KLH created at 4-Apr-89 00:42:36
Date: Tue, 4 Apr 89 00:42:36 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: New KCC for WAITS?
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <EIzyk@SAIL.Stanford.EDU>
Message-ID: <12483381494.18.KLH@SRI-NIC.ARPA>
Thanks! Looking forward to seeing it...
Considering what else I'll be doing to KCC, adding a wholine update call
is trivial. I'll look for it, and ask you what you want if the manual
doesn't describe a standard usage.
One question I was wondering about. Has WAITS added the notion of
subdirectories or SFDs? If not, is there any logical scheme you can
think of for emulation? (all filenames in C programs will be passed
through a common parser that knows how to convert unix-style pathnames
into local system format names).
-------
4-Apr-89 00:57:09-PDT,1193;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue, 4 Apr 89 00:57:06 PDT
Message-ID: <EJ0er@SAIL.Stanford.EDU>
Date: 04 Apr 89 0056 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: New KCC for WAITS?
To: KLH@SRI-NIC.ARPA
No, subdirectories per se don't exist. A user can have multiple directories,
all accessible from one main one, but the directories are all independent
(all top level). There's a "current directory" (also called "alias"),
returned (or set) by the DSKPPN UUO. Filenames without an explicit
directory (PPN) refer to the current alias directory. Of course,
directory names are (still) sixbit, with a project half and a programmer
name half, e.g., [S,ME].
The SHOWIT UUO for putting a filename on the wholine is pretty trivial.
You won't need any of the mentioned flags, just the I/O channel number
in the AC. You have to have done the OPEN or INIT already (to make the
channel number meaningful). I don't think you have to have done the
LOOKUP yet, though. SHOWIT is "undone" by a RELEAS UUO, so any new
OPEN/INIT should get another SHOWIT (if you're reading multiple files).
4-Apr-89 06:01:01-PDT,415;001000000001
Mail-From: KLH created at 4-Apr-89 06:00:55
Date: Tue, 4 Apr 89 06:00:55 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Previous msg
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8904031447.AA10338@tut.cis.ohio-state.edu>
Message-ID: <12483439441.18.KLH@SRI-NIC.ARPA>
Yes, I got a message about COUGH.USR. Haven't looked at that file yet,
though I will eventually.
-------
4-Apr-89 15:10:40-PDT,417;001000000001
Mail-From: KLH created at 4-Apr-89 15:10:25
Date: Tue, 4 Apr 89 15:10:25 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Our operating system
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8903311859.AA18225@tut.cis.ohio-state.edu>
Message-ID: <12483539474.18.KLH@SRI-NIC.ARPA>
I get a protection failure when attempting to read COUGH.USR[525,6].
-------
5-Apr-89 19:11:59-PDT,1453;001000000015
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 5 Apr 89 19:11:35 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA26676; Wed, 5 Apr 89 22:10:26 EDT
Date: Wed, 5 Apr 89 22:10:26 EDT
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904060210.AA26676@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Protection problem fixed
Cc: ben@csi.compuserve.com
Ken - Sorry about the protection failure. I think it's been fixed.
Also, I'm going to be away on vacation next week. I'll be
experiencing some of that record heat in L.A. I wish I
could work it out so that I could swing by your neck of the
woods and say hello, but I don't think I'll be able to.
Three or four years ago, against the advice of some people who
knew better, CompuServe purchased Sargasso C from a person in
Massachusetts. Sargasso C, we learned later, is terrible
inefficient, far far from ANSI, and (this is my opinion) written
by a hodge-podge of people (probably students). Indeed, the
person who sold it to us was a professor. It is virtually
unmaintainable. The code generator is undecipherable. In
a nutshell, it sucks!
The contract is being drawn up. I'm not crazy about lawyers
and don't talk well to them, so I don't know exactly when I
will see any results, but I'll keep on him.
I'll be in touch again probably after vacation.
5-Apr-89 19:20:30-PDT,742;001000000001
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 5 Apr 89 19:19:42 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA26956; Wed, 5 Apr 89 22:14:01 EDT
Date: Wed, 5 Apr 89 22:14:01 EDT
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904060214.AA26956@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Sargasso C
Ken -- If, you'd like to see Sargasso C in action, we have it
installed on level 5. At the OK prompt, type LEVEL 5.
Then it's simply R CC. A lot of help is on device HLP:
for a lot of things. Sargasso C doco is CC.DOC or some-
thing like that. It might be on level 5. In that case
look on device LV5: insteada HLP:.
6-Apr-89 03:34:25-PDT,3167;001000000001
Mail-From: KLH created at 6-Apr-89 03:34:15
Date: Thu, 6 Apr 89 03:34:15 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: cough, cough, etc
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8904060210.AA26676@tut.cis.ohio-state.edu>
Message-ID: <12483937029.17.KLH@SRI-NIC.ARPA>
Thanks, I pulled over COUGH.USR and scanned it. It's interesting to see
how various improvements have been added... I was particularly impressed by
the date/time section, since I've had the dubious pleasure of dealing with
those issues before. Nice to see them tackled head on!
One request before you go on vacation -- if you haven't already
arranged it, can you try to send a DEC TOPS-10 monitor calls manual?
I've run out of leads here, and it's obvious from looking at our
TOPS-20 copy of UUOSYM.MAC (2-Feb-88) that there have been a lot of
new and potentially very useful things added. Actually, I guess this
can wait a while longer, since I'll still be limited initially to just
the basic stuff supported by the PA1050 emulator on TOPS-20; it won't
become essential until dealing with the non-basic parts of the port.
Some news from here: I've finally succeeded in getting official permission
to use SRI facilities (TOPS-20 and all) without charge! No need to
hassle with government equipment either, thank goodness. So I'm basically
all set. To speed things up, I can start doing some preliminary work
without waiting for the contract to officially start, and charge those
hours later; this way you'll get a basic port as soon as possible.
(Perhaps a risky business practice, but since now I won't have to pay for
CPU/disk, I can gamble my time as I see fit.)
Thanks for the explanation about Sargasso C -- I suppose I should have
guessed. I did manage to get a copy of the Sargasso doc from the DOC
command and skimmed that, so now I can actually formulate some
opinions of my own! My first impression is that their documentation
is pretty reasonable, but Sargasso C clearly was developed with a
different philosophy from KCC. It looks to me like they set out to
write a TOPS-10/20 compiler for the C language -- DEC style
invocation, switches, and system-specific routines for filename
parsing and the like. It compiles C, and that's about it.
What I did with KCC by contrast was to develop a "porting environment"
such that we can import as much Unix-based software as possible, and
export almost anything we write on TOPS-20. This is important to
understand since most of the inefficiencies and restrictions that
might be found bothersome are direct consequences of this philosophy,
which boils down to relying on an OS interface of UNIX "system calls".
I still twitch when I see the word "inefficient", though.
All for now, except a word about lawyers. As it turns out, I've had a
couple of them on my hockey team for several years, and they're great
fun to talk with, but I compare them to doctors (have one of them,
too) in that I'd just as soon not have to deal with them
professionally! An important distinction...
Enjoy your vacation!
--Ken
-------
6-Apr-89 17:12:37-PDT,514;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 6 Apr 89 17:12:24 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890314)
id AA25835; Thu, 6 Apr 89 19:13:04 EDT
Date: Thu, 6 Apr 89 19:13:04 EDT
From: H. Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904062313.AA25835@tut.cis.ohio-state.edu>
To: klh@sri-nic.arpa
Subject: Monitor calls
Ken -- A DEC Monitor Calls manual went out today. You'll probably
get it Monday.
-- Benny
10-Apr-89 13:50:31-PDT,441;001000000001
Mail-From: KLH created at 10-Apr-89 13:43:43
Date: Mon, 10 Apr 89 13:43:43 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Monitor calls
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8904062313.AA25835@tut.cis.ohio-state.edu>
Message-ID: <12485096555.19.KLH@SRI-NIC.ARPA>
Just got the monitor calls notebook a minute ago. Looks like a vast
improvement over the 1972 version, indeed... thanks!
-------
17-Apr-89 16:56:34-PDT,1287;001000000005
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 17 Apr 89 16:55:05 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890413)
id AA01502; Mon, 17 Apr 89 19:54:09 EDT
Date: Mon, 17 Apr 89 19:54:09 EDT
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904172354.AA01502@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: I'm back
Hello -- I'm back from sunny California, a bit unmotivated as a result
of mellowing out and being wined and dined for a week. Any problems or
concerns with respect to KCC? I'm told negligible progress has been
made with regard to the contract, but I'm bothering the lawyer whe
should be working on it about twice a week now. You wouldn't perchance
have a contract that could be used for your services would you? I
told our guy that this endeavor was an aside for you and that you
probably didn't have a contract like this, but I thought I'd ask
anyway. Talk at you later.
---Benny
P.S. If I'm typing this online, and I make a typo on the last character
of a line and then hit carriage return, there's no way of going back and
undoing the mistake is there?
Suppose I create a message with emacs. What's the command to send
that message to you?
18-Apr-89 15:34:35-PDT,1996;001000000001
Mail-From: KLH created at 18-Apr-89 15:34:25
Date: Tue, 18 Apr 89 15:34:25 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: I'm back
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
Message-ID: <12487213859.18.KLH@SRI-NIC.ARPA>
No, I do have a fair number of questions that will need answering
before we can bring KCC up on your system, but thought it would be
best to wait until the contract stuff was out of the way before
getting real serious about it. If you think it might take quite a
while, perhaps you want to reconsider the idea of doing things as a
"software purchase", if that's faster. It's really up to you.
I don't have a ready-made contract form, sorry. SRI has various forms
plus contracts people to fill them out, but it would be a bit tacky for me
to ask for that kind of help, especially after getting the use of the
facilities. If you really think it would help, I can try to invent
a draft in plain english, and send it to you.
All that a contract is needed for is to document our understanding of
what we're agreeing to -- if you have trouble deciding what we're
agreeing on, we can talk some more about that; if it's just to protect
yourself against being ripped off (reasonable in view of previous
experience, I guess) then I'm not sure how I could help anyway.
About mail... are you using MM as the mail reading/sending program?
If so, you ought to be able to invoke EMACS while composing your
message or reply. Exactly how that is set up will depend on the
particular site, but at ours, ^E typed during text entry will invoke
the editor. Another way is to escape out with ESC and then give the
command "edit" to the subcommand ("S>" or "R>") prompt. Use ^X ^B to
list the buffers, you might want to edit the header while you're at
it, or look at the original message. Returning to MM with ^X ^Z then
leaves you with everything waiting final confirmation to send.
If you're not using MM then I dunno.
-------
18-Apr-89 17:15:19-PDT,2737;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 18 Apr 89 17:12:54 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890413)
id AA19974; Tue, 18 Apr 89 19:45:30 EDT
Date: Tue, 18 Apr 89 19:45:30 EDT
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904182345.AA19974@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: KCC
Ken -- I'll continue to work out our contract stuff locally. I will
bring up the notion of a software purchase(s). I think I (we) have
a pretty good idea as to what we're agreeing to. I don't feel the
need to reconsider anything. You're right about us not wanting to
get ripped off again. I wasn't involved in that Sargasso C business,
and a lot of "experts" around here advised against it. However,
we bought it anyway. I'm at a loss as to how it happened. Everyone
who has looked at the KCC documentation agrees that this looks a lot
better than Sargasso C. But upper management still remembers Sargasso
C, and so... we trying to put together a contract. <sigh>
I don't want you to be ripped off either. While you and I can sit at
our respective terminals and probably do real business simply on good
faith, your reimbusement is not coming out of my pocket. I don't like
doing it, but the contract probably gives us more credibility to you.
We certainly want an ANSI compiler on our system. If you want to give
us a compiler (non-ANSI) that will run on our system and bill us for it
say $2500 (give or take some), we'd probably buy it. If that deal works
and is comfortable to everyone, we could try the same thing for the
ANSI upgrade. At some point, the contract would appear. Just an idea.
The basic issues we are trying to put into the contract (just so you'll
know) are things like
1. We get a TOPS-10 compiler to play with. We want it to live
up to our expectations (I know that's nebulous).
2. After we see that it works, you do the ANSI upgrade.
At some points you do library work. (But if you wanted,
maybe we could to -- I don't think that's an issue with us.
Typically, we think we'd have a better product if you did
the work.)
We also want to throw in something like 6 months of support
at so many dollars per hour not to exceed so many dollars.
Anyway, it's something like that that we are hoping to churn out. I
apologize for it getting sort of messy.
I can't back up.
For each part above, we want to put some fixed value on it.
Figuring at $60/hour is probably about reasonable, but I don't
think we want to talk about hourly rates (at least we don't want
to emphasize hourly rates).
Gotta run - wife is hollering at me.
19-Apr-89 13:07:38-PDT,2333;001000000001
Mail-From: KLH created at 19-Apr-89 13:07:23
Date: Wed, 19 Apr 89 13:07:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8904182345.AA19974@tut.cis.ohio-state.edu>
Message-ID: <12487449235.18.KLH@SRI-NIC.ARPA>
OK, what you say sounds good. The only change I would suggest at this
point would be to move a lot of the estimate for the enhanced port
into that for the initial (basic) port.
This is partly because if you want a T10 compiler to experiment with,
I think you'll want something a little more useful than just something
that compiles itself; makes for a better impression, too. This is
also partly because I've been reviewing all of the library code with
one eye on the T10 documentation, and the resulting dependency tree is
more interwoven than I initially guessed. It's not so much stuff that
is "needed", as stuff that occasionally makes references to flags,
variables or routines in other modules. Even when they aren't going
to be used, I still have to do something about all those places and
temporarily conditionalize them out or substitute something else. In
many cases it will be easier in the long run just to provide the
T10-variant code in the first place.
So, while I don't think the overall T10 port is any more or less
difficult, from integration considerations it would be better if we
allocated more effort to "basic" than "enhanced". Or even put it all
into basic, and left additional enhancements for the "follow-on
maintenance". I feel a bit of concern when I realize that to people
with ideas of testing out the implementation, their definition of
"basic" is going to be everything THEY expect to need; "enhanced"
stuff, of course, is just the stuff SOMEONE ELSE will need. Erk!
If you think it's best to stick with the original plan on the surface,
that's fine, but I'll probably flesh out additional code using my
judgement as to what's needed, and if Compuserve does decide to go for
ANSI-ness & enhancement, I can recoup the investment then. My risk,
but I think a reasonable one.
Enough contract biz. I'll go ahead and send you another message with
some questions...
--Ken
(p.s. so are you using MM? Did you get anywhere using the edit feature?)
-------
19-Apr-89 13:16:12-PDT,881;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 19 Apr 89 13:16:06 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890413)
id AA19809; Wed, 19 Apr 89 16:15:38 EDT
Date: Wed, 19 Apr 89 16:15:38 EDT
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904192015.AA19809@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: MM
No, I haven't figured out MM yet. It's here, but something happens to about
50% of my keys when I invoke it (they stop echoeing).
Anyway, I'm setting up myself to scan interesting newsgroups today.
Thanks for the feedback. We had a mgmt. meeting today and I had to
update my V.P. on the status of KCC. The result is that I will be putting
together the contract. It'll be okay, I'll live, it's probably the best
way to go.
Looking forward to your questions...
19-Apr-89 14:44:18-PDT,6339;001000000001
Mail-From: KLH created at 19-Apr-89 14:44:07
Date: Wed, 19 Apr 89 14:44:07 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC->T10 questions
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8904192015.AA19809@tut.cis.ohio-state.edu>
Message-ID: <12487466846.18.KLH@SRI-NIC.ARPA>
OK, here we go...
[0] How do you want to actually transport the initial source and binary?
Can you read TOPS-20 DUMPER tapes? Would FTP to Ohio-State.EDU be the
best method? I assume the .REL file format is identical on T10 and T20,
and I would also guess that the "csave" executable format (not paged) is
directly portable, but what about TOPS-20 paged .EXE format?
[1] Your OS has sufficiently many additional features from standard TOPS-10
that it makes sense to use a new system name. The convention I've used in
the C environment definition file (<c-env.h>) is SYS_xxx where xxx is the
system identifier. What name would you like to use? A 3-character ident
would be desirable, but not essential. The existing names are:
SYS_T20, SYS_10X, SYS_T10, SYS_ITS, SYS_WAITS
Since you already have a CSISYM.UNV file, I assume you'll want CSI, but
just making sure.
[2] KCC needs a standard directory location for its #include header files
and library .REL files. I assume a logical name is the best means of doing
this on T10 (it's C: on TOPS-20). What logical name do you want to use?
I assume it will be OK to use SFDs in that directory; in particular, there
are many files such as <sys/file.h> which presume a subdirectory called "sys".
[3] What is your preferred filename syntax? I've seen both
dev:[ppn]file.ext and dev:file.ext[ppn]
It doesn't really matter unless you also use a more divergent syntax; I am
setting the filename parser up to handle a combined T10/Unix format.
[4] Do your programs have any convention for filename quoting? In particular,
are there any "quote characters"? If not, which character(s) would you like
to use? T20 uses ^V, ITS uses ^Q, UNIX often but not always uses \.
[5] How are user names obtained, given a PPN? Vice versa? Given the lack
of any discussion of this in the doc I've seen, I assume this would be
a Compuserve-only mechanism, if one. If you DO handle user names, do you
want to permit them in file pathnames?
[6] How do you want to map between UNIX and TOPS-10 file protection codes?
The extremes are obvious, but the in-between cases will have to be
approximations.
[7] As far as I know, there is no way for fork() to ever work on TOPS-10.
exec(), however, can be made to work using the RUN UUO and some appropriate
convention for passing arguments. Do you have any thoughts as to the best
method of passing on the argv array? Is the start-offset-of-1-and-use-TMPCOR
convention universal? If so, how to know what 3-character TMPCOR program
identifier to use? (Just taking the first 3 chars of filename doesn't work,
eg "LINK" != "LNK"). Is there a way for a program to set the RESCAN (TTY
input) buffer prior to invoking RUN with a start offset of 0, so it can
fake out the new program into thinking the user typed those args? (This is
how the T20 code does it, so that it will work both with C and non-C programs.)
[8] I'm wondering about the use of non-standard I/O byte sizes; the T10
doc isn't clear on these points. If I were to initialize a disk buffer ring
control block with a 9-bit byte pointer prior to the first IN UUO, would
the monitor correctly figure out that I'm using 9-bit bytes, and set up
the new pointer and count appropriately? Or does it always smash the
pointer to use 7-bit or 36-bit bytes depending on the I/O mode the device
was OPEN'd in? This is fuzzy enough that I'm not ready to trust what the
PA1050 compatibility package does on T20. I realize non-DSK devices like
the TTY are weirder.
[9] Is it common for programs to open TTY: by themselves so as to get
an I/O channel that can be manipulated in standard fashion, or is it
more conventional for them to treat the controlling TTY specially and
use the monitor UUOs like TTCALL which don't need a channel number?
From a consistency viewpoint, the runtime would like to treat the
controlling TTY like a normal device, but you may prefer to avoid the
inefficiency of OPENing it on every startup.
[10] Is there any way to twiddle things so that a program invoked by the RUN
UUO gets its "controlling TTY" mapped to something other than a TTY; say, so
the input comes from a file? I assume not, but just making sure.
[11] Have you thought about whether you want pipe() to do anything?
Like fork(), this doesn't look promising.
[12] Do you want to eventually consider the use of PTYs to implement
certain forms of fork() or system(), by starting up another job (could
be done via the KCC forkexec() function)? I noticed the CSI-specific
FRCUUO call, but don't think it could safely be used for system().
[13] Is there any way to query the status of an open I/O channel so as
to find out the current file position? Or do you have to keep track
of it yourself and hope you have the same notion that the monitor does?
[14] Do you have a standard algorithm for finding the actual EOF on character
oriented disk files, where the last valid character may come in the middle
of a word? Should the I/O routines just ignore all trailing NUL bytes in the
last word? I haven't seen any indication that T10 has the concept of a file
byte count (as opposed to a word count).
[15] What is the maximum size of a disk file? Nothing actually comes out and
says what this is, but various things imply that you can have only 2^18 words,
perhaps bumped up to 2^25 with 6.03.
[16] Oh, almost forgot. The runtime wants to do a RESCAN of the invoking
command line (assuming started at normal address). Is it a standard convention
for the program args to follow a ";" on that line? The runtime needs to
put something in argv[0]; this could be one of:
(1) the entire text up to ";"
(2) the probable program name (ie #1 parsed to determine filename,
without "RUN", PPN, ext, etc)
(3) the program name as returned by GTNAM$, assuming the monitor
sets this prior to starting the program.
Those are the main things that came up to begin with.
--Ken
-------
19-Apr-89 15:47:29-PDT,2765;001000000001
Mail-From: KLH created at 19-Apr-89 15:43:23
Date: Wed, 19 Apr 89 15:43:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC resources
To: joaquin@SRI-NIC.ARPA, camph@KL.SRI.COM, kuo@SRI-NIC.ARPA,
vivian@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12487477634.18.KLH@SRI-NIC.ARPA>
Hmmm, Vivian notes in her minutes of the DCA meeting that Gayle Wix
turned down our request for the use of NIC resources. That's okay for
this particular upgrade, since the KL is available until August, but
it occurs to me that a conflict might arise in the future, so I
thought I'd alert you now. It's especially important to determine
what this means with respect to future KCC maintenance; depending on
the implications, it may mean that we have to move KCC completely off
the NIC, or not distribute it any more, or simply let everything
decay in its tracks.
Were Gayle's objections based on the ethical propriety of this
particular request, or on the false notion that NIC funds would be
used to perpetuate what she sees as a bad architecture? I could
understand the first reason, but any other reason should be attacked
vigorously to save trouble in the future, since it could prevent us from
doing what we've been doing up to now.
I still think DCA is going to need a TOPS-20 C compiler for at least
another 18 months (14 months past KL expiration date) and it is still
quite likely that ANSI C represents our best (most cost-effective)
transition path. It only makes sense to dump it if you assume that we
will throw away everything we've written so far, and start completely
from scratch, as Gayle seems to want -- but we don't have an OFFICIAL
mandate for this yet, and the new SOW certainly ducks the issue. That
worries me.
So I can still imagine a scenario where DCA decides that they do need
the ANSI standard version of KCC. In this case we should feel free to
charge them a bundle, since they didn't contribute anything
originally. I consider that SRI is contributing something with
facility access, so there is no problem about SRI being able to use
the new KCC; the question is whether SRI wants to let DCA get any
benefits of the new KCC for free or not.
In fact, if we consider KCC to be an externally maintained piece of
software (and we have been pretty careful about NOT charging KCC work
to DCA, precisely so that they couldn't assert rights to it), then we
should probably already be charging them a hefty fee for software
maintenance and regular upgrades. They may not relish paying for bug
fixes that were formerly "on the house", but if all this is just because
Gayle likes to play hardball, then so it goes. Again, what are the
reasons and the implications?
--Ken
-------
19-Apr-89 20:09:36-PDT,1424;001000000015
Mail-From: VIVIAN created at 19-Apr-89 20:09:19
Date: Wed, 19 Apr 89 20:09:19 PDT
From: Vivian Neou <Vivian@SRI-NIC.ARPA>
Subject: Re: KCC resources
To: KLH@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA, camph@KL.SRI.COM, kuo@SRI-NIC.ARPA
cc: Vivian@SRI-NIC.ARPA
In-Reply-To: <12487477634.18.KLH@SRI-NIC.ARPA>
Message-ID: <12487526047.16.VIVIAN@SRI-NIC.ARPA>
Gayle said no based on the "no support for a dead system" reason
she usually uses. I'll relay the gist of your message as best
I can to Jose and Frank tomorrow, and perhaps we can have further
discussions with Gayle before we leave. I have a couple comments of my
own though. To date, we've used project resources (the system) for
KCC development. Granted, we don't charge them for the labor, but
this has been a shared effort as far as resources go. I thought
that the things that had already been ported to C could already run in a
Sun environment. Is that incorrent? I realize that ther are some
operating system dependencies, but your assertion that ANSI C
is necessary for the transition unless everything is redone from
scratch seems a much too extreme.
We've all done a lot of work in the past few months to develop a
better relationship with Gayle. Given the current power structure at
DCA I think it would be dangerous to jepordize that relationship with
threats about charging them for an ANSI version of C.
Vivian
-------
20-Apr-89 15:05:26-PDT,3016;001000000001
Mail-From: KLH created at 20-Apr-89 15:01:29
Date: Thu, 20 Apr 89 15:01:29 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC resources
To: Vivian@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA, camph@KL.SRI.COM,
kuo@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12487526047.16.VIVIAN@SRI-NIC.ARPA>
Message-ID: <12487732153.18.KLH@SRI-NIC.ARPA>
This message won't get to you in time, but I'll clarify anyway. What
Gayle thinks about the upgrade doesn't matter. What I worry about is
what she thinks about future KCC maintenance once the KL is gone. The
attitude she seems to be expressing is one which could prevent us from
doing ANYTHING with KCC other than keeping a binary copy around. That
is, no bug fixes, no distribution, no BUG-KCC mailing list, nothing.
You are perfectly correct about the trade we have been doing in the
past -- system resources in return for no labor charges -- but this is
precisely what Gayle is threatening to do away with. If you asked her
directly about this arrangement she would probably torpedo that too.
Does that help explain why I'm concerned?
You are correct that our C implementation lets us port things to a SUN
environment. I was not trying to say that ANSI C is necessary for a
transition, nor that without it we have to redo everything from
scratch. You missed the point, which is that GAYLE wants us to redo
everything from scratch (regardless of language); and in that case,
whether we use old KCC or new KCC is irrelevant to her and us. Let me
sketch out the transition alternatives a bit more precisely:
[1] Throw everything away, start over from scratch (new H/W and S/W)
Result: KCC is irrelevant.
[2] Port current S/W into a SUN (or very similar) UNIX environment.
Result: can leave KCC alone.
[3] Port current S/W into unknown future environment supporting C.
Result: should use ANSI C for max portability.
Of these alternatives, I think #3 is the most conservative. Without explicit
direction in the SOW, #1 scares me. #2 is the quickest and easiest thing to
do, but will they let us do it?
I don't see the issue of "charging for ANSI KCC" as a threat -- it is the
natural outcome when forced to do things on a strict cost-benefit basis.
If DCA insists on examining KCC support on this basis (ie "what is the cost
and what are the benefits") then we have to first show that the benefits
exist, and then show how they compare to the cost. It is already incurring
a cost in the sense of using system resources. If these resources were
moved elsewhere, KCC no longer incurs an indirect cost, but it makes no sense
to say that it has then become "free"; it still consumes the same resources
elsewhere, and we have to recover this cost directly, which means charging.
Having a good working relationship with Gayle doesn't mean we have to
agree with her on everything. Are you ready to give up on the SUN
source code issue?
Hope this helps (after the fact...)
--Ken
-------
20-Apr-89 22:38:06-PDT,806;001000000011
Mail-From: VIVIAN created at 20-Apr-89 22:37:55
Date: Thu, 20 Apr 89 22:37:55 PDT
From: Vivian Neou <Vivian@SRI-NIC.ARPA>
Subject: Re: KCC resources
To: KLH@SRI-NIC.ARPA, joaquin@SRI-NIC.ARPA, camph@KL.SRI.COM, kuo@SRI-NIC.ARPA
cc: Vivian@SRI-NIC.ARPA
In-Reply-To: <12487732153.18.KLH@SRI-NIC.ARPA>
Message-ID: <12487815243.25.VIVIAN@SRI-NIC.ARPA>
We didn't get an opportunity to discuss this with Gayle today. I
guess we can develop an official NIC response to this problem after
we're all back in Menlo Park. As for source code, I did give up on
getting it from DCA. We'll still be getting it for overhead
uses if the paperwork ever gets through, but the cost is only $500
now. It's being handled as a shared facility cost between various
computer groups at the institute.
-------
21-Apr-89 10:43:48-PDT,15829;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by SRI-NIC.ARPA with TCP; Fri, 21 Apr 89 10:34:40 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890413)
id AA23889; Fri, 21 Apr 89 13:11:10 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA02105; 21 Apr 89 12:36:21 EST (Fri)
Date: 21 Apr 89 12:00:20 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: some answers
Message-Id: <"CSI 5555-8079"@CompuServe.COM>
to: Ken Harrenstein
fr: Benny Jones
I asked one of our monitor wizards to look at your list
of questions. Here is his response.
Here are some answers...see whether you think they answer the
questions and/or make sense.
Thanks.
(0) TOPS-10 and TOPS-20 .REL file formats are the same as far as I
know.
I'm not positive, but I think our .exe files are mostly compatible
with TOPS-20's. If TOPS-20 "csave" refers to .sav/.hgh/.low
files, then we can indeed run them, but we consider them obsolete
and no longer use them in system areas.
(1) I agree that CSI is the logical name.
(2) We don't use SFDs, so the standard #include <> file names will
probably have to be mapped by the compiler to their real names
both to get around the lack of subdirectories and the limit of
six-character names.
(3) On input, we accept both dev:[ppn]file.ext and dev:file.ext[ppn]
syntaxes. For output, the format dev:file.ext[ppn] seems to be
universal.
(4) Like TOPS-10, we have no convention for character quoting in file
names; instead, we use string quoting. DEC uses quotation marks,
but CS long ago decided on apostrophes, so it's a good idea to
accept both '!!!' and "!!!" to mean a file whose name consists of
three exclamation points.
Personally, I like the idea of accepting a backslash to quote a
single character, and I've used that convention in a few of my
programs, but I'm not aware of any other CS programs that accept
that convention.
The use of control characters is not feasible because we, by
convention, treat all control characters specially on terminal
input--a character either has a function and performs it, or is
discarded. ^Q is XON, ^V is the CS equivalent of ^R to retype a
line.
(5) We don't have the concept of user names, just PPNs. There is
something called an "account ID," but that's solely for accounting
purposes and does not identify a user or affect file access.
(6) I'm not sure I understand the context of the question, but I'd
guess we'll have to provide a few CSI-specific functions to allow
the use of the nine-bit protection codes.
Although we use TOPS-10-style protections, CS has defined a second
set of protection codes that some programs accept. The commands
protect this.txt(2)
protect this.txt<055>
are identical. These CS protections are "virtual" in the sense
that they don't really exist except as a command syntax--the
protection of this.txt really is the nine-bit value 055. I guess
somebody thought they'd be easier for customers to understand.
Anyway, I think it's safe to ignore the issue of CS protections
for now, but it's something to be aware of.
(7) Right, we have nothing like fork(), and exec() would have to RUN.
The runoffset-1-with-TMPCOR convention is fairly universal:
programs supporting the concept of being run with arguments
usually do it that way, although not all programs support it, and,
as you said, you just have to know the TMPCOR file name.
Your idea of "typing in" a line is feasible, although I think it
would require a couple of operating system changes, and it's
probably the best way to handle the general case of exec(). I
think we'd want to be able to do both. Possibilities:
RUNOFFSET-WITH-TMPCOR:
From the runner's point-of-view: I suggest that offset-one-
with-TMPCOR RUN be provided as a function, perhaps
run(program, runoffset, TMPCOR_file_name, TMPCOR_string)
where a null TMPCOR file name means "don't write any TMPCOR
file."
From the runee's point-of-view: I think the most convenient way
to handle a runoffset-1 entry is to automatically read and
delete the TMPCOR file and set up the argv vector if the program
declares the TMPCOR file name at compilation time. Perhaps
something like
#define RUNOFFSET_1_TMPFILE_NAME ABC
would enable the runoffset 1 entry handling. There ought to be
a function that indicates whether the argv vector came from a
runoffset-one TMPCOR file, too, but at least you wouldn't have
to code specifically for such just to make it work at all.
PUTTING TEXT IN THE TYPEIN BUFFER:
We have the ability to "type in" a line, so your idea is probably
the most reasonable for exec(). I think we'll have to fix it so
it works right with RESCAN. (On a runoffset-zero entry, you
normally do a RESCAN 1 to ask whether there's a command line
to be rescanned--that way, you're sure you're interpreting the
command that invoked you, and not reading typed-ahead characters.
But our mechanism for "typing in" a line does not let you flag it
as a command line to be rescanned.)
(8) Basically, the answer is that the byte size will be initialized by
the OPEN, but may then be changed, and subsequent byte counts will
be calculated based on that byte size.
I've included a much more detailed answer at the end of this memo.
(9) I'm not sure what our runtime systems do. One thing to consider
is that you cannot, in general, open a terminal on more than one
channel. If the runtime opens the job-controlling terminal on a
channel, and the user later opens it, the runtime system would
have to realize what's happening and act appropriately.
(10) No, not really. You could define a logical device named TTY:
that maps to a file, but that won't redirect TTCALLs or
TRMOPs, it just affects OPENs.
(11) My guess is that pipe(), as you said, can't be rationally
implemented on our systems.
(12) I don't think it's worth using PTYs for fork() or system() calls.
In general, I don't think their absence would be a problem. In
our case, many uses of system() are better handled in other ways-
-e.g., if someone wanted to system("copy...") to copy a file,
we'd rather provide a function to do that than start another job
and execute a monitor command. And they're operating-system-
specific enough that I don't think there's any real issue of
compatibility with other C implementations.
(13) There's no way to ask where you are within a file.
(14) You're right, disk file lengths are kept in words, so there are
usually extra null bytes at the end of a file. In text files,
the usual approach is to discard nulls in the last word. (More
below.)
(15) If you use the USETI and USETO calls to position within a file,
the maximum length is about 2^18 blocks (not words), but the
FILOP flavors of those functions provide a full word for the
block number, eliminating that limit. I think the absolute limit
would be, in theory, 2^35 words, so the word count doesn't
overflow. We do have some files longer than 2^18 blocks.
(16) There are three conventions for passing arguments in a command
that runs a program.
(a) irun prog; args <=theoretically, the semicolon introduces a
comment, so those really shouldn't be
interpreted as args. But some programs
treat them as args because the semicolon
used to be the only way to do this.
(b) irun prog (args) <=this is the "correct" way to include
arguments on an irun command (DEC, of
course, calls it "run"; the CS "run"
command is equivalent to DEC's "execute"
command). DEC's SCAN, for example,
allows this (try "r runoff (args)").
Normally, omission of the close paren is
not considered an error. I think they
ignore anything after the close paren, if
present.
(c) command args <=if the program can be invoked directly by
a command, then the usual stuff applies.
This refers to built in commands like
"directory," of course, but a user can
define his own commands on our system by
giving, say,
xyz :== \irun prog
We interpret the leading backslash to
mean that the program should see the
original command line--"xyz xxx"--rather
than the substituted command.
Your question of what to put in argv[0] is an interesting one
that I haven't really thought about, but I can think of one
reason to avoid using the program name (via GTNAM$)--you can
define several commands that run a single program:
xyz :== \irun prog
foo :== \irun prog
You'd want to be able to tell them apart via argv[0], kind of
like linking two names to the same file/program under UNIX (but
in our case, the program name you'd see is "prog" in both cases).
DISK IO:
Here is a much more detailed answer to questions 8 and 14. Some of
this explanation may be overkill, but I figured it was better to err
on the side of mentioning things that might already be obvious than to
omit them, especially because I'm not familiar enough with TOPS-20 to
know which things are differences and which are the same as TOPS-10.
A TOPS-10 disk file is always--no matter how it was written--treated
as a sequence of blocks, each block containing 128, 36-bit words. Its
length is maintained to the word boundary. The way in which bytes
were placed in those words is not considered a characteristic of the
file, so there is no byte size or bit packing mode associated with the
file. (There is a four-bit "mode" field, but it is really meaningless
because it reflects only the IO mode in which the file was opened, not
the way in which bytes were placed in words, and it is sufficiently
useless that it tends to disappear--programs that copy files often
destroy the mode field.)
(Note--Apparently, in prehistoric times, TOPS-10 maintained file
lengths in blocks instead of words. CS decided to keep that behavior
as default, so there is a "true size" flag that must be set upon
startup in order to work properly. Thus, everybody does a TRUSZ$ call
after the RESET. If you open a channel with FILOP rather than OPEN, I
ignore the "true size" flag for IO on that channel, so it's a problem
only if you do OPENs. Other than the "true size" nonsense, there are
very few differences between TOPS-10 and CS disk IO.)
Under TOPS-10, the file is a sequence of blocks numbered from 1.
Unlike TOPS-20, there are no monitor calls to read bytes--you always
read blocks and break them into bytes yourself. There are
fundamentally two ways to read the blocks, buffered mode or dump mode.
In dump mode (017 in the low-order four bits of the IO status when you
open the channel), the IN or OUT calls take a command list of IOWDs,
each IOWD transferring an integral number of blocks.
In the buffered modes, each IN or OUT conceptually transfers one
block, using a ring of one-block-long buffers with a header that
contains a byte pointer and count into the "current" buffer being
filled or emptied.
In either case, the USETI/O functions can position to a different
block of the file for subsequent IO calls. USETs are a little tricky
in buffered mode, though, requiring some extra handling of the
buffers.
In buffered mode, the byte size in the byte pointer in the header is
initialized by the OPEN depending on the mode: for mode 0 or 1, 7-bit
bytes; for mode 010, 36-bit bytes. You can subsequently change the
size, and the new size will be used for subsequent calculations.
Internally, counts are maintained in words. An input call reads a
block into the buffer, calculates the number of bytes per word based
on the size indicated in the byte pointer, multiplies that by the
number of words in the buffer (for disks, always 128 except for the
last block of the file), and returns that as the byte count.
An output call ignores the byte size and count; it calculates the
number of words in the buffer by subtracting the address of the first
word of the buffer from the address in the byte pointer. (There is a
mode bit that tells the monitor to ignore the byte pointer and instead
believe a word count that you place in the buffer.)
Of course, the byte size doesn't affect the data in the buffer, which
is a bit-for-bit copy of the block on disk. For example, a text file
is stored with five characters per word. If you change the byte
pointer to use 8 bit bytes and read a block, your first eight-bit byte
would contain the first ASCII character in its high-order seven bits
and the high-order bit of the second character in its low-order bit.
In our case, there are two bit-packing modes of primary interest to a
program interpreting a file as a byte stream. What seems to be
conceptually cleanest in our environment is to interpret text and
binary files like this (assuming, for the moment, that a char is eight
bits wide):
Text: fopen("test.txt","rt")--stored on disk as a sequence of 7-bit
bytes. On input, 7-bit bytes have a leading zero bit prefixed;
CRLF pairs are translated to \n (would a lone CR be passed or
discarded?). On output, 8-bit bytes have the MSB discarded, and
\n translated to CRLF pairs. An additional mode flag should
allow suppression of newline manipulation.
Binary: fopen("test.arc","rb")--stored on disk as a sequence of 8-bit
bytes. No translation.
We already have several programs that have the concept of "binary"
files as streams of eight-bit bytes, a format we use for uploading and
downloading arbitrary files to or from a PC or for processing .arc-
format files, for example. Such a file is stored on disk as a
sequence of octets, four per word, with the low-order four bits of
each word set to zero.
To avoid rounding up the length to a multiple of four octets (a result
of file lengths being maintained in words), our convention is that the
low-order four bits of the last word in the file contains the number
of unused bytes in that word (the low-order bits in all other words
are 0; logically, they should be zero to indicate that no bytes within
the word are skipped, and they allow programs to infer that it's a
"binary" file).
By the way, as you noted in question 14, one glitch in ASCII files
under TOPS-10 is that you must discard nulls, at least at the end of
the file (most programs ignore them anywhere), because file lengths
are maintained only to the word.
21-Apr-89 13:53:38-PDT,648;001000000001
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 21 Apr 89 13:53:28 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890413)
id AA06307; Fri, 21 Apr 89 14:58:57 EDT
Date: Fri, 21 Apr 89 14:58:57 EDT
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904211858.AA06307@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: mail
Ken -- I've sent you some answers to your questions. However, I've
sent them from our mainframe at CompuServe. I can't say I trust
this gateway yet. Please let me know if you haven't gotten them
by the time you go home tonight. Thanks.
21-Apr-89 15:39:47-PDT,419;001000000001
Mail-From: KLH created at 21-Apr-89 15:38:14
Date: Fri, 21 Apr 89 15:38:14 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: some answers
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5555-8079"@CompuServe.COM>
Message-ID: <12488000988.20.KLH@SRI-NIC.ARPA>
Got the "answers" message OK. Looks helpful. Will have more when I have
time to go over it slowly. Thanks...
-------
22-Apr-89 10:16:44-PDT,16037;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sat, 22 Apr 89 10:11:32 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA25950; Fri, 21 Apr 89 23:26:40 EDT
Date: Fri, 21 Apr 89 23:26:40 EDT
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8904220326.AA25950@tut.cis.ohio-state.edu>
To: KLH@sri-nic.arpa
Subject: Answers
Cc: ben@csi.compuserve.com
to: Ken
fr: Benny Jones
I showed one of our monitor guys your list of questions.
Here is his response.
--------------------------------------------------------------------
Here are some answers...see whether you think they answer the
questions and/or make sense.
Thanks.
(0) TOPS-10 and TOPS-20 .REL file formats are the same as far as I
know.
I'm not positive, but I think our .exe files are mostly compatible
with TOPS-20's. If TOPS-20 "csave" refers to .sav/.hgh/.low
files, then we can indeed run them, but we consider them obsolete
and no longer use them in system areas.
(1) I agree that CSI is the logical name.
(2) We don't use SFDs, so the standard #include <> file names will
probably have to be mapped by the compiler to their real names
both to get around the lack of subdirectories and the limit of
six-character names.
(3) On input, we accept both dev:[ppn]file.ext and dev:file.ext[ppn]
syntaxes. For output, the format dev:file.ext[ppn] seems to be
universal.
(4) Like TOPS-10, we have no convention for character quoting in file
names; instead, we use string quoting. DEC uses quotation marks,
but CS long ago decided on apostrophes, so it's a good idea to
accept both '!!!' and "!!!" to mean a file whose name consists of
three exclamation points.
Personally, I like the idea of accepting a backslash to quote a
single character, and I've used that convention in a few of my
programs, but I'm not aware of any other CS programs that accept
that convention.
The use of control characters is not feasible because we, by
convention, treat all control characters specially on terminal
input--a character either has a function and performs it, or is
discarded. ^Q is XON, ^V is the CS equivalent of ^R to retype a
line.
(5) We don't have the concept of user names, just PPNs. There is
something called an "account ID," but that's solely for accounting
purposes and does not identify a user or affect file access.
(6) I'm not sure I understand the context of the question, but I'd
guess we'll have to provide a few CSI-specific functions to allow
the use of the nine-bit protection codes.
Although we use TOPS-10-style protections, CS has defined a second
set of protection codes that some programs accept. The commands
protect this.txt(2)
protect this.txt<055>
are identical. These CS protections are "virtual" in the sense
that they don't really exist except as a command syntax--the
protection of this.txt really is the nine-bit value 055. I guess
somebody thought they'd be easier for customers to understand.
Anyway, I think it's safe to ignore the issue of CS protections
for now, but it's something to be aware of.
(7) Right, we have nothing like fork(), and exec() would have to RUN.
The runoffset-1-with-TMPCOR convention is fairly universal:
programs supporting the concept of being run with arguments
usually do it that way, although not all programs support it, and,
as you said, you just have to know the TMPCOR file name.
Your idea of "typing in" a line is feasible, although I think it
would require a couple of operating system changes, and it's
probably the best way to handle the general case of exec(). I
think we'd want to be able to do both. Possibilities:
RUNOFFSET-WITH-TMPCOR:
From the runner's point-of-view: I suggest that offset-one-
with-TMPCOR RUN be provided as a function, perhaps
run(program, runoffset, TMPCOR_file_name, TMPCOR_string)
where a null TMPCOR file name means "don't write any TMPCOR
file."
From the runee's point-of-view: I think the most convenient way
to handle a runoffset-1 entry is to automatically read and
delete the TMPCOR file and set up the argv vector if the program
declares the TMPCOR file name at compilation time. Perhaps
something like
#define RUNOFFSET_1_TMPFILE_NAME ABC
would enable the runoffset 1 entry handling. There ought to be
a function that indicates whether the argv vector came from a
runoffset-one TMPCOR file, too, but at least you wouldn't have
to code specifically for such just to make it work at all.
PUTTING TEXT IN THE TYPEIN BUFFER:
We have the ability to "type in" a line, so your idea is probably
the most reasonable for exec(). I think we'll have to fix it so
it works right with RESCAN. (On a runoffset-zero entry, you
normally do a RESCAN 1 to ask whether there's a command line
to be rescanned--that way, you're sure you're interpreting the
command that invoked you, and not reading typed-ahead characters.
But our mechanism for "typing in" a line does not let you flag it
as a command line to be rescanned.)
(8) Basically, the answer is that the byte size will be initialized by
the OPEN, but may then be changed, and subsequent byte counts will
be calculated based on that byte size.
I've included a much more detailed answer at the end of this memo.
(9) I'm not sure what our runtime systems do. One thing to consider
is that you cannot, in general, open a terminal on more than one
channel. If the runtime opens the job-controlling terminal on a
channel, and the user later opens it, the runtime system would
have to realize what's happening and act appropriately.
(10) No, not really. You could define a logical device named TTY:
that maps to a file, but that won't redirect TTCALLs or
TRMOPs, it just affects OPENs.
(11) My guess is that pipe(), as you said, can't be rationally
implemented on our systems.
(12) I don't think it's worth using PTYs for fork() or system() calls.
In general, I don't think their absence would be a problem. In
our case, many uses of system() are better handled in other ways-
-e.g., if someone wanted to system("copy...") to copy a file,
we'd rather provide a function to do that than start another job
and execute a monitor command. And they're operating-system-
specific enough that I don't think there's any real issue of
compatibility with other C implementations.
(13) There's no way to ask where you are within a file.
(14) You're right, disk file lengths are kept in words, so there are
usually extra null bytes at the end of a file. In text files,
the usual approach is to discard nulls in the last word. (More
below.)
(15) If you use the USETI and USETO calls to position within a file,
the maximum length is about 2^18 blocks (not words), but the
FILOP flavors of those functions provide a full word for the
block number, eliminating that limit. I think the absolute limit
would be, in theory, 2^35 words, so the word count doesn't
overflow. We do have some files longer than 2^18 blocks.
(16) There are three conventions for passing arguments in a command
that runs a program.
(a) irun prog; args <=theoretically, the semicolon introduces a
comment, so those really shouldn't be
interpreted as args. But some programs
treat them as args because the semicolon
used to be the only way to do this.
(b) irun prog (args) <=this is the "correct" way to include
arguments on an irun command (DEC, of
course, calls it "run"; the CS "run"
command is equivalent to DEC's "execute"
command). DEC's SCAN, for example,
allows this (try "r runoff (args)").
Normally, omission of the close paren is
not considered an error. I think they
ignore anything after the close paren, if
present.
(c) command args <=if the program can be invoked directly by
a command, then the usual stuff applies.
This refers to built in commands like
"directory," of course, but a user can
define his own commands on our system by
giving, say,
xyz :== \irun prog
We interpret the leading backslash to
mean that the program should see the
original command line--"xyz xxx"--rather
than the substituted command.
Your question of what to put in argv[0] is an interesting one
that I haven't really thought about, but I can think of one
reason to avoid using the program name (via GTNAM$)--you can
define several commands that run a single program:
xyz :== \irun prog
foo :== \irun prog
You'd want to be able to tell them apart via argv[0], kind of
like linking two names to the same file/program under UNIX (but
in our case, the program name you'd see is "prog" in both cases).
DISK IO:
Here is a much more detailed answer to questions 8 and 14. Some of
this explanation may be overkill, but I figured it was better to err
on the side of mentioning things that might already be obvious than to
omit them, especially because I'm not familiar enough with TOPS-20 to
know which things are differences and which are the same as TOPS-10.
A TOPS-10 disk file is always--no matter how it was written--treated
as a sequence of blocks, each block containing 128, 36-bit words. Its
length is maintained to the word boundary. The way in which bytes
were placed in those words is not considered a characteristic of the
file, so there is no byte size or bit packing mode associated with the
file. (There is a four-bit "mode" field, but it is really meaningless
because it reflects only the IO mode in which the file was opened, not
the way in which bytes were placed in words, and it is sufficiently
useless that it tends to disappear--programs that copy files often
destroy the mode field.)
(Note--Apparently, in prehistoric times, TOPS-10 maintained file
lengths in blocks instead of words. CS decided to keep that behavior
as default, so there is a "true size" flag that must be set upon
startup in order to work properly. Thus, everybody does a TRUSZ$ call
after the RESET. If you open a channel with FILOP rather than OPEN, I
ignore the "true size" flag for IO on that channel, so it's a problem
only if you do OPENs. Other than the "true size" nonsense, there are
very few differences between TOPS-10 and CS disk IO.)
Under TOPS-10, the file is a sequence of blocks numbered from 1.
Unlike TOPS-20, there are no monitor calls to read bytes--you always
read blocks and break them into bytes yourself. There are
fundamentally two ways to read the blocks, buffered mode or dump mode.
In dump mode (017 in the low-order four bits of the IO status when you
open the channel), the IN or OUT calls take a command list of IOWDs,
each IOWD transferring an integral number of blocks.
In the buffered modes, each IN or OUT conceptually transfers one
block, using a ring of one-block-long buffers with a header that
contains a byte pointer and count into the "current" buffer being
filled or emptied.
In either case, the USETI/O functions can position to a different
block of the file for subsequent IO calls. USETs are a little tricky
in buffered mode, though, requiring some extra handling of the
buffers.
In buffered mode, the byte size in the byte pointer in the header is
initialized by the OPEN depending on the mode: for mode 0 or 1, 7-bit
bytes; for mode 010, 36-bit bytes. You can subsequently change the
size, and the new size will be used for subsequent calculations.
Internally, counts are maintained in words. An input call reads a
block into the buffer, calculates the number of bytes per word based
on the size indicated in the byte pointer, multiplies that by the
number of words in the buffer (for disks, always 128 except for the
last block of the file), and returns that as the byte count.
An output call ignores the byte size and count; it calculates the
number of words in the buffer by subtracting the address of the first
word of the buffer from the address in the byte pointer. (There is a
mode bit that tells the monitor to ignore the byte pointer and instead
believe a word count that you place in the buffer.)
Of course, the byte size doesn't affect the data in the buffer, which
is a bit-for-bit copy of the block on disk. For example, a text file
is stored with five characters per word. If you change the byte
pointer to use 8 bit bytes and read a block, your first eight-bit byte
would contain the first ASCII character in its high-order seven bits
and the high-order bit of the second character in its low-order bit.
In our case, there are two bit-packing modes of primary interest to a
program interpreting a file as a byte stream. What seems to be
conceptually cleanest in our environment is to interpret text and
binary files like this (assuming, for the moment, that a char is eight
bits wide):
Text: fopen("test.txt","rt")--stored on disk as a sequence of 7-bit
bytes. On input, 7-bit bytes have a leading zero bit prefixed;
CRLF pairs are translated to \n (would a lone CR be passed or
discarded?). On output, 8-bit bytes have the MSB discarded, and
\n translated to CRLF pairs. An additional mode flag should
allow suppression of newline manipulation.
Binary: fopen("test.arc","rb")--stored on disk as a sequence of 8-bit
bytes. No translation.
We already have several programs that have the concept of "binary"
files as streams of eight-bit bytes, a format we use for uploading and
downloading arbitrary files to or from a PC or for processing .arc-
format files, for example. Such a file is stored on disk as a
sequence of octets, four per word, with the low-order four bits of
each word set to zero.
To avoid rounding up the length to a multiple of four octets (a result
of file lengths being maintained in words), our convention is that the
low-order four bits of the last word in the file contains the number
of unused bytes in that word (the low-order bits in all other words
are 0; logically, they should be zero to indicate that no bytes within
the word are skipped, and they allow programs to infer that it's a
"binary" file).
By the way, as you noted in question 14, one glitch in ASCII files
under TOPS-10 is that you must discard nulls, at least at the end of
the file (most programs ignore them anywhere), because file lengths
are maintained only to the word.
---------------------------------------------------------------------------
This may be a duplicate message. Drop me a note when you get this.
---------------------------------------------------------------------------
22-Apr-89 23:07:49-PDT,359;001000000011
Mail-From: KLH created at 22-Apr-89 23:07:43
Date: Sat, 22 Apr 89 23:07:43 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Answers
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <8904220326.AA25950@tut.cis.ohio-state.edu>
Message-ID: <12488344957.20.KLH@SRI-NIC.ARPA>
Got the duplicate too.
-------
22-Apr-89 23:47:52-PDT,5743;001000000001
Mail-From: KLH created at 22-Apr-89 23:47:46
Date: Sat, 22 Apr 89 23:47:46 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: T10 answer comments, more Qs
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <12488344957.20.KLH@SRI-NIC.ARPA>
Message-ID: <12488352247.20.KLH@SRI-NIC.ARPA>
OK, some comments on the answers, and some more questions! Actually, my
original missive was getting overly long, so I've decided to break things
up into separate messages. This one just talks about the previous questions;
following messages will bring up other things.
(0) OK, it should be no problem to cross-compile .SAV and .REL files
which can be run directly on CSI; just have to get them there. That
part of my question was apparently overlooked -- how do you want to
gt them there? Can you read TOPS-20 DUMPER tapes, or do you want to
use FTP to Ohio-State.EDU, or what?
(1) OK, SYS_CSI it is.
(2) No SFDs? Arrgh! Let me rephrase the question: KCC needs a
standard directory location for its #include header files and library
.REL files. I assume a logical name is the best means of doing this
on T10 (it's C: on TOPS-20). If so, what logical name do you want to
use? What logical name do you want to use for another UFD that will
be the "sys" subdirectory? (Will have another msg about SFDs later)
Incidentally, all current #include <xxx.h> files already limit xxx to
6 characters, so there is no mapping problem there.
(3) OK, no problem with filename syntax. Two more related questions:
Do you want "node::" to be an acceptable component?
I don't have any documentation that directly describes the syntax
for specifying protection; you mentioned <055> and (2). Are these
always suffixed if present, no separating spaces, etc? If you
want the latter form too, I'll need the mapping algorithm.
(4) OK, will permit 'xxx' on CSI, and both "xxx" and \x\x\x on either T10/CSI.
(5) Hmmm, how does your mail software know what your "name" is? I know
this isn't necessarily a "user name"; still, if there is any kind of
mapping between real names and PPNs (not necessarily 1-1) then it would
be possible for cuserid() and getlogin() to work, and these are very nice
functions to have.
(6) Protection context -- where T10 software is concerned, the T10-Unix
mapping doesn't matter much since you'll be able to specify the exact
T10 protection as part of the filename. It mostly affects programs which
you want to port to or from Unix and thus which may be using Unix protection
codes; ideally they would do something "reasonable" on T10. I'll just set
up a simple mapping and it can be changed later if there is any need.
(7) OK, I can handle the TMPCOR and runoffset+1 stuff; the hooks are all
already there, and the compiler itself has code to use that mechanism (so
it can be invoked as a COMPIL-class command, and call LINK itself). I'll
have to move some of it out into the forkexec() library function, though.
The most general method is definitely to use RESCAN, so if you can provide
a way to stuff this buffer, that would be a great simplification. TOPS-20
RSCAN% allows this, so there's ample precedent.
There are two other ideas in conjunction with this:
(1) KCC-compiled programs could all simply look for the "KCC"
TMPCOR filename if started at +1. There is no need to maintain
several TMPCOR files. Invoking forkexec() with TMPCOR args but
without a specific name will simply use "KCC" as the default.
(2) If there is a way to emulate, via LOOKUP, the search that
RUN does to find the program binary file, AND if there is some
variable in the extended lookup block that can reliably be used
to determine whether the program was KCC-compiled or not, THEN
we can invent almost any mechanism we want for the two programs
to cooperate in passing arguments. This may be overkill, but is
a possibility to keep in mind.
(8) Thanks for the confirmation on I/O bytesize.
(9) Hmmm. The runtime can detect a user attempt to open TTY: and map
it into an existing open channel, so that is not a serious problem.
I'm mostly wondering more whether it's considered more efficient to
use the TTCALLs for I/O to the controlling terminal, or whether it is
better to OPEN TTY: and use a normal I/O channel. In the absence of any
preference, I'll do the former.
(10) OK, no primary I/O redirection. With no fork() that doesn't matter
much, I guess.
(11) Actually, although pipe() as a call probably can't be done, it would
be possible to implement the "proga | progb | progc" command line syntax
as long as the programs didn't require interactive input; just use
temporary files and pass along the remainder of the command line from
program to program. I won't pursue this, but if you ever want it, it can
be done.
(12) OK, no system() for now.
(13) "There's no way to ask where you are within a file." Arrrgh!!!
I was still hoping it wasn't so!
(14) OK. Do you want anything special done when appending to a text file?
That is, should the code examine the last word and back up over any zero
bytes?
(15) OK on max disk file size.
(16) Hmmm. So is there a way to figure out which argument-passing
convention is being used? I can see the glimmerings of a method (like
"check initial word for RUN, RU, R, <etcetc>, if see ';' do one thing,
if '(' another thing...). KCC permits the program to determine, at
compile time, how it wants its args furnished, but of course it would
be optimal if the runtime could figure it out for maximum flexibility.
Good point about GTNAM$, forget it then.
More stuff in following msgs, re I/O, SFDs, signals.
-------
22-Apr-89 23:56:46-PDT,2395;001000000001
Mail-From: KLH created at 22-Apr-89 23:56:38
Date: Sat, 22 Apr 89 23:56:37 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: T10 Q: SFDs
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <12488344957.20.KLH@SRI-NIC.ARPA>
Message-ID: <12488353860.20.KLH@SRI-NIC.ARPA>
Not having subdirectories poses a problem. Apart from
whatever assumptions imported programs might make, the KCC sources
themselves are organized using subdirectories, as on Unix. These dirs
correspond to:
Compiler source:
kcc
Include files:
include
include/sys
Library source:
lib (general)
lib/stdio (STDIO rtns)
lib/usys (Unix syscall rtns)
lib/math (math rtns)
lib/* (misc seldom-used stuff)
Unless you want to consider installing SFDs (not likely, huh?), it
seems like we'd have to create a "KCC" project # and make a UFD for
each subdir, each having a different programmer #. How scarce a
resource are UFDs? While it doesn't make much sense to combine the
three categories above, I could probably merge all of the library
subdirs into a single directory by renaming all of the filenames and
changing the .MIC files and stuff. I'd prefer not to, because that makes
things more unpleasant looking for other systems, but if it's a
real problem...
There's one other idea, which may be too advanced for a first
step but could be implemented later: do a simulation. One way that
this might be done is by using a convention that any empty file with
the extension "CFD" is to be considered a "C File Dir" which points to
a real UFD. The .RBNCA (user-settable) word can be used to hold the
UFD's PPN. Any pathname given to the C library code would track these
CFD pointers.
So, for example, attempting to open the pathname "lib/stdio/fget.c" would
first check for LIB.CFD in the current UFD, to get another UFD wherein it
looks for STDIO.CFD to get the final UFD where FGETC.C should be located.
Backtracking can be done simply by having a .CFD filename of ".." which
points to the "parent" UFD. This is almost like having links.
I don't know if this is a feasible proposal, but it illustrates one idea.
Since it's not really needed for KCC or for C, it will depend on how involved
you want to get in porting software to and from Unix-like systems. It sure
is a nice feature to have, though.
-------
23-Apr-89 00:18:47-PDT,2166;001000000001
Mail-From: KLH created at 23-Apr-89 00:18:42
Date: Sun, 23 Apr 89 00:18:42 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: T10 I/O Qs
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <12488344957.20.KLH@SRI-NIC.ARPA>
Message-ID: <12488357879.20.KLH@SRI-NIC.ARPA>
Thanks for the long explanation of I/O, it clarified some things.
Have you read the STDIO part of the KCC LIBC.DOC file, which describes
the args to fopen()? Please do if you haven't, and comment on the
current implementation.
Basically, "binary" files are treated as having 9-bit bytes -- not
8-bit. There are lots of things in C that depend on bytes completely
describing a word, and it really is much better if binary files use
the same bytesize.
It is possible to open() and fopen() a file with 8-bit bytes, using a
nonportable convention, and I can certainly adopt the (also
nonportable) convention you describe for finding the last byte. That
won't work for anything else, of course. Naturally, what I'd REALLY
like to see supported is a way of setting or determining both the
bytesize and the EOF of a file. It might be sufficient just to know whether
a file had been generated by a KCC program or not, since if so the runtime
could do some arcane poking around to get this information.
I note that more recent versions of TOPS-10 have re-used some RIB
locations to carry precisely this sort of information -- .RBTYP,
.RBBSZ, .RBRSZ, .RBFFB. A pity these aren't available.
Buffering or DUMP mode?
Could you elaborate on the use of USETI/O with buffered I/O,
since things like fseek/lseek, append, and update mode will depend on this.
I've been assuming that you'd prefer the I/O routines to use buffering
rather than dump mode, to trade off some runtime complexity for better
throughput. But if it doesn't matter, perhaps it would be better to just
use dump mode throughout, to avoid synchronization problems?
I was not planning to implement any of this in the initial port
since it is not needed for the compiler, but the clearer this is now, the
better I can prepare the groundwork.
-------
23-Apr-89 00:33:58-PDT,1327;001000000001
Mail-From: KLH created at 23-Apr-89 00:33:53
Date: Sun, 23 Apr 89 00:33:53 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: T10 memory alloc
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <12488344957.20.KLH@SRI-NIC.ARPA>
Message-ID: <12488360642.20.KLH@SRI-NIC.ARPA>
Is there any reasonable way to get access to the unused address
space above the high segment, and use it for dynamically allocated
memory, or stack storage, etc? Some programs are going to want all the
malloc-able storage they can get. It doesn't look like there is a way to
do this with standard TOPS-10, but your system might have this capability
with GCORE$ and RCORE$.
Otherwise, the way I'll have to set up the runtime is to use the
space between the low and high segments for both the stack and malloc'd
memory, using the CORE UUO. I assume there is no reason to ever prefer that
KCC programs be one-segment; they are always two-segment, with all executable
code in the high segment and all variables in the low segment.
I'm a little concerned about these TOPS-10 user core
allocation restrictions I keep reading about. Do you actually use
them? The KCC runtime simply assumes it has the full address space
available until told otherwise by a failing system call.
-------
23-Apr-89 01:33:36-PDT,2305;001000000001
Mail-From: KLH created at 23-Apr-89 01:33:06
Date: Sun, 23 Apr 89 01:33:05 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: T10 signals
To: hbj@cis.ohio-state.edu
cc: ben@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <12488344957.20.KLH@SRI-NIC.ARPA>
Message-ID: <12488371419.20.KLH@SRI-NIC.ARPA>
You mentioned once that you did want to be able to use signal(). That is
probably going to be the most difficult part of this whole port, depending
on how much of the T10 and Unix interrupt systems you want to merge. When
I wrote the TOPS-20 code for sigvec() (the new BSD generalized call) it
took a long time (over a month at least) to figure out how it should work
and get it working. Very painful.
However, I understand that TOPS-10 UUOs are never interrupted, thus one
is always dealing with a user (not monitor) PC. If true, this helps.
Some. Let's see..
It appears that APRENB traps and .JBINT error intercepts are all subsumed
by the software interrupt system (SIS), and that therefore SIS is the
right mechanism to use. However, it's not clear whether the existence
of CSI's PIINI$ means that DEC's PIINI. UUO is not implemented, or is
implemented in parallel. Which should be used -- SIS or CSISIS? (hmm, this
is sounding like a name-calling contest :-)
Is it reasonable to leave the SIS turned off unless the user program
explicitly invokes signal() to catch something? This is how it's done
on TOPS-20, to avoid pointless overhead.
Have you thought about how you would like to map the ANSI signal types,
specifically
SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, SIGTERM
or would you like to support as many of the UNIX signals as possible,
or do you want to provide a way for signal() to handle any CSI interrupt
condition?
Do you want to emulate the 4.3BSD sigvec() mechanism, including
sigpause(), sigblock(), etc? I hope you have access to a local BSD
UPM manual set; if not, let me know and I can send descriptions.
Actually, it would probably be a good idea if you read the KCC
source code and doc to get an idea of what's involved. The
SIGNAL.DOC file is a good start; then there are the two files it
references, namely USYS/CODSIG.DOC and USYS/SIGVEC.C.
It all depends on how fancy you want to get...
-------
24-Apr-89 00:13:06-PDT,4245;001000000001
Mail-From: KLH created at 24-Apr-89 00:13:04
Date: Mon, 24 Apr 89 00:13:04 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC progress
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12488618996.20.KLH@SRI-NIC.ARPA>
I think I'm ready to try generating a KCC for WAITS. Here's my general
plan, plus some questions (but feel free to comment on anything).
First, I'll generate a LIBC.REL and CC.REL for WAITS.
I don't know anything about the .DMP format WAITS uses, so I'm not sure
any binary I can generate would execute directly on WAITS, but I'm pretty
sure that the .REL file format is portable and the WAITS linker can be
used to generate the CC.DMP binary.
At this point, you could FTP over the necessary files and continue, or
I can do it if (1) you set up an account for me, and (2) the net connection
from here to SAIL isn't too horrible.
Initially we'll need two publicly readable directories, which
correspond to /usr/include and /usr/include/sys. On TOPS-20 these are
identified by C: (with a subdirectory <.SYS>). Do you support
anything like logical names, so that we could (for example) use C: and
CSYS:? Nice, but not necessary. Perhaps these dirs can be [SYS,KCC]
and [SYS,KCS]; or [KCC,INC] and [KCC,INS]. Note that if you want to
get the KCC sources later, those will take up at least another three
dirs, so some kind of logical organization around the name "KCC" would
be handy.
I'll need to know the names of these dirs before I can generate the WAITS
KCC.
Anyway, the port is then simply a matter of FTPing the two .REL files plus
a bunch of .H files, and testing KCC.
Actually, come to think of it, instead of starting with KCC itself, I could
just cross-compile some small test programs which either I or you could
then bring over to WAITS and try out, to verify that the basic I/O and
stuff works as it should.
I don't think it makes sense to copy over the entire library or compiler
source for awhile. It is going to be changing continuously for the next
month or two. Bug fixes and additions can be done by editing the files
here and cross-compiling to produce new .RELs.
Various other questions, shouldn't hold up the above plan:
Is there any way for a program to "stuff" its RESCAN buffer just before
RUN-ing another program, so as to pretend the user typed that command line?
This would be a very convenient way of passing arguments.
I don't suppose there is any way that a file's "bytesize" and "length in
bytes" can be set and later obtained?
Should "text" I/O mode (which is 7-bit and does CRLF<->LF conversion)
ignore all NUL chars, not just those in the last word? "Binary" mode
is 9-bit, by the way.
Have you thought any more about a scheme for simulating subdirs (using
"link" files with an extension of ".CFD")? Not necessary, of course.
When you type in a filename, is the normal syntax dev:name.ext[ppn] or
dev:[ppn]name.ext? Do you have an additional syntax to specify protection,
like DEC's dev:name.ext[ppn]<prot>?
How do you want to quote filename components? The SAIL Monitor Command
manual says you use "down arrows" like quote marks, which I assume means
the character valued 01 (control-A elsewhere). Is it OK to also use
double-quotes like DEC? Is it OK to permit a single-char quoter like
'\' to quote the following char, like Unix?
Is there a description of .DMP file format someplace, or do you know
whether it corresponds to the old 10/50 .SAV format that TENEX/TOPS-20
still support? (That could simplify things...)
How do you map from PPNs to "user names"? That is, how would you like
the functions cuserid() and getlogin() to work?
If you have time to think about it, how do you want WAITS file protections
mapped to and from UNIX file protections? (I already have a kludge in place)
Is it lots better to do disk I/O using buffered mode rather than dump
mode? What if you're doing both read/write and USETI/O on a file, so as
to move around making random changes?
Is there any way to get access to the unused address space above the
high segment, for dynamic memory allocation?
Do you think you'll ever want signal() to do something?
-------
24-Apr-89 00:56:58-PDT,600;001000000001
Mail-From: KLH created at 24-Apr-89 00:56:57
Date: Mon, 24 Apr 89 00:56:57 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC - symbols needed
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12488626986.20.KLH@SRI-NIC.ARPA>
Hmm, almost forgot. It would be handy to have a .UNV file of WAITS
symbols, specifically the UUOs and any other symbols that are normally
considered available to the FAIL user. Otherwise I'll have to plug in
those values by hand to cross-compile. The DEC UUOSYM.UNV file takes
care of most things, but not the WAITS-specific stuff.
-------
24-Apr-89 01:06:18-PDT,858;001000000001
Mail-From: KLH created at 24-Apr-89 01:06:17
Date: Mon, 24 Apr 89 01:06:16 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC and SHOWIT
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12488628682.20.KLH@SRI-NIC.ARPA>
Although this won't be needed for awhile, could you clarify how you want
SHOWIT to be invoked? Do you want it called on each input file that was
specified in the command line, or (because most input files do some #includes)
do you want it to always show the current source of input? The latter is
a bit more painful and doesn't seem necessary as most of the compiler's time
is spent on code generation rather than .h file parsing.
Is it necessary to make a final SHOWIT at the end of the program to turn
things off, or does that happen automatically when channel is closed or
the job exits?
-------
24-Apr-89 07:23:20-PDT,550;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 24 Apr 89 07:22:40 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA17186; Mon, 24 Apr 89 10:11:10 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA09161; 24 Apr 89 10:07:57 EST (Mon)
Date: 24 Apr 89 09:00:04 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Yes to DUMPER tapes
Message-Id: <"CSI 5557-760"@CompuServe.COM>
to: Ken
fr: Benny Jones
Yes -- we can read DUMPER tapes.
24-Apr-89 08:14:54-PDT,1939;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 24 Apr 89 08:09:47 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA22929; Mon, 24 Apr 89 11:08:30 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA09977; 24 Apr 89 10:46:10 EST (Mon)
Date: 24 Apr 89 10:10:31 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Miscellanea
Message-Id: <"CSI 5557-1491"@CompuServe.COM>
to: Ken
fr: Benny Jones
We can ignore the "node::" component in file specifications.
Protection is not required to be suffixed. Our parsers
allow it to be anywhere (although some placements may not
make sense). I'll send you Compuserve <=> DEC protection mappings.
Our OS has no concept of "real names". It only knows about PPNs.
Our mail system addresses (names) is not associated with PPNs at
all.
You asked whether it's more efficient to use TTCALLs for I/O to
the controlling terminal or to OPEN TTY: and use a normal I/O
channel. I'm told it's about 50/50. However, I will be sending
you some documentation on some recently implemented TRMOPS.
Since TTCALLs are not interruptible, if a hangup occurs while
a program is doing a lengthy OUTSTR, the interrupt service is
not called and the normal cleanup activities do not execute. It
was felt we needed interruptible terminal I/O. Hence a couple
of new TRMOPs. I'll send you the documentation in a separate
message.
What to do when appending to a text file? Interesting question.
Most of our programs probably start at the next word. If you are
willing to have the code examine the last word and back up over null
bytes, then that certainly sounds desirable.
How to figure out argument-passing mechanism. Your idea of
"check initial word for RUN, RU, R, see if ';', do one thing,
if '(' do another" is probably the best.
24-Apr-89 09:15:27-PDT,1530;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 24 Apr 89 09:14:50 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA17243; Mon, 24 Apr 89 10:11:23 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA09194; 24 Apr 89 10:08:40 EST (Mon)
Date: 24 Apr 89 09:55:24 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: SFD considerations
Message-Id: <"CSI 5557-1321"@CompuServe.COM>
to: Ken
fr: Benny Jones
The lack of SFDs is a sticky problem. We (CompuServe) have never
had SFDs. I don't know why that is.
I realize that this will impact porting software to and from
Unix systems, but it seems we are able to accept that. With
this in mind, I guess I have to ask for (more) special CompuServe
consideration in the construction of .MIC files and stuff.
UFDs are not particularly scarce, and the use of 4 or 5 UFDs
for the purposes of compiler/library construction is fine.
For example, a compiler's primary source files might reside
in [311,1000]. It's library source files might reside in
[311,1001]. We define C: to point to [311,1001] prior to
rebuilding the compiler in order that the rebuild use the
library sources in [311,1001].
As in your system, let's use C: for the logical name for
the PPN containing #include header files and library .REL
files. Can we avoid worrying about the sys subdirectory?
Can we assume it will also be C: or will there be name
collisions?
24-Apr-89 10:56:32-PDT,2753;001000000001
Mail-From: KLH created at 24-Apr-89 10:56:18
Date: Mon, 24 Apr 89 10:56:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: SFD considerations
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA, hjb@cis.ohio-state.edu
In-Reply-To: <"CSI 5557-1321"@CompuServe.COM>
Message-ID: <12488736092.20.KLH@SRI-NIC.ARPA>
About merging C: with its "sys" subdirectory...
Considering that the library files LIBxxx.REL are already "merged"
into C:, there is some precedent for this sort of merging. However,
there is at least one name conflict (time.h), and there may be others
in the future. In general, the <x.h> files are for portable (ANSI) C
stuff, and the <sys/x.h> files are for UNIX (BSD) system call defs.
There are not many of them, but the names are standard and it's hard
to think of an algorithmic way to map them into 6-char names in the
general directory.
The simplest immediate solution (ie requires no additional changes
to KCC code) is to use another UFD and another logical name, such as
CSYS:. I recently added a switch that permits specifying a
non-standard location for <sys/x.h> files. Note that using simulated
SFDs (as per my .CFD suggestion) would not eliminate the need for
another UFD, although CSYS: would be unnecessary.
On the other hand, it's pretty common now to have other subdirs
(besides sys) in /usr/include, so ideally we need a method applicable
to more things than just "sys". At the NIC we already have such
subdirs, although they aren't distributed as part of KCC. Given that
desiderata, either subdirectories need to be simulated, or KCC has to
be changed.
I already described one way of simulating subdirs. Looking at the option
of changing KCC, I have two thoughts:
[1] An extremely blunt method would be to just keep a table of those
names within the compiler itself. This would mean rebuilding the
compiler each time a new <subdir/x.h> file was added, or if the mapped name
were changed to avoid conflict with a new <x.h> file.
[2] A more flexible variant of [1] would be to keep a file called
(e.g.) <includ.map> which the compiler knows about; this would be a
text file with one line per mapping, of the format
<fullname> <mapname>
and the compiler would have to read it in at runtime the first time it
encounters an #include <dir/x.h>. So, for example, there would be entries
like this:
<sys/time.h> <s-time.h>
<sys/timeb.h> <s-timb.h>
<sys/times.h> <s-tims.h>
This isn't too hard to do, and would be readily acceptable if TOPS-10
were the only system that KCC had to support. But it's not, and I do
want to keep things consistent -- so I'm trying to decide just how
ugly this would look on TOPS-20.
Any other ideas?
-------
24-Apr-89 11:14:20-PDT,783;001000000001
Mail-From: KLH created at 24-Apr-89 11:14:02
Date: Mon, 24 Apr 89 11:14:02 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: one more try on "real names"
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA, hbj@cis.ohio-state.edu
In-Reply-To: <"CSI 5557-1491"@CompuServe.COM>
Message-ID: <12488739323.20.KLH@SRI-NIC.ARPA>
The Unix OS doesn't have any concept of "real name" either! It's all
done outside the kernel with /etc/passwd or other data files.
How does your mail system identify senders and receivers? I have been
assuming that people don't just use identifiers like [1234,567], and
also that they don't all maintain idiosyncratic nickname maps; i.e.
that there is a central registry someplace. No? If not, I give up; how
does it work, then?
-------
24-Apr-89 12:25:22-PDT,413;001000000001
Mail-From: KLH created at 24-Apr-89 12:25:12
Date: Mon, 24 Apr 89 12:25:12 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: another Q...
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12488752278.20.KLH@SRI-NIC.ARPA>
Is there any convention on WAITS for naming "temporary files" that will
go away when the job is logged out, or at least that will get reaped once
in a while?
-------
24-Apr-89 12:36:44-PDT,608;001000000001
Mail-From: KLH created at 24-Apr-89 12:36:34
Date: Mon, 24 Apr 89 12:36:32 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Q re temp files
To: BEN@csi.compuserve.com
cc: klh@SRI-NIC.ARPA, hbj@cis.ohio-state.edu
In-Reply-To: <"CSI 5555-8079"@CompuServe.COM>
Message-ID: <12488754342.20.KLH@SRI-NIC.ARPA>
Um, is there any convention on TOPS-10 or your system where a job can
create "temporary" files that are deleted when the job logs out, or which
at least will be reaped every once in a while?
It's unclear to me whether anything treats the extension ".TMP" seriously
or not.
-------
24-Apr-89 13:03:44-PDT,1460;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 24 Apr 89 13:03:07 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA09520; Mon, 24 Apr 89 16:02:27 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA00398; 24 Apr 89 15:43:20 EST (Mon)
Date: 24 Apr 89 15:30:09 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: No usernames
Message-Id: <"CSI 5557-4083"@CompuServe.COM>
to: Ken
fr: Benny Jones
We have a special mail program that runs in a special PPN. It's
called InfoPlex. When we log into the special PPN, InfoPlex runs.
It asks us our address code. I type in BEN. It then asks me my
access code. I type that in. I'm then into the mail system and
can receive, send, and compose messages. InfoPlex is only on one
host. We have dozens of hosts, but have to depend on one for mail.
If it goes down, we can't get or send mail. Neither are we able
to be notified asynchronously of mail sent to us. InfoPlex does not
know what account we may be logged into.
So, while we do have password files on each host, InfoPlex knows nothing
about them (even the ones on the InfoPlex host).
When a new person is hired, they are assigned an address code (usually
their initial, a dot, and their last name) and a secret access code.
This is what they use to get into InfoPlex.
I don't think we have anything analogous to usernames.
24-Apr-89 13:10:56-PDT,523;001000000001
Mail-From: KLH created at 24-Apr-89 13:10:54
Date: Mon, 24 Apr 89 13:10:53 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: No usernames
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5557-4083"@CompuServe.COM>
Message-ID: <12488760596.20.KLH@SRI-NIC.ARPA>
OK, I get it now. I'm so used to having host access/login equate to mail
access/login that I had a hard time believing the mail info was completely
independent of the host login stuff. Thanks for the explanation.
-------
24-Apr-89 14:53:36-PDT,1293;001000000015
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Mon, 24 Apr 89 14:53:33 PDT
Message-ID: <1sTs5G@SAIL.Stanford.EDU>
Date: 24 Apr 89 1453 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: another Q...
To: KLH@SRI-NIC.ARPA
I'll try to send you some more answers tonight or tomorrow. I have an
idea for the subdirectory kludge, although I don't know if it's worth
using.
We'll use [*,KCC] directories for all the stuff. I guess it should be
[INC,KCC] for /usr/include, [INS,KCC] for /usr/include/sys.
Filename syntax is dev:name.ext[prj,prg]. No, there's no protection
syntax, outside of COPY (/PRO=777).
The .DMP files are not compressed and start with word 74 (octal) of the
core image. Our FILEX documentation describes this as "old PDP-6 format".
This seems to be the same as .XPN format except without the first 74
words.
All null bytes should be ignored in text files. Also, if a text file
starts with:
COMMENT xxVALID 00000 PAGES
where the 0's can be any digits and the "xx" can be " " or "IN", then
this is an E directory page and should be ignored up to the first formfeed
('014). (That's a ^V ('026) after the "COMMENT".) Files don't (usually)
end with formfeeds, by the way.
25-Apr-89 09:24:05-PDT,1137;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 25 Apr 89 09:23:14 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA02055; Tue, 25 Apr 89 12:19:40 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA20639; 25 Apr 89 11:04:10 EST (Tue)
Date: 24 Apr 89 16:07:31 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: SFDs
Message-Id: <"CSI 5557-4366"@CompuServe.COM>
to: Ken
fr: Benny
Consider this for SFDs. We can define logical names for PPNs.
If, in an include file, there is a subdirectory specified, could
KCC be made to look for a defined logical name based on some
variation of the subdirectory name? For example,
#include sys/time.h /* Here KCC would look for CSYS: */
#include usr/x.h /* Here KCC might look for CUSR: */
#include usr/sys/time.h /* Here KCC looks for CUSYS: */
etc.
It would be the responsibility of the programmer (or monitor) to
ensure that these logical names are defined.
Also, would it be possible to support something like
#include "[311,1000]common.h"
25-Apr-89 11:10:06-PDT,1186;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 25 Apr 89 11:06:34 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA07017; Tue, 25 Apr 89 14:05:21 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA00604; 25 Apr 89 13:56:09 EST (Tue)
Date: 25 Apr 89 11:45:21 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Some signal stuff
Message-Id: <"CSI 5557-8259"@CompuServe.COM>
Ken -- Here's the first message about signals...
DEC's software system is not implemented or supported.
We'll need support for the CSI software interrupt system.
Yes, it is reasonable / desirable to leave the SIS turned off
unless the user explicitly invokes signal() to catch something.
We'd like to have signal handle any CSI interrupt condition.
Let's try the following mappings of ANSI signals to interrupt events:
SIGABRT ==> $PIECC (ref section 5.3.8 of COUGH DROPS)
SIGFPE ==> $PIEOV
SIGILL ==> $PIEII
SIGINT ==> $PIEBK
SIGSEGV ==> $PIEIR
SIGTERM ==> $PIEKL
More info is coming on other unanswered topics. Just trying to
get it all together.
25-Apr-89 17:10:19-PDT,4340;001000000001
Mail-From: KLH created at 25-Apr-89 17:10:03
Date: Tue, 25 Apr 89 17:10:03 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: SFDs
To: BEN@csi.compuserve.com
cc: hbj@cis.ohio-state.edu, KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5557-4366"@CompuServe.COM>
Message-ID: <12489066277.20.KLH@SRI-NIC.ARPA>
If, in an include file, there is a subdirectory specified, could
KCC be made to look for a defined logical name based on some
variation of the subdirectory name? For example...
Yes, but again there is the problem of specifying how "some variation"
is arrived at. "usr/sys/" into CUSYS: isn't obvious. The
<includ.map> strategem I mentioned previously could include directory
mappings, so that this can be represented as a line of the form:
<usr/sys/> CUSYS:
or just use a PPN instead of a logical name. I would still prefer to
have such a file even with these logical names available, due to the
greater (and safer) flexibility.
Also, would it be possible to support something like
#include "[311,1000]common.h"
Oh yes, but I think I should explain why, because I suspect there may
be a slight confusion here. The extent to which KCC (meaning the
compiler) understands #include file names is very limited, in the
sense that the filename argument is treated like an arbitrary string.
If it is delimited by <> then a site-dependent (or switch-specified)
prefix and suffix is tacked on to that string, and the result given to
STDIO's fopen(), which calls USYS's open(). Everything else follows
automatically from the USYS code, which provides the Unix emulation.
KCC does not (and ideally should never) parse the filename.
Because the USYS filename parser (used by every system call that
requires a pathname) will support "[ppn]file.ext", your example will
work. Here is a fuller description of what it will handle:
/* T10/WAITS filespec parser
** This parser is able to handle filename strings which are in standard
** TOPS-10 format, or UNIX format, or a combination thereof.
** The general syntax is:
** {node::} {dev:} {[dirpath]} {upath} {filename} {[dirpath]}
**
** node - a TOPS-10 network site name (single word).
** dev - Device or logical structure name (single word).
** [dirpath] - a TOPS-10 directory path, syntax: [P,PN{,sfds}]
** If present, must always contain the UFD (PPN).
** It may contain SFDs after the PPN.
** Only one [dirpath] may be given.
** upath - a UNIX-style directory path, syntax: {/}{upath | name}/
** filename - Syntax is: name{. | .ext}
** i.e. "name", "name.", or "name.ext"
**
** The "upath" syntax has these peculiarities:
** - An absolute dirpath (begins with "/") must have a PPN after the "/".
** - A relative dirpath is relative to the "default directory path"
** as returned by PATH. if there is no device, or the "current
** path" for the specified device.
** - A PPN has the syntax "n,n" on TOPS-10; "nam,nam" on WAITS.
** Due to possible future ambiguity ("n/n"), it is a bad
** idea to use a PPN as the first part of a relative pathname.
** - "." may be given as a directory name.
** - ".." can be given also.
** - Someday, "/dev/foo" could become FOO:, but why?
** - A upath can be combined with a [dirpath], however the upath cannot
** start with a '/' or a PPN; it is considered to be relative
** to [dirpath].
*/
So, as you can see, the USYS code provides a very general common interface
to any C program, including KCC. This is why a SFD-simulation scheme is
both feasible (because everything goes through a common parser) and useful
(because it will work for everything, not just for the compiler). By
comparison, using either the <includ.map> idea or the logical-name-transform
idea is a kludge that is specific to the compiler alone, and just for #include
files enclosed in <>s.
We can get along fine for the time being just with C: and CSYS:, so
this certainly isn't something that needs to be decided right away. I
hope the above explains a bit better why I am ultimately more
interested in the notion of subdirectory simulation.
-------
28-Apr-89 02:28:16-PDT,588;001000000001
Mail-From: KLH created at 28-Apr-89 02:28:08
Date: Fri, 28 Apr 89 02:28:08 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: another Q...
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <1sTs5G@SAIL.Stanford.EDU>
Message-ID: <12489692161.28.KLH@SRI-NIC.ARPA>
OK so far, although the hack of trying to ignore E directory pages seems
like a pretty gross thing to do. It's hard to believe that all user
programs have to do this kind of thing; shouldn't the monitor be taking
care of it? Oh well, it can be done. What was your idea about subdirs?
-------
28-Apr-89 07:37:26-PDT,3344;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 28 Apr 89 07:34:24 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA28233; Fri, 28 Apr 89 10:32:11 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA01729; 28 Apr 89 09:56:17 EST (Fri)
Date: 28 Apr 89 09:19:13 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Returned mail: Host unknown
Message-Id: <"CSI 5558-6087"@CompuServe.COM>
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA00546; 27 Apr 89 17:19:57 EST (Thu)
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA08105; Thu, 27 Apr 89 14:42:21 EDT
Date: Thu, 27 Apr 89 14:42:21 EDT
From: Mail Delivery Subsystem <Mailer-Daemon@tut.cis.ohio-state.edu>
Subject: Returned mail: Host unknown
Message-Id: <8904271842.AA08105@tut.cis.ohio-state.edu>
To: ben@csi.compuserve.com
----- Transcript of session follows -----
550 sri-nic.arap!klh@rutgers.edu... Host unknown
----- Unsent message follows -----
Received: by tut.cis.ohio-state.edu (5.59/3.890421)
id AA08094; Thu, 27 Apr 89 14:42:26 EDT
Received: by osu-cis.cis.ohio-state.edu (smail2.5)
id AA08173; 27 Apr 89 14:14:45 EST (Thu)
Date: 27 Apr 89 13:57:17 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@SRI-NIC.ARAP>
Subject: Subdirectories
Message-Id: <"CSI 5558-2970"@CompuServe.COM>
Ken...
Your method for dealing with subdirectories wins favor
around here.
...Benny
-----------------------------------------------------------------
Forwarded Message 5558-2886
Reply to: How to deal with subdirectories
It sounds reasonable to me. I like his <includ.map> idea better than
what we talked about. A couple of observations, none of which seem to
conflict with his ideas:
(1) Note that a TOPS-10-style directory may include null components.
It's legal to say [,] or [,100] or [333,] and the TOPS-10-specific
open() or fopen()--whichever is the one that actually parses the
string--should take the null component from the user's logged-in
PPN.
(2) I like the idea that <includ.map> may contain PPNs. The advantage
of PPNs is that neither we (the system) nor the user need define a
bunch of logical names. Such names would, I think, be of little
use. That is, if we defined logical names, I doubt that any human
would ever refer to them (you certainly wouldn't in source code).
Of course, if you want to examine a header file, you must understand
the <includ.map> mechanism. But that's easier than trying to
remember (or guess) a hardcoded "usr/sys/ maps to CUSYS:" approach.
And ideally, the documentation obviates much need to refer to the
.h's themselves.
And if you want to redirect one of the .h directories for some
reason, you can still do so--assuming we define a name C: as a
starting point, and the compiler looks for C:includ.map--by doing
copy c:includ.map to *.*
edit includ.map
define c: as dsk:
GSB for BEN 13:44 EDT 27-Apr-89 Message 5558-2886 forwarded by
INET:Mailer-Daemon@tut.cis.ohio-state.edu Mail Delivery Subsystem
09:11 EDT 28-Apr-89 (890428131131 515645.640000 CHB112-3)
for BEN 09:13 EDT 28-Apr-89 Message 5558-6049 forwarded by
28-Apr-89 15:21:55-PDT,1975;001000000001
Mail-From: KLH created at 28-Apr-89 15:21:48
Date: Fri, 28 Apr 89 15:21:48 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: map comments
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5558-6087"@CompuServe.COM>
Message-ID: <12489833003.28.KLH@SRI-NIC.ARPA>
A few acknowledgements. I won't be around this weekend, by the way. Hope
things are moving along.
Your method for dealing with subdirectories wins favor
around here.
Actually, includ.map is only a method for dealing with #include files,
not with subdirectories in general. I'm still interested in any
comments pro/con about the .CFD notion. These pointer files can be
manipulated with the mkdir() and rmdir() calls, if you wondered.
(1) Note that a TOPS-10-style directory may include null components.
It's legal to say [,] or [,100] or [333,] and the TOPS-10-specific
open() or fopen()--whichever is the one that actually parses the
string--should take the null component from the user's logged-in
PPN.
Ah, I hadn't known that. No problem. It's open() that does the filename
parsing.
(2) I like the idea that <includ.map> may contain PPNs.
Yes, this is a natural consequence of open(). It's also true that C
users almost never want to examine a .h header file; the documentation
should be sufficient. In fact, it has to be, as the ANSI draft now
permits the compiler to simply emulate the effect of an #include,
without ever having an actual .h file at all!
And if you want to redirect one of the .h directories for some
reason, you can still do so--assuming we define a name C: as a
starting point, and the compiler looks for C:includ.map--by doing
copy c:includ.map to *.*
edit includ.map
define c: as dsk:
Yes. It is also possible to specify an alternative location with the -H
switch at compile time, although redefining C: is much easier when a system
supports logical names.
-------
1-May-89 17:33:22-PDT,11775;001000000015
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Mon, 1 May 89 17:33:17 PDT
Message-ID: <MXuK6@SAIL.Stanford.EDU>
Date: 01 May 89 1732 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: WAITS answers for KCC
To: KLH@SRI-NIC.ARPA
I think I'm ready to try generating a KCC for WAITS. Here's my general
plan, plus some questions (but feel free to comment on anything).
First, I'll generate a LIBC.REL and CC.REL for WAITS.
I don't know anything about the .DMP format WAITS uses, so I'm not sure
any binary I can generate would execute directly on WAITS, but I'm pretty
sure that the .REL file format is portable and the WAITS linker can be
used to generate the CC.DMP binary.
At this point, you could FTP over the necessary files and continue, or
I can do it if (1) you set up an account for me, and (2) the net connection
from here to SAIL isn't too horrible.
I've created a KLH account on SAIL for you with password kccfix, but I'll
be happy to do any of the testing for you. You should probably change
the above password with the UFD command (just type return to all the
non-password questions except type Y to the final Y/N question).
Initially we'll need two publicly readable directories, which
correspond to /usr/include and /usr/include/sys. On TOPS-20 these are
identified by C: (with a subdirectory <.SYS>). Do you support
anything like logical names, so that we could (for example) use C: and
CSYS:? Nice, but not necessary. Perhaps these dirs can be [SYS,KCC]
and [SYS,KCS]; or [KCC,INC] and [KCC,INS]. Note that if you want to
get the KCC sources later, those will take up at least another three
dirs, so some kind of logical organization around the name "KCC" would
be handy.
There is only one logical name, SYS:, which is [1,3]. So as I mentioned
before, we'll use the directories [INC,KCC] and [INS,KCC], which I've
already created. You should have no problem moving files to and from
those directories, if you're logged in to SAIL (even through FTP).
We can create additional directories for the sources anytime. They
should be [*,KCC] for some values of *.
When you log in, your directory will be [1,KLH]. You can create other
[*,KLH] directories with the UFD command (e.g., UFD FOO,KLH to create
[FOO,KLH]).
I'll need to know the names of these dirs before I can generate the WAITS
KCC.
Anyway, the port is then simply a matter of FTPing the two .REL files plus
a bunch of .H files, and testing KCC.
Actually, come to think of it, instead of starting with KCC itself, I could
just cross-compile some small test programs which either I or you could
then bring over to WAITS and try out, to verify that the basic I/O and
stuff works as it should.
If you want to try it out with your new SAIL account, go ahead. Or let me
know and I'll test whatever you've got.
I don't think it makes sense to copy over the entire library or compiler
source for awhile. It is going to be changing continuously for the next
month or two. Bug fixes and additions can be done by editing the files
here and cross-compiling to produce new .RELs.
Sounds reasonable.
Various other questions, shouldn't hold up the above plan:
Is there any way for a program to "stuff" its RESCAN buffer just before
RUN-ing another program, so as to pretend the user typed that command line?
This would be a very convenient way of passing arguments.
Yes. For display terminals (DD, DM, etc.), the best thing is to use the
PTLOAD UUO, since that allows the user to edit the input before typing return.
For non-displays, you have to use PTWRS7 (or ...9) to load a string of 7-bit
(or 9-bit) characters. This will also work for displays if you don't want
to figure out what kind of terminal it is (almost always a display, but...).
Use a PTY line number of zero to load the user's own line editor/input buffer.
I don't suppose there is any way that a file's "bytesize" and "length in
bytes" can be set and later obtained?
Hmm, setting the size of the file? That is only done by writing the file.
You can certainly get the size. Of course LOOKUP returns the size in
words (negative, swapped), and UGETF also returns a record pointer to the
end of the file (128-wd records, so the resolution is only one record).
Should "text" I/O mode (which is 7-bit and does CRLF<->LF conversion)
ignore all NUL chars, not just those in the last word? "Binary" mode
is 9-bit, by the way.
Yup, ignore NUL chars. E, for instance, pads records with nulls. Will
text files written by KCC have lines ending in CRLF? That's what we need.
Have you thought any more about a scheme for simulating subdirs (using
"link" files with an extension of ".CFD")? Not necessary, of course.
We could do this by having a zero length file for which we use the "PPN
of the writer" as the link to the new directory. This means that copying
such a file would change the link! I would have to write a special
program to "set" the writer (the link PPN), but it would be very simple.
When you type in a filename, is the normal syntax dev:name.ext[ppn] or
dev:[ppn]name.ext? Do you have an additional syntax to specify protection,
like DEC's dev:name.ext[ppn]<prot>?
The syntax is just dev:name.ext[prj,prg] (where prg is the user name, and
prj is the "project" ("sub"-directory). No protection syntax.
How do you want to quote filename components? The SAIL Monitor Command
manual says you use "down arrows" like quote marks, which I assume means
the character valued 01 (control-A elsewhere). Is it OK to also use
double-quotes like DEC? Is it OK to permit a single-char quoter like
'\' to quote the following char, like Unix?
Yup, we use downarrows (001, ^A) to quote filenames. But if you allow
both that and double quotes, that would be fine. (The double-quote
char can appear in a filename, but downarrow cannot, since it isn't a
sixbit characer.) I don't think '\' should quote a character, since
it is a sixbit char, and I can't think of any other WAITS programs that
allow such single-char quoting. It's pretty rare that filenames need
quoting anyway.
Is there a description of .DMP file format someplace, or do you know
whether it corresponds to the old 10/50 .SAV format that TENEX/TOPS-20
still support? (That could simplify things...)
As I said, .DMP is the uncompressed core image except for the first 74
(octal) words. The UUO Manual describes what goes into the first 140
words of the core image (mostly by the system) -- see appendix 2, Job Data
Area. User code start at 140 (in the core image). If you have user UUOs,
the dispatch instruction would be in 41, which is saved in JOBS41
(somewhere above 74).
How do you map from PPNs to "user names"? That is, how would you like
the functions cuserid() and getlogin() to work?
The right half of the PPN is the "programmer name", that is, the "user
name". For cuserid() and getlogin() both, simply take the programmer name
(in sixbit) and turn it into ASCII (three chars max) by adding octal 40 to
each char. Note that each half of the PPN is right justified (omit leading
spaces/nulls).
If you have time to think about it, how do you want WAITS file protections
mapped to and from UNIX file protections? (I already have a kludge in place)
Something like this: Map the three groups of 3 bits directly into the WAITS
three groups of 3 bits in the same order of groups of bits, except never set
the two high order bits of the WAITS 9-bit protection (they are no longer
protection against the owner, who can always read and write his own files).
Unix -> WAITS -> Unix
user 100 owner
group 070 group
others 007 others
200 -> IGNORE (could mean "u-w": it is delete protect)
400 -> IGNORE (means dump-never)
octal
digit
Unix -> WAITS -> Unix
r 1 r x
w 6
x 1 r x
2 w
4 w
Is it lots better to do disk I/O using buffered mode rather than dump
mode? What if you're doing both read/write and USETI/O on a file, so as
to move around making random changes?
Actually, dump mode is faster and also better when doing random I/O via
USETI/O. Buffered mode is OK for writing files sequentially. There should
be at least 9 buffers (INBUF UUO makes given number of buffers, at address
in JOBFF).
Is there any way to get access to the unused address space above the
high segment, for dynamic memory allocation?
Not really.
Do you think you'll ever want signal() to do something?
Well, there is a user generated interrupt (out of band tty input) that
might want to cause something to happen. But I wouldn't worry about it.
Hmm, almost forgot. It would be handy to have a .UNV file of WAITS
symbols, specifically the UUOs and any other symbols that are normally
considered available to the FAIL user. Otherwise I'll have to plug in
those values by hand to cross-compile. The DEC UUOSYM.UNV file takes
care of most things, but not the WAITS-specific stuff.
SAIDFS.MID[CSP,SYS] has the WAITS symbols for UUOs, etc., in a Midas
source (sigh).
Although this won't be needed for awhile, could you clarify how you want
SHOWIT to be invoked? Do you want it called on each input file that was
specified in the command line, or (because most input files do some #includes)
do you want it to always show the current source of input? The latter is
a bit more painful and doesn't seem necessary as most of the compiler's time
is spent on code generation rather than .h file parsing.
For small files (e.g., .h files), it's now necessary to use SHOWIT. So you
could just use it for the files in the command line, although it shouldn't
cost much to do it for each file opened (it doesn't do wholine output
immediately, only when the wholine is updated). But if you do a SHOWIT
for an included file, you need to do another SHOWIT for the previous file
after the included file is finished.
Is it necessary to make a final SHOWIT at the end of the program to turn
things off, or does that happen automatically when channel is closed or
the job exits?
No, when you close the file (RELEAS the channel), the SHOWIT is undone
automatically.
Is there any convention on WAITS for naming "temporary files" that will
go away when the job is logged out, or at least that will get reaped once
in a while?
No, not really. They won't go away automatically, but you should use
the extension .TMP on the current directory, with some made up name.
Because of that, you should probably check to make sure the filename
you choose is not already in use (do a safety LOOKUP first).
OK so far, although the hack of trying to ignore E directory pages seems
like a pretty gross thing to do. It's hard to believe that all user
programs have to do this kind of thing; shouldn't the monitor be taking
care of it? Oh well, it can be done. What was your idea about subdirs?
As I said before, E directories need to be ignored by KCC. (The mod I
proposed long ago that would have made this unnecessary was rejected.)
Repeating: If a text file starts with:
COMMENT xxVALID 00000 PAGES
where the 0's can be any digits and the "xx" can be " " or "IN", then
this is an E directory page and should be ignored up to the first formfeed
('014). (That's a ^V ('026) after the "COMMENT".)
The directory page is formatted to look like a comment to FAIL, SAIL,
MACRO, and FORTRAN, but other processors have to ignore it specially.
1-May-89 17:45:12-PDT,447;001000000001
Mail-From: KLH created at 1-May-89 17:45:09
Date: Mon, 1 May 89 17:45:09 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: WAITS answers for KCC
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <MXuK6@SAIL.Stanford.EDU>
Message-ID: <12490645530.47.KLH@SRI-NIC.ARPA>
Thanks, that was very complete! I think I have enough to go on, I'll let
you know when I get started. Probably sometime later this week...
-------
2-May-89 13:19:13-PDT,2528;001000000001
Mail-From: KLH created at 2-May-89 13:17:40
Date: Tue, 2 May 89 13:17:39 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: WAITS answers for KCC
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <MXuK6@SAIL.Stanford.EDU>
Message-ID: <12490858978.47.KLH@SRI-NIC.ARPA>
A few more comments and questions...
I'll plan on using PTWRS9 -- not PTLOAD, because the idea here is just to
pass a command line directly to the next program, without giving the user a
chance to muck it up. I hadn't noticed that PTYUUO was valid for normal
terminal lines in some situations -- good feature!
Yes, text files written by KCC programs will have \n translated to CRLF.
Uh, how does one get the "PPN of the writer" with a LOOKUP? Is this a
new feature? The number of things remembered about a file is, from what
I can see, limited to the name, ext, size (in wds), protection, date written,
date referenced, last dumped date, and "creation date" whatever that is.
There is an implication that the file is owned by whatever UFD it lives in.
I don't think I can build DMP format files here (unless I write a special
program), so I'll just transfer .RELs.
There's no easy way to predict ahead of time whether a program is going to
want to do random access on a file. However, that is relatively rare, so
I think I'll go with buffering first, and use IOCON (bit 40 of i/o status)
to synch the buffering if random I/O turns out to be needed. Although the
TOPS-10 doc has no caveats about this bit, the WAITS doc implies that the
system only "tries", and that one would be better off using a single buffer.
What's the story? Is it permitted to switch between dump and buffered mode
by using SETSTS?
9 buffers is a lot. Due to interrupt emulation considerations, the
low-level code isn't allowed to dynamically allocate memory, thus all
buffers are pre-allocated as static structures. Ugly, but the only
foolproof solution. So I'm concerned about wasting too much space by
reserving enough buffers for 16 channels -- 9*16*203= 29K. I'll start
by using the minimum number to test the code with (2) and keep trying to
think of a better way.
Thanks for the SHOWIT clarification. I've set KCC up so it will just
show progress through the command-line files, which is where it spends
most of its time.
SAIDFS.MID, huh. There isn't a .FUN anywhere, is there? Could one be
readily generated from the monitor source?
OK, E directories will be ignored (choke).
-------
2-May-89 18:25:12-PDT,5406;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue, 2 May 89 18:25:06 PDT
Message-ID: <mX$qz@SAIL.Stanford.EDU>
Date: 02 May 89 1824 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: Re: WAITS answers for KCC
To: KLH@SRI-NIC.ARPA
A few more comments and questions...
I'll plan on using PTWRS9 -- not PTLOAD, because the idea here is just to
pass a command line directly to the next program, without giving the user a
chance to muck it up. I hadn't noticed that PTYUUO was valid for normal
terminal lines in some situations -- good feature!
You can use PTWRS7 if you have 7-bit text, or PTWRS9 if you have 9-bit
text. You imply that perhaps you expect to be passing 9-bit input (including
WAITS CONTROL and META bits). Or maybe you just have the text in 9-bit
strings.
Yes, text files written by KCC programs will have \n translated to CRLF.
Uh, how does one get the "PPN of the writer" with a LOOKUP? Is this a
new feature? The number of things remembered about a file is, from what
I can see, limited to the name, ext, size (in wds), protection, date written,
date referenced, last dumped date, and "creation date" whatever that is.
There is an implication that the file is owned by whatever UFD it lives in.
The disk MTAPE UUO, function 14, can get you the writer of a file for
which you have done a LOOKUP (or ENTER). Give a word count of 17 (octal)
and look at the last word returned -- that's the writer's PPN. That PPN
has nothing to do with the "owner" of the file, which is indeed the UFD
it lives in. The PPN just records who wrote the file, for informational
purposes. It's very handy -- I wish Unix had such info.
I don't think I can build DMP format files here (unless I write a special
program), so I'll just transfer .RELs.
OK, we should be able to load them here.
There's no easy way to predict ahead of time whether a program is going to
want to do random access on a file. However, that is relatively rare, so
I think I'll go with buffering first, and use IOCON (bit 40 of i/o status)
to synch the buffering if random I/O turns out to be needed. Although the
TOPS-10 doc has no caveats about this bit, the WAITS doc implies that the
system only "tries", and that one would be better off using a single buffer.
What's the story? Is it permitted to switch between dump and buffered mode
by using SETSTS?
It's permitted, and it looks like the output buffers get forced out to the
disk correctly when you switch to dump mode (I just finishing looking over
the code). I don't think IOCON has any effect on output, so I wouldn't
use it. The only reference I could find to IOCON was for input, probably
for things like reading one magtape buffer and keeping in sync with the
tape. Actually, I think USETO forces the buffers out properly, before
changing the disk pointer. However, if you're trying to write AND read
the disk randomly, you should use USETI before any read (from a new place)
and USETO before any write (to a new place). Note that USETI and USETO
set the same pointer, but flush only their respective buffers.
9 buffers is a lot. Due to interrupt emulation considerations, the
low-level code isn't allowed to dynamically allocate memory, thus all
buffers are pre-allocated as static structures. Ugly, but the only
foolproof solution. So I'm concerned about wasting too much space by
reserving enough buffers for 16 channels -- 9*16*203= 29K. I'll start
by using the minimum number to test the code with (2) and keep trying to
think of a better way.
If the buffers aren't preassigned to specific channels, you could reserve
say 2*16*203 + 7*2*203, which is about 10K I guess. Then you could give
the first two disk channels opened 9 buffers each. Sort of a kludge,
but.... Actually, I guess you're in control of how many channels are made
available, so it doesn't really have to be all 16. (WAITS allows more
than that, actually, thanks to IOPUSH and IOPOP, which push and pop
channels to let them be reused temporarily).
Thanks for the SHOWIT clarification. I've set KCC up so it will just
show progress through the command-line files, which is where it spends
most of its time.
SAIDFS.MID, huh. There isn't a .FUN anywhere, is there? Could one be
readily generated from the monitor source?
Well, SAIDFS.MID is the best starting place. A version of it could be
hacked up and compiled to generate a .FUN. These symbols don't change
(and if they did, KCC wouldn't be using any new ones), so this would
be a one-time job. SAIDFS only exists because MRC insisted on writing
some Midas programs (most of which we've converted to FAIL). FAIL doesn't
need this stuff.
OK, E directories will be ignored (choke).
Thanks.
I should say one more thing. SAIL is supposedly on its way out. CSD is
planning to remove SAIL from CSD-CF sometime soon, at which time some
group(s) that use it may try to keep it going for another year or so. I,
of course, would like to see it keep going for a while. Also, there is
another system running WAITS that might like to have (a new) KCC, namely
CCRMA (Computer Music). And in fact, Peter Lothberg is trying to get
WAITS up and running on a KL or KA in Sweden somewhere.
3-May-89 13:46:35-PDT,1222;001000000011
Return-Path: <hbj@cis.ohio-state.edu>
Received: from tut.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 3 May 89 13:40:29 PDT
Received: by tut.cis.ohio-state.edu (5.59/3.890428)
id AA22337; Wed, 3 May 89 16:14:29 EDT
Date: Wed, 3 May 89 16:14:29 EDT
From: H Benny Jones <hbj@cis.ohio-state.edu>
Message-Id: <8905032014.AA22337@tut.cis.ohio-state.edu>
To: klh@sri-nic.arpa
Subject: Stopped
Cc: hbj@cis.ohio-state.edu
Ken -- I was on my way (almost) to the FAX machine with your contract
when I was stopped in my tracks by one of our corporate officers telling
me that nothing was going out until our attorney looked at it. He'll
be in tomorrow, and then he'll let me know when he can look at it. The
thinking is, "send them something we're willing to sign, don't send them
something we'll want to make changes to later. If they want to make
changes, fine, but it would not be good form for us to send you something
and then want something different later."
I'm not sure what I would've done when I got to the FAX machine. I
still don't have your number.
Anyway, the contract is o the lawyer's desk. I'll prod him tomorrow.
Hope things are going okay at your end.
--- Benny
3-May-89 14:00:19-PDT,417;001000000001
Mail-From: KLH created at 3-May-89 14:00:07
Date: Wed, 3 May 89 14:00:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Stopped
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8905032014.AA22337@tut.cis.ohio-state.edu>
Message-ID: <12491128851.47.KLH@SRI-NIC.ARPA>
FAX, huh. You can use 415/859-6028. That's a SRI number but I got an OK.
Looking forward to seeing it.
-------
3-May-89 14:24:42-PDT,1290;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 3 May 89 14:19:39 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/3.890428)
id AA17829; Wed, 3 May 89 16:20:52 EDT
Date: 03 May 89 14:41:36 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Contract nearing launch
Message-Id: <"CSI 5560-14636"@CompuServe.COM>
to: Ken
fr: Benny Jones
In a matter of hours or in a day or two, I'll send you
an attempt at a contract. First, thank you for your
patience in this. The overall form of the contract you
will see came out of a book called COMPUTER SOFTWARE
AGREEMENTS, FORMS AND COMMENTARY by Ridley, Quittmeyer and
Matuszeski published by Warren, Gorham & Lamont.
I removed some stuff that I did not feel applicable.
I composed the exhibits (which explains the less-than-
lawyer-like terminology).
I did not put dates that milestones are to be delivered by.
I would like your input for this. I did put in some dollar
amounts. Your input on these figures is welcome as well.
I apologize for any omissions. Please advise me as to
anything you have problems with. Keep in mind this is an
initial pass, so glaring errors can be corrected.
Well, back to it...
8-May-89 13:53:50-PDT,361;001000000001
Mail-From: KLH created at 8-May-89 13:52:17
Date: Mon, 8 May 89 13:52:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Fax hax
To: hbj@cis.ohio-state.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8905032014.AA22337@tut.cis.ohio-state.edu>
Message-ID: <12492438146.31.KLH@SRI-NIC.ARPA>
Just to let you know I got the trmop doc you faxed...
-------
9-May-89 12:56:26-PDT,3612;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 9 May 89 12:45:56 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/3.890428)
id AA06610; Tue, 9 May 89 15:46:15 EDT
Date: 09 May 89 15:32:14 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC issues
Message-Id: <"CSI 5564-3975"@CompuServe.COM>
to: Ken
fr: Benny Jones
Here are some more discussions regarding questions you have
asked about memory usage and file I/O.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
(1) GCORE$ and RCORE$ may allocate pages anywhere in your addressing
space. If you care, you can find out what's where at runtime:
GETSEG can tell you the address span of the segment you got, and
PAGE. can return a bit map of in-use pages.
(2) It's probably most reasonable to use dump mode. It's not too hard
to do USETs during buffered mode input; I can give you a sample.
But it's nearly impossible to update a file in place with buffered
mode. You must use the same buffer ring for both input and output.
However, the original design seems to preclude rational bidirec-
tional use of buffers--a buffer full of data read from disk looks
just like a buffer full of data to be written to disk--so you need
magic that detects the first read after write or vice versa, does a
WAIT, zaps use bits, includes the buffer address in the first IN or
OUT, and other things that seem flaky to me.
FOROTS, as I recall, does that, but not very well--it seems to be
afraid of losing sync, so it does lots of USETs. And there are
severe interactions with the monitor; for example, it depends on the
exact order that a CLOSE monitor call does things.
Dump mode seems more reasonable to me. The only thing even remotely
tricky is figuring out where the EOF is on input, but you can ask
for the file's length.
(3) I'm not familiar with those LOOKUP words. I suspect that their
contents are arbitrary, left to runtime systems, but I'll see if I
can find out. "Available to runtime systems" words sound more
useful for language-specific files (e.g., FORTRAN binary, COBOL
ISAM, 1022 DMS). I think we we want something of more general use.
(Also, the idea of VAX-ifying things--so files have tons of
attributes like carriage control, byte size, record size, fixed v.
variable length records, etc., associated with them--scares me,
although I'll admit it's just a personal opinion.)
I've thought about ways to handle different bit-packing modes, but
haven't yet come up with anything decent. I think it's worth
thinking about, but it's trickier than it sounds--what happens when
you copy the file? What happens when you put it in a .PAK file and
later extract it? What happens if you put it on a FILSAV tape and
later restore it? BACKUP tape? Download it and later upload it?
In my opinion, we should eventually do something, but if it's going
to require modifying every program on the system, we might as well
think it through rather than jump at it PPS style.
With respect to C, I think it's an issue only when you read an
existing file and you don't specify "b" or "t" mode. It should be
reasonable to declare that the initial implementation's default mode
is "t" (or, like Microsoft C, the default is a global symbol that
you can define if you want to override the default for a particular
program).
9-May-89 13:56:45-PDT,699;001000000001
Mail-From: KLH created at 9-May-89 13:42:02
Date: Tue, 9 May 89 13:42:02 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC issues
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5564-3975"@CompuServe.COM>
Message-ID: <12492698425.40.KLH@SRI-NIC.ARPA>
Thanks for the info. It does sound like dump mode is the right thing
when a file is being updated (as opposed to just read or written).
FYI, in ANSI C there is no such thing as an explicit "t" mode
specification; a file is either binary or text depending on whether the
'b' flag character is given to fopen(). Just a minor clarification that
doesn't conflict with your desired defaults.
-------
18-May-89 12:20:50-PDT,567;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 18 May 89 12:19:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA11316; Thu, 18 May 89 15:08:09 EDT
Date: 18 May 89 14:42:28 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Remember me
Message-Id: <"CSI 5568-3623"@CompuServe.COM>
to: Ken
fr: Benny Jones
I have in my possession a contract. Is it okay to fax
it to you? It's in WordPerfect, so it's not easily
typeable as straight ASCII text.
18-May-89 12:37:36-PDT,452;001000000001
Mail-From: KLH created at 18-May-89 12:37:30
Date: Thu, 18 May 89 12:37:29 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Remember me
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5568-3623"@CompuServe.COM>
Message-ID: <12495045971.19.KLH@SRI-NIC.ARPA>
Good, I was starting to wonder. Yes, FAX is okay. The number is
415/859-6028 (same as before, just so you don't have to look it up...)
Thanks!
-------
19-May-89 12:36:21-PDT,577;001000000001
Mail-From: KLH created at 19-May-89 12:21:47
Date: Fri, 19 May 89 12:21:47 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Got it
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5568-3623"@CompuServe.COM>
Message-ID: <12495305255.18.KLH@SRI-NIC.ARPA>
Just got the fax. It is a bit longer and more convoluted than I expected, so
I will need a little time to digest it. My name is misspelled, by the way;
is that a problem? (You had it right on the fax cover letter, but the document
itself has "Harrenstein".)
More later...
-------
19-May-89 20:03:55-PDT,662;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 19 May 89 20:03:40 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA08727; Fri, 19 May 89 23:05:10 EDT
Date: 19 May 89 22:59:17 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: The Contract
Message-Id: <"CSI 5568-10410"@CompuServe.COM>
to: Ken
fr: Benny Jones
Sorry about the name spelling; it'll be fixed. The
contract is longer and more convoluted than I anticipated
as well. We'll try and sort out any problems. Again,
I apologize for it taking so long and appreciate your
patience.
20-May-89 17:54:02-PDT,5354;001000000011
Mail-From: KLH created at 20-May-89 17:53:57
Date: Sat, 20 May 89 17:53:57 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: The Contract
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5568-10410"@CompuServe.COM>
Message-ID: <12495627870.18.KLH@SRI-NIC.ARPA>
OK, I've read through the fax and here are my comments, most of which
have to do with clarification rather than changes; I'm more interested
in getting started than quibbling.
General: too many wherefores, therefores, whereofs, whereases, and
heretos (did I leave out any? :-)
(1) p.1: name misspelled, as already mentioned.
(2) p.1: The first paragraph implies that I am a duly organized corporation.
As far as I know, I'm not; there is no "KLH Inc". Do I have to (or should
I) be? Is this a problem?
(3) end of para 2.2: the "second round limit" makes me a little uneasy
because I can imagine legitimate reasons for going through more than
two cycles of sending, testing and fixing, especially since I won't be
working directly on your system (at least not initially). I would be
satisfied if this were simply a "reasonable number". The fuzziness
of this term would counterbalance the fuzziness of the "Acceptance Tests"
and "Performance Standards". This means you can still call it quits if
you get fed up, without artificially limiting any mutual efforts.
(4) Sections 4 & 5: They seem to express what we want, thanks.
Although I am not sure I understand the part about "right to grant
sublicenses" (4.1). Is this just another way of saying you can make
copies?
(5) para 6.2: the point about "if Customer has performed any
maintenance..." brings up an interesting topic related to (4) above. I
understand the motivation behind this standard protection clause, but
I also don't want to prevent you from making contributions. As you
know, one thing that I am hoping for by keeping the software itself
"free" is feedback in the form of bug fixes and improvements. But the
existing wording (sec 4&5&6 together) may in fact cover this, if we
interpret it to mean that the only way you can change the "subject
programs" is to get my authorization (ie I can get the fixes/improvs),
and then the result is still free and clear of all claims etc (5.1).
In practice, my "authorization" would basically consist of adopting
any changes into the standard distribution, whereupon they can
legitimately come under the "warranty", so you also get something in
return. If this is a correct interpretation, then the wording is fine.
(6) sec 7: This is a bit scary, since it brings thoughts of AT&T
harassment lawsuits to mind. It's like crossing the street -- the
odds of being run over are pretty slim, but if it happens then you get
mashed regardless of innocence. Makes sense from your viewpoint, though.
(7) sec 8: Where did the 10 year number come from? I'm not sure what it
applies to, since the other times mentioned were a few months (delivery
schedule) and a year ("warranty"). I'm not against it, just wondering
what it means. As for commence date, more on that later.
(8) para 9.1: In between the entirely plausible "earthquake" and
"riots" you forgot the unlikely event of "vacation". Just kidding...
(9) para 9.6: It took me a long time to parse this. Geez!
(10) para 9.10: I'd like to change my "Notice" address to my home:
Kenneth L. Harrenstien
1700 Santa Cruz Ave.
Menlo Park, CA 94025
My reasoning is that although SRI is permitting me to use its facilities,
that is the extent of their involvement -- if SRI was mentioned in a contract
without their knowledge (even by implication) I don't think they'd like it.
Thanks.
(11) Exhibit A: Strictly speaking, the specification as written refers
only to the C compiler, not to the entire C implementation. Is this
intentional? The ANSI draft standard itself refers to the "language"
(compiler) and the "library" separately. The word "implementation" is
used to refer to both. However, you also mention "...shall include
development of ANSI I/O support functions and any ancillary routines
deemed necessary and reasonable..." which is flexible enough to cover
as much of the implementation as we want. So if you want to leave the
wording as is, that's fine.
(12) Exhibit B&C: (here's the "more later"!)
I'm concerned that Milestone A (1 June 1989) may no longer
be feasible due to the contract delay. It sort of conflicts with the
contract date (19 May) and the statement in para 1.1 about "within 10
days of final execution of this Agreement". I suggest we make it 15 June.
I'm still willing to commit to the other two dates; the window that I
have for using SRI's KL will close in September, and I really want to
get everything finished before then.
The division of payments and tasks is reasonable given that it
is a total contract. If each step was optional then I would have to
be more careful about getting an exact matchup of effort/time/money
and would probably end up changing some numbers; but viewing it as a
way to develop trust, it should be fine.
That's all. I hope this doesn't cause too much additional delay. A
procedural question: given a final version, what happens? Do we
exchange copies & signatures via U.S. mail?
Thanks,
--Ken
-------
20-May-89 18:18:25-PDT,606;001000000001
Mail-From: KLH created at 20-May-89 18:18:23
Date: Sat, 20 May 89 18:18:23 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: CSI or CSMS?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5568-10410"@CompuServe.COM>
Message-ID: <12495632317.18.KLH@SRI-NIC.ARPA>
I noticed in the contract that it referred to your operating system as
"CSMS". What does that mean? I asked about an appropriate OS acronym
a while back and had the impression that "CSI" was the right thing,
but this makes me wonder. It's surprising the name would not be mentioned
in COUGH.USR.
-------
22-May-89 08:24:36-PDT,1336;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 22 May 89 08:21:25 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA25239; Mon, 22 May 89 11:02:30 EDT
Date: 22 May 89 10:39:38 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Contractual stuff
Message-Id: <"CSI 5570-2665"@CompuServe.COM>
to: Ken
fr: Benny Jones
The acronym CSMS stands for "CompuServe Monitor System" or
something like that; I'm not sure. But CSI is the appropriate
OS acronym for KCC's purposes. Go figure.
I'll get another contract off to you incorporating most all of
your changes. With respect to division of payments, I'd like
for you to be comfortable with it with respect to the matchup
of time/effort/money; comfortable and covered. While I think
CompuServe is honorable, I think you should treat us rather
strictly with respect to any and all concerns. Basically, I
don't want to foster any trust that might not be realized in
dealings that I have no part in.
I don't know where the 10 year number came from. It was in
the contract that I had copied originally.
I had trouble parsing some sections as well.
We won't throw in any more whereas's, heretofores, or hereuntos.
We'll even take some out.
22-May-89 14:55:07-PDT,3506;001000000001
Mail-From: KLH created at 22-May-89 14:55:00
Date: Mon, 22 May 89 14:55:00 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Contractual stuff
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5570-2665"@CompuServe.COM>
Message-ID: <12496119580.18.KLH@SRI-NIC.ARPA>
With respect to division of payments, I'd like
for you to be comfortable with it with respect to the matchup
of time/effort/money; comfortable and covered. While I think
CompuServe is honorable, I think you should treat us rather
strictly with respect to any and all concerns. Basically, I
don't want to foster any trust that might not be realized in
dealings that I have no part in.
OK, I see what you mean. I'll try to explain here. I'm not worried
about the first two parts; they look good to me. It's the third that
might cause surprises, since that is the part most directly concerned
with tuning and enhancing the implementation for CSI, but also has a
quite small budget (approx 50 hrs).
The wording of Exhibit A doesn't say who does the "deeming" of which
ancillary routines are necessary and reasonable. (Oh, I just noticed
a typo that slipped by us! Last sentence "as part compiler" should
probably be "as part of compiler".) So it is conceivable that
CompuServe could insist that something is necessary and reasonable
which in fact requires an enormous amount of work. This kind of task
is also likely to be more difficult, since by definition the features
can only be tested and debugged in a CSI environment, unlike the
results of the other two.
For example, I'll tell you right now that getting signal() to do
something useful on CSI is my biggest worry. ANSI doesn't REQUIRE
that it do very much (it is too implementation-dependent), so I can
make it satisfy the ANSI requirement right now without really giving
you anything, but of course that isn't what we want.
The original idea behind the third step was that we could save
CompuServe some money by using your strengths (better knowledge of the
operating system, on-site access, etc) to do most of whatever
enhancing and debugging is necessary, with advice/assistance from my own
strengths (knowledge of implementation internals/tradeoffs, Unix, C,
etc). However, the contract COULD be interpreted as meaning I am
agreeing to do all of this by myself for $3K. Ack!
So, perhaps you are right, and Milestone C needs to be clarified. I'm
afraid I don't have an immediate suggestion, because (again, by definition)
that is the part where my estimates are going to be much less reliable,
which makes it hard to put a single total amount on it. (This is where
going to an hourly or daily rate would be safest for both of us, if that
was an option.) Any number I suggested to replace 3K would still be subject
to the same reservations about scope and difficulty.
Perhaps the best thing at the moment is to add the phrase "that both
parties agree are necessary" to replace the word "deemed" in Exhibit
A. This makes it clear that both of us have veto power to make sure
the effort stays within limits, and doesn't compromise our
flexibility. If it should turn out that you are happy with everything
up to the point where the 3K runs out, and would still like me to do
more stuff, we can always put together another agreement. I don't
know if there is any need for the current contract to mention that
possibility.
That seem OK to you?
--Ken
-------
24-May-89 03:38:40-PDT,1457;001000000001
Mail-From: KLH created at 24-May-89 03:38:38
Date: Wed, 24 May 89 03:38:37 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC progress
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12496520738.18.KLH@SRI-NIC.ARPA>
Hi, I was busy on other things for a while, but am back on this and
getting closer. I just ran into a weird problem, though.
The compatibility package on TOPS-20, when it simulates the initialization
that an IN or OUT does on the buffer ring header, always sets the P field
of the byte pointer to 0, regardless of the bytesize in the S field. Thus,
if I have set it up for 7-bit bytes, the first OUT (for example) inits the
byte ptr to 00700,,<data-1>. Now, this would be OK if it was just an IDPB
or IBP that hacked the pointer, since the first increment would then align
it properly. Unfortunately, the KCC code is clever, and uses ADJBP to
mung it by a variable number of bytes. Now, ADJBP preserves byte alignment,
so one can end up with weird BP values that are off by one bit. This
screwed up data in strange ways...
I'm surprised the code didn't just set the P field to 44 and thus always
ensure alignment.
Is this really the way it works in a real live monitor like WAITS?
Is it possible to simply ignore the byte pointer, and just adjust the
byte count in order to tell the monitor how much has been read/written?
I can set and maintain my own pointers elsewhere.
-------
24-May-89 15:01:32-PDT,1195;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Wed, 24 May 89 15:01:26 PDT
Message-ID: <25cypc@SAIL.Stanford.EDU>
Date: 24 May 89 1458 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: KCC progress
To: KLH@SRI-NIC.ARPA
You pretty much described what happens on WAITS (probably same as TOPS-10).
The OPEN sets up the left half of the byte pointer, after which you can
change the byte size. The first IN or OUT sets up the right half with
the address <data-1> and zeroes the byte position field, as you described.
How about just aligning the byte pointer after each IN or OUT, say
by IBP PTR and then ADJBP <-1>,PTR [and MOVEM AC,PTR] (which has the
advantage of working for any byte size).
In WAITS, you can use the IOWC bit in IO status to inhibit system
computation of the output word count. The system will ignore the byte ptr
and use the word count in the word preceding the buffer's data. Offhand,
I don't know of any programs that do this, so I can't swear that it works,
but it should.
For input, you can use all your own pointer and count, after setting them
up from the system ptr and count.
24-May-89 15:10:03-PDT,753;001000000001
Mail-From: KLH created at 24-May-89 15:09:59
Date: Wed, 24 May 89 15:09:59 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: KCC progress
To: ME@sail.stanford.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <25cypc@SAIL.Stanford.EDU>
Message-ID: <12496646597.18.KLH@SRI-NIC.ARPA>
Thanks for the confirmation. I worked around it in basically the way you
suggest, except I keep the pointer always incremented until just before
giving it back to the monitor (on OUT), since C utilities assume pointers
point to the 1st char, not the char before it.
I just got the TOPS-10 version to successfully compile, assemble, and load
a simple program. I'm going to stress-test the T10 stuff a bit more before
I attempt the WAITS version.
-------
24-May-89 20:10:04-PDT,2069;001000000001
Mail-From: KLH created at 24-May-89 20:09:57
Date: Wed, 24 May 89 20:09:57 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Misc questions
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5570-2665"@CompuServe.COM>
Message-ID: <12496701202.18.KLH@SRI-NIC.ARPA>
While we wait, I'll be coming up with more questions as I review past
messages and stuff. Here are a few...
An empty field in a PPN (eg [,123] or [123,] or [,]) should be filled in
from the corresponding field in the user's logged-in PPN, but where is this
done? Does the monitor do this when one or both of the halfwords is zero,
or is it actually each program's parser that must detect this and replace
the zero values? I hope it's the monitor, but if not it's easy to do.
When you quote filenames with '' or "", how do you include one of the
quote characters in the filename, e.g. how do you specify a filename
that contains both ' and "? What happens if one of them appears in
the middle of an otherwise unquoted filename, as in FOO'BA?
Do you want me to use the new TRMOPs in preference to TTCALLs whenever
possible? Unix programs are used to the possibility that read() or write()
of a slow device (specifically TTY) can be interrupted, so that aspect
should not be a problem.
I should probably have asked this one before. What goals are you
hoping KCC will help you achieve? What will be its intended purpose?
Is it just to provide customers with a C implementation, or are you
planning to create or re-write systems applications in C? How should
memory efficiency trade off against CPU usage? Will high-speed I/O be
important? Interrupt-driven processing? Do you enforce any core size
restrictions on jobs, or can every job use the maximum virtual address
space?
While the answers probably won't make a lot of difference to the
result, having some idea of the overall objectives never hurts. At worst,
when faced with arbitrary decisions between space and speed, I'll have
a better guide than a flipped coin.
-------
25-May-89 05:56:47-PDT,623;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 25 May 89 05:56:38 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA29564; Thu, 25 May 89 08:57:04 EDT
Date: 25 May 89 08:26:43 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Forthcoming contract
Message-Id: <"CSI 5573-591"@CompuServe.COM>
to: Ken
fr: Benny Jones
I hope to have a revised contract FAX'd out to you today.
I took out that indemnification stuff, but the lawyer made
me put it back in. Most all your other changes were dealt
with too.
25-May-89 07:01:02-PDT,1679;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 25 May 89 07:00:52 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA00319; Thu, 25 May 89 09:59:20 EDT
Date: 25 May 89 09:35:37 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Misc. answers
Message-Id: <"CSI 5573-1267"@CompuServe.COM>
to: Ken
fr: Benny
It's the responsibility of the parser to fill in the empty
fields in a PPN. The monitor won't do it.
If a filename has both a " and a ' in it, then one of them
should be doubled up. If the filename is quoted with single
quotes, then the single quote should be doubled up. If the
filename is quoted with double quotes, then the double quote
should be doubled up. We have some things that work this
way, strange as it seems. If one of these characters appears
in an otherwise unquoted filename, then it should signify
the end of parsing for that particular field.
Use of the TRMOPs is indeed preferable to TTCALLs.
We hope to use KCC as our systems development language. We
plan on it supplanting DEC's BLISS for this purpose. So,
yes, we're going to create and rewrite systems applications in
C. The issue of memory efficiency vs CPU usage is tough.
Can we get a compiler switch? Maybe that's something we could
put in. High speed I/O is important. We'll also use interrupt-
driven processing for some applications. We support the
notion of "classes" for memory use whereby users in one class
are not able to have as much memory as users in another class.
So, yes, we enforce core restrictions as well.
25-May-89 13:28:05-PDT,633;001000000001
Mail-From: KLH created at 25-May-89 13:28:02
Date: Thu, 25 May 89 13:28:02 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Forthcoming contract
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5573-591"@CompuServe.COM>
Message-ID: <12496890182.18.KLH@SRI-NIC.ARPA>
OK, the revised contract just arrived by fax. Assuming I don't stumble
over anything else while scanning it, what's next? Do you want me to
sign it and send a fax back, or sign and mail it, or wait for you to
mail an official document that I can mail back, or find a notary, or...
what does your lawyer want done?
-------
25-May-89 14:26:52-PDT,1547;001000000001
Mail-From: KLH created at 25-May-89 14:14:48
Date: Thu, 25 May 89 14:14:48 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: The Contract
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12495627870.18.KLH@SRI-NIC.ARPA>
Message-ID: <12496898694.18.KLH@SRI-NIC.ARPA>
Two (or 2.5) final questions:
* (repeat of earlier q) In para 4.1 I don't fully understand the part
about "right to grant sublicenses". Is this just another way of
saying you can make copies?
* One change I don't quite get is that in 6.2 about "authorization
which shall not be unreasonably withheld". Does the fact of a change here
mean that my interpretation (as per prev msgs) was not correct? Or were
you trying to address my concern about encouraging improvements?
The only reason I would deliberately "withhold authorization"
would be if CompuServe refused to make the changes available to others
as part of the KCC distribution. Is this "reasonable"? I'd like to make
sure this is clear.
Other comments, no response required:
I notice that instead of a "reasonable number" of rounds, you
have "fourth round". I guess this is okay; if we can't get it right
after that many we are probably wasting our time. In practice I think
most or all problems will be dealt with by messages and spot fixes rather
than bulk package delivery.
My new mailing address still perpetuates the usual misspelling, but
since that's only for addressing purposes it shouldn't matter.
Another msg coming up...
--Ken
-------
25-May-89 14:32:58-PDT,562;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 25 May 89 14:23:50 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA07612; Thu, 25 May 89 17:24:03 EDT
Date: 25 May 89 16:55:18 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: I'm not here (but I'll be back)
Message-Id: <"CSI 5573-4836"@CompuServe.COM>
to: Ken
fr: Benny
I'm leaving momentarily until next Tuesday. The current
contract has been faxed to you however. Talk at you next
week.
25-May-89 14:33:03-PDT,551;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 25 May 89 14:23:55 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA07639; Thu, 25 May 89 17:24:13 EDT
Date: 25 May 89 17:00:07 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject:
Message-Id: <"CSI 5573-4881"@CompuServe.COM>
Ken --- I guess you can sign it and mail it back. I guess we should
exchange contracts via mail. I dunno. I'll check into it, but won't
be able to until Tuesday.
25-May-89 14:50:37-PDT,1217;001000000001
Mail-From: KLH created at 25-May-89 14:42:06
Date: Thu, 25 May 89 14:42:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Software xfer details
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5573-1267"@CompuServe.COM>
Message-ID: <12496903664.18.KLH@SRI-NIC.ARPA>
We'll need to dispose of the mundane details of how the software
should be transported. The ideal method, of course, would be FTP, but
that doesn't seem to be feasible. The next best thing from my
viewpoint would be for you to send me a magtape or two with the return
delivery pre-paid. (US mail, UPS, Fedex, whatever). That way I can
avoid the need to bother SRI people with my personal reimbursements
for tape expenses.
There's also the question of how to organize the directories etc. At
this point, what I'd like to do is define my own logical names that
will point to specific UFDs, so I can just use the logical names in
the various control files. But I can't be sure from my reading whether
your system supports user-defined (job specific) logical names, or how
many.
If your other large packages have a consistent way of setting things up,
I try doing things a similar way.
-------
25-May-89 15:56:20-PDT,2492;001000000001
Mail-From: KLH created at 25-May-89 15:56:00
Date: Thu, 25 May 89 15:56:00 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Misc. answers
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5573-1267"@CompuServe.COM>
Message-ID: <12496917117.18.KLH@SRI-NIC.ARPA>
Thanks for the filename parsing clarifications.
I will attempt to provide both TTCALL (TOPS-10 generic) and TRMOP (CSI
specific) versions. The initial binary you get will be TOPS-10 generic
since that is the only thing I can test here, and I want to make sure
the first transfer bootstraps successfully.
We hope to use KCC as our systems development language. We
plan on it supplanting DEC's BLISS for this purpose. So,
yes, we're going to create and rewrite systems applications in
C. The issue of memory efficiency vs CPU usage is tough.
Can we get a compiler switch? Maybe that's something we could
put in. High speed I/O is important. We'll also use interrupt-
driven processing for some applications. We support the
notion of "classes" for memory use whereby users in one class
are not able to have as much memory as users in another class.
So, yes, we enforce core restrictions as well.
Aha, this helps me a lot. This tells me that any extra time I have
should go into having KCC generate better code, rather than into
simulating Unix more extensively. I have not used BLISS-36 myself, but
I understand from others that it produces very good code, undoubtedly
better than KCC can do.
I think it is unlikely that you will be able to get really high-speed
I/O using the standard library functions. Those are meant to be portable,
not optimized to any particular system. The TOPS-20 version, for example,
uses SIN% and SOUT% rather than PMAP% (that is, bytes are copied to/from
the monitor, rather than mapped directly to/from files). However, because
the C library is quite distinct from the C language, you can "roll your
own" very easily for special purposes.
Given the limited amount of address space in a single-section program and
your enforcement of user memory limitations, I will spend some thought
on reducing the size of the static data that the KCC runtime uses. In
my opinion, the general trend in software is to larger and larger programs,
which run on faster and faster CPUs, thus anything which remains on
a single-section machine must of necessity try to minimize its memory
requirements.
--Ken
-------
25-May-89 15:59:33-PDT,532;001000000001
Mail-From: KLH created at 25-May-89 15:59:30
Date: Thu, 25 May 89 15:59:30 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Procedural question
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5573-1267"@CompuServe.COM>
Message-ID: <12496917753.18.KLH@SRI-NIC.ARPA>
By the way, who will I be dealing with at CSI when it comes to installing,
running, and testing KCC? You, or one of your "minions"? Will you be
using the CPS machine that I have the guest account on, or something else?
-------
25-May-89 16:14:33-PDT,1307;001000000001
Mail-From: KLH created at 25-May-89 16:14:31
Date: Thu, 25 May 89 16:14:30 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: ELLE?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5573-1267"@CompuServe.COM>
Message-ID: <12496920486.18.KLH@SRI-NIC.ARPA>
Hey, one other miscellaneous thing occurred to me as I was commenting on
memory usage restrictions. You might be interested in looking at an
editor I wrote, called ELLE (ELLE Looks Like Emacs). Its main claim
to fame is the ability to edit files of any size using very small
amounts of memory; it does not need to read in the entire file, as
do almost all other editors. It's in C, of course; the original
motivation for it was to get EMACS-like editing on a V6 PDP-11/40
which permitted only 32K words per process. It turns out to be handy
even on a TOPS-20 with real EMACS because some files are too large
to look at otherwise, and ELLE can handle 7, 8, or 9-bit files.
Of course, it's only a limited subset of the real EMACS.
If enough of the library is working to support it, I'll include a copy
on the first tape. That way, if I need to do any online work, I'll
have a tool I'm familiar with (tho FINE is okay in a pinch), as well as a
non-trivial sample program other than KCC itself.
-------
25-May-89 16:18:12-PDT,670;001000000001
Mail-From: KLH created at 25-May-89 16:18:06
Date: Thu, 25 May 89 16:18:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: PPN parsing question
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12496921141.18.KLH@SRI-NIC.ARPA>
I'm told that on the TOPS-10 system I'm targetting, specifying a PPN of
the form [,123] causes the LH to default to the logged-in PPN. Ditto
for the RH. It follows of course that [,] becomes simply the logged-in PPN.
This is distinct from the "connected-directory" PPN.
Should the same behavior happen on WAITS? Or do you want [,FOO] to produce
something with 0 in the LH and sixbit/FOO/ in the RH?
-------
25-May-89 16:25:40-PDT,694;001000000001
Mail-From: KLH created at 25-May-89 16:25:30
Date: Thu, 25 May 89 16:25:28 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: WAITS name compression
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12496922480.18.KLH@SRI-NIC.ARPA>
Sort of a silly question, but amazing how many places I need this.
What should I use as a 3-letter abbreviation to denote the WAITS OS?
I would use this in filenames like namSYM.UNV.
Seems like WTS is plausible. On the other hand, SAI might also be a good
candidate for historical reasons. WAI would be an odd compromise.
I can use whatever you think best.
I forgot again what WAITS was supposed to stand for. Sheesh!
-------
25-May-89 18:23:51-PDT,1286;001000000015
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Thu, 25 May 89 18:23:47 PDT
Message-ID: <MdvpR@SAIL.Stanford.EDU>
Date: 25 May 89 1823 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: WAITS name compression and PPNs
To: KLH@SRI-NIC.ARPA
WAITS doesn't officially stand for anything. It was selected as the name
of the system without an anti-acronym, but since the name I had proposed
had lost the vote, I decided WAITS was the Worst Acronym Invented for a
Timesharing System.
For PPNs only partially specified, most pieces of WAITS (that allow it)
fill in the missing part from the corresponding half of the current PPN.
(It doesn't make any sense for [,FOO] to mean 0,,'FOO', since a PPN never
has a zero half.) A PPN of [FOO] should mean [FOO,], since the left half
is the less significant half (the "project"). In fact, a PPN of "[FOO,BAR"
is permitted by many programs, simply meaning "[FOO,BAR]", but I don't care
whether you implement that in KCC.
Either WTS or WAI is OK as a 3-letter abbreviation of WAITS (though
neither is great). I guess WTS has the right "sound", so I would chose
it. I'd like to avoid using "SAIL" in any form, since it doesn't
designate the operating system.
25-May-89 18:25:21-PDT,392;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Thu, 25 May 89 18:25:18 PDT
Message-ID: <ydvqm@SAIL.Stanford.EDU>
Date: 25 May 89 1825 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: WAITS PPNs, clarification
To: KLH@SRI-NIC.ARPA
By "current PPN", I mean the "connected directory", as opposed to the
logged-in PPN.
26-May-89 10:35:04-PDT,895;001000000001
Mail-From: KLH created at 26-May-89 10:34:25
Date: Fri, 26 May 89 10:34:25 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: WAITS name compression and PPNs
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <MdvpR@SAIL.Stanford.EDU>
Message-ID: <12497120720.19.KLH@SRI-NIC.ARPA>
Fine, WTS it is. I had the same misgivings about SAIL, it was mostly
the name of SAIDFS.MID that made me wonder. I'll ignore that, then, and
go with WTS. Funny, I know KS told me before what WAITS "stood for", but
I guess he must have been winging it.
You want [FOO] to be recognized as [FOO,], huh. I guess that's okay. I'll
avoid the unbalanced bracket case, though, things just get too messy.
You're sure, though, that the missing pieces are filled in from the
connected PPN, not the logged-in PPN? Yet another difference. (Big
deal, I know...)
Thanks.
-------
30-May-89 09:57:04-PDT,1494;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 30 May 89 09:43:48 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA07622; Tue, 30 May 89 10:52:12 EDT
Date: 30 May 89 10:37:58 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Contract
Message-Id: <"CSI 5574-3085"@CompuServe.COM>
to: Ken
fr: Benny
Paragraph 4.1 was copied out of the book on software contracts.
I'm told that what it means is that we can act as a distributor
of the compiler, although that is not our intent. Perhaps a
better wording would be "a company-wide license with right to
make multiple copies for company use".
In 6.2, our lawyer added the phrasing you noted, in his second
reading of the contract. He feels that the phrase that he added
is needed. It seems to me that the reason you cited under which
you would "withhold authorization" is reasonable. Namely, if
CompuServe refuses to make it's changes available to others as
part of the KCC distribution. But it's okay if we keep changes
that expose proprietary aspects of our system to ourselves isn't
it? I don't have any in mind, but "what if...".
Last week, I removed the whole statement regarding reasonable
number of rounds. Our lawyer objected, so it had to go back
in. I chose 4 rounds somewhat arbitrarily.
You wouldn't consider changing the spelling of your name would
you? (Just kidding...)
30-May-89 09:59:18-PDT,2172;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 30 May 89 09:44:16 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA05523; Tue, 30 May 89 09:29:58 EDT
Date: 30 May 89 08:27:57 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Miscellanea and ELLE
Message-Id: <"CSI 5574-1811"@CompuServe.COM>
to: Ken
fr: Benny
I'll get answers to your contract questions today, and
a new corrected copy out to you (also today, I hope).
I'll make sure your name is spelled right everywhere too.
ELLE. I'm very eager to have a look at ELLE. The business
of FINE reading an entire file into memory is a big weakness
of that editor. Can ELLE edit multiple files/windows?
When it comes to installing KCC, you'll probably be dealing
with me. And at this point I should probably explain our
notion of "levels" of software. I'm told CompuServe devised
this scheme to replace DEC's concept of OLD: and NEW:. Our
system software that goes on SYS: can be staged through levels.
Level 0 software is production and goes into [1,4] on the
primary structure of a system. Level 1 software is somewhat
experimental and as such, lives in [1,41]. Level 5 software
is more experimental and lives in [1,45]. Users may establish
levels of operation with the LEVEL command. LEVEL 1 sets your
job to level 1. When in level 1, your job will first look in
[1,41] for system software. If it's not found there, it will
look in [1,4]. Similarly, if you are operating on level 5, the
monitor will look for all files normally found on SYS: first
in [1,45], then in [1,41], and lastly in [1,4].
Our compiler work project is [311,*]. Once the contract is in
place, I'll create an account for KCC in project 311 and give you
the password. We'd like to be able to rebuild and run the compiler
from this or any account. This proved a bit tricky with Sargasso
C and I just thought I'd mention it. It also reminds me that our
MAKE may not be the best. I don't use it a lot, so I'm not really
qualified to judge it.
More later...
30-May-89 11:42:02-PDT,928;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue, 30 May 89 11:32:08 PDT
Message-ID: <AfDYI@SAIL.Stanford.EDU>
Date: 29 May 89 2329 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: WAITS name compression and PPNs
To: KLH@SRI-NIC.ARPA
Well, MRC made up the name SAIDFS for his MIDAS programs. I wouldn't
have chosen it (in fact, I didn't even know about it for years, I think).
There have been various suggestions of what WAITS could stand for,
but none is official. Mine is the only semi-official one.
Yup, [FOO] should be [FOO,], with missing pieces from the current
("connected", although we don't use that term in WAITS) directory, not the
logged-in PPN. None of these special cases is crucial, so you could omit
any weird case if you want. (But if [FOO,] means anything for WAITS, it
should be consistent with WAITS, not TOPS-10.)
30-May-89 12:39:03-PDT,873;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 30 May 89 12:21:39 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA11895; Tue, 30 May 89 14:51:06 EDT
Date: 30 May 89 14:19:55 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Tapes & stuff
Message-Id: <"CSI 5575-1700"@CompuServe.COM>
to: Ken
fr: Benny
I had two tapes sent out to you today. I requested that
return payment be included. Please let me know if all is
not in order when you receive them.
I expect to fax you another copy of the contract today.
It may not be signed, but if you don't have any problems
with it, I'll get two copies of it signed and mail them
both to you. Then, if you'd sign them both and mail one
of them back to us, I'd appreciate it.
Sound reasonable?
30-May-89 12:51:07-PDT,573;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 30 May 89 12:50:50 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890516)
id AA11953; Tue, 30 May 89 14:51:32 EDT
Date: 30 May 89 14:21:20 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Protections
Message-Id: <"CSI 5575-1728"@CompuServe.COM>
to: Ken
fr: Benny
I'm going to get you the DEC <==> CompuServe protection
mappings tomorrow. Is there anything else that I need
to get to you that I may have forgotten?
30-May-89 13:20:55-PDT,1876;001000000001
Mail-From: KLH created at 30-May-89 13:20:34
Date: Tue, 30 May 89 13:20:34 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Contract
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5574-3085"@CompuServe.COM>
Message-ID: <12498199541.49.KLH@SRI-NIC.ARPA>
... of the compiler, although that is not our intent. Perhaps a
better wording would be "a company-wide license with right to
make multiple copies for company use".
Yes, that would be much clearer. Can this be done?
... But it's okay if we keep changes
that expose proprietary aspects of our system to ourselves isn't
it? I don't have any in mind, but "what if...".
Well, with the above wording change you suggest ("multiple copies for
company use"), I don't really have any problem with your making any changes
you want and keeping them to yourself. That's permitted under existing
copyright rules. The problem happens if you try to re-distribute your
changes as a derivative work. But almost by definition, if you had
a proprietary change, you'd hardly be distributing that! And in practical
terms, any CSI-specific stuff you do is unlikely to ever work anywhere
else anyway. Let's keep your lawyer happy.
Last week, I removed the whole statement regarding reasonable
number of rounds. Our lawyer objected, so it had to go back
in. I chose 4 rounds somewhat arbitrarily.
That's OK, as I mentioned.
You wouldn't consider changing the spelling of your name would
you? (Just kidding...)
Heh. Actually, I HAVE thought about this! My grandparents and relatives
use "Harrenstein" -- it's only my father (and hence myself and siblings) who
wound up switching the i and e. Long story. If nothing else, it does
give me a handle on figuring out which mailing list a particular piece of
junk mail originated from...
-------
30-May-89 13:24:31-PDT,961;001000000001
Mail-From: KLH created at 30-May-89 13:24:23
Date: Tue, 30 May 89 13:24:23 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Tapes & stuff
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5575-1700"@CompuServe.COM>
Message-ID: <12498200236.49.KLH@SRI-NIC.ARPA>
I had two tapes sent out to you today. I requested that
return payment be included. Please let me know if all is
not in order when you receive them.
Great!
I expect to fax you another copy of the contract today.
It may not be signed, but if you don't have any problems
with it, I'll get two copies of it signed and mail them
both to you. Then, if you'd sign them both and mail one
of them back to us, I'd appreciate it.
Fine... the wording change you suggested is the only thing that I'd
like to see done, otherwise you can assume it's fine. If I get
a fax today, I'll try to review it anyway and let you know ASAP.
--Ken
-------
30-May-89 13:25:57-PDT,856;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 30 May 89 13:25:44 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890530)
id AA13532; Tue, 30 May 89 16:26:20 EDT
Date: 30 May 89 16:02:36 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Fax problems
Message-Id: <"CSI 5575-2665"@CompuServe.COM>
to: Ken
fr: Benny
I attempted to fax you the contract a while ago, but
ran into technical problems. When I tried to redial
your fax number, I got ring no answer. Anyways...
I sent you about 10 pages. I think I sent you all
but the exhibits which were unchanged. Let me know
what needs changing. If all is okay, I'll mail two
signed copies of the contract out to you.
And let me know if you'd like a complete 14 pages sent.
Thanks.
30-May-89 13:37:43-PDT,764;001000000001
Mail-From: KLH created at 30-May-89 13:37:38
Date: Tue, 30 May 89 13:37:37 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Fax problems
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5575-2665"@CompuServe.COM>
Message-ID: <12498202645.49.KLH@SRI-NIC.ARPA>
Looks like the machine ran out of paper -- faxed out? Will have it
restocked shortly, but I got enough of the new contract, and since it
has your new wording, it's fine with me -- go ahead!
By the way, I did a little reading on copyrights recently and if my
understanding is correct, most of the stuff in section 5 about trade
secrets is probably unnecessary. However, I'm no lawyer, and we
don't want to perpetuate more go-arounds, so let's go...
-------
30-May-89 15:08:05-PDT,5983;001000000011
Mail-From: KLH created at 30-May-89 15:08:03
Date: Tue, 30 May 89 15:08:03 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: More questions
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5575-1728"@CompuServe.COM>
Message-ID: <12498219108.49.KLH@SRI-NIC.ARPA>
I'm going to get you the DEC <==> CompuServe protection
mappings tomorrow. Is there anything else that I need
to get to you that I may have forgotten?
I don't remember offhand if there was something missing. I'm sure anything
that is needed will make itself known. Here are a few more things I've
been thinking about.
(1) The value of time_t.
So far, I've made this value identical to that of UNIX for all
systems that KCC runs on; that is, the number of seconds since
1/1/1900 UTC. I also provide three routines to get the "local format"
time word as type "tadl_t", and convert it to and from time_t.
The main reason for this is to ensure UNIX software portability; it
has also turned out to help us transfer data files which have the date in
a binary format. Internally, it simplifies the library code since it
only has to work for one particular format.
However, your programmers could perhaps expect time_t to be in CSI's
"universal MJD.f" format (identical to TOPS-20 GTAD format), for the
convenience of code which deals with your operating system. Thus, this
needs to be discussed and settled so that no one is unpleasantly surprised.
I don't have strong feelings about the format; I can easily
change it so time_t on CSI is 36-bit MJD.f rather than 32-bit MJD.s.
Conversion between either of these is just a few instructions. My
recommendation, however, would be to try the latter first, on the
grounds that the major reason for using C in the first place is
portability, and any code of yours which needs to deal directly with MJD.f
is going to be non-portable and might as well be flagged by the use of
the tadl_t data type. By contrast, code which is happy with time_t
will definitely be portable (and you get a fighting chance to reverse-port
Unix-specific software). For example, you can obtain the creation
date and access date of a file by using stat() which converts the OS
format into time_t.
(2) How to build the compiler on CSI.
I am hampered by some ignorance here. I'm not sure what tools
are available for automatic program building. What I use on TOPS-20 is
KCC, MACRO, MAKLIB, and LINK, with .MIC files to invoke everything
appropriately. I have recently restructured things so that logical names
and .CCL files are used to establish bindings and module lists; the .MIC
files are now simple enough that they could be typed by hand if necessary.
If your version of LINK is not the most recent one, there may or may not
be problems; we'll have to see. I'm sure in any case that MIC and batch
CTL files need a different format on TOPS-10; you may have to do that
yourself.
I had to give up my 2400-baud modem to someone else with a
project requirement, which is why I haven't already tried to check
these things out on CPS. I'm hoping to get a new modem within a week
or two (should have arrived already, but hasn't yet).
(3) Minor annoying problem, related to above:
For various good reasons, KCC does its own invocation of MACRO and
LINK rather than expecting that a higher-level COMPIL-class command has
set everything up. One reason is because this avoids the need to mung
the EXEC or monitor to know about .C files; another reason is that the
MACRO args are unusual (require two files per module), and the LINK args
may also vary depending on the KCC switches. A final reason is that this
allows KCC to most closely approach the behavior of Unix compilers.
Now, recall that the output of KCC is actually an assembler
source file, not a .REL. On systems like TOPS-20 which allow
subforks, KCC can simply invoke the assembler and then clean up
afterwards. However, on TOPS-10, KCC has to turn control completely
over to the assembler, which does result in the desired .REL files but
also leaves around unnecessary .MAC and .PRE files. Can you think of
any way to ensure cleanup of these? The only thing I've been able to
come up with is a disgusting kludge whereby I'd have MACRO invoke a KCC
utility program instead of LINK; this utility would have its own
TMPCOR file set up to tell it which .MACs to flush, and would then
finally invoke LINK.
I'm not sure if it's worth bothering about. Any thoughts?
It could be that some people will consider this the more useful default
anyway.
Incidentally making KCC output .RELs directly is possible, but
would be non-trivial and would pose an interesting problem with
respect to handling the asm() and #asm facility. Sigh.
(4) Stack size allocation.
Another annoyance. It turns out that the TOPS-10 C startup code must
decide how large the stack should be, and the guess it makes may not always
be appropriate. Currently the stack size is stored in a patchable variable,
but this is not very elegant.
On CSI, if it is indeed permissible to allocate impure pages from
the address space above the high segment, then I can solve this simply by
using the same memory layout as on TOPS-20, where dynamic memory is allocated
above the high segment and the stack grows from the end of the low segment
until it collides with the start of the high segment. By handling PDL
overflow conditions, the need to pre-allocate a large low segment can also
be avoided, and memory is used most efficiently. The maximum stack size
can be varied by setting the highseg start location (LINK switch).
On a normal TOPS-10, however, I don't see any way to avoid the
need to pre-allocate the stack. Thus, the first version of KCC you get will
do things this way (vanilla TOPS-10, remember). Someday I guess the stack
size could be set in a loader argument switch.
(5) enough for one message...
-------
30-May-89 15:45:51-PDT,2269;001000000001
Mail-From: KLH created at 30-May-89 15:45:47
Date: Tue, 30 May 89 15:45:47 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Miscellanea and ELLE
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5574-1811"@CompuServe.COM>
Message-ID: <12498225977.49.KLH@SRI-NIC.ARPA>
ELLE. I'm very eager to have a look at ELLE. The business
of FINE reading an entire file into memory is a big weakness
of that editor. Can ELLE edit multiple files/windows?
Yes. Only 2 windows (as per Emacs convention) but as many buffers as
will fit in memory. It is also likely to support more terminals as it
uses TERMCAP. But no OS crash recovery and no user-definable macros other
than one keyboard macro.
Thanks for the level description. I noticed STLEV$ in COUGH.USR but
no explanation of what it meant.
I don't think there will be a problem building or running KCC from any
account, if the file permissions allow it. As I mentioned in another
message today, the KCC and library sources are now put together with
lots of logical names, in a different fashion from previous
distributions. The intent is to permit building or maintaining
different versions of KCC from the same central (possibly read-only)
set of sources; all site-dependent sources and all binaries can be
kept in different directories.
This does assume two things, however. The first is that user-defined
logical names must be possible (up to 10 or so). Judging from CSI's DEFIN$
UUO, this is okay. The second thing I'm not as sure about -- the ability
for a logical name to specify a search path, as on TOPS-20. For example,
a typical definition of C: for a cross-compiler would be:
C: => CT10:, CSTD:
which means that a LOOKUP of C:F.E would first look in CT10:F.E and
if not found would then try CSTD:F.E. TOPS-20 also permits definitions
like:
C: => CT10:, C:
which means that the second alternative is to try C:F.E where the
self-reference to C: means to use the system definition of C:, rather
than the job's.
If logical names cannot specify search paths (ie more than one
alternative) then it isn't necessarily a fatal flaw, but I will have
to revise my plan. I'd appreciate knowing what's possible.
--Ken
-------
31-May-89 14:02:11-PDT,598;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 31 May 89 14:01:56 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890530)
id AA10161; Wed, 31 May 89 17:01:37 EDT
Date: 31 May 89 16:53:37 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Logical names
Message-Id: <"CSI 5577-4446"@CompuServe.COM>
to: Ken
fr: Benny
At this time, I'm afraid that logical names cannot
specify search paths (i.e. more than one alternative).
I'll see if it can be added as it appears useful in
many contexts.
31-May-89 14:32:20-PDT,517;001000000001
Mail-From: KLH created at 31-May-89 14:32:17
Date: Wed, 31 May 89 14:32:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: More questions
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12498219108.49.KLH@SRI-NIC.ARPA>
Message-ID: <12498474740.49.KLH@SRI-NIC.ARPA>
Whoops, one correction. The value of time_t that KCC uses is the #
seconds since 1/1/1970, not 1/1/1900 as I earlier stated. 1970 is the
base that Unix uses, 1900 is the base for a network time protocol.
-------
2-Jun-89 14:45:41-PDT,2080;001000000011
Mail-From: KLH created at 2-Jun-89 14:38:17
Date: Fri, 2 Jun 89 14:38:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Time info
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5577-4446"@CompuServe.COM>
Message-ID: <12499000121.49.KLH@SRI-NIC.ARPA>
I'm having a little trouble deciding exactly how to handle times on CSI.
For example, it isn't clear to me how the "local time zone" is set.
Evidently this is meant to be done on a per-user (per-job) basis, so
that people hooked up from different timezones to a single host
machine will always see times from the viewpoint of their own zone.
But how is this done?
Also, do your systems support .RBTIM (extended LOOKUP block)? Is this
word in "local" time or UTC? I was assuming UTC, which is how the
TOPS-20 PA1050 package emulates it, but I just realized that the
documentation (both DEC 6.03 and COUGH.USR) is distressingly vague on
just when a "universal date/time" refers to a LOCAL time as opposed to
UTC. COUGH.USR is better, to be sure, but isn't consistent; there
are many instances where "universal" is mentioned, without specifying
what type it is. The treatise on "File Creation Times" is also disturbing
as it appears to imply that you don't support the extended LOOKUP block
(i.e. no access to the "internal UTC creation time").
I must admit, before now I had never even imagined the notion
of a "local universal" time -- the very words are a logical
contradiction! TOPS-20 and UNIX had the right idea by making all time
values always be GMT (UTC).
Does your system support %CNDTM and %CNGMT in the .GTCNF GETTAB table?
This won't be important for the CSI-specific version, but it will
affect the initial TOPS-10 port.
FYI: The C library does its own time figuring, after getting initial values
from the OS if possible. The (painful) code has to exist anyway since
some systems don't provide OS support for timezones or summer time,
and it is normally faster than making a monitor call. It is also
easier to change and debug.
-------
2-Jun-89 15:33:14-PDT,1208;001000000001
Mail-From: KLH created at 2-Jun-89 15:33:10
Date: Fri, 2 Jun 89 15:33:10 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Time info
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12499000121.49.KLH@SRI-NIC.ARPA>
Message-ID: <12499010112.49.KLH@SRI-NIC.ARPA>
Uh, perhaps you could pass the word to whoever maintains COUGH.USR that
Appendix A needs to be updated. The macros won't work as written and
don't support everything mentioned in the text. (e.g. SIZBIT instead of
SIXBIT, TZBLK$ instead of TZONS, $ instead of & ...)
I had to decipher them to figure out what the format of a timezone
block should be for TZONE$ since the text doesn't describe it. There are
enough mistakes that I'm not confident I've arrived at an accurate
description, and the block format looks weird enough that I think I'll
just wait until you can extract the facts from someone knowledgeable.
I was hoping that TZONE$ could be used to determine timezone info.
Unfortunately, if the documentation is complete, all it can be used for is
determining the offset between UTC and whatever local time the job is using;
it won't tell you what the summer time algorithm is.
-------
2-Jun-89 19:44:09-PDT,509;001000000001
Mail-From: KLH created at 2-Jun-89 19:44:07
Date: Fri, 2 Jun 89 19:44:07 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: another Q...
To: ME@SAIL.Stanford.EDU
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <1sTs5G@SAIL.Stanford.EDU>
Message-ID: <12499055798.49.KLH@SRI-NIC.ARPA>
Uh, minor question. When I ignore an E directory page "up to the first
formfeed", is that formfeed also flushed, or does it become the first char
the program sees? I'm assuming the former, but just wondered.
-------
3-Jun-89 02:51:24-PDT,546;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Sat, 3 Jun 89 02:51:21 PDT
Message-ID: <yhRIj@SAIL.Stanford.EDU>
Date: 03 Jun 89 0244 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: another Q...
To: KLH@SRI-NIC.ARPA
Well, the program should probably see the formfeed that ends the
directory, so that it knows what page it is reading from (for error
messages or whatever). Most programs won't care, but KCC itself might
like to report page and line numbers for errors.
5-Jun-89 14:08:36-PDT,2962;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 5 Jun 89 14:04:44 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA00654; Mon, 5 Jun 89 16:08:08 EDT
Date: 05 Jun 89 15:49:57 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: IBM announcement
Message-Id: <"CSI 5579-5362"@CompuServe.COM>
I know that I'll probably pay for forwarding this to b-ark, but I couldn't
help myself...
Forwarded Message 5573-10015
Subj: IBM announcement
This came from Jeremy Biggs over at Access UK. Thought you'd
enjoy it.
Carl Nelson
NEWS REPORT 29
25 May 1989
IBM ANNOUNCES EXTENDED MOUSE SUPPORT
The following is a direct, word-for-word reproduction of a recent IBM
'Service Support' announcement. (Honest !)
ESD PRODUCT SERVICE SUPPORT
SUBJECT: NEW RETAIN TIP
Record number: H013944
Device: D/T8550
Model: M
Hit Count: UHC00000
Success count: USC0000
Publication code: PC50
Tip key: 025
Date created: 089/02/14
Date last altered: 089/02/15
Owning B.U.: USA
Abstract: MOUSE BALLS NOW AVAILABLE AS FRU
Mouse balls are now available as a Field Replacement Unit (FRU). If
a mouse fails to operate, or should perform erratically, it may be in
need of a ball replacement. Because of the delicate nature of this
procedure, replacement of mouse balls should be attempted by trained
personnel only.
Before ordering, determine type of mouse balls required by examining the
underside of each mouse. Domestic balls will be larger and harder than
foreign balls. Ball removal procedures differ, depending upon manufacturer
of the mouse. Foreign balls can be replaced using the pop-off method, and
domestic balls replaced using the twist-off method. Mouse balls are not
usually static sensitive, however excess handling can result in sudden
discharge. Upon completion of ball replacement, the mouse may be used
immediately.
It is recommended that each servicer have a pair of balls for maintaining
optimum customer satisfaction and that any customer missing his balls should
suspect local personnel of removing these necessary functional items.
P/N N33F8462 - Domestic Mouse Balls
P/N N33F8461 - Foreign Mouse Balls
SAS Keywords:
PSY2 8525SYSMISC 8530SYSMISC 8550SYSMISC
8560SYSMISC 8570SYSMISC 8580SYSMISC
ESD PRODUCT SERVICE SUPPORT, BOCA RATON, FL.
JB
PS For those who don't believe this, the original document is in my office.
------ End of Message ------
C.NELSON for ABT 13:54 EDT 26-May-89 Message 5573-8658 forwarded by
ABT for JRB 17:36 EDT 26-May-89 Message 5573-10015 forwarded by
JRB for BEN 08:18 EDT 30-May-89 Message 5574-1689 forwarded by
5-Jun-89 14:15:11-PDT,9927;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 5 Jun 89 14:07:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA00495; Mon, 5 Jun 89 16:07:04 EDT
Date: 05 Jun 89 15:36:48 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Marooned in Realtime
Message-Id: <"CSI 5579-5233"@CompuServe.COM>
to: Ken
fr: Benny
Here's the response I received after forwarding
your questions to a more knowledgeable source than
I.
--------------------------------------------------------------------
Forwarded Message 5579-4413
Subj: Time answers
I agree 100% that TENEX and UNIX did it right, using universal time
with conversion to or from local regarded as an I/O function. I wish
TOPS-10 had done it that way; its effect on file LOOKUPs is described
below.
Here's some information on how I handle time zones; some of this might
be redundant, but I hope it'll answer the questions.
(1) Establishing the time zone
Each job has a time zone, described by a time zone tripleword.
When you login, it's set according to the location of the network
node to which your terminal is connected; if you enter via Tymnet,
Telenet, etc., we try to figure out the location of their node.
It's also possible to set a time zone for any particular PPN,
overriding the default.
You can change the zone with SETUUO, and you can read it with
REDUU$. However, the idea is that a program shouldn't look
directly at the tripleword; it should use monitor calls to perform
conversions as required.
You can "r usr:tzone" to play with a program that changes your
time zone. It can be useful for finding time zone dependencies.
(2) Reading the clock
The oldest ways to read the clock, using the MSTIME, DATE, and
TIMER calls, return local time (a poor choice, but retained to
avoid breaking old programs).
The doubleword at memory locations 36 and 37 octal, named .JBCLK,
contains the current time (UTC in days; what I call MJD.f and DEC
calls "universal" format). Typically, of course, you'd use only
the first word, but you can get a few extra bits of resolution
(though not 35 more) from the pair.
The GTAD$ and GTADU$ calls are obsolete, although they work.
(3) Conversions between binary formats
The MJD.f integer portion can be converted to YYMMDD with the
UNDMY$ call, and v.v. with DMYUN$. There is no call to
simultaneously convert both the integer and fractional parts
(UNDMY$ already existed when I implemented time zones, and it
takes only three or four instructions to convert the fraction as
shown in chapter 10, so I didn't think it was worth adding another
call).
DECUN$ and UNDEC$ also exist, but they're not as useful because
they use the DEC DATE format.
(4) Conversions between binary and text and accounting for time zones
There are TZONE$ functions that convert local MJD.f to UTC MJD.f;
UTC MJD.f to local MJD.f plus time zone name; and UTC MJD.f to
textual local time. They apply summer time appropriate to the
time being converted.
The TZONE$ conversion functions use your job's time zone unless
you include a time zone tripleword in the argument block. (That
is, use the shorter argument block unless you want to specify a
time zone.) Programs usually don't specify time zones, but some
billing programs want to use Eastern time as a reference.
ODTIM$ is another MJD.f-to-string converter. Unlike TZONE$, it's
stupid about summer time (a time in December is converted to
summer time if you execute ODTIM$ in June), but it has a bit that
inhibits zone conversion, making it useful for a straight MJD.f-
to-text conversion with no time zone implications.
unv:csisym.usr, under ODTIM$, shows the text format bits for
ODTIM$ and TZONE$. I think the only one not included in chapter
10 is the YMD-format bit.
(5) File creation times
As a result of our TOPS-10 heritage, file creation times in
LOOKUP/ENTER blocks are a little messy. First, they're in the DEC
DATE format with time in minutes rather than an MJD.f. Second,
they're in local time. Third, they reflect "current" rather than
"proper" summer time.
(a) The "real" file creation time is stored in the .RBEXT and
.RBPRV words as a DEC DATE and time in minutes. The .RBTIM
word does not contain the file's creation time; it contains
the time this instance of the file was created.
For example, if you take a file created 1 May 1989 and save it
(on tape, in a .pak file, in an .arc file) and then restore
it, the creation time in .RBEXT/.RBPRV remains 1 May; however,
.RBTIM will indicate today, because that's when this honest-
to-god physical copy of the file was created. .RBTIM is UTC,
by the way.
(b) The times returned in the "regular" creation time fields are
local. I'd rather return UTC, but TOPS-10 programs assume
they can convert to text without regard to zones and display
local time. (Internally, I maintain it correctly; do a
directory, change your zone with "r usr:tzone," then do
another directory, and you'll see that the times change.)
(c) There's one remaining nuisance--the "incorrect" application of
summer time--that makes it less straightforward if you want to
convert a file's creation time to UTC. If a file's creation
time is, say, 1989-06-03 1300 UTC, a LOOKUP will return (in
the DEC format) 1989-06-03 0900 to me, and 0600 in CA.
Come back in December and look at the file, and that same
creation time--1300 UTC--will be returned as 0800 (0500 in CA)
in the LOOKUP block. In other words, although a TZONE$ UTC-
to-local conversion would convert 1989-06-03 1300 UTC to 1989-
06-03 0900 EDT year-round, I convert it to 0800 EST when
returning it in the LOOKUP block during standard time. Thus,
this is one instance in which you should use TZONE$ to get the
current offset from UTC and do the addition yourself, if you
want to convert a file creation date.
(I did it that way to avoid a transition anomaly. Had I done
the conversion correctly, a file's local-time creation would
jump forward an hour when local time jumps backward at the
transition to standard time. That would break programs that
compare creation times--because they're comparing local time,
there would be an hour during which programs like COMPIL would
incorrectly decide not to compile something.)
(6) Summer time algorithm
There's no way for a program to determine the summer time
algorithm. The theory is that there's no reason for anyone to
know that, TZONE$ being available to do the conversions for you.
The time zone tripleword indicates, but doesn't describe, the
algorithm.
I decided against providing the ability to describe the summer
time algorithm in a time zone tripleword because the tripleword
should be static. By specifying the algorithm (0=never, 1=USA,
etc.), the tripleword must be changed only if the time zone truly
changes. By describing the algorithm (nth Sunday of nth month),
the tripleword would require changing at arbitrary times.
For example, the recent change to the start of summer time in the
USA required no program changes or alteration of stored time zone
triplewords. I simply changed the meaning of "USA standard summer
time" and everything worked. Had that meaning been embedded in
the tripleword, the change could have been a nightmare.
(7) We do support %CNDTM, although it's faster to fetch location 36.
We do not support %CNGMT; rather than a system-wide time zone,
each job has its own time zone.
(8) The time zone tripleword format
-------------------------------------------
|std n4|sum n4| 0000 | offset |
-------------------------------------------
| summer time indication |
-------------------------------------------
| std time zone name | sum time zone name |
-------------------------------------------
The right half of the first word gives the offset from UTC to
local standard time as a two's complement signed fraction of a day
with 17 fraction bits. It is negative for longitudes west of
Greenwich. Note that it is displaced one bit from what would
appear in an MJD.f because it requires a sign bit (the sign bit
can't take the place of a mantissa bit because offsets up to 13
hours are reasonable in some places near 180 deg).
The standard and summer time zone names are represented in SIXBIT.
The first three characters of each name appear in the third word,
and the fourth characters appear in the high-order part of the
first word as shown.
The second word indicates the handling of summer time. It can be
0: Always standard time
1: USA summer time
2: Australian summer time
3: European summer time
4: UK summer time
5: Canadian summer time
I'm not positive my handling of codes 2-4 are correct; they were
right when I originally put them in, but might well be out of date
now.
GSB for BEN 14:12 EDT 05-Jun-89 Message 5579-4413 forwarded by
5-Jun-89 15:41:44-PDT,2186;001000000001
Mail-From: KLH created at 5-Jun-89 15:40:07
Date: Mon, 5 Jun 89 15:40:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Current status
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12499797808.49.KLH@SRI-NIC.ARPA>
Got the tapes and the contract. I'll mail your copy back either
today or tomorrow (probably tomorrow). The tape will take a little
longer.
I have generated a TOPS-10 version of KCC & LIBC that has successfully
recompiled itself using the TOPS-20 PA1050 package and current
versions of MACRO and LINK. This of course does not contain any of
the CSI-specific UUOs or features, but since I am using only very
basic DEC UUOs, it should be a viable bootstrap.
I am now working on cleaning up the layout of the various source files
so that there is as little reliance as possible on TOPS-20 features
such as logical name search lists. I modified KCC to get around that;
there may be some additional inconvenience on TOPS-10 but it should be
limited to keeping an extra copy of some binary files for LINK's
benefit.
Once I finish the cleanup and reorganization, I'll send you a tape.
This version will not have everything I had hoped (most notably
random-access I/O), but will serve to establish our procedures for
getting the software there and installed. Any inherent problems that
arise can then be fixed in a follow-up tape with plenty of time before
June 15.
I just had a thought. If it is true that .EXE files have the same
format on TOPS-10 and TOPS-20 (something I am still dubious about)
then it may be possible to use KERMIT at 2400 baud to transfer small
self-contained test programs (approx 40 pages of 512 wds) over to CPS.
This would give me a head start while waiting for you to get the tape
and set up the source directories. I'm not sure yet how I'll manage
to route them without using the NIC 20, but I'll think of something.
A question: How much do you want me to keep you informed and/or
involved? That is, do you want things kept out of your hair as much as
possible, or do you want to indulge in keeping your hands dirty? I can
moderate e-mail accordingly.
--Ken
-------
5-Jun-89 22:22:24-PDT,842;001000000001
Mail-From: KLH created at 5-Jun-89 22:22:21
Date: Mon, 5 Jun 89 22:22:21 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Another Q about lookup/enter block
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12499871033.29.KLH@SRI-NIC.ARPA>
Pardon if I've asked this before and forgotten the answer. On page 21
of the UUO manual it mentions that the "creation date" in the rightmost
15 bits of word 1 contain the "creation date", which is "a slightly
less than well defined quantity".
A normal TOPS-10 refers to that field as the "access date", and what
WAITS uses for "time/date written" is TOPS-10's "time/date created". So
I was a little mixed up for a while.
What exactly is that field (21:35 of word 1) used for? Do you not have
anything to indicate the last time or date a file was read?
-------
5-Jun-89 23:09:37-PDT,4070;001000000001
Mail-From: KLH created at 5-Jun-89 23:09:22
Date: Mon, 5 Jun 89 23:09:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Marooned in Realtime
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-5233"@CompuServe.COM>
Message-ID: <12499879593.29.KLH@SRI-NIC.ARPA>
Bobble up... more questions! Pass 'em along...
The doubleword at memory locations 36 and 37 octal, named .JBCLK,
contains the current time (UTC in days; what I call MJD.f and DEC
calls "universal" format). Typically, of course, you'd use only
the first word, but you can get a few extra bits of resolution
(though not 35 more) from the pair.
Bizarre... how does this work? Does the hardware trap references to
these locations, or does the monitor really go around updating every JOBDAT
area each clock tick? Both hard to believe. Anyway, so you're saying
location 36 in a job is the same thing as %CNDTM, which is "local" time
in MJD.f format (and not UTC)? If I still need to use TZONE$ in order to
get the real UTC from this value, I might as well just use GTADU$ in the
first place, I guess; correct? (I would normally simply remember the offset
in another word somewhere and add it in, but this won't work during summer
time transitions. Bah.)
(a) The "real" file creation time is stored in the .RBEXT and
.RBPRV words as a DEC DATE and time in minutes. The .RBTIM
word does not contain the file's creation time; it contains
the time this instance of the file was created.
Thanks, the DEC documentation wasn't clear about how .RBTIM differed
from the old-style creation date.
I assume the same cautions regarding the creation date also apply to
the file access date. Is the latter really updated every time the
file is read? Amazingly enough, nothing in any DEC documentation
actually says what happens (not unusual, unfortunately).
Let me digress here so you can see what I'm getting at. If you have a
UPM, look up stat(2). I need to emulate the following three values:
st_atime - last access time (file created, read, or written)
st_mtime - last data modify time (file created or written)
st_ctime - last status change time (file created, written, or
status information changed in any way, such as
renamed, copied, given new protection or owner, etc)
My current mapping is:
st_atime - most recent of old-style access date (midnight) and st_ctime
st_mtime - old-style creation date & time
st_ctime - most recent of .RBTIM and st_mtime
Note that I don't ever need the old-style DEC dates for any reason
other than to convert them to UTC. Thus, if there is a way to get the
UTC directly, that would be a great win. Do all the hints about
"internal" stuff mean that there is a way to get the UTC times with an
extended LOOKUP? (I'm on my knees praying...)
There's no way for a program to determine the summer time
algorithm. The theory is that there's no reason for anyone to
know that, TZONE$ being available to do the conversions for you.
The time zone tripleword indicates, but doesn't describe, the
algorithm.
Sorry, I should have been more precise. An indication of the algorithm
is what I wanted, not a full description. The second-word value in the
timezone block is sufficient. The library contains code to dispatch to
the appropriate algorithms depending on timezone type, although only
USA is currently implemented.
Given your peculiar service requirements and the (unusual)
availability in the monitor of timezone support, it looks like the
best thing would be for me to violate my normal layering rules and put
certain CSI-specific calls into some functions that normally rely on
Unix system calls. This will ensure that changes to the monitor
algorithms are immediately reflected in all binaries, without
requiring recompilation, albeit at the cost of increased execution time.
Thanks for the detailed explanations, they help a lot.
--Ken
-------
6-Jun-89 01:28:10-PDT,2101;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue, 6 Jun 89 01:28:06 PDT
Message-ID: <Aj0fA@SAIL.Stanford.EDU>
Date: 06 Jun 89 0057 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: Another Q about lookup/enter block
To: KLH@SRI-NIC.ARPA
If you do a long-block LOOKUP (400 bit on in IO mode), you get 6 words
returned instead of 4, and the low 15 bits of the 5th word contain the
reference date (no time, just date), which is the last date on which the
file was read (or written, actually). (The left half of that word
contains the reference count, which is the number of different dates on
which the file has been referenced since the date written. The 6th
word returned holds the date the file was backed up to tape.) By the
way, note that the 400 bit has a DIFFERENT meaning in the IO mode at
the moment of the INIT or OPEN, so you probably shouldn't have it on
then (although for a sharable device like the disk, it doesn't matter, as
long as you don't have some non-sharable device assigned as the sharable
device). So if you want the 400 bit on for a LOOKUP, you should set it
with SETSTS sometime after the INIT or OPEN. The 400 bit also affects
ENTER; in particular, it lets (makes) you set the date written explicitly,
rather than just using the current time and date.
The WAITS "creation date" is sort of the date the file first came into
existence, not being updated when you alter the file (e.g., in RA mode).
But this isn't exactly true, no one uses or depends on that date, and
it isn't, as you've noticed, entirely documented (I don't know exactly
when it is updated).
The WAITS "date/time written" is called that instead of "date created" to
distinguish the date you first create a file from the date that you last
updated it -- you certainly haven't "created" the file on the last date,
but you've written the file then, so we call it the date written, not the
date created (as TOPS-10 misleadingly calls it). Hope that clarifies
the reason for the different terminology.
6-Jun-89 06:19:35-PDT,855;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 6 Jun 89 06:19:19 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA17681; Tue, 6 Jun 89 09:20:35 EDT
Date: 06 Jun 89 08:39:59 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Involvement
Message-Id: <"CSI 5579-7594"@CompuServe.COM>
How much to keep me informed/involved?
I like to stay informed. You can't send me too much e-mail.
I'm involved in so many things at present that I don't know
what to do, and progress on several fronts is suffering. If
my involvement can help, then by all means involve me. I
suspect that I can best serve by providing accounts and
services and information. I'll try and be here if needed.
How many UFDs do you want for source directories?
6-Jun-89 07:12:04-PDT,1204;001000000001
Mail-From: KLH created at 6-Jun-89 07:11:55
Date: Tue, 6 Jun 89 07:11:55 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Involvement
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-7594"@CompuServe.COM>
Message-ID: <12499967438.41.KLH@SRI-NIC.ARPA>
I like to stay informed. You can't send me too much e-mail.
I'm involved in so many things at present that I don't know
what to do, and progress on several fronts is suffering. If
That seems a little contradictory, but I'll take your word for it and
send whatever news or questions come up. Good luck...
How many UFDs do you want for source directories?
Umm. While I could squish things together into fewer dirs, for the
time being it's probably simplest to keep a one-to-one mapping with the
TOPS-20/Unix layout. This will require 11 source dirs, plus 1 for
holding the resulting binaries, plus 2 to function as the installed
implementation, for a total of 14. Since we may want to generate
both a T10 and a CSI implementation at the same time for comparison/debugging,
it won't hurt to add another binary directory which makes 15.
A bit more on dirs in next message.
-------
6-Jun-89 09:33:38-PDT,3539;001000000001
Mail-From: KLH created at 6-Jun-89 09:33:36
Date: Tue, 6 Jun 89 09:33:36 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: CSI command manual?
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12499993230.41.KLH@SRI-NIC.ARPA>
I think I need a CSI monitor command manual. I just fumbled my way
through getting a toy .EXE file from TOPS-20 to CPS via a SUN using
KERMIT, and getting the damn thing to execute.
The good news is that the .EXE file format is similar enough that
at least tiny things appear to work. The bad news is that it is HELL
trying to get anything to work.
Admittedly, I was winging it with only the rudimentary on-line "help"
and a 1970 DEC manual on hand. But is that really an excuse for RUN
DSK:FOO.EXE to complain "? EXEUNL Unknown language: EXE" followed by
"? EXENSF No such file: FOO.REL"? ... of course, .SAV didn't work any
better. Okay, I find that EXECUTE loses too, and eventually realize
that "R" is much different from "RUN", and gives me a chance provided
I'm careful to specify the entire filename to prevent it from
defaulting everything wrong (FOO becomes SYS:FOO.EXE and evidently
SYS: does not search my dir first...) But as it turns out, just being
careful isn't good enough, as R silently ignores the extension you
give it, if something else already exists with an .EXE! Much
confusion until I realized that it was loading an older buggy file...
But prior to that, while I still wasn't sure if KERMIT had transferred
the file properly or not, I typed in a little macro test program and
used LOAD on that, which happily seized the .REL and everything
worked. I try to LOAD and then SAVE. Eh, it complains "ICSNCF - no
current file". Dumb ICS editor command, I guess. I try SSAVE. It
complains "? Execute only". I guess I just tried to SSAVE the editor.
I try loading with the /SAVE switch given to LINK, and it makes a
FOO.EXE for me. Goody, I try R DSK:FOO and get "? No starting address
in file". Geez, doesn't any of this software ever talk to each
other?? Does it even talk to itself?? Finally I get a runnable EXE
with NSSAVE and verify that it IS possible to get something working.
Various other miscellaneous problems, none fatal but all annoying.
KERMIT-10 needs to be given SET FILE BYTE-SIZE 7 (not 8) in order to
transfer 36-bit words, contrary to at least one kermit manual. KERMIT-10
claims that giving a filename specification to the RECEIVE command will
override the sender's filename, but instead I got "?Kermit-10 Wild file specifications illegal on RECEIVE". If you can see anything wild about either
"ktexd.exe" or "ktest.kx" (the receiving and sending names), tell me how.
Attempting to give a second RECEIVE command to the same KERMIT-10 seemed
to always produce "?Kermit-10 Terminal open failure", requiring a quit
and re-invocation.
Trying to execute a standard SAV format file ( -<cnt>,,<loc-1> followed
by cnt words, etc) gives an error message "? Not enough core available
to load file KTEST.SAV". This is a very tiny program. The EXE format
version worked. However, when I attempted to duplicate this success with
a real C program (18432 words), I got the error "? Too many segments"
which I guess has something to do with the fact it is a two-segment
program.
At least it IS possible to transfer a 36-bit file accurately (I used
FILCOM to print out a binary listing), and it appears to take about
one minute per 512-word page.
Questions in next message.
-------
6-Jun-89 10:10:02-PDT,1544;001000000001
Mail-From: KLH created at 6-Jun-89 10:10:00
Date: Tue, 6 Jun 89 10:09:59 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: A few questions
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12499999856.41.KLH@SRI-NIC.ARPA>
Do you know if there are any KERMIT settings I should consider tuning
in order to get a better transfer rate? It appears to send lots of
very tiny packets, and the delay for each ack is significant. Some
years ago I wrote a Unix kermit that worked well enough that I did
filesystem dumps over a serial line, but I don't think the features of
that version got into circulation, and I'd rather not dig into it again
if someone can just provide a setting...
I ran into a couple of problems with CSI logical names while experimenting.
For one thing, the DEFINE command appears not to allow logical names to
have anything but alphanumeric chars in them. I couldn't quote them either.
I can't think of any reason why this should be so.
Logical names can be defined to be other logical names, but this
doesn't work. If FOO: is defined as BAR: which is defined as [123,45]
then a reference to FOO:FILE.EXT will complain that BAR: is a
non-existent device. This once again trips up the nice file
directory bindings I set up for building the implementation. It looks
like TOPS-10 is going to require a lot more repetitive typing than
other places.
Not a question: I just found IGET and IRUN, which is what I really
wanted all along. I feel a little better now...
-------
6-Jun-89 10:18:51-PDT,1106;001000000001
Mail-From: KLH created at 6-Jun-89 10:18:45
Date: Tue, 6 Jun 89 10:18:45 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Contract question
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12500001451.41.KLH@SRI-NIC.ARPA>
I was just about to send off the contract form when I had a nagging
thought. Were both of those copies supposed to be signed? Most of
the fax copies you sent me previously had someone's signature on them,
and I expected this to be the case for the real thing as well, so that
both of us wound up with a copy that had both sets of signatures on it.
But neither of these copies is signed by anybody (yet). Was this
intentional, or an oversight?
I suspect it might be the latter because otherwise there would not
have been much point in sending two copies... I could just have
photocopied one of them. If my guess is right, then what I can do is
just sign and mail both of them back, whereupon you can re-mail one of
them back to me after your lawyer spills ink on it.
I'll hold onto it until I hear from you (yet another day...)
-------
6-Jun-89 11:27:43-PDT,1190;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 6 Jun 89 11:15:25 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA23281; Tue, 6 Jun 89 14:16:15 EDT
Date: 06 Jun 89 13:39:13 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Troubles
Message-Id: <"CSI 5579-9996"@CompuServe.COM>
Ken -- Sorry about your troubles. Here are a few clues. You
should be able to do a privileged SET WATCH FILES command and
will probably find it helpful.
The R command does look on SYS:. To run an image from your
current directory use IRUN.
For macro work, I typically use LOAD (which will force a recompilation
if the source has been modified) followed by a START or a NSAVE
command. To get DDT into the act, use LOAD/D.
The GO command will redo the last "execute class" command issued (i.e.
a COMPILE, a LOAD, a RUN). ^X^E out of FINE will exit FINE, updating
the edit and rerun the last "execute class" command also.
Yes, our host version of KERMIT is ------- (fill in the blank). Sorry.
I'll try and get you a manual that documents some of our commands.
--- Benny
6-Jun-89 11:52:32-PDT,562;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 6 Jun 89 11:52:06 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA24302; Tue, 6 Jun 89 14:53:21 EDT
Date: 06 Jun 89 14:19:37 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Contract
Message-Id: <"CSI 5579-10332"@CompuServe.COM>
Ken --- Sigh. Yes, I asked that you be sent two SIGNED copies
of the contract. If you'll sign both of them, we'll sign them
and send you one back. Sorry.
Benny
7-Jun-89 02:27:26-PDT,953;001000000001
Mail-From: KLH created at 7-Jun-89 02:27:22
Date: Wed, 7 Jun 89 02:27:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: .DMP format question
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12500177781.26.KLH@SRI-NIC.ARPA>
Thanks for previous answer. Now I'm trying to puzzle out how to best
format my first test programs, and it will help if I know something about
the formats that WAITS will accept.
The problem with DMP as described in the manual is that it sounds impossible.
How do you store a two-segment program with a bunch of stuff in the low seg
and more stuff starting at 400000? You don't really have hundreds of
empty disk blocks in between, do you?
Or are all of your programs one-segment? I must be missing something, but
I don't know what it is.
Will .SAV files be accepted by the monitor? You know, the old DEC format
where each block of words starts with <-count>,,<addr-1> ...
-------
7-Jun-89 04:03:24-PDT,357;001000000001
Mail-From: KLH created at 7-Jun-89 04:03:21
Date: Wed, 7 Jun 89 04:03:20 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Contract
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-10332"@CompuServe.COM>
Message-ID: <12500195253.26.KLH@SRI-NIC.ARPA>
OK, signed both and will send them on their way today.
-------
7-Jun-89 04:23:20-PDT,1580;001000000001
Mail-From: KLH created at 7-Jun-89 04:23:17
Date: Wed, 7 Jun 89 04:23:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Status
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12500198884.26.KLH@SRI-NIC.ARPA>
After more assorted troubles that you don't really want to know about,
I succeeded in loading and running some C programs on CPS.
I still don't know exactly what the problem is with EXE-format files,
someone who knows more about the internals of the monitor would have
to check into this. I know how TOPS-20 EXE files are constructed, but
have no source of information on TOPS-10.
What I did was transfer a copy of LIBC.REL (the C library) and the
RELs of some test programs, using your LINK to put things together.
They all worked, including command line I/O redirection. I was a
little surprised -- even though I tested them with the PA1050 simulator,
one never knows.
I could possibly transfer the RELs for KCC itself. Hmm, that's about
184 pages of RELs, at one minute each it'd take 3 hours. If the
TOPS-10 Kermit can hold itself together for more than one file at
a time, maybe I'll try that. It took me several tries to get LIBC.REL
across, though -- the first few times, something hung up on me and
I had to reconnect and relogin. No idea whether it was due to forcible
logout, or network wedgage, or modem problems (tho I think the latter is
unlikely, based on error-free history). Is this a known problem? If there
were any error messages, they were of course lost in the kermit transfer.
-------
7-Jun-89 04:46:30-PDT,558;001000000001
Mail-From: KLH created at 7-Jun-89 04:46:28
Date: Wed, 7 Jun 89 04:46:28 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: CPS usage questions
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12500203104.26.KLH@SRI-NIC.ARPA>
How heavily loaded is the system my guest account is on? Are there
any problems with using it (and the network) during the daytime for
stuff like file transfers or large compiles? You already said not to
worry about connect charges or disk space; now I'm checking about
CPU and network I/O.
-------
7-Jun-89 05:41:15-PDT,1243;001000000001
Mail-From: KLH created at 7-Jun-89 05:41:13
Date: Wed, 7 Jun 89 05:41:12 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: success!
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12500213069.26.KLH@SRI-NIC.ARPA>
Perhaps it doesn't matter what the DMP format is for twoseg programs
(although I am still curious). I cross-compiled a library for WAITS,
FTP'd over the LIBC.REL and some test-program .RELs, and with the
help of an old monitor command manual was able to use the loader to
produce DMP files that execute properly! I/O redirection works, too!
It's apparent that some of the code in KCC which invokes LINK will
need to be changed; the version you have appears to be sufficiently
different that syntax which works on TOPS-10/20 won't work on WAITS.
I'm also wondering why you seem to have two different linkers, LOADER
and LINK. Is one preferable to the other? Is there a way I can
find out how the TMPCOR files given to them are formatted?
Once I have that info, I can twiddle KCC to invoke the linker properly
and can then bring over the KCC REL files to test it out. If that
works, I just need to copy the #include files into [*,KCC] and you
then have a real C compiler...
-------
7-Jun-89 07:30:12-PDT,739;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 07:30:02 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA01418; Wed, 7 Jun 89 10:30:00 EDT
Date: 07 Jun 89 08:41:45 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: misc
Message-Id: <"CSI 5579-13717"@CompuServe.COM>
Ken -- All of our systems get pretty heavily loaded during the day. Don't
worry about CPU and network I/O or impacting any other users. Your guest
account happens to be on the same system as project 311 that will be opened
up to you soon. I've created 15 UFDs for your use.
I'll FAX you a copy from the DEC manuals on the makeup of .EXE files.
7-Jun-89 07:38:44-PDT,696;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 07:36:36 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA01390; Wed, 7 Jun 89 10:29:45 EDT
Date: 07 Jun 89 08:45:34 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Operations taking systems
Message-Id: <"CSI 5579-13758"@CompuServe.COM>
Ken -- Operations sometimes takes systems down in the middle of the night.
I mention this because it seems that you might be trying to use the system
during the very early morning hours Eastern Time. They are supposed to
warn users, but if you're in the middle of a Kermit transfer...
7-Jun-89 10:07:33-PDT,3031;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 10:07:11 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA04099; Wed, 7 Jun 89 13:07:38 EDT
Date: 07 Jun 89 11:51:44 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Time for an answer
Message-Id: <"CSI 5579-15510"@CompuServe.COM>
LOCATION 36--The doubleword at location 36 contains UTC, not local
time. We also return UTC for %CNDTM. For example,
DHB>r usr:ddt
DDT
0[ 0 %cndtm
gettab$x
<SKIP>
0[ 135103,,657774 36[ 135103,,660010
^C
DHB>day
4:15 PM EDT Tuesday, June 6, 1989
DOS Command:mjd 0135103.660010
MJD 47683 (0xba43, 0135103) = Tue 1989-06-06 2015:02.637.
(MJD is an 8086 program that converts an MJD.f to or from text without
applying any time zone offset, here showing that the values in 36 and
%CNDTM correspond to UTC.)
From our point of view, it's impossible for %CNDTM to be local time
because GETTAB simply fetches a word without doing any conversion. I
thought TOPS-10 also stored UTC there, but perhaps not--without the
concept of per-job time zones, maybe they store "system" local time
there.
Locations 36-37 are updated by the monitor at about a 60 Hz rate.
Statistics hinted that the savings of a MOVE over a monitor call
exceeded the loss caused by the updates. Note, by the way, that it's
not necessary to update every job's doubleword. If you're not
running, you can't notice that your copy is out-of-date, so I update
only the running job's doubleword (with an additional update on a
context switch to a job).
FILE ACCESS DATES--A file's access date is updated when a file is
closed after having been read, although there is a "don't update the
access date" option for CLOSE (programs that copy files to backup
tapes use it). Because the access time resolution is only one day,
the disk copy is updated at most once a day.
Of course, that resolution makes time zone conversions irrelevant; I
mainly just back it up by a day if it would appear to be in the future
(access date is the 6th, but it's only the 5th in your time zone).
STAT() EQUIVALENTS--Although I'd had the impression (from K&R) that
st_ctime was the file's original creation time, for which the old-
style creation time is more appropriate than .RBTIM, it looks like
that's not quite true, and the ctime/.RBTIM and mtime/.RBPRV mapping
makes more sense. The main significance would be in, say, deciding
whether to compile something, where the old-style times should be
compared; using .RBTIM, the decision could be incorrect (extra
compilation if you restore a source and binary but the binary happens
to be restored first, or failing to recompile if you edit a source,
then restore an old binary).
GSB for BEN 11:33 EDT 07-Jun-89 Message 5579-15387 forwarded by
7-Jun-89 12:02:46-PDT,1357;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 12:02:35 PDT
Message-ID: <ejZUB@SAIL.Stanford.EDU>
Date: 07 Jun 89 1202 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: success!
To: KLH@SRI-NIC.ARPA
Congratulations on getting your test C programs running under WAITS.
To answer your questions anyway: The location HILOC (135) in the
saved .DMP file contains the address where the high segment begins
(after the .DMP file has been loaded into core). And, no, .SAV files
cannot be run.
The reason we have two loaders (two linkers?) is that we've had LOADER
from the beginning of time and it is what most things use. But someone
brought LINK-10 over to SAIL about 10 or 12 years ago so that certain
types of programs would load faster (I guess LINK is faster than
LOADER at resolving external symbols, or something like that). Most
WAITS programs are one .REL file, so they don't care and LOADER is the
default. I would say that whichever one you can get to load KCC's
.REL files is the one to use.
I'll see what I can find out about the TMPCOR format. You might
just compile a program and look at the TMPCOR file ("R TMPCOR;?" to
play with your TMPCOR files). It's probably standard LOADER stuff
(got any old DEC documentation on LOADER?).
7-Jun-89 12:42:32-PDT,612;001000000001
Mail-From: KLH created at 7-Jun-89 12:42:26
Date: Wed, 7 Jun 89 12:42:26 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: misc
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-13717"@CompuServe.COM>
Message-ID: <12500289752.26.KLH@SRI-NIC.ARPA>
OK, I won't worry about it then, although if things are too sluggish to
suit me I'll just shift accordingly. I try to only use the SRI machine
on off-hours so it's likely that CPS access will follow a similar
schedule also. But we'll see.
Received the EXE-format fax, will comment on it in a separate msg.
-------
7-Jun-89 12:49:58-PDT,560;001000000001
Mail-From: KLH created at 7-Jun-89 12:49:56
Date: Wed, 7 Jun 89 12:49:56 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Operations taking systems
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-13758"@CompuServe.COM>
Message-ID: <12500291116.26.KLH@SRI-NIC.ARPA>
Thanks, I had wondered about that. For a while, an attempt to login was
being met with a message about DDH being temporarily unavailable. I guess
it's possible they might have yo-yo'd a bit, and of course I won't have
seen any message.
-------
7-Jun-89 13:20:57-PDT,2479;001000000001
Mail-From: KLH created at 7-Jun-89 13:20:37
Date: Wed, 7 Jun 89 13:20:36 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Time for an answer
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-15510"@CompuServe.COM>
Message-ID: <12500296698.26.KLH@SRI-NIC.ARPA>
LOCATION 36--The doubleword at location 36 contains UTC, not local
time. We also return UTC for %CNDTM. For example,
Great. I'll have the CSI version use this, then. I must admit that
it's a novel way to do things. On ITS, some programs do something
similar by mapping the appropriate monitor page into their own address
space; I had the mailer do this, for example, since it asked for the
time incessantly.
STAT() EQUIVALENTS--Although I'd had the impression (from K&R) that
st_ctime was the file's original creation time, for which the old-
style creation time is more appropriate than .RBTIM, it looks like
that's not quite true, and the ctime/.RBTIM and mtime/.RBPRV mapping
makes more sense. The main significance would be in, say, deciding
whether to compile something, where the old-style times should be
compared; using .RBTIM, the decision could be incorrect (extra
compilation if you restore a source and binary but the binary happens
to be restored first, or failing to recompile if you edit a source,
then restore an old binary).
Right, in fact that's the most common reason for looking at the times from
stat(), and st_mtime is the appropriate value since that is supposed to
reflect the time the data itself was modified, rather than some random
attribute of the file. So I think we're okay from that angle.
K&R is simply wrong about st_ctime. The 2nd edition didn't fix that
either; of course, there isn't necessarily any real connection between
what they show of Unix and an actual Unix, since the examples are
oriented to teaching C and not a particular flavor of Unix.
Personally I believe that Ken and DMR originally did plan to have
st_ctime reflect the creation time once and for all, but somehow it
got changed in the kernel and the symbol was re-interpreted as "change
time" rather than "creation time". Oh well.
You didn't say whether the old-style DEC access or creation dates were
generated from UTC values that are accessible to a knowledgeable program.
Could you either squash this hope or explain how to do it?
Thanks!
--Ken
-------
7-Jun-89 13:49:05-PDT,604;001000000001
Mail-From: KLH created at 7-Jun-89 13:49:02
Date: Wed, 7 Jun 89 13:49:01 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Help...
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-15510"@CompuServe.COM>
Message-ID: <12500301874.26.KLH@SRI-NIC.ARPA>
I successfully brought over all the RELs for KCC and linked everything
together. However, when I attempt to run the resulting program, I get
the message "? Not enough core available". When I try to use the CORE
command to get more, I just get the inane error "? Execute only".
I'm stuck. What now?
-------
7-Jun-89 15:17:10-PDT,1196;001000000001
Mail-From: KLH created at 7-Jun-89 15:17:03
Date: Wed, 7 Jun 89 15:17:02 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: EXE format problems
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12500317897.26.KLH@SRI-NIC.ARPA>
Well, on looking at the document you faxed, I can see some differences
from TOPS-20 format. These are:
(1) TOPS-20 has two additional "chunk" types:
1775 - Entry Vector. Always present. TOPS-10 appears to ignore it.
1774 - Program Data Vector. Optional, rarely used.
(2) TOPS-10 has two flag bits not present in TOPS-20:
bit 0 - part of hiseg. (having this off probably hurts)
bit 3 - concealed. (having this off shouldn't hurt)
I looked at a few EXE files with BINDMP and confirmed that their format
is as described by the document. I'm curious, however, why there are
two different commands, SSAVE and NSSAVE; this seems to imply that the
two produce slightly different formats. If so, what is the difference?
My best guess is that the problems with direct transfer of T20 EXE files are
due to not having bit 0 set for the hiseg pages. I can write a program
to set those flags, and see if that works.
-------
7-Jun-89 15:54:22-PDT,817;001000000001
Mail-From: KLH created at 7-Jun-89 15:53:39
Date: Wed, 7 Jun 89 15:53:38 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Automated building
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12500324559.26.KLH@SRI-NIC.ARPA>
I'd like to put together some files that will automate the KCC build on
your system, similar to the ones I have on TOPS-20. Do you have any
preference as to mechanism? There seem to be a couple of different ways
to do this kind of thing, and it's probably best to use anything you have
already standardized on or are most familiar with.
If there's no preference, what options would you suggest looking into? (There
may be some that postdate my manual). It appears you don't have MIC.
If you don't know that either, I'll figure something out.
-------
7-Jun-89 16:19:50-PDT,1864;001000000001
Mail-From: KLH created at 7-Jun-89 16:19:48
Date: Wed, 7 Jun 89 16:19:48 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: status: EXE and CORE
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12500329321.26.KLH@SRI-NIC.ARPA>
(Are you getting enough mail yet?)
OK, I've figured out how to transform a TOPS-20 EXE into a TOPS-10 EXE, and
have brought over and run a converted C program. It seems possible that the
actual problem may not have been the "hiseg" bit, but rather the fact that
TOPS-20 SAVE by default sets all pages to be both sharable and writable,
and it may be that TOPS-10 can't handle the many separate groups of such
pages (hence the error message about too many segments). I'll can do a few
more tests later, but for the time being it's sufficient to know that I
just need to reset the flag bits to simulate what TOPS-10 EXE files contain.
I checked my old monitor command manual (still more informative than the
online HELP) and figured out why CORE was failing. I got it to merely
say "? Not available" which basically means I don't have a large enough
core quota. You'll have to get it bumped up for me -- if possible, to
the max of 512 pages. KCC needs 240 pages just to load itself.
Aside: why even bother to enforce any core restrictions any more? If
the system uses paging, then it seems like enforcing, maintaining, and
changing core restrictions would be far more trouble than it's worth.
(think about all the real time you and I have just wasted on this.)
After all, any programs that use "too much" memory will merely suffer
degraded performance due to page faults and get poorer treatment from
the scheduler, and users all by themselves will get the notion of
either using different programs or only running them during light-load
periods. Evolution in action...
-------
7-Jun-89 19:35:36-PDT,906;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 19:35:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA16067; Wed, 7 Jun 89 22:36:10 EDT
Date: 07 Jun 89 22:15:16 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Automated
Message-Id: <"CSI 5579-18884"@CompuServe.COM>
Ken -- regarding automated building. We have MAKE albeit sort of buggy I'm
told (I don't use it myself, but a lot of people do). I use COM files, but
current doco is hard to find. Try DDH:[300,2]DECODE.DOC. In fact, look
over the "stuff" in DDH:[300,2].
Sorry I was unresponsive to the problems with EXEs, but I was unavailable
most all afternoon. Just trying to catch up now.
I'm not sure what MIC is, but I may know it by another name.
I'll try and address the core problems/questions tomorrow.
8-Jun-89 01:13:48-PDT,581;001000000001
Mail-From: KLH created at 8-Jun-89 01:13:21
Date: Thu, 8 Jun 89 01:13:21 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: What's SAILOW?
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12500426452.26.KLH@SRI-NIC.ARPA>
There appears to be some doc in LINK.JFR[S,DOC] which, in its examples,
always includes SYS:SAILOW as the first module loaded. I can't seem to
find the source for this and rather than blindly include it I'd like
to find out whether it really does contain something needed.
Just trying to avoid trial-and-error approach.
-------
8-Jun-89 03:18:03-PDT,1481;001000000001
Mail-From: KLH created at 8-Jun-89 03:18:02
Date: Thu, 8 Jun 89 03:18:02 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Help!
To: me@sail.stanford.edu
cc: klh@SRI-NIC.ARPA
Message-ID: <12500449149.26.KLH@SRI-NIC.ARPA>
I brought over all of the REL files for KCC (CC*.REL[1,KLH]) and tried
to build an executable with both LOADER and LINK.
For LINK, I did:
.R LINK
*@WCC.CCL
which succeeded; however, attempting to run the resulting NCC.DMP
caused an instant error with the very first instruction! It said "Ill
mem ref at user 503361" which is the start address. I copied it to
WCC.DMP.
Then I tried loading DDT with it to see if I could use that to investigate.
I did:
.R LINK
*@WAITS.CCL
(the only difference in this CCL file is the addition of SYS:DDT as the
first .REL module). LINK blew up in the middle of the load with "Ill mem
ref at user 443612". I'm getting kinda tired of those, you know?
So then I decided to try LOADER. I put together a different command
file and did:
.LOAD @WAITS.LDR
which succeeded, but only after I removed the "%500000<" switch which
LOADER is supposed to grok but which the LOAD command choked on. Then,
when I tried running the resulting NCC.DMP, I got "PC exceeds mem bounds
at user 564103". That is a perfectly good address, well within the
bounds of the high segment code.
What is going on here? Is WAITS full of illegally obtained memory?
Anyway, I'm stuck.
-------
8-Jun-89 05:24:45-PDT,863;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 05:24:36 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA25874; Thu, 8 Jun 89 08:25:04 EDT
Date: 08 Jun 89 08:18:51 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Core (lack thereof)
Message-Id: <"CSI 5580-836"@CompuServe.COM>
Ken -- Sorry about the core restriction on project 525. I thought I
had no quota. At one time I know I didn't. I'll request it be bumped.
The accounts in project 311 have no such restriction.
Re your questions as to why enforce core restrictions at all. We don't
want customers to see system performance degrade due to somebody using
too much core. Also, I might note, we swap entire jobs and not pages
with reduces the overhead associated with this.
8-Jun-89 05:49:28-PDT,1187;001000000001
Mail-From: KLH created at 8-Jun-89 05:49:22
Date: Thu, 8 Jun 89 05:49:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Core (lack thereof)
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-836"@CompuServe.COM>
Message-ID: <12500476698.26.KLH@SRI-NIC.ARPA>
Thanks, let me know when it's ready.
Re your questions as to why enforce core restrictions at all. We don't
want customers to see system performance degrade due to somebody using
too much core. Also, I might note, we swap entire jobs and not pages
with reduces the overhead associated with this.
I thought that might be the ostensible reason. I would still maintain that
it's fallacious from a hardware viewpoint, although the software may simply
make it impossible to fix easily. For example, user quotas could
merely refer to the # of physical pages, while always permitting the maximum
virtual address space; small users would always get good response, whereas that
of large users will vary with the size of their permitted quota, without
impacting anyone else. Too late now to be practical, let's file this
under religious discussion.
-------
8-Jun-89 05:55:33-PDT,582;001000000001
Mail-From: KLH created at 8-Jun-89 05:55:26
Date: Thu, 8 Jun 89 05:55:26 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Automated
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5579-18884"@CompuServe.COM>
Message-ID: <12500477802.26.KLH@SRI-NIC.ARPA>
Based on DECODE.DOC it looks like COM files will be quite sufficient
to accomplish the KCC building; the notions are very similar to MIC.
Thanks for the pointer.
Out of curiousity, when you say MAKE, are you talking about something
akin to Unix "make"? Or something else?
-------
8-Jun-89 06:10:21-PDT,1186;001000000001
Mail-From: KLH created at 8-Jun-89 06:10:14
Date: Thu, 8 Jun 89 06:10:13 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: More slightly lost questions
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-836"@CompuServe.COM>
Message-ID: <12500480494.26.KLH@SRI-NIC.ARPA>
Oh, about the project 311 UFDs you mentioned. I assume you are waiting
for the project to officially start before giving me access, right?
Once that is done, my question is whether you have some way to
"connect" to a UFD other than that of your login PPN, so that DSK:
refers to this "connected directory". I didn't see any likely looking
command to do this; does that mean you have to accomplish it by
actually redefining DSK: to be a particular UFD?
While I'm at it, is there a way to have a bunch of commands executed when
you log in? On TOPS-20 this is done with a LOGIN.CMD file; on Unix with
variously named files (eg .login), and random programs have *.INI files.
A DEFINE command shows me that C: is defined to be something for my job,
but I don't know where that's being set.
Thanks for the SET WATCH tip -- good stuff (like T20 SET TRAP).
-------
8-Jun-89 08:07:18-PDT,584;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 08:07:03 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA29651; Thu, 8 Jun 89 11:07:25 EDT
Date: 08 Jun 89 10:10:09 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: ICS manual
Message-Id: <"CSI 5580-1903"@CompuServe.COM>
Ken -- An ICS (Integrated Command System) manual should be sent to you
this week. This should go some way towards explaining some of the more
oft-used commands for our operating system.
8-Jun-89 08:07:47-PDT,1100;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 08:07:37 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA29739; Thu, 8 Jun 89 11:08:21 EDT
Date: 08 Jun 89 10:25:59 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Stuff
Message-Id: <"CSI 5580-2048"@CompuServe.COM>
Our MAKE is indeed akin to the UNIX "make". Functionally. Once you get
in project 311, look around for *.MAK for sample make files. MAKE does offer
some advantages, but COM files will do nicely as well.
I use the DEFINE command to "connect" to other UFDs. But I'm not sure
you can redefine DSK:. Normally, I define another UFD to be called PROD:
(for production). I then work locally and refer to PROD:foo.for for
referencing a production copy of foo.for.
When you log in, the system will attempt to execute file LOGIN.COM.
In 311, you will probably get some additional definitions as a project-
wide LOGIN.COM executes too.
By the way, a sample defining is
DEFINE PROD: AS [311,1000]
8-Jun-89 08:50:21-PDT,1265;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 08:50:16 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA00497; Thu, 8 Jun 89 11:39:59 EDT
Date: 08 Jun 89 10:59:09 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Time & EXEs
Message-Id: <"CSI 5580-2366"@CompuServe.COM>
SSAVE creates .sav or .shr files. NSAVE and NSSAVE create .exe files,
the difference being that your "high segment" is marked sharable if you
do NSSAVE, not so for NSAVE.
There's no way to get the creation or access time of a file in any but
the standard DEC LOOKUP block format. The best you can do is convert
that to a local-time MJD.f (e.g., with DECUN$) and then do a TZONE$ call
to calculate the (current) offset from UTC to local and add it in.
The GTEFS$ call returns the written and allocated lengths of an open
file so you can find their current values. It could be extended to
return two more words, the UTC creation and access times (I don't want
to return the .RBTIM word because it's not kept in core and I don't want
GTEFS$ to touch the disk), if you want to submit a PPS.
GSB for BEN 10:56 EDT 08-Jun-89 Message 5580-2344 forwarded by
8-Jun-89 12:49:13-PDT,598;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 12:01:53 PDT
Message-ID: <mkpTy@SAIL.Stanford.EDU>
Date: 08 Jun 89 1201 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: Help!
To: KLH@SRI-NIC.ARPA
Well, the instruction at the starting address of WCC.DMP is SUB 11,4
followed by MOVEM 11,-2(17). All in all a bad way to start. Probably
something is wrong with the loading. Are you trying to start the
upper segment somewhere besides 400000? If so, I think you'll fail.
I'll look at things more later.
8-Jun-89 12:57:10-PDT,462;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 12:19:02 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA04575; Thu, 8 Jun 89 15:19:40 EDT
Date: 08 Jun 89 14:55:28 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: No core no more
Message-Id: <"CSI 5580-4367"@CompuServe.COM>
Ken -- I'm told that [525,5] now has no core quota. Good luck!
8-Jun-89 13:32:04-PDT,529;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu ([128.146.8.98]) by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 13:08:04 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA05093; Thu, 8 Jun 89 15:51:50 EDT
Date: 08 Jun 89 15:13:49 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: COM file manual
Message-Id: <"CSI 5580-4560"@CompuServe.COM>
Ken --- Another document that describes other features of COM files
is HLP:COMFIL.MAN. I'm told it's 125 pages.
8-Jun-89 14:59:22-PDT,677;001000000001
Mail-From: KLH created at 8-Jun-89 14:57:53
Date: Thu, 8 Jun 89 14:57:52 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: Help!
To: ME@sail.stanford.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <mkpTy@SAIL.Stanford.EDU>
Message-ID: <12500576551.26.KLH@SRI-NIC.ARPA>
Yes, the T10/WTS version wants to start the high seg at 500000, in order to
leave enough room for dynamic allocation between the lowseg and hiseg. Nothing
in the documentation says this is unreasonable -- lower than 400000, yes, but
not higher.
NCC.DMP was generated with a hiseg starting at 400000, so that particular
factor is removed. Hope you can find out what's going on.
-------
8-Jun-89 16:15:15-PDT,889;001000000001
Mail-From: KLH created at 8-Jun-89 16:15:10
Date: Thu, 8 Jun 89 16:15:10 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: big core big win
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-4367"@CompuServe.COM>
Message-ID: <12500590623.26.KLH@SRI-NIC.ARPA>
I just tried out KCC now that the core quota is lifted.
Works fine! Compiled, assembled, and linked toy programs. I was
mostly worried about KCC's interaction with MACRO and LINK, but there
appear to be no problems. So the bootstrap is now in place and in
theory we only need to transfer source files from here on. Amazing
what can be done with a serial line and a lot of patience.
I would like to say that you can try it now, but it's probably best to
wait until the [311,] directories open up and I can install the various
header files that real programs will need.
-------
8-Jun-89 16:43:24-PDT,1976;001000000005
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 16:43:14 PDT
Message-ID: <iktwk@SAIL.Stanford.EDU>
Date: 08 Jun 89 1642 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: Help!
To: KLH@SRI-NIC.ARPA
So then I decided to try LOADER. I put together a different command
file and did:
.LOAD @WAITS.LDR
which succeeded, but only after I removed the "%500000<" switch which
LOADER is supposed to grok but which the LOAD command choked on. Then,
when I tried running the resulting NCC.DMP, I got "PC exceeds mem bounds
at user 564103". That is a perfectly good address, well within the
bounds of the high segment code.
OK, I know what caused this problem. It's a WAITS bug in handling of
two-segment .DMP files, which I discovered but didn't fix about 6 years
ago. This is only the second known complaint from this bug, although
the bug is completely repeatable in a given instance.
Anyway, when the system generates the upper segment, it truncates it to
end where the .DMP file ends, except for extending that to the next
1K boundary. However, the upper segment happens not to have been on
a page boundary initially, so it had to be shuffled up some number of
words to align it. Unfortunately, the high part fell off the end of
core (I'm not sure why the system doesn't detect this -- it probably
just prevents the error by limiting the BLT). So indeed 564103 exceeded
mem bounds, which ended at 563777.
A quick fix for any .DMP file is to add a page (or two?) of data to the
end of the file, to make sure the BLT up doesn't lose any data.
I've done that and generated NCC2.DMP[1,KLH], which now runs but gets
three of these: "internal runtime error: iobfre() - bad arg", followed
by an ill mem ref. (MAYBE I'll fix the bug, but don't count on it.)
I haven't looked into the problem of LINK dying when you load DDT.
8-Jun-89 16:46:46-PDT,2132;001000000001
Mail-From: KLH created at 8-Jun-89 16:46:40
Date: Thu, 8 Jun 89 16:46:40 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Stuff (mostly "connected directory")
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-2048"@CompuServe.COM>
Message-ID: <12500596358.26.KLH@SRI-NIC.ARPA>
... but COM files will do nicely as well.
OK. Anything I set up will probably use COM, to save time.
I use the DEFINE command to "connect" to other UFDs. But I'm not sure
you can redefine DSK:.
Well, this is an important point, since KCC always leaves all output
on DSK: regardless of the location of the source, and the build files
are set up to take advantage of this. I could have left the files on
the source directory, but I thought it best to do what the Unix
compiler does -- certainly makes it easier to generate diverse
binaries from a central set of sources.
I found experimentally that it is possible to redefine DSK:, but unfortunately
it does not behave as expected. For example, doing
DEFINE DSK: as DSK:[300,2]
will not make anything different. Doing
DEFINE DSK: as DDH:[300,2]
does vector all name.ext filename references to [300,2], but attempting to
specify a filename like name.ext[525,5] will fail -- it still looks in
[300,2]. The only way to refer to a different directory is by giving a
non-DSK device name in addition to the PPN. This isn't good.
What is really needed is a way of specifying the "default" PPN,
the one that is used when none is furnished. Is there a way? The PATH.
UUO can do this, I think, but what is the user-level monitor command to
use?
If all else fails, I CAN add another switch to KCC to specify the path
for output files, but I'm hoping this won't be necessary.
When you log in, the system will attempt to execute file LOGIN.COM.
In 311, you will probably get some additional definitions as a project-
wide LOGIN.COM executes too.
Yeah, I already get a bunch of those; does that mean I'm getting your
project-wide LOGIN.COM for 525? I had to chuckle about TYEP; I'm partial
to TY myself.
-------
8-Jun-89 17:04:13-PDT,964;001000000011
Return-Path: <ME@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 17:04:08 PDT
Message-ID: <Mku00@SAIL.Stanford.EDU>
Date: 08 Jun 89 1704 PDT
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: re: Help!
To: KLH@SRI-NIC.ARPA
Another fix for the short .DMP file is this, assuming the file is NCC.DMP.
GET NCC
it says "Job setup in 124+116 pages"
add 124 and 116, getting 240. add 2 for the fix, getting 242
GET NCC 242
it says "Job setup in 240+118 pages".
actually, 240 might win itself, just see if the upper size changes.
aha, the upper is two pages bigger, unfortunately, the
lower is also bigger, so we fix that
C 124
to reduce lower size to initial value>
SSAVE NCC.2
save new program and upper segment -- note "SSAVE" has two S's
Actually, you might simply want to add 1 page of unused core to the end of
the upper to avoid the problem and these kludges entirely.
8-Jun-89 17:23:42-PDT,1780;001000000001
Mail-From: KLH created at 8-Jun-89 17:23:36
Date: Thu, 8 Jun 89 17:23:36 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: re: Help!
To: ME@sail.stanford.edu
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <Mku00@SAIL.Stanford.EDU>
Message-ID: <12500603080.26.KLH@SRI-NIC.ARPA>
Actually, you might simply want to add 1 page of unused core to the end of
the upper to avoid the problem and these kludges entirely.
How do I do this? The last things loaded are the library routines,
and due to interdependencies each module includes a .REQUIRE of the library
(CWTS:LIBC.REL in the cross-compiled rels), so I'm not sure I can
guarantee that following the libc/library spec with a dummy 1-page module
will make it the last thing loaded.
Is this something that will affect all C programs KCC builds? (the
CCL files are merely copies of what KCC would generate if building
itself). From your description, I don't understand why the bug doesn't
afflict more software on WAITS.
The internal runtime error from _iobfre() sounds like something is
being messed up with the I/O data structures, but I can't say what it
might be offhand -- it happened three times because it attempts to close
three file descriptors on exit (0, 1, and 2).
In the meantime, I've successfully brought up KCC on a real TOPS-10
as well as the T20 PA1050 simulator, so the problem must have something
to do with either the way the WAITS linker puts it together, or with the
WAITS-specific code in KCC. Because the WAITS C runtime is already known to
work with small test programs (including reading and writing files), that
makes me suspicious of the linker, but I don't know quite where to start.
Getting a NCC put together with DDT would help, I guess. Ideas?
-------
8-Jun-89 20:36:47-PDT,724;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 20:36:31 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA12850; Thu, 8 Jun 89 23:37:14 EDT
Date: 08 Jun 89 23:01:10 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Let's go for it!
Message-Id: <"CSI 5580-6396"@CompuServe.COM>
Well, I'm certainly excited! Go ahead and try project XXX.
The password is the name of your compiler and you should be
able to get into programmers 4700 through 4717 with it.
Methinks I managed to forget some of your questions regarding
interactions/chainings with LINK, MACRO et al. Sorry.
Let me know if problems.
9-Jun-89 05:02:24-PDT,4007;001000000001
Mail-From: KLH created at 9-Jun-89 05:01:49
Date: Fri, 9 Jun 89 05:01:48 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Let's go for it!
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-6396"@CompuServe.COM>
Message-ID: <12500730185.26.KLH@SRI-NIC.ARPA>
I tried logging into the new dirs. Unfortunately, they have nothing
in common with [525,5] from the viewpoint of file access permissions.
A brief conversation with the operator confirmed that there was no
way to access files if the protections prohibited it, even if you
knew the password. I guess this shows how much I don't know about
TOPS-10.
I reset the UFD for 525,5 to be <775> and all files therein to be
(2), so I could copy them over; there isn't anything private there.
However, on reflection, I think it would be best if I checked with
you prior to going ahead. The rest of this message describes what
I have in mind, and includes a bunch of questions.
------------------
Suggested directory layout: (* indicates possible system-wide logical name)
Prog# Lognam Distribution-name
4700 * C: none -- CSI installed version (mostly copy of CINC:)
4701 * CSYS: none -- " " " (mostly copy of CINCS:)
4702 CDIST: PORT Overall top-level distribution directory
4703 CCSI: CSI CSI-specific binaries
4704 CT10: T10 T10-specific binaries
4705 CINC: INCLUDE <*.h> files
4706 CINCS: SYS <sys/*.h> files
4707 CKCC: KCC Compiler source
4710 CLIB: LIB Library source top-level dir
4711 CGEN: GEN General utilities
4712 CMATH: MATH Math routines
4713 CSTDIO: STDIO Standard I/O
4714 CTEST: TEST Library test programs
4715 CUSER: USER User libraries (eg TERMCAP)
4716 CUSYS: USYS Un*x emulation routines
4717 (unused - spare)
All directories to have protection <770> or <775> (either OK with me),
all files to have <007> or <005>. The main thing is to have full access
to everything there without having to continually log in to each one
separately.
4700 and 4701 will serve as C: and CSYS: for the "installed" compiler,
used by people not directly involved with KCC development or testing.
These will be independent of whatever work is being done on the other
dirs. Actually, other PPNs could be used; up to you. Those logical
names can be defined system-wide; all of the others are intended to
be defined only when needed, by a LOGIN.COM (or whatever) file in CDIST:.
For purposes of generating the binaries, one of the following methods
will have to be used:
(A) login to CCSI: or CT10: and run the COM files from there.
(B) login to CDIST: and somehow convince the monitor that
files with no device/PPN spec should be written to
a particular PPN (namely CCSI: or CT10: or whatever)
(C) Add a KCC switch to specify a path for all output files.
Method B is what is used on TOPS-20 and UNIX, by connecting to the
desired directory. If you can find a way to do this, that would
clearly be preferable. Otherwise, we'll have to use (A) until I can
get around to (C).
You will note that I have set things up to use C: and CSYS: rather
than trying to squish both into a single directory. We can still
explore that later if necessary, but for now it is simplest to just
duplicate the organization that currently exists.
Various questions:
Can we get method B to work? Is there a method D I haven't considered?
Do you want me to change the password? I didn't, because I thought these
dirs might be used primarily by other CSI people.
Would you prefer that KCC use logical names other than C: and CSYS:, or
be invoked as "KCC" instead of "CC", to avoid any conflicts or confusion
with the large quantity of existing C stuff you have? (I peeked around
a little.) Whatever you want to use is ok with me.
I have one other major procedural question which is independent of the
above; I'll send it in a separate message so as to get this one off
now.
--Ken
-------
9-Jun-89 05:25:12-PDT,1187;001000000001
Mail-From: KLH created at 9-Jun-89 05:25:09
Date: Fri, 9 Jun 89 05:25:09 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Delivery method?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-6396"@CompuServe.COM>
Message-ID: <12500734435.26.KLH@SRI-NIC.ARPA>
After the success of getting the bootstrap running just with KERMIT (I
was able to copy all the KCC binaries (using wild-card SEND) with only
one restart), it occurs to me that it's theoretically possible to
import the rest of the distribution by that method, and save the tape
for later.
A quick scan of the sources indicates that it would take about 700
minutes worth of kermitting, i.e. about 11+ hours total, not counting
possible service interruptions. It can probably be done over the weekend.
Do you think it's worth trying this? Would this be considered
satisfactory delivery per the contract? I can, of course, still
generate a tape and mail it as originally planned; the two are about
evenly matched in terms of my time (unless my connection goes
haywire!), but the kermit method might be much less work for you.
Let me know what you think.
--Ken
-------
9-Jun-89 07:26:30-PDT,467;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 9 Jun 89 07:26:19 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA23461; Fri, 9 Jun 89 10:27:00 EDT
Date: 09 Jun 89 09:55:59 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Kermit
Message-Id: <"CSI 5580-7877"@CompuServe.COM>
Ken -- Go ahead with Kermit if that seems to work well. Sounds good to
me!
9-Jun-89 07:27:43-PDT,1359;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 9 Jun 89 07:27:37 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA23622; Fri, 9 Jun 89 10:28:27 EDT
Date: 09 Jun 89 10:16:12 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Directories etc.
Message-Id: <"CSI 5580-8076"@CompuServe.COM>
Ken -- You mentioned that 4700 and 4701 would serve as C: and CSYS:
for the "installed" compiler, used by people not directly
involved with KCC development or testing.
We want to use project 311 only for maintenance and development.
Any changes or bug fixes will be applied to the sources in
project 311 and the binaries rebuilt. Once the binaries are
rebuilt, they will be 'installed' by software administration
people into public system areas. Few people can get at anything
in project 311.
So, except for the business about system-wide names, your
directory layout is fine by me.
Random answers:
Not necessary to change the password at this time.
Can we have the compiler invoked by "KCC" for now, and
perhaps change it to "CC" later? Since we can define
logical names, this probably has to do with the rescanning
of the command line, huh?
More about directories and rebuilding in a followup message...
9-Jun-89 08:03:58-PDT,2235;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 9 Jun 89 07:58:58 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA24244; Fri, 9 Jun 89 10:59:29 EDT
Date: 09 Jun 89 10:48:31 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Ramblings
Message-Id: <"CSI 5580-8307"@CompuServe.COM>
Ken -- Insofar as people outside of project 311 cannot write to any
of 311's UFDs, your suggested protections are fine.
When I first read you message, I felt that perhaps you were
suggesting that the production compiler be used by the general
masses out of project 311. This is unacceptable; production
software is run out of some programmer in project 1. But in
rereading your message, I'm not sure this was what you were
suggesting.
Sargasso C lives on level 5 right now. It will probably die
there. Level 5 is [1,45]. (Project 311 is on structure MBX:
on system DHH. System DHH has multiple structures, the primary
structure being DDH:. So, to see what's in level 5, you would
have to say CAT DDH:[1,45] or, more simply CAT LV5:. End of
tangent.) There may be some people using Sargasso C. I would
like for the first release of KCC to go up on level 4. (Not
much else is out there, and it won't conflict with Sargasso C.)
Level 4 is [1,44].
For a public release of KCC, is C: and CSYS: all that you would
feel is required? And if our monitor doesn't provide these names
automatically, the DEFINE command will suit our purposes, right?
You only bring up the issue of UFD protections to facilitate
rebuilding the binaries, right?
As far as I can tell, your Method A is the only method available
today unless whatever is run from CDIST: can be editted to
build either CSI- or T10- specific versions. We've done similar
things with our compilers (KI- or KL-specific). Snoop around
looking for RTSLIB.COM, maybe BUILD.COM. I don't know if this
is relevant.
Looking back, I think maybe I've misunderstood your last message.
There's a good chance that a lot of the above discourse in unnecessary.
Sorry. Have I confused any issues or created any problems?
9-Jun-89 16:40:37-PDT,2413;001000000001
Mail-From: KLH created at 9-Jun-89 16:40:33
Date: Fri, 9 Jun 89 16:40:33 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Ramblings
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5580-8307"@CompuServe.COM>
Message-ID: <12500857387.23.KLH@SRI-NIC.ARPA>
When I first read you message, I felt that perhaps you were
suggesting that the production compiler be used by the general
masses out of project 311. This is unacceptable; production
software is run out of some programmer in project 1. But in
rereading your message, I'm not sure this was what you were
suggesting.
Well, not really. The purpose of having 4700 and 4701 be independent
of the others is to keep a stable implementation around which can be
used even when the sources and test binaries are being changed and
trashed. They can be made publicly readable even while the others are
kept private, so KCC can be used from any other UFD. As to who might
use them, that's really up to your discretion. I wasn't sure what you
had in mind, so was trying to set up a configuration that would let
you permit other programmers, or even users, to try KCC if you wanted;
your reading of my ambiguity here was correct. Keeping it separate
from the general masses is fine; you can install copies of 4700+1
whenever and whereever you please.
For a public release of KCC, is C: and CSYS: all that you would
feel is required? And if our monitor doesn't provide these names
automatically, the DEFINE command will suit our purposes, right?
Yes, right. Other logical names can certainly be substituted for
those, if you wish. It's fairly easy to change the configuration
parameters.
You only bring up the issue of UFD protections to facilitate
rebuilding the binaries, right?
Right. It doesn't matter who else has access, as long as whoever works
on KCC has complete access.
As far as I can tell, your Method A is the only method available
today unless whatever is run from CDIST: can be editted to
build either CSI- or T10- specific versions.
Not unless I implement method C. It looks like I'll have to do that
eventually. Meanwhile could you verify whether the PATH. UUO is
supported or not?
Anyway, you've given me what I needed to know, so I'll attempt to go
ahead and set up a source transfer this weekend. Will keep you posted!
--Ken
-------
11-Jun-89 08:46:06-PDT,1357;001000000001
Mail-From: KLH created at 11-Jun-89 08:46:04
Date: Sun, 11 Jun 89 08:46:04 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Status -- need help ASAP
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12501295297.23.KLH@SRI-NIC.ARPA>
I've run into something that I'll need you to resolve before I can go
any farther. Can you find out exactly what the DEC DEVTYP UUO returns
on your system???
The C runtimes are being confused because what DEVTYP returns is not what
they expect. In particular, when I specified an arg of SIXBIT /DSK/,
the DEVTYP UUO returned <43,,3> which leads the runtime to think it is
dealing with a terminal (symbol .TYTTY == 3). The "directory device" flag
in TY.MAN (sign bit) is also off. What's going on??? This code works
correctly under PA1050, which is a very very basic TOPS-10 emulator.
If it is the case that CSI has munged this UUO (why, for godsake), then
you need to tell me a way to determine whether a device is disk or not, and
this method has to work on BOTH a vanilla TOPS-10 and CSI.
All of the KCC sources have been transferred, and I have set up all of
the protections and .COM files which are needed to build both the compiler
and library. But I cannot build them until this problem is resolved;
KCC will not work on anything but toy programs.
--Ken
-------
12-Jun-89 05:09:09-PDT,496;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 05:09:02 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA01355; Mon, 12 Jun 89 08:08:56 EDT
Date: 11 Jun 89 21:58:10 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: I'm looking into it
Message-Id: <"CSI 5583-763"@CompuServe.COM>
Ken -- I'll let you know about DEVTYP first thing tomorrow morning
Eastern time.
-- Benny
12-Jun-89 05:10:03-PDT,1334;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 05:09:59 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA01444; Mon, 12 Jun 89 08:09:52 EDT
Date: 12 Jun 89 07:37:34 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: DEVTYP
Message-Id: <"CSI 5583-1148"@CompuServe.COM>
Ken -- I'm not sure this is going to be what you want to hear.
Please advise as to how serious it is. Thanks.
----------------------------------------------------------------------
Forwarded Message 5583-1102
Reply to: DEVTYP question
Right, CS DEVTYP is essentially useless. Bits 12, 14, and 16-17 more-
or-less work and the others are garbage.
The most compatible alternative is DEVCHR, which is most compatible with
DEC. Differences exist in
bit DEC CS
--- --------------------- -----------------
5 terminal in use N/A
6 bidirectional plotter
7 "display" spooled device
8 "long dispatch table" N/A
9 paper tape punch network device
10 paper tape reader paper tape device
Bit 1 set to 1 (DV.DSK) indicates a disk under both CS and DEC.
GSB for BEN 07:21 EDT 12-Jun-89 Message 5583-1102 forwarded by
12-Jun-89 08:23:44-PDT,769;001000000001
Mail-From: KLH created at 12-Jun-89 08:23:43
Date: Mon, 12 Jun 89 08:23:43 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: ring ring ring
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12501553373.23.KLH@SRI-NIC.ARPA>
Is "system DHH" being cycled deliberately, or is there really a
problem? What should I do, in general, to find out when it is
expected to be back up? Is there anything that can be done in
response to the "Host Name:" or "User ID:" prompt which will do
something other than tell me the system is temporarily unavailable?
I have several things ready to transfer over and install which I
expect will cure the EXE and DEVTYP problems, but for a while now I
haven't been able to get in. Fidget, fidget...
-------
12-Jun-89 09:21:43-PDT,1514;001000000001
Mail-From: KLH created at 12-Jun-89 09:21:33
Date: Mon, 12 Jun 89 09:21:32 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Not about KCC
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12501563899.23.KLH@SRI-NIC.ARPA>
I was wondering how many SC-30's you have, how well they hold up, and what
CompuServe's plans are for them -- get more? Replace? Upgrade?
The reason I'm curious is because eventually we'll need to replace our own
DEC-2065 and although we know the SC-30 is a possibility, we also will
have a tough battle trying to convince our client (Defense Communications
Agency) that a PDP-10 lookalike makes sense; they are very gun-shy because
they got burned the last time they tried that with a Foonly F3. If you
don't know what Foonly is (or was), I'd describe it as a garage operation
that was eventually taken over by Tymshare, which was taken over by McDonnell
Douglas, which thereupon dumped the projects that were depending on those
machines and thus completely turned off the maintenance spigot.
SC claims that the cost of a SC-30 can be recovered with the savings
on one year of DEC 2065 maintenance. Size and speed look a lot
better. But we don't have any hard data on things like distributed
customer base, MTBF, and the like, which we might be able to wave in
front of people who aren't quite so enamored of the PDP-10. Hence my
interest in your experiences, if there's anything you can relate.
(low priority, no hurry)
--Ken
-------
12-Jun-89 12:06:32-PDT,664;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 11:43:53 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890601)
id AA09632; Mon, 12 Jun 89 14:30:22 EDT
Date: 12 Jun 89 13:50:00 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: DHH availability
Message-Id: <"CSI 5583-4050"@CompuServe.COM>
to: Ken
fr: Benny
DHH is the inhouse system. When a customer system goes down
or becomes unavailable for any reason, the inhouse system is
taken to replace it. I know it's inconvenient, but there's
not much that can be done about it. We fidget too.
12-Jun-89 12:19:57-PDT,2146;001000000001
Mail-From: KLH created at 12-Jun-89 12:01:26
Date: Mon, 12 Jun 89 12:01:26 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Success!!!!
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12501593007.23.KLH@SRI-NIC.ARPA>
I have completely regenerated KCC and LIBC from the sources, and installed
the implementation in C: and CSYS: ready for use.
A few more (necessary) details:
I suggest you do a @[311,4702]DEFDIR prior to poking around. This sets
up all the logical names as well as defining the command variable "KCC".
After this, you can use KCC (from any dir) just by saying something like
"kcc hello.c". Of course, you'll have to be in proj 311 since the access
will trip you otherwise. If want to change the default file protection
of 4700 and 4701 to be something publicly readable, that's fine with me;
just keep the first two octets 00.
I am still tweaking the regeneration mechanism, so I don't advise trying
to use it without checking with me first. To see how it works, look at
CPORT:DEFDIR.COM
CT10:DEFXCC.COM
CT10:NCC.COM
CLIB:LIBC.COM
That's all there is! It's really quite simple once KCC itself is working.
I updated C:LIBC.DOC and C:USYS.DOC to some extent, to show what is
implemented and what isn't. It is a bit cryptic, though. Remember
that this instance of KCC is a bootstrap "vanilla TOPS-10" version, as
I promised, and has no CSI-specific code whatsoever; for that reason,
things like time zones will be wrong. The biggest deficiency, in my
opinion, is that I/O is limited to plain reading or writing; not both,
and no seeking. This is sufficient for the compiler to work, but not
for some fancier programs like ELLE (which is why it isn't there yet).
One more hint for when you try running your own C programs. The command
line parser doesn't know about "irun" (TOPS-10, remember), so it works
best to use either of these methods:
(1) Define a cmd var such as "foo :== \irun foo;" and invoke as "foo arg1 arg2"
(2) First do "iget foo" and then "start; arg1 arg2"
Enjoy. Let me know if any problems, questions, etc.
--Ken
-------
12-Jun-89 12:31:12-PDT,395;001000000001
Mail-From: KLH created at 12-Jun-89 12:21:28
Date: Mon, 12 Jun 89 12:21:28 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: DHH availability
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5583-4050"@CompuServe.COM>
Message-ID: <12501596654.23.KLH@SRI-NIC.ARPA>
Ahhhh... that explains a lot. Thanks. You must have an interesting
configuration.
-------
12-Jun-89 13:05:26-PDT,655;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 13:04:07 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA11615; Mon, 12 Jun 89 16:03:37 EDT
Date: 12 Jun 89 15:44:35 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Waiting for system to come back up
Message-Id: <"CSI 5583-4971"@CompuServe.COM>
to: Ken
fr: Benny
I failed to mention that DHH, besides being the inhouse
system, gets the 1st release of monitor changes. The
unavailability of DHH seems more due to its crashing
than being appropriated for customer use.
12-Jun-89 16:54:57-PDT,1306;001000000001
Mail-From: KLH created at 12-Jun-89 16:54:54
Date: Mon, 12 Jun 89 16:54:54 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Contract stuff
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12501646432.23.KLH@SRI-NIC.ARPA>
It occurred to me I had better check on this. Did you receive the signed
copies I mailed back last week? It would be pretty funny if the paperwork
wasn't done until after the first milestone!
Speaking of which, I think it's essentially complete. I will put a
few more hours into setting up CSI-specific binaries in CCSI:, but the
differences are extremely minor and this is more to verify that the
build procedures will work than to provide any extra functionality.
When I'm done with that, I'll let you know and then leave it all alone
for you to do "acceptance testing".
It's tempting to put more time now into enhancing the OS-dependent
parts of the implementation, and I'm certainly willing to make minor
additions on the spot if you consider them essential, but the fact is
it now can (and did) recompile itself on your system -- and I should
be moving on to the ANSI upgrade stuff. As you probably noticed, I
spent a lot more time struggling with the system than I expected to.
(At least it was educational!)
--Ken
-------
12-Jun-89 19:39:03-PDT,1200;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 19:38:58 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA20091; Mon, 12 Jun 89 22:38:54 EDT
Date: 12 Jun 89 22:27:13 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC
Message-Id: <"CSI 5583-6664"@CompuServe.COM>
to: Ken
fr: Benny
Yes, the signed contracts arrived this morning. I'll return
one of them to you tomorrow (signed).
I felt like it took longer than you anticipated too, due
primarily to idiosyncracies with our OS. I felt bad about
that and hope it wasn't too frustrating. We (corporate 'we')
really appreciate your efforts, and I think I speak for some
who have not even seen the work, when I say we are quite
pleased with the progress thus far.
I don't anticipate any problems with acceptance testing. I
might need some hand-holding when it comes to getting up on
the system, but that's a few days off.
We are looking forward to the ANSI upgrade. I hope that turns
out to be EASIER than you anticipate.
We'll play with the compiler some more tomorrow. Thanks again.
13-Jun-89 18:09:23-PDT,1459;001000000001
Mail-From: KLH created at 13-Jun-89 18:09:18
Date: Tue, 13 Jun 89 18:09:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC status
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12501922118.23.KLH@SRI-NIC.ARPA>
I've built a CSI-specific version of KCC and the library, and
installed it so the "C:" in [311,4700] is now that version.
The main difference is that SYS_CSI is defined as 1 by <c-env.h>, so
conditionals that check this will work; for example, CSIUUO is now
defined by <muuo.h>. TRUSZ$ is executed at startup, and the time
routines are somewhat more likely to be correct (but because the CSI
calls are not used everywhere, there are still possible holes). The
command line scanner should ignore "IRUN" and "IRU".
I'm going to try not to do any more hacking on this for a while, although
I keep thinking of new things to fix.
I've put a BUILD.DOC file in [311,4702] which explains what to do in order
to rebuild KCC or LIBC, although it doesn't attempt to explain the why.
You can start from this file to find all of the other files involved.
Let me know if any questions or problems pop up. Good luck!
--Ken
p.s. CTEST: contains a number of test programs, of extremely variable
quality. One that I find very handy just for finding out what a C
program is seeing on the command line is TECHO. Run it in whatever
guise, and it will tell you what the argv array looks like.
-------
14-Jun-89 11:20:28-PDT,1253;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 14 Jun 89 11:20:18 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA02782; Wed, 14 Jun 89 14:20:14 EDT
Date: 14 Jun 89 13:07:05 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC rebuilding
Message-Id: <"CSI 5584-9068"@CompuServe.COM>
Ken -- I'm trying to rebuild the compiler prior to installing it
publicly on our systems. I'm having no serious problems. I'm
also working my way through all the documentation.
Two things. I see that KCC knows about a processor called the PDP-11.
CompuServe knows that machine well also. Would you care to say anything
about what would be involved in making a PDP-11 cross-compiler out of
KCC? It would be hosted on the 10 naturally.
Also, our independent processing facility, ICON, used for processing
batch commands on a PTY believes errors should begin with a CR-LF sequence,
followed by a '?', followed by a SPACE. I see that KCC differs a bit from
this notion. As a result, errors in a compilation will not cause a job
to abort or to trap to error-handling code.
Other than that, I feel things are going well.
-- Benny
14-Jun-89 14:45:06-PDT,3502;001000000001
Mail-From: KLH created at 14-Jun-89 14:42:50
Date: Wed, 14 Jun 89 14:42:48 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC rebuilding
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5584-9068"@CompuServe.COM>
Message-ID: <12502146673.23.KLH@SRI-NIC.ARPA>
Two things. I see that KCC knows about a processor called the PDP-11.
CompuServe knows that machine well also. Would you care to say anything
about what would be involved in making a PDP-11 cross-compiler out of
KCC? It would be hosted on the 10 naturally.
The CPU_PDP11, CPU_VAX, and CPU_M68 conditional flags exist only so
that software which is somewhat machine-dependent can be readily
ported across different systems by including <c-env.h>. While in
principle KCC can do cross-compiling, I'm not sure that would be the
best way to go to get a PDP-11 compiler.
I find it hard to believe, given the fact that C/Unix first attained
its popularity on 11s, that there isn't someone out there who already
has or sells a C compiler that would be suitable. If for some reason
that was impossible and a cross-compiler was the only way to go, then
I would probably attempt to start with GNU CC since its orientation to
8-bit byte-addressable machines won't be a problem, and an 11 needs as
much optimization as one can get. I wonder if anyone has already done
this. It would be easy to ask FSF if they know.
To be brutal about it, there's also the question of how long you
really want to support a PDP-11. 68000-based systems, for example,
are getting much cheaper, and they're much smaller and faster. We
used to have a bunch of 11s around which I did much happy hacking on,
but they're all gathering dust somewhere else now; the upkeep was too
expensive for what they could do. I suppose a really high-end 11/70
or 11/44 could last a little longer yet.
If the idea is to burn spare PDP-10 cycles, well, there are the usual
two aspects: code generation and library support. Doing a straightforward
hack job on KCC's code generation phase could probably not be very hard
(tedious maybe); but if the target system doesn't already support Unix
style system calls then a fair bit of the library would have to be
re-done, as it was for TOPS-10.
Also, our independent processing facility, ICON, used for processing
batch commands on a PTY believes errors should begin with a CR-LF sequence,
followed by a '?', followed by a SPACE. I see that KCC differs a bit from
this notion. As a result, errors in a compilation will not cause a job
to abort or to trap to error-handling code.
Another idiosyncracy I guess. "\n?" is what TOPS-20 looks for, and I would
imagine TOPS-10 also as so much of the DEC code is common to both. The
COM files were readily aborted by such error messages, by the way.
If you are talking about the specific error messages KCC generates during
processing, rather than the summary message saying how many errors were
seen, then I'd have to classify this as a feature, since normally you
want to find as many errors as possible on a pass through the code.
It's true that sometimes a single small error can provoke a long stream
of other error messages from a confused compiler, but this is an universal
problem for C compilers.
Since the "\n?" sequence is inserted at only one or two points in KCC, it can
be changed to "\n? " for CSI if that is what you want.
--Ken
-------
14-Jun-89 16:43:05-PDT,2764;001000000001
Mail-From: KLH created at 14-Jun-89 16:39:35
Date: Wed, 14 Jun 89 16:39:35 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Possible library change
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12502167931.23.KLH@SRI-NIC.ARPA>
I'm thinking about a change to the way the C library is loaded, and
would like to know if you have any comments. Again, not urgent, but
eventually this will surface again.
Currently, KCC inserts an assembler pseudo of the form
.REQUIRE "C:LIBC.REL"
into every module it compiles. There were originally two reasons for
this:
(1) To allow commands like COMPILE, LOAD, and EXECUTE to work
without needing to add special knowledge (where LIBC.REL lived) to either
the monitor, EXEC, or LINK. KCC is now capable of invoking LINK all
by itself, as well as determining which modules need to be compiled, and
so is relatively independent of this now. In fact, I no longer recommend
using those commands, except perhaps for COMPILE.
(2) To get around the (archaic) misfeature that LINK only
searches libraries in a single pass. Many modules refer to each other
recursively, and thus in the absence of a library symbol index, more than
one pass through the library is necessary.
What I would like to do is flush the .REQUIRE pseudo completely. This will
remove the last remaining problem with cross-compiling and maintaining
different versions, because the library pathname will no longer be hardwired
into every .REL module and can be changed simply with a switch to the KCC
command that actually loads a program; or LINK can be used completely by
hand with no unpleasant and confusing surprises.
However, the problem is ensuring that the loading process doesn't end
with any symbols still undefined. A simple way to resolve this is to
always include commands to search the library several times, as many as
are needed. The trick is deciding how many. At least two, certainly; but
how to guarantee that three (or more) will never be needed? I have tried
using a library ordering tool (written in Fortran) but it's not really
helpful in dealing with the densely interconnected LIBC.REL. I would also
like to avoid forcing unnecessary re-scans of LIBC, if LINK is stupid enough
to do so even when no undefined symbols remain.
You must have encountered this kind of problem before with other languages
on DEC systems, and I'm wondering if you have anything to say about it.
Of course, the real solution would be to fix MAKLIB and LINK to generate
and use a symbol index within the library (just as present-day Unix "ar"
and "ld" do) so that only one pass is ever necessary. But it seems a bit
late to have much hope of seeing this happen.
--Ken
-------
15-Jun-89 09:35:46-PDT,951;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 15 Jun 89 09:33:35 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA24555; Thu, 15 Jun 89 12:32:53 EDT
Date: 15 Jun 89 12:15:01 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: PDP-11s been velly velly good to us
Message-Id: <"CSI 5585-2915"@CompuServe.COM>
Ken -- Re PDP-11s, they are our bread and butter. We have close
to 1500 PDP-11s across the country. You're calling into one right
now. We trying to move away, probably to a 386-based system.
Our PDP-11 software is in assembly language, so "moving away" is
quite an effort. The question about KCC cross-compiling to PDP-11
code was primarily one of curiosity.
I'd still like you to consider adding a space after the "?" in
KCC error messages, but I'll ponder that a bit more and save that
discussion for later.
Benny
15-Jun-89 17:06:01-PDT,917;001000000001
Mail-From: KLH created at 15-Jun-89 17:05:02
Date: Thu, 15 Jun 89 17:05:02 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: PDP-11s been velly velly good to us
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5585-2915"@CompuServe.COM>
Message-ID: <12502434708.23.KLH@SRI-NIC.ARPA>
Aha, the old "installed base" situation. That sure is a lot of 11s!
I'd still like you to consider adding a space after the "?" in
KCC error messages, but I'll ponder that a bit more and save that
discussion for later.
I don't have any problem with adding a space after the "?" in any
error messages that already start with "?". I thought you might have
been asking that ALL error messages (even those without a "?") have
the "? " sequence added, but fortunately that doesn't seem to be what
you meant.
By the way, the ICS user manual arrived today.
--Ken
-------
16-Jun-89 05:49:04-PDT,638;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 16 Jun 89 05:48:47 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA15468; Fri, 16 Jun 89 08:44:20 EDT
Date: 16 Jun 89 08:22:26 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Can't run KCC everywhere I want to
Message-Id: <"CSI 5586-1506"@CompuServe.COM>
Ken -- What's the minimum core needed to run KCC? And is there anything
that can be done about that? I find that I'm unable to run the compiler
from many accounts that don't have large core quotas. Thanks. Benny
16-Jun-89 12:02:22-PDT,1250;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 16 Jun 89 10:53:27 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA19838; Fri, 16 Jun 89 13:22:32 EDT
Date: 16 Jun 89 12:58:46 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Suggestion for dealing with 6-character limitation on DEC-10s
Message-Id: <"CSI 5586-3581"@CompuServe.COM>
Ken -- The DEC-10 assembler's 6-character global name limitation
ought not to be propagated up to the C language. This would present
problems with previously existing C programs that use longer names.
Given that correctly compiling programs has to come before debugging
them, would it be possible for KCC to generate unique names for all
symbols exported to the assembler and linker, so that it could correctly
compile programs with longer names? Perhaps a debugging option could
direct the compiler to deal with external names as it does now, to
facilitate debugging, or perhaps it could generate unique names only for
those globals whose names exceed 6 characters. This would allow KCC to
compile programs imported from other environments not crippled with
a 6-character name limitation.
16-Jun-89 16:31:50-PDT,3032;001000000001
Mail-From: KLH created at 16-Jun-89 16:31:37
Date: Fri, 16 Jun 89 16:31:36 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Can't run KCC everywhere I want to
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5586-1506"@CompuServe.COM>
Message-ID: <12502690767.18.KLH@SRI-NIC.ARPA>
Ken -- What's the minimum core needed to run KCC? And is there anything
that can be done about that? I find that I'm unable to run the compiler
from many accounts that don't have large core quotas. Thanks. Benny
The absolute minimum is the size of the lowseg, plus hiseg, plus 24 pages of
stack that is initially allocated on startup. Plus many dynamically
allocated pages to hold the symbols, parse trees, etc; if the compilation
of a particular program happens to require more dynamic memory than the
system can provide, KCC stops with a fatal error.
(1) make sure the hiseg is shared (the loader doesn't seem to make this the
default)
(2) Reduce the size of some of KCC's tables. This will reduce the size of
the programs it can compile. KCC itself is a good test case, and the
current limits are set to ensure it can compile itself.
(3) Use an auto-expanding stack for the lowseg, and have dynamically allocated
memory come from new hiseg pages. This reduces the initial size of the
lowseg; however, the space available in the hiseg may then be too cramped.
KCC has trouble compiling itself on TOPS-20 in this configuration; I have to
use the extended-addressing version.
Starting the TOPS-10 hiseg at page 500 gives enough room for
any reasonable program, and is also very simple. However, most of the
24 pages initially allocated for the stack aren't usually needed (they
ARE for compiling KCC, however). I'm not really attracted to the
notion of trapping and handling PDL overflows (i.e. enabling and
setting up interrupts in every C program) but I'm not sure how else
this could be done.
(4) Put more hair into malloc() and sbrk() so that I/O buffers can be
dynamically allocated (instead of static, which wastes a lot of space),
without interfering with malloc(). The static I/O buffers currently
use about 16 pages I think.
(5) Use a compiler that either writes out lots of temporary files to
save impure storage, or uses lots of overlays to save pure storage, or
both. The old PDP-11 compilers and some micro compilers do this, with
with a new distinct program loaded up to process one file into yet
another file several times until all is done. KCC already partly
does this by keeping the assembler and linker phase separated. It
would be possible, but a lot of work, to split out more.
(6) Do whatever is needed to flush tiny core quotas. Yeah! Yeah!
Yeah! If, as you say, KCC is mostly for use by CompuServe developers,
then this may not be much of a problem; at any rate I'm sure they'd
appreciate this particular solution!
I don't know if this helps you any, but that's what comes to mind.
--Ken
-------
16-Jun-89 16:48:47-PDT,2960;001000000001
Mail-From: KLH created at 16-Jun-89 16:48:15
Date: Fri, 16 Jun 89 16:48:14 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Suggestion for dealing with 6-character limitation on DEC-10s
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5586-3581"@CompuServe.COM>
Message-ID: <12502693795.18.KLH@SRI-NIC.ARPA>
Ken -- The DEC-10 assembler's 6-character global name limitation
ought not to be propagated up to the C language. This would present
problems with previously existing C programs that use longer names.
Given that correctly compiling programs has to come before debugging
them, would it be possible for KCC to generate unique names for all
symbols exported to the assembler and linker, so that it could correctly
compile programs with longer names? Perhaps a debugging option could
direct the compiler to deal with external names as it does now, to
facilitate debugging, or perhaps it could generate unique names only for
those globals whose names exceed 6 characters. This would allow KCC to
compile programs imported from other environments not crippled with
a 6-character name limitation.
The dpANS has specifically endorsed the current limitation of 6 monocase
characters on all external identifiers. That is, to be strictly conforming
(ie maximally portable), a program MUST ensure that all its external symbols
are unique in the first 6 monocase characters. Compilers are at liberty
to support extensions to this, but are not required to do so. This point
has come up many times, and no one could get around it. Trying to generate
a "unique" mapping is guaranteed to fail in surprising ways.
The best and most common solution is simply to include a file of macros
which map long names into short unique ones. It's unfortunate that many
people are careless about making their code portable in this regard, but
then there are many other things they are often careless about (like assuming
chars are always signed, or pointers are the same as ints, and so on).
When I port code, I find that adding macros to do name mapping is usually
the simplest part of the whole thing.
There is one problem KCC has with the 6 char limitation which I'm
hoping to fix along the way; internal static functions or variables
are currently also truncated to 6 monocase chars, creating the
possibility of needless conflicts within a module (typically the
conflicts appear during the assembler phase). KCC can and should make
these unique, since nothing outside of the module will use them; the
current state is mainly a concession to DDT. Externals, however, are
governed by the draft proposed Standard as I mentioned.
Of course, you could in theory invent your own .REL format and write a
new LINK. This is the "final solution" that the Committee backed away
from enforcing. If you decide to undertake this...
--Ken
-------
17-Jun-89 10:49:42-PDT,839;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sat, 17 Jun 89 10:49:36 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA11685; Sat, 17 Jun 89 13:49:37 EDT
Date: 17 Jun 89 00:05:32 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Looking and thinking
Message-Id: <"CSI 5587-95"@CompuServe.COM>
I rebuilt KCC. When I run the resultant NCC.EXE via "iru ncc" and
follow that with a "mem" command, I get the following:
000000-220777 Not segment (W) 145 pages
500000-665777 Not segment (R) 118 pages
Are these values approximately correct?
-------
Thanks for the article on time; I passed that along. Thanks also for
the discussion on exported symbols and the 6-char business. I'm
digesting that now.
Benny
17-Jun-89 10:49:53-PDT,1016;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sat, 17 Jun 89 10:49:49 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA11714; Sat, 17 Jun 89 13:49:52 EDT
Date: 17 Jun 89 00:23:14 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: 6 character symbols and LINK
Message-Id: <"CSI 5587-101"@CompuServe.COM>
I understand what you say about dealing with 6-char symbols exported to
LINK. I probably should have elaborated on my question a bit, but I
believe you answered it. I was chiefly concerned about the static
internals and the concession to DDT (in CC.DOC under the discussion
of exported symbols). Perhaps support a switch to enable or disable
the concession.
LINK does support long names; there's already a REL block for exactly
that purpose. There's just no compiler to make use of this, and even
if there was, DDT would have to be taught about new symbol tables. It'd
be interesting work.
17-Jun-89 18:12:30-PDT,526;001000000001
Mail-From: KLH created at 17-Jun-89 18:12:26
Date: Sat, 17 Jun 89 18:12:26 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Looking and thinking
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5587-95"@CompuServe.COM>
Message-ID: <12502971266.18.KLH@SRI-NIC.ARPA>
000000-220777 Not segment (W) 145 pages
500000-665777 Not segment (R) 118 pages
Are these values approximately correct?
Yes, they're correct. Was there anything that you were concerned about?
-------
17-Jun-89 18:29:29-PDT,1769;001000000001
Mail-From: KLH created at 17-Jun-89 18:29:23
Date: Sat, 17 Jun 89 18:29:23 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: 6 character symbols and LINK
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5587-101"@CompuServe.COM>
Message-ID: <12502974352.18.KLH@SRI-NIC.ARPA>
I was chiefly concerned about the static
internals and the concession to DDT (in CC.DOC under the discussion
of exported symbols). Perhaps support a switch to enable or disable
the concession.
Well, I hadn't planned on making it a switch, since I don't see any
other way to ensure that KCC is conformant. Since KCC knows at
compile time what all of the static internals are, it can always
ensure that the results are unique within that file. Unfortunately it
will cost some additional overhead (to maintain extra info and check
it). The mapping can look something like $SYMnn or whatever.
LINK does support long names; there's already a REL block for exactly
that purpose. There's just no compiler to make use of this, and even
if there was, DDT would have to be taught about new symbol tables. It'd
be interesting work.
Yeah, I've thought about using those blocks, but didn't for various reasons:
* No assembler supports them; would have to generate RELs directly.
* DDT doesn't support them either. Agh!
* Not all places have an uptodate LINK.
* Want to bet that LINK's new-block handling has no bugs?
It would also be possible to do it using block structured symbols to
divvy long names up into 6-char chunks with case-shift prefixes, but
again too many other pieces of software would have to be revamped.
So let's just be grateful that the committee realized this too!
-------
19-Jun-89 09:59:22-PDT,1166;001000000001
Mail-From: KLH created at 19-Jun-89 09:58:06
Date: Mon, 19 Jun 89 09:58:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Memory question
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12503405562.18.KLH@SRI-NIC.ARPA>
Since the issue of core usage appears to be a problem for you, what
exactly were you thinking a reasonable size for the compiler would be?
If the answer isn't too different from the current configuration, then
something could be done. For example, several static tables can be
made dynamically allocated and the lowseg size could be reduced by a
fair number of pages, at the usual expense of more CPU time and
smaller maximum program sizes.
But there isn't any hope for reducing the hiseg size, however,
especially with the ANSI additions. Oh, it could be done, but the
expense of chopping up the compiler into further phases is probably
better spent on buying more memory or another machine.
With this kind of problem, I guess you're unlikely to port much if any
GNU software, since it typically (even defiantly) assumes the existence
of a vast virtual memory address space...
--Ken
-------
19-Jun-89 21:35:50-PDT,2786;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 19 Jun 89 21:35:00 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA24075; Mon, 19 Jun 89 18:16:11 EDT
Date: 19 Jun 89 16:58:45 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: SC-30s
Message-Id: <"CSI 5592-2452"@CompuServe.COM>
Ken -- My boss responds to your question about the SC-30 and how
we feel about them. --- Benny
-----------------------------------------------------------------
Forwarded Message 5592-2085
Reply to: Question
Benny,
I asked ABT if he wished to respond. He told me to. The SC30 might cost them
$400K, which is what SC wanted to charge us. These people don't care about
money, so I don't know if he could do any better. The machine itself runs 2.5
times faster than the KL in our normal customer or Inhouse load. Running DCMMD
(the KI memory diagnostic) gives it a 1.0 ratio instead of the 2.5. The box is
very small and very well put together. The hardware is very reliable and we
have had few microcode problems, but we have had some. The number of crashes
still seem to be somewhat less than the KL's and will be much less after the
initial microcode and engineering bugs are gone. Some instructions, notably
the byte instructions are considerably optimized, supposedly. The TOPS20 style
paging is supposed to be optimized but we use TOPS10 style paging and are using
up to 8 megawords of main memory at the moment (we dropped a couple of bits in
the table to allow more addressing). We're adding a SCSI interface this
summer. They have a frontend processor which can act as the normal KL PDP11
(which we don't use), there is the DTE (which we do use), CI, NI, Massbus and
SA (IBM channel) and FA (Fast IBM channel) interfaces. 4 CPU's can be put into
a single cabinet and can be used in SMP mode. The backplane is PC not
wire-wrapped.
Self maintenance can be tough, but SC people have been generally interested in
helping. Perhaps more so because they know we will find the solutions
ourselves if they don't (which GSB often does). Delivery has been a problem in
the past but is not for us at present. Maybe because we don't care right now.
I can't think of anything else to add at the moment. I'd suggest discussing
price with them first, since this would certainly determine a desire to pursue
an SC30, so far as I am concerned. Used KL's are $5K to $10K, but will never
be highly reliable and will be expensive to maintain, power (we can sell a
better power supply) and cool. You can probably buy a lot of throw away KL
parts for $400K, however...
Joe
JRB for BEN 16:15 EDT 19-Jun-89 Message 5592-2085 forwarded by
19-Jun-89 21:36:14-PDT,2206;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 19 Jun 89 21:36:06 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA23476; Mon, 19 Jun 89 17:43:55 EDT
Date: 19 Jun 89 16:58:45 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: SC-30s
Message-Id: <"CSI 5592-2452"@CompuServe.COM>
Ken -- My boss responds to your question about the SC-30 and how
we feel about them. --- Benny
-----------------------------------------------------------------
Forwarded Message 5592-2085
Reply to: Question
Benny,
I asked ABT if he wished to respond. He told me to. The SC30 might cost them
$400K, which is what SC wanted to charge us. These people don't care about
money, so I don't know if he could do any better. The machine itself runs 2.5
times faster than the KL in our normal customer or Inhouse load. Running DCMMD
(the KI memory diagnostic) gives it a 1.0 ratio instead of the 2.5. The box is
very small and very well put together. The hardware is very reliable and we
have had few microcode problems, but we have had some. The number of crashes
still seem to be somewhat less than the KL's and will be much less after the
initial microcode and engineering bugs are gone. Some instructions, notably
the byte instructions are considerably optimized, supposedly. The TOPS20 style
paging is supposed to be optimized but we use TOPS10 style paging and are using
up to 8 megawords of main memory at the moment (we dropped a couple of bits in
the table to allow more addressing). We're adding a SCSI interface this
summer. They have a frontend processor which can act as the normal KL PDP11
(which we don't use), there is the DTE (which we do use), CI, NI, Massbus and
SA (IBM channel) and FA (Fast IBM channel) interfaces. 4 CPU's can be put into
a single cabinet and can be used in SMP mode. The backplane is PC not
wire-wrapped.
Self maintenance can be tough, but SC people have been generally interested in
helping. Perhaps more so because they know we will find the solutions
ourselves if they don't (which GSB often does). Delivery has been a problem in
19-Jun-89 21:37:46-PDT,1809;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 19 Jun 89 21:37:18 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA19116; Mon, 19 Jun 89 13:49:45 EDT
Date: 19 Jun 89 13:16:16 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Big Low Seg
Message-Id: <"CSI 5592-294"@CompuServe.COM>
Ken -- Our memory quotas are a fact of life around here, and often
serve to annoy us as much as anybody, particularly when some development
has to be done on a customer system. Even inhouse accounts have these
quotas enforced here. Project 311 is fortunate not to have any in effect.
Is there anything that can be done about the size of KCC's low seg? Below
you can see how it stacks up against other compilers on our hosts. I find
that I can only run it from project 311.
As I expect you're involved in other endeavors, if you could point me in a
direction, I could set about trying to do something about this.
Thanks... Benny
---------------------------------------------------------------------------
[Session log begun at 11:16 AM EDT Monday, June 19, 1989]
[Job 58 on DHB, [311,2] on T30ACQ]
OK
r xf4
*^C
OK
mem
000000-007777 Not segment (W) 8 pages
400000-503777 DDH:XF4[1,41] %7G(502) (R) 68 pages
OK
r bliss
*^C
OK
mem
000000-022777 Not segment (W) 19 pages
400000-667777 DDH:BLISS[1,4] %4A(230) (R) 184 pages
OK
r basic
*^C
OK
mem
000000-010777 Not segment (W) 9 pages
400000-470777 DDH:BASIC[1,4] %2D(76)-1 (R) 57 pages
OK
cc
?KCC - bad usage, see C:CC.DOC for help.
OK
mem
000000-220777 Not segment (W) 145 pages
500000-665777 Not segment (R) 118 pages
OK
set nolog
[Session log ended at 11:16 AM EDT Monday, June 19, 1989]
20-Jun-89 04:41:19-PDT,2764;001000000001
Mail-From: KLH created at 20-Jun-89 04:41:18
Date: Tue, 20 Jun 89 04:41:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Big Low Seg
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5592-294"@CompuServe.COM>
Message-ID: <12503610034.18.KLH@SRI-NIC.ARPA>
I'm not sure what to make of the comparison of initial compiler sizes;
sort of like comparing ripe watermelons with sun-dried raisins, only
I'm not even sure which is which. What I'd like to know is what
exactly your quotas are and what memory usage (in numbers) you would
consider reasonable from (1) the compiler, and (2) the C runtime in
general.
I'd also like to know whether you are thinking of this as a fatal
problem for "acceptance testing", or as a feature request for later,
or what. I understand the size is causing you some problems, but
since it's not a technical matter, I'm not sure just how to classify
this.
Is there anything that can be done about the size of KCC's low seg?
Like I said, much of KCC's lowseg usage is simply statically
allocated, empty arrays. I'll omit the explanations of why this is a
Good Thing on TOPS-20 and ITS since it just boils down to non-paged vs
paged. Much of the lowseg can be transformed into slower dynamic
allocation, so that a compilation will use only the memory (plus
tracking overhead) that is actually needed rather than the sum of all
maximums.
But I don't have any idea of whether it can easily be reduced "enough"
without knowing what "enough" is. Remember, it's very possible that
even with a small initial lowseg, the dynamic space required will
still exceed some quotas.
As I expect you're involved in other endeavors, if you could point me in a
direction, I could set about trying to do something about this.
What kind of direction? My first comment would be to change over to
demand paging, but you already know that :-). If you mean twiddle
with parameters, well, there certainly are a number of things you
could do to produce a "limited" version of the compiler. WARNING:
such a version will almost certainly be unable to recompile KCC itself, so
work from copied sources and leave the full version alone! If you look at
CKCC:CCPARM.H you'll see a bunch of parameters that can be trimmed
quite a bit for small programs, and you can patch the $STKSZ variable
in the resulting runtime to reduce the size of the initial runtime
stack.
I'm not really hopeful that you'll be able to save very much this way
-- it feels like using a penknife to shave chips off a log. Almost
all of the sizes there were initially lower and got bumped up over
time to accomodate one or another actual program that choked
otherwise.
--Ken
-------
20-Jun-89 04:42:06-PDT,319;001000000001
Mail-From: KLH created at 20-Jun-89 04:42:03
Date: Tue, 20 Jun 89 04:42:03 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Contract arrived
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12503610172.18.KLH@SRI-NIC.ARPA>
FYI -- the signed copy came in the mail yesterday. Thanks!
-------
20-Jun-89 04:55:44-PDT,663;001000000001
Mail-From: KLH created at 20-Jun-89 04:55:41
Date: Tue, 20 Jun 89 04:55:41 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: SC-30s
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5592-2452"@CompuServe.COM>
Message-ID: <12503612653.18.KLH@SRI-NIC.ARPA>
Thanks for the info! I guess the bottom line is, how many SC30s (vs KLs)
did you decide to get?
I assume not 1500 of them...
p.s. Good point about throw-away KL parts.
p.p.s. Do you know about this Swedish computer club, Stacken, that is
collecting a complete set of PDP-10s with software to match? Amazing what
you can pick up in flea markets :-)
-------
20-Jun-89 05:15:56-PDT,930;001000000001
Mail-From: KLH created at 20-Jun-89 05:15:54
Date: Tue, 20 Jun 89 05:15:54 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: one more...
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12503616334.18.KLH@SRI-NIC.ARPA>
and I'm done with tonight's mail.
I'm interested in any other observations you have about KCC. So far I
have "?err" and lowseg size.
Status: I am currently re-writing the preprocessor to support the
dpANS. It's a real bitch to get right, which is why I'm doing it
first. KCC's current PP is character-based, but the dpANS makes
a switch to PP tokenizing almost mandatory. The result will be
a hybrid; tokenized for lexical manipulations, but char-scanned
for pass-throughs or conditional skips.
Interesting tidbit: Did you know GCC always reads its input files
completely into memory and thereupon grovels over them with a char
pointer? Quite typical...
-------
20-Jun-89 05:23:55-PDT,675;001000000001
Mail-From: KLH created at 20-Jun-89 05:23:54
Date: Tue, 20 Jun 89 05:23:53 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: well, not quite the last one
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12503617789.18.KLH@SRI-NIC.ARPA>
Just occurred to me that it would be a good idea to ask if you had
developed any profiling, metering or performance analysis tools over there.
That is, something that you can point at a program and have it tell
you which parts are using what % of the runtime. There are a couple
of things like that on T20 which check the PC every so often, but I
haven't really been able to get them working well.
-------
20-Jun-89 06:49:34-PDT,1002;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 20 Jun 89 06:49:15 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA10854; Tue, 20 Jun 89 09:38:57 EDT
Date: 20 Jun 89 08:33:01 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Proposed library changes
Message-Id: <"CSI 5595-700"@CompuServe.COM>
Ken -- Concerning your message from a few days ago about possible
library changes, they seem fine and reasonable to me. We maintain
a fairly complex library for our other languages. Some care has
been taken with respect to the order that the routines are placed
in the library. MAKLIB will generate a symbol index (I don't think
we added that feature), and we do use that. Once in a while we run
into that nastiness about having to search a library more than once,
but so far it's only been a very minor annoyance. People either know
how to deal with it or they stop by my office.
20-Jun-89 09:04:47-PDT,1623;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 20 Jun 89 09:04:20 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA13584; Tue, 20 Jun 89 11:48:14 EDT
Date: 20 Jun 89 11:12:45 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Acceptance testing
Message-Id: <"CSI 5595-2274"@CompuServe.COM>
Ken -- The issue of the low seg will not stand in the way of
acceptance of this first phase of the compiler effort; however,
it is viewed as a problem that needs to be dealt with.
I'm reluctant to ask for specific sizes with respect to the
low seg for the compiler as there may be issues that I'm unaware of
and I don't know the magnitude of the work involved. Reducing the
stack size and moving some tables that are probably in the low seg
to the high seg were two areas to study suggested around here. I'd
like to see the effect of these changes. FYI, there are some accounts
used on all systems that can only get at 64K.
I don't have any (and I haven't heard of any) issues that will hold up
acceptance of the compiler. I've rebuilt it and installed it on level
5. C: is defined as LV5: and CSYS: is defined as LV3:. I've also
installed the documentation on HLP:. That reminds me though; you at
one time sent me a message on coding sequences. While I have that in
my briefcase, I have deleted it from my mailbox. I was wondering if
that is a DOC file that you could put in [311,4700] or someplace?
All things considered, I think things are looking pretty good. I hope
you do.
Benny
20-Jun-89 09:24:17-PDT,687;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 20 Jun 89 09:21:26 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA14244; Tue, 20 Jun 89 12:20:21 EDT
Date: 20 Jun 89 11:43:26 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Utilities
Message-Id: <"CSI 5595-2535"@CompuServe.COM>
Ken -- Over the next weeks (maybe months) we will be looking at
development of utilities like profilers, source-formatters, cross-
referencers, debuggers, etc. Not too much going on yet.
Re GNU C. Yes, I see that GNU C reads itself into a string variable.
I hate it when that happens.
20-Jun-89 10:17:53-PDT,3441;001000000001
Mail-From: KLH created at 20-Jun-89 10:06:34
Date: Tue, 20 Jun 89 10:06:26 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Acceptance testing
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
Message-ID: <12503669225.18.KLH@SRI-NIC.ARPA>
[There are 3 questions buried in here that I hope you can answer.]
Ken -- The issue of the low seg will not stand in the way of
acceptance of this first phase of the compiler effort; however,
it is viewed as a problem that needs to be dealt with.
OK, I'll keep it in mind, but I can't really do anything about it
until the ANSI upgrade is finished. I guess that means moving the
issue into phase 3, uh, milestone C.
I'm reluctant to ask for specific sizes with respect to the
low seg for the compiler as there may be issues that I'm unaware of
and I don't know the magnitude of the work involved. Reducing the
stack size and moving some tables that are probably in the low seg
to the high seg were two areas to study suggested around here. I'd
like to see the effect of these changes. FYI, there are some accounts
used on all systems that can only get at 64K.
Don't worry, I'm not going to just take a number from you and run off
flailing at it. I can give you some idea of what might be involved
with trying to come in under various numbers. 64K is probably a good
starting point. Q1: Does that number refer only to the lowseg size (ie
1/4 of addr space)?
About reducing stack size: the main reason it is large is because
KCC needs a 24K word stack to recompile itself due to the handling of
some nested switch() statements which isn't that unusual in C programs.
Changing the algorithm won't be easy; it needs enough room to store all
the cases, whether on the stack or from dynamic memory, even though it
is only needed for a very short time.
Moving tables to high seg? The bulk of the lowseg stuff is what Unix
would call "bss" -- blank storage segment. There are a few things that
could be moved once the ANSI "const" keyword exists, although I don't
think they will amount to more than a couple pages. String literals
are already put in the hiseg.
Although you haven't actually said this, I gather the impression that
hiseg size is not a problem. Q2: True? (If so, good.)
Q3: How are pages allocated with GCORE$ accounted for vs the quota?
That is, if I gobble a bunch of pages above the high segment for
dynamic storage, are they counted as part of the lowseg for quota
purposes?
That reminds me though; you at
one time sent me a message on coding sequences. While I have that in
my briefcase, I have deleted it from my mailbox. I was wondering if
that is a DOC file that you could put in [311,4700] or someplace?
Yes, it is (or should be) CKCC:SEQNCE.DOC. I don't believe I
kermitted the internal KCC doc files along with the source -- I had
other things to worry about at the time. I'll set up a transfer, so
by the time you get this message the most useful CKCC:*.DOC files
should be there: CRTSYM, INTERN, and SEQNCE. There are a few others
but they are awfully random.
All things considered, I think things are looking pretty good. I hope
you do.
So far... it's just the 3rd part (where all the CSI mods are piled up)
that worries me, since that can easily be semi-infinite. But we'll
work it out.
--Ken
-------
20-Jun-89 10:47:41-PDT,432;001000000001
Mail-From: KLH created at 20-Jun-89 10:28:14
Date: Tue, 20 Jun 89 10:28:13 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: CKCC:*.DOC files there
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12503673190.18.KLH@SRI-NIC.ARPA>
OK, Kermit did its thing and the files are now there. Reading
INTERN.DOC, in particular, might give you some insight into
the memory use issues. (or maybe not...)
-------
21-Jun-89 10:31:56-PDT,3580;001000000001
Mail-From: KLH created at 21-Jun-89 10:31:46
Date: Wed, 21 Jun 89 10:31:46 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Some Ideas
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12503935979.18.KLH@SRI-NIC.ARPA>
I was trying to fall asleep last night and came up with a couple of
ways that we might be able to significantly reduce KCC's impure core.
(1) The largest single table in KCC is probably the nodes[] table; it uses
55 pages alone with the current size definition. It already has the
hooks for dynamically extending itself, so you can try building
a new KCC into a new binary directory by putting "-DMAXNODE=100" into
the KCC invocation line of the copy of NCC.COM in that binary directory.
You can do this right now and regain 50 pages from the lowseg, at least on
startup. The amount it will need during operation will depend on the
size of the largest top-level declaration in the source.
-------------------
(2) Do a preprocessor pass. This is a common approach on small
systems, which run CPP as a separate program. It would be painful to
actually make a stand-alone CPP since the preprocessing shares a lot
of code with other KCC stages, and since TOPS-10 doesn't support
subforks it would necessitate even more hair with TMPCOR/RUN and yet
another set of parallel output files. However, (and this is the idea
I favor) it would be relatively easy to set up KCC so that for each
input source file, it:
(a) generated a temporary file, nnnCPP.TMP, holding the preproc output.
(b) flushed all memory related to preproc syms, vars, strings.
(c) read in the temp file as normal C input.
The main advantage of this is not needing to keep around all of the
macro definitions (symbols and bodies), as well as some portion of
string storage space, and (if uuosym.h or csisym.h is used) being able
to flush the storage used for the .UNV files.
The reason I like this is that it's simple enough that I could probably
rig it up in a couple of man-days, and can be switch selected. That is,
the decision of whether to trade off speed for space can be made at KCC
invocation time.
Of course, this only helps with programs that happen to reference UNV
files (many pages) or define a lot of macros (anywhere from one to
many pages, depending). You also lose the (non-standard) feature of
being able to use arbitrary constant expressions (eg sizeof) in #if
conditionals, instead of just those fitting the dpANS constraints.
-------------------
(3) I looked again at the switch() code generation. It gobbles 4 (yes 4)
pages of stack space for EACH nesting of switch statements, regardless of
the actual size of the switch. So, for example, something like the
following program:
switch (foo) { case 1: switch (x) { ... } case 2: ... }
which has 2 levels of switch() nesting, would require 8 pages of stack
space in order to compile. Pretty gross, huh. This can be fixed to
use dynamic memory, but it will be harder to change the algorithm
because it relies heavily on hashing into a hefty power-of-2 table
size. I would guess three or four man-days effort (I get real
cautious whenever messing with the code generation phase).
-------------------
I have a few other ideas but the payoff/effort ratio doesn't seem as
promising; after I hear from you about my previous questions, I should
have a better feel for their practicality anyway. Let me know if you
think any of these are worth pursuing after you try the MAXNODE
redefinition.
--Ken
-------
22-Jun-89 14:01:10-PDT,486;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 22 Jun 89 13:57:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA06226; Thu, 22 Jun 89 17:01:15 EDT
Date: 22 Jun 89 16:29:14 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: We've bought 10 SC-30s
Message-Id: <"CSI 5597-3800"@CompuServe.COM>
Ken -- I'm told that we are buying (have bought) around 10 SC-30s.
Benny
22-Jun-89 15:45:49-PDT,602;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 22 Jun 89 15:45:22 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA06199; Thu, 22 Jun 89 17:01:03 EDT
Date: 22 Jun 89 16:25:47 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC
Message-Id: <"CSI 5597-3765"@CompuServe.COM>
Ken -- I've rebuilt KCC with MAXNODE=100 and $STKSZ=01000. Things
seem okay; I'll respond more directly to your ideas and your questions
in a later message after we use this release a bit more.
Benny
22-Jun-89 15:46:04-PDT,953;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 22 Jun 89 15:45:55 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA06171; Thu, 22 Jun 89 17:00:49 EDT
Date: 22 Jun 89 16:21:40 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC feedback (more later)
Message-Id: <"CSI 5597-3740"@CompuServe.COM>
Ken -- Here's the nature of the feedback I'm getting concerning KCC:
-- The last line of an #include file must end in a CRLF.
-- Unreferenced externals generate commented out assembly
EXTERNs.
-- The concession to DDT for static symbols (we've discussed).
-- CompuServe has a convention of translating and underscore to
a percent instedda a dot.
-- Non-unique symbols names not detected in compiler. Passed on
to assembler where the assembler complains. Seems that KCC should
be the complainer.
Benny
22-Jun-89 16:26:38-PDT,1844;001000000001
Mail-From: KLH created at 22-Jun-89 16:26:35
Date: Thu, 22 Jun 89 16:26:35 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC feedback (more later)
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5597-3740"@CompuServe.COM>
Message-ID: <12504262717.18.KLH@SRI-NIC.ARPA>
Thanks for the feedback. Here are some responses:
-- The last line of an #include file must end in a CRLF.
Yes, the dpANS will require this of all source files. I'm not sure
what you mean by this comment, though: (a) some C:*.H files don't end
in CRLF? (b) People don't like this requirement? or (c) People want
this to be enforced? (KCC tries to be flexible, which can explain any
instances of (a))
-- Unreferenced externals generate commented out assembly
EXTERNs.
Yes, this is intentional, for information only. Do you want this
information flushed? (Normally the MAC files are never looked at; in
fact, they shouldn't even exist, but I couldn't think of an easy way
for the TOPS10 version to delete them afterwards without inventing
another program.)
-- CompuServe has a convention of translating and underscore to
a percent instedda a dot.
I guess it's possible to change this, if you think it's really
worthwhile (sigh). Note that the `ident` extension exists precisely to
permit interaction with symbols from another universe.
-- The concession to DDT for static symbols (we've discussed).
-- Non-unique symbols names not detected in compiler. Passed on
to assembler where the assembler complains. Seems that KCC should
be the complainer.
These are two aspects of the same thing, which I plan to fix in the
upgrade. It will take at least another storage word per symbol plus
additional checking overhead, but I don't see any alternative.
--Ken
-------
23-Jun-89 07:54:33-PDT,735;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 23 Jun 89 07:54:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA03279; Fri, 23 Jun 89 10:58:34 EDT
Date: 23 Jun 89 10:23:11 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: static I/O buffers
Message-Id: <"CSI 5600-1571"@CompuServe.COM>
Ken -- In looking at UIODAT.C, there's the comment that syscalls
cannot invoke malloc() as needed. I guess this is still
the case, huh. It seems that correcting that will fix
a lot of lowseg size concerns (e.g. A 'hello world' program
has a somewhat large lowseg). I'll try and get off this
memory subject for a while.
23-Jun-89 09:02:23-PDT,831;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 23 Jun 89 09:01:13 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA04414; Fri, 23 Jun 89 12:05:31 EDT
Date: 23 Jun 89 11:33:58 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Byte sizes
Message-Id: <"CSI 5600-2191"@CompuServe.COM>
Could you discuss your reasons for choosing 9-bit bytes as a default over
8-bit bytes? On the -10, 8-bit bytes seem more portable than 9-bit. SZ,
ARC, and PC-10 binary file transfers all use 8-bit bytes.
I'm told (I haven't had time to verify it yet) that if a file is fopen()'d
with "b8" to force 8-bit bytes, that NULL bytes will be generated to pad
the file to a block boundary instedda stopping on the correct byte boundary.
23-Jun-89 17:13:20-PDT,1073;001000000001
Mail-From: KLH created at 23-Jun-89 17:12:53
Date: Fri, 23 Jun 89 17:12:53 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: static I/O buffers
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5600-1571"@CompuServe.COM>
Message-ID: <12504533289.18.KLH@SRI-NIC.ARPA>
Ken -- In looking at UIODAT.C, there's the comment that syscalls
cannot invoke malloc() as needed. I guess this is still
the case, huh.
Yes. It would be possible to make it dynamic and still remain maximally
portable by adding system-specific code for CSI which used GCORE$ to get
pages from the highseg downwards. This way there will be no conflict
with either malloc() or sbrk(). Another thing for phase 3.
A less portable method would be to invoke sbrk(). For this to work,
programs cannot rely on sbrk returning successive addresses in
sequence, as it does on Unix. Unfortunately, one example of code that
makes this assumption is malloc(), which I would dearly like to
replace with my own version if I ever get the time.
-------
23-Jun-89 17:40:20-PDT,1692;001000000011
Mail-From: KLH created at 23-Jun-89 17:40:17
Date: Fri, 23 Jun 89 17:40:16 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Byte sizes
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5600-2191"@CompuServe.COM>
Message-ID: <12504538275.18.KLH@SRI-NIC.ARPA>
I'm told (I haven't had time to verify it yet) that if a file is fopen()'d
with "b8" to force 8-bit bytes, that NULL bytes will be generated to pad
the file to a block boundary instedda stopping on the correct byte boundary.
Isn't that what TOPS-10 normally does? The C runtime isn't padding
anything, it just closes the I/O channel, and the system then
presumably fills the rest of the block with zero bytes. Remember,
this version is basically just the TOPS-10 bootstrap -- it does NOT
have the CSI-specific 8-bit byte hack (4-bit code in last word) that
you described to me earlier. Phase 3 again.
Could you discuss your reasons for choosing 9-bit bytes as a default over
8-bit bytes? On the -10, 8-bit bytes seem more portable than 9-bit. SZ,
ARC, and PC-10 binary file transfers all use 8-bit bytes.
I don't have much time so this answer may appear too brief.
There is absolutely no way to conform to the dpANS without using a
byte size that will exactly fill a word. For the PDP-10 there are
only 4 possible byte sizes: 9, 12, 18, and 36. I/O is included in
this because "A binary stream is an ordered sequence of characters
that can transparently record internal data."
There are at least two "right" ways to fix this, in my opinion, but
you probably aren't going to like either of them. Gotta run, more later.
--Ken
-------
24-Jun-89 09:16:11-PDT,958;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sat, 24 Jun 89 09:15:50 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA26466; Sat, 24 Jun 89 12:20:30 EDT
Date: 24 Jun 89 10:38:21 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: files
Message-Id: <"CSI 5603-321"@CompuServe.COM>
Ken --
I should have been more specific about the null bytes: I was
referring to padding on input, not output. A file that is 3 words long
will return 512 bytes via fgetc().
The cause is our most ridiculous feature. Although file lengths are
maintained with a resolution of one word, they are rounded up to a
multiple of 128 unless you do a "TRUSZ$ 1," call before the OPEN. It's
adequate to do this once after each RESET, although it's probably easier
to just do it before each OPEN. This doesn't apply to FILOP., which
ignores the "TRUSZ" setting.
24-Jun-89 09:23:15-PDT,1053;001000000001
Mail-From: KLH created at 24-Jun-89 09:23:11
Date: Sat, 24 Jun 89 09:23:11 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: files
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5603-321"@CompuServe.COM>
Message-ID: <12504709926.18.KLH@SRI-NIC.ARPA>
The cause is our most ridiculous feature. Although file lengths are
maintained with a resolution of one word, they are rounded up to a
multiple of 128 unless you do a "TRUSZ$ 1," call before the OPEN. It's
adequate to do this once after each RESET, although it's probably easier
to just do it before each OPEN. This doesn't apply to FILOP., which
ignores the "TRUSZ" setting.
Oops, my goof, sort of. In CUSYS:URT.C, at the start of the init_uio() call
there is:
CSIUUO_AC("TRUSZ$", 1);
which should have been:
CSIUUO_CH("TRUSZ$", 1);
I missed the point in COUGH.USR that it's the AC #, not the contents,
that sets the flag. Sigh. You can go ahead and fix that, it will only
affect the CSI binary.
--Ken
-------
26-Jun-89 07:57:58-PDT,782;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 26 Jun 89 07:57:35 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA23218; Mon, 26 Jun 89 10:58:24 EDT
Date: 26 Jun 89 10:34:49 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Segment sizes
Message-Id: <"CSI 5604-2938"@CompuServe.COM>
Ken -- I believe I answered the question about GCORE$ pages vs
the quota in a previous message. Here are responses to
two other questions: I misspoke when I said there were
many users that could only get at 64K. That should have
been 48K, and that number is including both high and low
segs. Your impression that the high seg size is not a
problem is correct.
Benny
26-Jun-89 09:35:00-PDT,899;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 26 Jun 89 09:34:55 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA26395; Mon, 26 Jun 89 12:35:51 EDT
Date: 26 Jun 89 12:09:28 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Making CC.EXE shareable
Message-Id: <"CSI 5604-3851"@CompuServe.COM>
Ken -- I want to make the compiler a shareable image. In KCC:CCASMB.C,
there is a routine MAKTFLINK where I'd like to put the following conditional
down near the end where "/SAVE" is copied to the argument list for NON-WAITS
systems.
#if SYS_CSI
t = estrcpy(estrcpy(estrcpy(t,"\n"), ofilename), "/NSSAVE");
#else
#if !(SYS_WTS)
t = estrcpy(estrcpy(estrcpy(t,"\n"), ofilename), "/SAVE");
#endif
#endif
Or something like this. Any thoughts? Criticisms? Comments?
Benny
28-Jun-89 08:27:42-PDT,1240;001000000001
Mail-From: KLH created at 28-Jun-89 08:27:39
Date: Wed, 28 Jun 89 08:27:39 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Making CC.EXE shareable
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5604-3851"@CompuServe.COM>
Message-ID: <12505748393.18.KLH@SRI-NIC.ARPA>
Ken -- I want to make the compiler a shareable image. In KCC:CCASMB.C,
there is a routine MAKTFLINK where I'd like to put the following conditional
down near the end where "/SAVE" is copied to the argument list for NON-WAITS
systems.
<...>
Or something like this. Any thoughts? Criticisms? Comments?
This change will affect every program that KCC builds, not just the compiler.
If that is what you want, fine. Otherwise, it is probably better to change
the NCC.COM file that builds KCC to do an IGET and NSSAVE of the resulting
image. If you can't decide because some programs will want /NSSAVE and others
will want /SAVE, then I can make it a parameter of the -i switch.
By the way, I hope you are keeping track of any changes you make, so that
I can re-integrate them into the ANSI version prior to bringing it over.
Too bad so few systems support file version numbers.
--Ken
-------
28-Jun-89 08:37:25-PDT,957;001000000001
Mail-From: KLH created at 28-Jun-89 08:37:22
Date: Wed, 28 Jun 89 08:37:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Segment sizes
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5604-2938"@CompuServe.COM>
Message-ID: <12505750163.18.KLH@SRI-NIC.ARPA>
Ken -- I believe I answered the question about GCORE$ pages vs
the quota in a previous message.
Hmm, if I got the message, I can't find it. Resend please?
Here are responses to
two other questions: I misspoke when I said there were
many users that could only get at 64K. That should have
been 48K, and that number is including both high and low
segs. Your impression that the high seg size is not a
problem is correct.
The last point is good, but I don't quite see how that goes along
with the 48K limit applying to both high and low segs. Unless you
are saying that such users won't be expected to run KCC anyway.
-------
28-Jun-89 09:54:02-PDT,4141;001000000001
Mail-From: KLH created at 28-Jun-89 09:50:32
Date: Wed, 28 Jun 89 09:50:32 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Byte sizes
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12504538275.18.KLH@SRI-NIC.ARPA>
Message-ID: <12505763481.18.KLH@SRI-NIC.ARPA>
More on this topic, then back to work.
Could you discuss your reasons for choosing 9-bit bytes as a default over
8-bit bytes? On the -10, 8-bit bytes seem more portable than 9-bit. SZ,
ARC, and PC-10 binary file transfers all use 8-bit bytes.
The dpANS distinguishes between text and binary streams so that
programs can be ported to systems with the ability (or need) to use
byte sizes other than 8 bits. Binary streams are specifically
guaranteed to be able to represent any internal data structures,
including full words. Additionally, while the dpANS does not require
it, in practice programs are maximally portable when the I/O bytesize
corresponds to the internal "char" type.
On TOPS-20, all files include bytesize information, so reading and
writing binary files always does the "right thing" whether the size is
8 or 9 bits. On read, the existing bytesize is used, so that is how
you can "specify" between 8 and 9; if it somehow happens to be wrong,
you can mung the file bytesize and not the program. On write, you
can't do this (the default is always 9 bits) but this doesn't (or
shouldn't) cause problems for other programs as long as they honor the
bytesize.
On TOPS-10, you have a problem. The "right" way to fix this, obviously,
is to carry bytesize information in the RIB (like more recent TOPS-10s
appear to). Ideally this would contain file length information as well,
to solve the problem of finding the last byte of a 9-bit file.
This could be, but doesn't have to be, a monitor-supported concept.
You mentioned that you already have a convention for determining which
byte of an "8-bit" file is really the last one, which indicates to me
that the programs which need this are already well-known and
identified, and probably CSI-supported, and thus modifiable if need be.
For a full implementation, all you need are 12 bits anywhere in the RIB
which will be (or can be made to be) preserved over dumps, copies, and
the like. These 12 bits would be akin to a byte pointer's P&S bits, where
the low 6 are the bytesize and the high 6 tell you what position in the
last word corresponds to the first unused byte; in conjunction with the
file length in words, you can then derive the file length in bytes.
This of course is a little more general than absolutely necessary, but
considering anything less carries the risk of being short-sighted. If
I recommended any lesser approach I'm afraid it would manage to bite
you painfully someday.
That said, there are some lesser notions.
[1] You could use fewer RIB bits to only support a few specific sizes.
The total number of states would be 14 (5 7-bit, 4 8-bit, 4 9-bit,
and 1 36-bit).
For example, the data mode of the file (16 states) can be used
as an indicator. You mentioned that some utilities may not reliably
reproduce this information; surely fixing the utilities is simple
compared with the great number of changes already made to the monitor
itself.
[2] You can use only a single RIB indicator (a full-word value or single bit)
to say "this file is 8-bit and uses the CSI last-word hack".
[3] You could define certain file extensions as ALWAYS being 8-bit files,
whether reading or writing.
[4] You can patch an internal variable in the C runtime of specific
programs so that binary streams always use 8-bit bytes.
[5] You could specify a new convention internal to C programs, and forget
about compatibility with other kludges. Re-code into C the
programs that currently deal with SZ/ARC/PC-10.
I have not listed "make 8-bit the default for binary streams for all
programs" because I'm convinced that would be a mistake. I hope you
are, too. As the refrain goes, you might have a compiler, but it
won't be an ANSI C compiler.
--Ken
-------
29-Jun-89 07:23:48-PDT,986;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 29 Jun 89 07:23:33 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA12232; Thu, 29 Jun 89 10:24:38 EDT
Date: 29 Jun 89 09:57:18 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: KCC bug?
Message-Id: <"CSI 5606-6784"@CompuServe.COM>
Ken -- Here's one for you.
Benny
---------------------------------------------------------------------
/* Benny - I'm having a problem with KCC. For some reason, it doesn't
seem to be able to do pointer arithmetic correctly. The following
program doesn't work correctly because the statement pt += 1 is not
being executed correctly. pt++ seems to work okay, but both
should work.
Michael Spaulding
*/
#include <stdlib.h>
main ()
{
char *buf1 , *pt1;
int x;
pt1 = buf1;
for (x = 0; x <= 5; x++)
{
printf ("pt1 is: %o\n", pt1);
pt1 += 1;
}
}
29-Jun-89 07:47:24-PDT,466;001000000001
Mail-From: KLH created at 29-Jun-89 07:47:16
Date: Thu, 29 Jun 89 07:47:16 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC bug?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5606-6784"@CompuServe.COM>
Message-ID: <12506003187.26.KLH@SRI-NIC.ARPA>
I just confirmed this is a real bug. Compiling with optimization off
(-O=) works. Will investigate and fix later today, right now there is a
VIP to be coddled.
-------
29-Jun-89 10:42:30-PDT,801;001000000001
Mail-From: KLH created at 29-Jun-89 10:29:12
Date: Thu, 29 Jun 89 10:29:12 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC bug?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5606-6784"@CompuServe.COM>
Message-ID: <12506032666.26.KLH@SRI-NIC.ARPA>
OK, I found and fixed the bug. Please pass on my thanks for reducing
it to a simple test case.
Although I was surprised that this hadn't come up before, I was not at
all surprised to find that it was in a portion of code that I
inherited and labelled a "BIG MESS" (foldboth() in CCOPT.C). I'll
kermit the new file over as soon as I run the fix through my usual
verification (complete KCC rebuild and comparison). This might take
a while as our machines are very slow right now.
--Ken
-------
29-Jun-89 10:42:38-PDT,755;001000000001
Date: Thu, 29 Jun 89 10:29:12 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC bug?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5606-6784"@CompuServe.COM>
Message-ID: <12506032666.26.KLH@SRI-NIC.ARPA>
OK, I found and fixed the bug. Please pass on my thanks for reducing
it to a simple test case.
Although I was surprised that this hadn't come up before, I was not at
all surprised to find that it was in a portion of code that I
inherited and labelled a "BIG MESS" (foldboth() in CCOPT.C). I'll
kermit the new file over as soon as I run the fix through my usual
verification (complete KCC rebuild and comparison). This might take
a while as our machines are very slow right now.
--Ken
-------
30-Jun-89 17:53:39-PDT,889;001000000001
Mail-From: KLH created at 30-Jun-89 17:53:29
Date: Fri, 30 Jun 89 17:53:29 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC bug?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5606-6784"@CompuServe.COM>
Message-ID: <12506375688.31.KLH@SRI-NIC.ARPA>
OK, no problems with the fix, so I brought over a new CKCC:CCOPT.C and
built a new CCSI:NCC.EXE. I'll leave it up to you to install that or
build a different configuration elsewhere.
One thing of interest you may want to pass on is that the case of "p
+= 1" will sometimes compile into a sequence of MOVE, IBP, MOVEM
rather than just an IBP of the memory location as "++p" would do.
This is optimized correctly in the most recent KCC, but the necessary
module is already too different as a result of the upgrade in
progress, so I opted to leave that out rather than retrofit.
-------
30-Jun-89 18:07:09-PDT,705;001000000001
Mail-From: KLH created at 30-Jun-89 18:07:06
Date: Fri, 30 Jun 89 18:07:04 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Status and other stuff
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12506378160.31.KLH@SRI-NIC.ARPA>
I'm going to be away from this Saturday eve until roughly Thursday, on
... uh... what is it they call those things... oh yes, "vacation", that's it.
The new dpANS preprocessor is done (modulo any stray bugs that squirm out
later). Prototypes are next. Still on schedule so far.
Have you decided yet whether to send a check for the first milestone? You've
had a few more than 10 days. Let me know what's up... thanks.
--Ken
-------
2-Jul-89 06:24:24-PDT,857;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sun, 2 Jul 89 06:24:18 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA01179; Sun, 2 Jul 89 09:25:48 EDT
Date: 01 Jul 89 22:04:17 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: The check's in the mail -- It really could be. I'll find out.
Message-Id: <"CSI 5608-769"@CompuServe.COM>
Ken -- I issued a check request for $7,000 earlier this week. I'm not
sure if I'll see any results, or if you'll simply get the check. I'll
look into this Wednesday when CompuServe is open again. I apologize
for the lateness; it's my fault, and I'll try to be more on the ball
with the next milestone.
Thanks for the update on the dpANS preprocessor. Sounds teriffic!
Have a good vacation!
Benny
5-Jul-89 15:43:48-PDT,1174;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 15:43:21 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA14584; Wed, 5 Jul 89 18:45:12 EDT
Date: 05 Jul 89 16:29:33 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Another bug?
Message-Id: <"CSI 5611-5211"@CompuServe.COM>
Ken -- I just received this. Does this seem like a bug or a
user misunderstanding? I'll try and get a little bug file
for item #2. Benny
----------------------------------------------------------------
Forwarded Message 5611-5179
Subj: kcc
I've had a few more problems with KCC:
1) The construct free(p),p=NULL causes the following error:
Lvalue expected in assignment expression (paraphrased)
2) The function getc() doesn't always return EOF correctly.
Once I got into an infinite loop because it never returned
eof. Using gets worked, though. I think the problem has to do
with the file ending on a fullword boundary.
Distribution:
BCD
BEN
M.SPAULDING for BEN 16:26 EDT 05-Jul-89 Message 5611-5179 forwarded by
6-Jul-89 07:26:15-PDT,470;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 6 Jul 89 07:26:10 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA00754; Thu, 6 Jul 89 10:22:01 EDT
Date: 06 Jul 89 09:48:13 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Check
Message-Id: <"CSI 5611-7493"@CompuServe.COM>
Ken -- I'll be sending that check out to you today. Sorry about the
delay. Benny
7-Jul-89 13:07:29-PDT,1145;001000000001
Mail-From: KLH created at 7-Jul-89 13:07:00
Date: Fri, 7 Jul 89 13:07:00 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Another bug?
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5611-5211"@CompuServe.COM>
Message-ID: <12508158543.34.KLH@SRI-NIC.ARPA>
Hi, I'm back now from the Canadian rockies, which are just fantastic. Very
difficult to return to Mundania... siiiiiigggghhhhh.
Anyway, about the bug messages:
1) The construct free(p),p=NULL causes the following error:
Lvalue expected in assignment expression (paraphrased)
Could not reproduce as given. Sample program?
2) The function getc() doesn't always return EOF correctly.
Once I got into an infinite loop because it never returned
eof. Using gets worked, though. I think the problem has to do
with the file ending on a fullword boundary.
Look on H&S (2nd ed) p. 87,88 for a description of the most likely
cause of this, which has to do with assigning the value of getc() into
a variable of type char rather than int. If this is not the case, I'd
appreciate an example.
--Ken
-------
7-Jul-89 14:15:58-PDT,834;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu ([128.146.8.98]) by SRI-NIC.ARPA with TCP; Fri, 7 Jul 89 13:57:09 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA03589; Fri, 7 Jul 89 16:53:59 EDT
Date: 07 Jul 89 16:35:28 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: misc
Message-Id: <"CSI 5612-3902"@CompuServe.COM>
Ken -- Welcome back. The check is in the mail (I put it there myself).
I don't expect you to embrace this notion, but I've gotta ask it --
Could KCC push arguments on the stack in source code order and not
in reverse order? I understand that the "reverse order" allows
variable size argument lists to be supported. Could pragmas be
provided that surround a function call to control the ordering of
arguments?
Benny
7-Jul-89 14:31:39-PDT,1440;001000000001
Mail-From: KLH created at 7-Jul-89 14:31:35
Date: Fri, 7 Jul 89 14:31:35 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: misc
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5612-3902"@CompuServe.COM>
Message-ID: <12508173942.34.KLH@SRI-NIC.ARPA>
I don't expect you to embrace this notion, but I've gotta ask it --
Could KCC push arguments on the stack in source code order and not
in reverse order? I understand that the "reverse order" allows
variable size argument lists to be supported. Could pragmas be
provided that surround a function call to control the ordering of
arguments?
Excuse me while I clean up the cookies I just spewed over my desk.
This falls into the category of "anything is possible, if you want it
bad enough". It would not be easy and won't fit within the bounds of
the current project.
I assume the motivation behind this is a desire to have C functions invoke
(or be called by) functions in other languages. A #pragma or special
keyword such as "fortran" can be used to declare such functions. I've
been asked about doing this for fortran-77 in the past, and have looked
into doing it, but the people weren't willing to let the results be
distributed elsewhere so nothing came of it.
If that's not the case and the reason is something else, I'd be
interested in knowing what's behind this request...
--Ken
-------
7-Jul-89 18:11:56-PDT,652;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 7 Jul 89 18:11:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA07524; Fri, 7 Jul 89 21:10:12 EDT
Date: 07 Jul 89 20:59:10 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Argument ordering
Message-Id: <"CSI 5612-4727"@CompuServe.COM>
The motivation for the argument request is just as you suggested. We
can talk about it later maybe; it's just that there seemed to be no
gentle way to approach it other than just to dive right in. Sorry
about those cookies on your desk.
Benny
7-Jul-89 18:50:32-PDT,1810;001000000001
Mail-From: KLH created at 7-Jul-89 18:50:29
Date: Fri, 7 Jul 89 18:50:29 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Argument ordering
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5612-4727"@CompuServe.COM>
Message-ID: <12508221073.25.KLH@SRI-NIC.ARPA>
You didn't mention what language(s) you were thinking of, but here's
one trivial approach that would work for simple cases.
Normally, any sizeable program that calls routines from another module will
be using #include to get shared definitions and declarations pertinent to
the other modules. Suppose you have a C program which wants to call the
routine FOO in module OLDPKG. In that C program, you'd have:
#include "oldpkg.h"
and in the OLDPKG.H file, you might have something like this:
#define foo(a,b,c) foo_entry(c,b,a)
extern int foo_entry();
In other words, you would have a macro specific to each function, which
knew how to arrange (or even mung) the args to that function. Look at
the file C:SYSITS.H for an example of this approach -- the SYSCALL macro
stuff reverses its args so that ITS system calls can simply point the
system directly to the arg block on the stack.
More complicated situations might well need KCC support -- for
example, if you want C functions to be invoked by other-language
routines, or even by both C and other languages. There are too many
possibilities to generalize beyond the obvious observation that the
best approach will depend on the specific case. I'd be glad to talk
more about this, it's just that any solution which requires compiler
modifications would mean either expanding the scope of this contract (if
you want me to do it) or waiting until I'm finished with the upgrade
(if you want to do it).
--Ken
-------
10-Jul-89 07:06:18-PDT,942;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 10 Jul 89 07:05:25 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA22819; Mon, 10 Jul 89 10:07:23 EDT
Date: 10 Jul 89 09:50:25 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Memory management and version support
Message-Id: <"CSI 5619-1463"@CompuServe.COM>
to: Ken
fr: Benny Jones
Here are a couple of items for your consideration to
include in phase 3.
We have a set of memory management routines that is
utilized by our various languages. We'd like KCC to
make use of these. Since you've indicated you want
to make changes in the current memory managment scheme,
perhaps, you could make use of some of our existing
work.
I'd like a mechanism for setting version numbers in our
programs and in the KCC compiler herself. Perhaps with
a #pragma.
10-Jul-89 11:35:47-PDT,993;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 10 Jul 89 11:26:11 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA27621; Mon, 10 Jul 89 14:26:21 EDT
Date: 10 Jul 89 13:56:04 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: C books
Message-Id: <"CSI 5619-3615"@CompuServe.COM>
Ken -- A few months back, I read an article in Computer Language
Magazine comparing a few of the books on ANSI-C. None of the
books reviewed were without some drawbacks. I was wondering
if you have a favorite, a recommendation or one to stay away from.
I'm interested in a book to serve as a reference for programmers
who know C and want to program in ANSI C. I have on a trial basis,
the Mark Williams book, ANSI C, A Lexical Guide. Do you have
any thoughts on that one? Thanks.
I've called a couple of companies about C validation suites. Geez,
are those expensive! (around $10K).
10-Jul-89 12:25:21-PDT,1556;001000000001
Mail-From: KLH created at 10-Jul-89 12:22:50
Date: Mon, 10 Jul 89 12:22:50 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: C books
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5619-3615"@CompuServe.COM>
Message-ID: <12508936935.51.KLH@SRI-NIC.ARPA>
C books:
The ones we use are those identified by the KCC user documentation,
namely Harbison & Steele plus (for the traditionalists) K&R. K&R is
more of a tutorial introduction, whereas H&S is oriented towards
implementors and clarifies more of the obscure details. I sent a lot
of comments to H&S about the 1st edition, but unfortunately their 2nd
edition introduced a good number of typos. I have not bothered to even
look at other books purporting to describe ANSI C because none of them
can authoritatively claim to be complete until the dpANS is formally
adopted by ANSI. For actual implementation decisions I use the most
recent dpANS itself (currently the Dec 7, 1988 version). Copies are
supposed to be available from a place called Global Engineering Documents;
I can't find their number just now but can dig it up if you want.
The dpANS is most decidedly not a tutorial, however.
C validation suites:
Actually, $10K is pretty cheap compared to some of the prices I ran
across when I looked into this! I thought it would be a neat idea
too, but since KCC isn't actually being sold, I can't justify that
kind of outlay. Unfortunately none of those suites is likely to have
much in the way of sales volume.
--Ken
-------
10-Jul-89 12:28:15-PDT,809;001000000001
Mail-From: KLH created at 10-Jul-89 12:27:36
Date: Mon, 10 Jul 89 12:27:35 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Memory management and version support
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5619-1463"@CompuServe.COM>
Message-ID: <12508937801.51.KLH@SRI-NIC.ARPA>
We have a set of memory management routines that is
utilized by our various languages. We'd like KCC to
make use of these.
Are you talking about DSFNC$? In either case, I'll need more details.
I'd like a mechanism for setting version numbers in our
programs and in the KCC compiler herself. Perhaps with
a #pragma.
What do you want these version numbers to look like? One word divvied
up DEC fashion? How is this done in your other supported languages?
-------
11-Jul-89 17:47:56-PDT,1188;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Tue, 11 Jul 89 17:46:46 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA25420; Tue, 11 Jul 89 15:43:11 EDT
Date: 11 Jul 89 15:28:51 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Michael Snyder
Message-Id: <"CSI 5621-3695"@CompuServe.COM>
Ken -- I'd like to introduce Michael Snyder. Michael is CompuServe's
compiler engineer. He's recently been looking at GNU C on our VMS
system. I've asked him to think about what's involved in developing
a source level debugger with KCC. He's read many of the messages
you've sent me over the past few months. I feel that I'm not always
as responsive as I'd like to be with respect to KCC and your questions.
I would like Michael to become more associated with KCC and what we
want to do with it. His address is MSNYDER at CompuServe (replace
BEN with MSNYDER in the address). While I'll still have active
involvement, at some point you might start hearing from Michael more
than me. Feel free to send messages to Michael, myself or both of us.
Benny
cc: msnyder
12-Jul-89 12:13:49-PDT,1042;001000000001
Mail-From: KLH created at 12-Jul-89 12:13:25
Date: Wed, 12 Jul 89 12:13:25 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Michael Snyder
To: msnyder@csi.compuserve.com
cc: BEN@csi.compuserve.com, KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5621-3695"@CompuServe.COM>
Message-ID: <12509459508.24.KLH@SRI-NIC.ARPA>
Ken -- I'd like to introduce Michael Snyder. Michael is CompuServe's
compiler engineer. He's recently been looking at GNU C on our VMS
system. I've asked him to think about what's involved in developing
a source level debugger with KCC. He's read many of the messages
you've sent me over the past few months.
Fine, this message should check out the address; could you send me
a confirming response just so we know it all works?
By the way, do you already have any PDP-10 source level debuggers,
i.e. is there any precedent in terms of symtab format etc, or will this
be more or less completely from scratch? Are you thinking of adapting
GDB? Just curious.
--Ken
-------
12-Jul-89 19:44:47-PDT,1365;001000000005
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 12 Jul 89 19:44:29 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA04219; Wed, 12 Jul 89 22:44:18 EDT
Date: 12 Jul 89 22:25:19 EDT
From: <MSNYDER@csi.compuserve.com>
To: Ken Harrenstien <KLH@sri-nic.arpa>
Subject: Re: Re: Michael Snyder
Message-Id: <"CSI 5622-5915"@CompuServe.COM>
Ken,
Hi, this is Michael Snyder; if you're reading this (and you are),
then everything checks out E-mail wise.
No, we don't have any PDP-10 source level debuggers, nor are we
aware of any. Can you suggest any leads? If not, yes, we will be
developing one from scratch, and yes, I was thinking of borrowing
as heavily as possible from GNU gdb. We also have sources for DDT,
to help with the low le
w(er, don't know exactly what happened there)
to help with the low level part.
I myself am almost totally unfamiliar with DEC operating systems or
architectures; I just finished my masters in CS at OSU, where the OS
of choice is UN*X. I was very pleased in reading up on KCC to see that
a great deal of effort has been made to make it emulate a UN*X
programming environment. Not that I'd be calling myself a UNIX guru
either, now; I come from an MS/DOS background before school.
Best,
Michael
13-Jul-89 07:34:59-PDT,1267;001000000011
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 07:32:15 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA16674; Thu, 13 Jul 89 10:12:14 -0400
Date: 13 Jul 89 09:55:55 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: KCC, GNU, ELLE
Message-Id: <"CSI 5623-1404"@CompuServe.COM>
Ken,
When I get around to seriously working on a DEC-10 c source debugger,
it's gonna need to be able to pull source code files back and forth thru
memory for display, and I'll probably find that keeping them entirely in
memory is undesireable. I wonder, do you think some of the routines in
ELLE that allow it to edit large files with small buffers would be
adaptable? When do we get to try compiling ELLE here?
Yesterday I tried exercising KCC by porting over the GNU version of
grep; only serious problems were name collisions caused by 1) long global
names in the source code and 2) functions that were duplicated in your
library. Once those were massaged away, it compiled and linked, but on
running, got an error msg from realloc(). I'll investigate more today.
I'm really impressed that I got as far as I did!
Michael
13-Jul-89 17:50:50-PDT,1913;001000000001
Mail-From: KLH created at 13-Jul-89 17:50:46
Date: Thu, 13 Jul 89 17:50:46 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC, GNU, ELLE
To: MSNYDER@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5623-1404"@CompuServe.COM>
Message-ID: <12509783066.24.KLH@SRI-NIC.ARPA>
I wonder, do you think some of the routines in
ELLE that allow it to edit large files with small buffers would be
adaptable? When do we get to try compiling ELLE here?
That would be possible. The buffer code is modular to the point of
being a separate package, although it hasn't to my knowledge been used
outside of ELLE. However, since the debugger will presumably only need
to read the text, not edit it, much of the complexity may be unnecessary.
ELLE can't be run on TOPS-10 until the runtime library is further enhanced;
the major thing missing is random-access file I/O.
I could arrange to send you the TAR distribution, however, so you
could play with it on some other machine and look at the source. It
is 780Kb which at 2K/minute would take about 6 to 7 hours to kermit over.
Want it?
Yesterday I tried exercising KCC by porting over the GNU version of
grep; only serious problems were name collisions caused by 1) long global
names in the source code and 2) functions that were duplicated in your
library. Once those were massaged away, it compiled and linked, but on
running, got an error msg from realloc(). I'll investigate more today.
I'm really impressed that I got as far as I did!
Sounds good... I always get a kick out of porting stuff too. I hope
the realloc() error isn't a library bug -- let me know what you find.
One problem with GNU software, as you've noticed, is that it isn't
always written with portability in mind, sometimes to the point of
relying on features specific to GNU CC. Sigh.
--Ken
-------
13-Jul-89 17:53:50-PDT,490;001000000001
Mail-From: KLH created at 13-Jul-89 17:53:45
Date: Thu, 13 Jul 89 17:53:44 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Letter?
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12509783606.24.KLH@SRI-NIC.ARPA>
Uh... I don't seem to have received any letter/check yet. Where did
you mail it to, and when should it have arrived? If it doesn't turn
up shortly you might have to think about cancelling it and issuing
another one. Strange.
--Ken
-------
13-Jul-89 19:42:22-PDT,729;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 19:42:17 PDT
Received: by saqqara.cis.ohio-state.edu (5.59/4.890612)
id AA02881; Thu, 13 Jul 89 22:42:00 EDT
Date: 13 Jul 89 22:10:40 EDT
From: <BEN@csi.compuserve.com>
To: <KLH@sri-nic.arpa>
Subject: Check
Message-Id: <"CSI 5623-5128"@CompuServe.COM>
We considered sending it Special Delivery or Overnight Express
or something like that and I said "nah". Now I wish I had've.
We mailed it to your address as specified in the contract, and
I believe it went out in either the Thursday A.M. or Friday A.M.
mail. Keep me posted... we'll cancel it and expedite another
check if necessary.
14-Jul-89 02:11:32-PDT,489;001000000001
Mail-From: KLH created at 14-Jul-89 02:11:26
Date: Fri, 14 Jul 89 02:11:26 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Check
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5623-5128"@CompuServe.COM>
Message-ID: <12509874209.24.KLH@SRI-NIC.ARPA>
OK, thanks, I'll dig around at home (there are other people in that house
and it may have been put into the wrong box) and let you know whether
it turns up then or in the next few days...
-------
14-Jul-89 09:22:39-PDT,1235;001000000011
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 09:21:50 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA17143; Fri, 14 Jul 89 12:14:37 -0400
Date: 14 Jul 89 11:47:16 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: elle, kcc
Message-Id: <"CSI 5623-7295"@CompuServe.COM>
Ken,
Regarding ELLE, I'd certainly like to look at it; I can get stuff as
far as OSU's pyramid via FTP, much faster than 2400 baud, then make a TAR
tape and carry it back to Compuserve. No wait, that only works on the Vax.
Well, let's wait until KCC's libraries can support it, anyhow.
One more question on KCC: while trying to track the realloc() behavior,
I had occasion to define away the word "void", hoping to make all symbols
global to ease the use of DDT. I imediately noticed that, while the decl
void foo;
would compile and default to int (as I believe it should -- aren't all
external declarations int by default?) the almost pathological decl
foo;
would not. I had the impression that the above was still a valid decl,
even if not good practice. Am I mistaken?
Michael
14-Jul-89 10:47:41-PDT,1494;001000000011
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 10:46:26 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA17116; Fri, 14 Jul 89 12:14:24 -0400
Date: 14 Jul 89 11:38:06 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: Ken Harrenstien <KLH@sri-nic.arpa>
Subject: Re: Re: KCC, GNU, ELLE
Message-Id: <"CSI 5623-7224"@CompuServe.COM>
Ken,
Re: GNU software and portability -- I don't agree at all! True,
they tend to make use of the special gcc features, but in my experience
so far, they hide those uses in #ifdefs so that the code will still compile
without gcc. I was able to compile (but alas, not run) all of gcc with
the Vax C compiler.
Re: realloc() in libc -- what it boils down to is, it seems that the
pointer sent to realloc() must be a char pointer. Any other type (well,
void and int are all I've tried) cause realloc() to choke with a message
"tried to reallocate invalid block". free() also chokes on 'em. Sample:
main()
{ foo = malloc(32); /* works ok, ignore warning */
free(foo); /* free chokes unless char *foo; */
}
This fails if foo is a pointer to void or int. Succeeds if foo is char *.
I suppose a cast would work around it, but many programs appear to call
malloc-related functions without casts...
If it helps, I noted with DDT that the pointer recieved by free had
bits 0-17 zeroed if the type was not char.
Michael
14-Jul-89 13:48:41-PDT,581;001000000001
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 11:39:32 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA20089; Fri, 14 Jul 89 14:39:30 -0400
Date: 14 Jul 89 14:18:32 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: void ::= static
Message-Id: <"CSI 5623-8249"@CompuServe.COM>
Ken,
Please excuse the previous message, which became garbled due to
a lack of coffee. For every occurance of the string "void",
substitute "static".
Michael
14-Jul-89 14:49:20-PDT,796;001000000001
Mail-From: KLH created at 14-Jul-89 14:14:58
Date: Fri, 14 Jul 89 14:14:58 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: elle, kcc
To: MSNYDER@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5623-7295"@CompuServe.COM>
Message-ID: <12510005924.24.KLH@SRI-NIC.ARPA>
Well, let's wait until KCC's libraries can support it, anyhow.
That won't happen until around mid-Sept if everything goes OK. If you
want to look at it or bring it up elsewhere before then, you can get
at it via FTP to blackjack.sri.com (login as anonymous, make sure you
use 8-bit transfer mode, and ask for "dist/elle/elle.tar41b").
The behavior with respect to "static foo;" and "foo;" is correct.
The dpANS is actually more strict in this regard than KCC currently is.
-------
14-Jul-89 14:54:56-PDT,1292;001000000001
Mail-From: KLH created at 14-Jul-89 14:27:18
Date: Fri, 14 Jul 89 14:27:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Re: KCC, GNU, ELLE
To: MSNYDER@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5623-7224"@CompuServe.COM>
Message-ID: <12510008168.24.KLH@SRI-NIC.ARPA>
Re: realloc() in libc -- what it boils down to is, it seems that the
pointer sent to realloc() must be a char pointer.
Right.
This fails if foo is a pointer to void or int. Succeeds if foo is char *.
KCC is not supposed to support "pointer to void" (a X3J11 committee invention)
yet so I'm surprised that attempt would even compile.
I suppose a cast would work around it, but many programs appear to call
malloc-related functions without casts...
A cast is REQUIRED. Any program that either (1) fails to properly declare
the type of external functions like malloc(), or (2) calls functions with
arguments of the wrong type, is not portable. A good example of what I
meant about GNU.
If it helps, I noted with DDT that the pointer recieved by free had
bits 0-17 zeroed if the type was not char.
A cast to (int *) has this effect.
See sec 4.7 of H&S re "Implicit Declarations" or "malloc" in C:LIBC.DOC
for more insight.
-------
16-Jul-89 07:10:01-PDT,464;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sun, 16 Jul 89 07:09:54 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA10542; Sat, 15 Jul 89 11:10:55 -0400
Date: 15 Jul 89 10:57:52 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Any check today?
Message-Id: <"CSI 5623-10304"@CompuServe.COM>
It's Saturday. Did the check perhaps come in the mail today?
17-Jul-89 10:28:16-PDT,845;001000000011
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 17 Jul 89 10:27:07 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA24056; Mon, 17 Jul 89 12:12:47 -0400
Date: 17 Jul 89 11:37:47 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: grep works!
Message-Id: <"CSI 5624-3325"@CompuServe.COM>
Ken,
Thanks for the clarifications. Added a cast to the arguments of
realloc and free, and grep now works beautifully. Regular expression
search is nice, and it's twice as fast as findit on plain strings.
But, wild card file specs in the command line don't work. I'm guessing
that TOPS-20 expanded them for you in the command line-to-argv[]
transition as unix does, but TOPS-10 doesn't. Any thoughts?
Thanks,
Michael
17-Jul-89 11:27:59-PDT,723;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 17 Jul 89 11:27:25 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA26383; Mon, 17 Jul 89 14:17:24 -0400
Date: 17 Jul 89 13:55:04 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Comparing apples and oranges
Message-Id: <"CSI 5624-4366"@CompuServe.COM>
Ken -- I'm advised that the time returned by the RUNTIM call has
(or possibly has) no relation to wallclock time. If this is the
case, then there is no basis for the comparison that I was trying
to make. Therefore, please ignore the message about the DHRYSTONE
program except the part about the check.
17-Jul-89 11:28:47-PDT,1255;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Mon, 17 Jul 89 11:28:06 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890612)
id AA26273; Mon, 17 Jul 89 14:15:41 -0400
Date: 17 Jul 89 13:42:14 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: DHRYSTONE program
Message-Id: <"CSI 5624-4260"@CompuServe.COM>
Ken --- Have you received your check yet? They'll (the checkprinters)
print checks again late this week, and I'll have them cut you another
one if you haven't received yours yet.
Re KCC. I have a troublesome DHRYSTONE program that seems to
give significantly better performance indicators on other machines
than with KCC on the 10s. Perhaps, sometime, you could take a look
at it and see if you see anything that could be improved upon.
The programs are found as EXH:[375,2]DRYSTN.C and TIME.C. The TIME.C
module makes a RUNTIM call to get the job's runtime instead of using
the wall clock time and causing all the other users on the system to
influence the results. I've worked on it a bit, but have not made
any significant improvement. The originals are found as D.C and T.C
in that same PPN on structure EXH:.
cc: msnyder
17-Jul-89 12:44:20-PDT,486;001000000001
Mail-From: KLH created at 17-Jul-89 12:44:06
Date: Mon, 17 Jul 89 12:44:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Mystery Solved!
To: ben@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12510775814.21.KLH@SRI-NIC.ARPA>
The letter arrived this weekend, and it turns out that the zip code on
the envelope was 84025 instead of 94025, so it must have taken quite a
detour! Same typo on the letterhead and check. Better luck next
time...
--Ken
-------
17-Jul-89 13:21:40-PDT,1069;001000000001
Mail-From: KLH created at 17-Jul-89 13:21:32
Date: Mon, 17 Jul 89 13:21:32 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: grep works!
To: MSNYDER@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5624-3325"@CompuServe.COM>
Message-ID: <12510782628.21.KLH@SRI-NIC.ARPA>
Good to know that grep works!
But, wild card file specs in the command line don't work. I'm guessing
that TOPS-20 expanded them for you in the command line-to-argv[]
transition as unix does, but TOPS-10 doesn't. Any thoughts?
Yes, on TOPS-20 command line arguments are normally expanded by
_runtm() in CUSYS:URT.C. This was easy as GTJFN% permitted the system
to do the file matching for you. There is no real problem with adding
similar expansion for TOPS-10, other than that the code for
reading in a UFD and scanning it by hand will represent another
increase in the size of the runtime code for all TOPS-10 C programs.
Ben is concerned about memory usage, but perhaps that is just a problem
for impure core rather than code.
-------
17-Jul-89 13:28:07-PDT,588;001000000001
Mail-From: KLH created at 17-Jul-89 13:28:05
Date: Mon, 17 Jul 89 13:28:04 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: DHRYSTONE program
To: BEN@csi.compuserve.com
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5624-4260"@CompuServe.COM>
Message-ID: <12510783820.21.KLH@SRI-NIC.ARPA>
I got your disclaimer message, but I'm wondering why you want wallclock
time at all for a benchmark program. That is, since RUNTIM returns the
CPU time a job uses, that would seem to be the appropriate thing.
The clock() function in the C library returns this, by the way.
-------
19-Jul-89 08:34:34-PDT,1040;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Wed, 19 Jul 89 08:34:23 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890718)
id AA22557; Wed, 19 Jul 89 10:10:50 -0400
Date: 19 Jul 89 10:02:34 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Generated code
Message-Id: <"CSI 5624-14771"@CompuServe.COM>
Ken -- I'm glad you finally received your check. I apologize for the
zipcode foulup; I'll try to be more attentive next time. The secretary
responsible is hanging from a light pole outside. I think she's sorry too.
I was looking at code generated by KCC. Given the following code segment
in main(),
register i,j;
i = foo();
j = i * 2;
if (i>j) exit(0);
I notice some (what appears to be extraneous) 'pushing' going on as
register 1 and register 5 are saved. What are your thoughts on this?
BTW, KCC compared very favorably in performance comparison with BLISS
using the DHRYSTONE program.
cc: Michael Snyder
19-Jul-89 09:09:10-PDT,1382;001000000001
Mail-From: KLH created at 19-Jul-89 09:07:48
Date: Wed, 19 Jul 89 09:07:48 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Generated code
To: BEN@CSI.CompuServe.COM
cc: KLH@SRI-NIC.ARPA, msnyder@CSI.CompuServe.COM
In-Reply-To: <"CSI 5624-14771"@CompuServe.COM>
Message-ID: <12511260727.37.KLH@SRI-NIC.ARPA>
No problem, maybe you should take her down now...
I notice some (what appears to be extraneous) 'pushing' going on as
register 1 and register 5 are saved. What are your thoughts on this?
This illustrates the maxim that assembler programmers should never peek
at the output of a compiler, unless they have very strong constitutions.
(The same could probably be said about restaurant kitchens.)
KCC has an incredibly baroque (pun intended) peephole optimizer that
attempts to compensate for a rather stupid code generator. Most of
the time it is surprisingly successful. I have nibbled around the
peepholer, instrumented it, and modularized it somewhat, but it still
remains the last large repository of original filthy code. If I have
some leftover time I'd like to hack at this, but for the nonce the
motto must remain "first make it work, then make it fast (or small)".
Thanks for the news about BLISS comparison. Want to add special
optimization code that checks for compiling DHRYSTONE? Heh, heh.
--Ken
-------
20-Jul-89 08:47:40-PDT,563;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 20 Jul 89 08:41:10 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890718)
id AA26648; Thu, 20 Jul 89 11:40:56 -0400
Date: 20 Jul 89 11:04:50 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Passing functions as parameters
Message-Id: <"CSI 5625-1796"@CompuServe.COM>
Ken -- KCC doesn't allow passing functions as parameters. You know
about this, and the ANSI upgrade will take care of it will it not?
Thanks!
20-Jul-89 16:32:37-PDT,598;001000000001
Mail-From: KLH created at 20-Jul-89 16:32:28
Date: Thu, 20 Jul 89 16:32:28 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Passing functions as parameters
To: BEN@CSI.CompuServe.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5625-1796"@CompuServe.COM>
Message-ID: <12511603820.27.KLH@SRI-NIC.ARPA>
KCC allows passing pointers to functions. The dpANS adds a little
more syntactic sugar but the result is exactly the same. If you send
me a sample of the case you're concerned with, I can tell you for
sure what the problem is and whether it will be valid ANSI syntax.
-------
21-Jul-89 14:20:45-PDT,1696;001000000001
Mail-From: KLH created at 21-Jul-89 14:20:24
Date: Fri, 21 Jul 89 14:20:23 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Status report
To: ben@CSI.CompuServe.COM
cc: klh@SRI-NIC.ARPA
Message-ID: <12511841920.27.KLH@SRI-NIC.ARPA>
The new dpANS declaration parsing (including arbitrary placement of
keywords, type qualifiers, and function prototypes) is now in place,
as are the new linkage conventions. The latter are different enough
that some things that used to work will no longer work; however they
are also necessary if static variable names are going to be uniquized
internally. Even without explicitly using prototypes, the additional
arg check warnings have already helped me find some bugs. I am now
almost finished with upgrading the expression parser -- there are many
annoyingly subtle changes in grammar and type handling, especially
with type qualifiers.
I should warn you that Aug 15 is going to be pretty tight, meaning
that the result will not be as thoroughly tested as I would like. A
more worrisome deadline is the fact that the KL I'm using to test the
work on is slated to go away at the end of August. In a couple of
weeks I'll know whether I'm over the hump or not.
I've come up with a number of ways to reduce the amount of impure
memory that the compiler uses; for example, I can reduce the storage
for symbols by perhaps a third, compact the parse-tree mechanism
somewhat, make more things dynamic instead of static, and so on.
However, given the time pressure and the after-the-fact nature of this
objective, those are pretty low priority at the moment. We can pursue
them later if you still want to.
--Ken
-------
27-Jul-89 17:15:22-PDT,2431;001000000001
Mail-From: KLH created at 27-Jul-89 17:15:17
Date: Thu, 27 Jul 89 17:15:17 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC Status and questions
To: ben@csi.compuserve.com, msnyder@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12513446621.34.KLH@SRI-NIC.ARPA>
The compiler upgrade to dpANS is now more or less complete. This
includes external name checking, and uniquizing of all static variable
and function names by prefixing them with a '%' and munching the names
as little as possible. I'm surprised how well it works. The stricter
linkage rules and function prototype checks have uncovered a fair
number of loose ends, so the improvements are already paying off.
There is only one hole that I know of: I cannot, at the moment, guarantee
that code dealing with "volatile" objects will not be optimized away; this
is mainly due to the teenage mutant nature of the peepholer. I've pegged
it as a low-priority non-essential for the time being (be sure to yell if
this is important).
I'm now working on the C library. There are mostly lots of little
things that need to be changed to match the dpANS wording.
There are a few places where I need some input:
GETENV()
There seems to be no way to implement this on a generic TOPS-10,
but on CSI I was thinking of using "global command variables" for setting
and reading environment names. This scheme would require a separate
command variable for each name (eg TERM, HOME, PATH), with a special
prefix (such as C$) to avoid conflicts with non-C programs. Thus, to
set your terminal type in a way that TERMCAP programs will understand,
you would do something like
SET DEF C$TERM :== Beeshit-100
Is this reasonable? If so, what prefix would you prefer? Alternative
ideas?
SYSTEM()
This function is rather problematical on a system without
inferior processes. Unless you have some ideas on how this could do
something useful, I'm going to leave it a no-op for now.
STDIO:
Have you thought any more about the suggestions I made for
resolving the byte-size and file length problems?
LOCALE, WCHAR_T, MB*()
I could not think of anything meaningful for these facilities
to do. Thus, the only supported locales are "C" and "" (same); also,
wide chars and multibyte chars are the same as normal chars. I hope you
didn't have thoughts of making them be something else...?
Thanks,
--Ken
-------
28-Jul-89 11:02:23-PDT,1354;001000000015
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 28 Jul 89 10:52:34 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA07917; Fri, 28 Jul 89 13:43:16 -0400
Date: 28 Jul 89 13:11:06 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: system()
Message-Id: <"CSI 5627-8103"@CompuServe.COM>
Ken,
I've been thinking about the issue of system() calls myself,
partly because somebody sent me a version of make that's supposed
to work with kcc_20. Here's my idea. You already have the concept
of using tmpcor to pass the argument line to a chained process, right?
How about, in case the parent process wants to return after the child
finishes, the parent will save an image of itself in a temporary file
including it's state (all variables values etc.) and if necessary, a
jump to the return address of the system() call. The name of the
temporary will be included in the tmpcor file somewhere. The child,
realizing that it's argument list came thru tmpcor, will look for such
a file name and, finding it, chain back to it when the child is finished.
I know there's probably thorny issues hidden in there somewhere
(and I still don't know much about this architecture), but do you think
it's a possibility?
Michael
28-Jul-89 13:13:50-PDT,1436;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 28 Jul 89 13:13:09 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA12462; Fri, 28 Jul 89 16:12:58 -0400
Date: 28 Jul 89 15:57:01 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: update
Message-Id: <"CSI 5627-9336"@CompuServe.COM>
to: Ken
fr: Benny
cc: MSnyder
Your status report sounds great! We (the corporate we)
are eagerly awaiting dpANS KCC.
I still don't know what to do about the byte-size problems.
I'll try and offer something in the next few days.
Your handling of the other issues seems fine. We looking them
over and will let you know asap if we see any problems.
You might want to incorporate wild card handling into KCC.
I've made a stab at it, and the only problems remaining
are in our libraries. Essentially, I've written BLISS
routines to emulate wfopen, wfname, and wfnext. URT.C
has been changed just a bit to use my routines and to allocate
memory for the returned names. Check [311,70016]URT.C and WILDF.BLI.
It's not working yet, but almost. Look at [311,2]OUT.C. Sorry
for the lack of explanatory comments in WILDF.BLI, but, well,
there's no good excuse is there?
As soon as it does start working, we'll have a working GREP.
That's in [311,4] and is made up of 4 or 5 files.
Until later...
28-Jul-89 15:32:31-PDT,681;001000000001
Mail-From: KLH created at 28-Jul-89 15:32:29
Date: Fri, 28 Jul 89 15:32:29 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: system()
To: MSNYDER@CSI.CompuServe.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5627-8103"@CompuServe.COM>
Message-ID: <12513690052.43.KLH@SRI-NIC.ARPA>
Glug. I don't know if that approach would work, but if you are willing
to go to that much trouble, I think it would be quite a bit easier to open
a PTY (ie set up a pipe to a second job) and feed in commands. The tricky
part is ensuring that this second job is logged into the same account and
UFD; may require an OS mod. It would be worthwhile in my opinion, though.
-------
28-Jul-89 15:40:15-PDT,685;001000000001
Mail-From: KLH created at 28-Jul-89 15:40:08
Date: Fri, 28 Jul 89 15:40:08 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: update
To: BEN@CSI.CompuServe.COM
cc: msnyder@CSI.CompuServe.COM, KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5627-9336"@CompuServe.COM>
Message-ID: <12513691444.43.KLH@SRI-NIC.ARPA>
You might want to incorporate wild card handling into KCC.
I'll look into it after the dpANS upgrade; even in the short time
I was installing KCC, I missed the feature. Of course incorporation
would be easier if the wf-() routines were already in C. Did you use
BLISS out of familiarity & time pressure, or just testing language
interoperability?
-------
29-Jul-89 00:36:28-PDT,896;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Sat, 29 Jul 89 00:36:02 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA20306; Fri, 28 Jul 89 21:11:15 -0400
Date: 28 Jul 89 20:54:11 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Why BLISS
Message-Id: <"CSI 5627-10340"@CompuServe.COM>
I used BLISS because the wild-card facility was added to a BLISS
library that we use. Someone was putting the finishing touches
on that facility about the time that Michael Snyder tried and
almost succeeded in compiling GNU GREP under KCC. About all that
didn't work was the wildcard file scanning. We took a look and
decided that this would be a good use for the BLISS stuff, and
since these routines take no more than one argument, the argument
ordering is not a problem.
cc: MSnyder
31-Jul-89 16:24:54-PDT,1568;001000000001
Mail-From: KLH created at 31-Jul-89 16:23:54
Date: Mon, 31 Jul 89 16:23:54 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: CSI PI query
To: ben@csi.compuserve.com, msnyder@csi.compuserve.com
cc: klh@SRI-NIC.ARPA
Message-ID: <12514485845.30.KLH@SRI-NIC.ARPA>
I was looking again at COUGH.USR to get an idea of what would be involved
with fleshing out signal(). After a while I realized what was missing --
there is no way documented to trigger an arbitrary interrupt channel.
Is there such a thing? If not, or if it can't be added, then I don't
think the existing Un*x-compatible mechanism can be preserved. This
mechanism does two things:
(1) permits all signals to be handled independently of each other
(2) suspends signal handling until a USYS (Un*x-syscall simulation)
routine is finished.
In order to implement this mechanism within a priority-level system, all
signals must have the same level, and the actual interrupt code must
get out of interrupt level as soon as possible -- and there must be a way
to re-trigger the interrupts later. Note also the existence of raise()
as part of the proposed ANSI standard.
Swamp warning: The whole issue of interrupts is extremely complex. We
could easily spend two months getting a full implementation of CSI
sigvec() designed and working. For more background, you can look at
the files SIGNAL.DOC, CODSIG.DOC, CUSYS:SIGVEC.C, and CUSYS:SIGDAT.C.
If you aren't interested in Un*x simulation then I really have no idea
what your vision of signal() is.
--Ken
-------
3-Aug-89 06:56:17-PDT,1040;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 3 Aug 89 06:56:09 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA04881; Thu, 3 Aug 89 09:39:18 -0400
Date: 03 Aug 89 09:05:14 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: KCC Status
Message-Id: <"CSI 5629-914"@CompuServe.COM>
That all sounds reasonable. The idea of a prefix for getenv() seems a
little awkward, but he's right that it's the only way that would work
because we don't separate the concepts of "defined commands" and
"variables" like we should.
The byte size problem is simply that there's no way to know whether a
file contains 7, 8, 9, or 36-bit bytes or whatever, a problem especially
in handling "b" files where C wants to use 9-bit bytes, precluding the
reading of 8-bit bytes without source-level changes. I'm trying to come
up with a reasonably clean way to implement that.
GSB for BEN 08:44 EDT 03-Aug-89 Message 5629-681 forwarded by
3-Aug-89 14:27:11-PDT,524;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu ([128.146.8.98]) by SRI-NIC.ARPA with TCP; Thu, 3 Aug 89 14:15:40 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA16234; Thu, 3 Aug 89 17:11:14 -0400
Date: 03 Aug 89 16:45:34 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: ~sbrk()
Message-Id: <"CSI 5629-4926"@CompuServe.COM>
Ken -- How do I deallocate memory allocated with sbrk()? I just took
a quick look and couldn't find it. Thanks.
3-Aug-89 14:49:54-PDT,1566;001000000001
Mail-From: KLH created at 3-Aug-89 14:42:06
Date: Thu, 3 Aug 89 14:42:06 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: ~sbrk()
To: BEN@CSI.CompuServe.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5629-4926"@CompuServe.COM>
Message-ID: <12515253745.53.KLH@SRI-NIC.ARPA>
Ken -- How do I deallocate memory allocated with sbrk()? I just took
a quick look and couldn't find it. Thanks.
You don't. (No wonder you couldn't find it!)
brk() is supposedly able to do this, but I've never seen it done in any
real program, because it would confuse sbrk() and malloc().
I have never seen any Unix program that actually freed any memory back
to the OS. At most, they use free() to release storage from malloc().
Since this was true even back when the kernel only swapped entire
impure segments, the situation is unlikely to ever change.
There is a BSD convention however which we could readily apply to KCC.
This would be to have malloc check the size of requests, and if the
size is an exact multiple of a page size, malloc would acquire a page-aligned
region of memory (independently of the normal linked chunk mechanism). free()
in turn will release those pages back to the OS.
This does require some inner knowledge on the part of the user program
and perhaps some extra hair to divvy up the insides of the pages;
however, the important thing is that the resulting code is fully
portable whether or not the C implementation follows this convention.
Would this accomplish what you want to do?
--Ken
-------
3-Aug-89 18:43:27-PDT,978;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Thu, 3 Aug 89 18:43:21 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA22151; Thu, 3 Aug 89 21:42:46 -0400
Date: 03 Aug 89 21:19:40 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: memory
Message-Id: <"CSI 5629-5893"@CompuServe.COM>
Ken -- In URT.C if the allocated memory for argv is insufficient,
then sbrk() is used to acquire more and the previous is copied to
the new. The previous is never freed however.
As I mentioned last week, we're messing with handling wildcards.
We've fixed a bug and I tried having a KCC program handle
[311,*]*.*. I ran out of memory. I don't know if the allocation
scheme that sbrk() uses would find it (I haven't looked into it
that deeply.), but I wanted to try freeing the old after copying
into the new.
I'll look into it more tomorrow. Thanks for the info.
Benny
4-Aug-89 08:36:59-PDT,1771;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by SRI-NIC.ARPA with TCP; Fri, 4 Aug 89 08:23:45 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA02072; Fri, 4 Aug 89 09:44:54 -0400
Date: 04 Aug 89 09:11:57 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: Miscellanea
Message-Id: <"CSI 5629-7022"@CompuServe.COM>
Ken -- this is probably backburner stuff, but I'd be interested in
any input you might offer. I'd like to get rid of the .MAC and .PRE
files left around after a compilation. I'd like to get rid of
the .MAC file optionally. [I'd like to have another debugging option
that causes DDT to be loaded too.]
We probably could add an option to MACRO to delete the source file after
assembly, and have KCC invoke MACRO with that option. Alternatively,
we could have KCC generate unique temporary files and feed them to
MACRO. Our other compilers go directly to .OBJ files. This might be
something we want to do at some point. I doubt that there's sufficient
funding in the current agreement to support that though.
On my whiteboard, I have listed 3 items that I'd like considered for
phase 3 work.
1 - Use our memory management routines.
2 - All I/O done with FILOPs and use extended channels.
3 - Provide support for DEC version numbers.
There will likely be more, and I've probably neglected to add some. I
offer all this only as FYI.
Your suggestion about applying the BSD convention of acquiring and freeing
page-aligned memory to KCC sounds interesting and may be worth doing. I
don't know the value of that. I'm inclined to leave that up to you.
Well, enough of this; have a fine weekend, and I'll type at you later.
cc: MSnyder
4-Aug-89 11:12:10-PDT,1820;001000000001
Mail-From: KLH created at 4-Aug-89 11:01:04
Date: Fri, 4 Aug 89 11:01:03 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: memory
To: BEN@CSI.CompuServe.COM
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5629-5893"@CompuServe.COM>
Message-ID: <12515475648.62.KLH@SRI-NIC.ARPA>
We've fixed a bug and I tried having a KCC program handle
[311,*]*.*. I ran out of memory. I don't know if the allocation
scheme that sbrk() uses would find it (I haven't looked into it
that deeply.), but I wanted to try freeing the old after copying
into the new.
No, it won't find it. This is a defect in the way wildcards were
originally set up -- it should first gobble storage for all strings,
and then allocate storage for the argv array, the same way it does for
command line and indirect files.
However, even with that, I would imagine that [311,*]*.* must be an
awful lot of filenames, and the simple-minded Unix scheme breaks down
there (it won't work on many Unix systems either because the argv
space is actually in the kernel temporarily, and is far more limited
than it is for KCC). TOPS-20's wildcard solution is more general at
the expense of requiring each program to do explicit wildcard testing
looping.
What this basically means is: if you are writing a program to do things
like grovelling over the file system, it will have to expand wildcards
itself on the fly, and you can quote those arguments with "". All other
programs can simply use argv. Attempts to force an "other program" to
do FS grovelling will have to be broken up into smaller requests.
Note that on systems where system() works, the latter could be done
by invoking a general-purpose splitter that invokes the real program on
automatically split chunks of filenames.
--Ken
-------
4-Aug-89 11:52:42-PDT,2650;001000000001
Mail-From: KLH created at 4-Aug-89 11:52:08
Date: Fri, 4 Aug 89 11:52:07 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Miscellanea
To: BEN@CSI.CompuServe.COM
cc: msnyder@CSI.CompuServe.COM, KLH@SRI-NIC.ARPA
In-Reply-To: <"CSI 5629-7022"@CompuServe.COM>
Message-ID: <12515484943.62.KLH@SRI-NIC.ARPA>
Deleting .MAC and .PRE files:
Yeah, they are a pain aren't they. On T20 KCC can flush them
itself because the assembler is invoked as a subprocess. My original
suggestion [1] was to invoke a simple program via TMPCOR/RUN to come
between the invocation of MACRO and LINK, which would simply delete
those files. This would be portable to other T10s and can even be
tested on T20. However, your idea [2] of a switch in MACRO would
certainly be trivial from KCC's viewpoint. The notion [3] of inventing
nnnFOO.* filenames and invoking MACRO on those is also possible and
probably no harder than [1] would be, but won't they tend to pile up
and consume quota during the lifetime of a job?
Direct .REL file generation:
Yeah, I've toyed with this idea for a long time, but on balance
it's never seemed worth the effort it would take. The original primary
motivation was to permit generating REL blocks with long SIXBIT symbols.
The major roadblock is deciding what to do about asm(). The time required
to run the assembler has never been much of a factor (especially with FAIL)
and once the MAC/PRE files are taken care of, I suspect you won't notice
it any more.
DDT debugging option:
There's no switch for this on Unix because the debugger is a superior
process, but we can invent one. It would be purely a matter of convenience
since you should already be able to do this by using the -L= switch at
an appropriate point in the command line. Use that to figure out what works.
Phase 3 stuff:
Yes, we need to decide on the priorities soon, since time is
going to be quite short. Your list is a good start. I'd like to
reserve comment for a little bit until we have a more complete
picture. Here are the things I've been worrying about, with a rough
estimate of importance (A-E) and difficulty (9-0):
A-6 Fix up I/O so random-access and update mode work.
C-9 signal()
C-3 ioctl() support for TTY:
D-5 Reduce compiler memory requirements
D-7 Improve T10 memory layout (if system has enough hooks)
Please add as many things to your list as you can think of. I'll go
over my notes for others. Then I can give you my own opinions on
their importance and how much effort they'll take, and with that info
you can decide which of them you want done.
--Ken
-------
7-Aug-89 09:13:39-PDT,2881;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Mon, 7 Aug 89 09:12:48 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA28464; Mon, 7 Aug 89 12:12:42 -0400
Date: 07 Aug 89 11:32:52 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@SRI-NIC.ARPA>
Subject: stuff about interrupts
Message-Id: <"CSI 5630-3733"@CompuServe.COM>
Ken -- FYI. From our monitor guy.
Benny
-----------------------------------------------------------------------
Thanks. I haven't finished reading the .docs and .c's yet, but here
is some information.
We have nothing like the TENEX concept of "interrupting in the middle
of a monitor call." Interrupts during monitor calls are handled much
like hardware instructions, with one of three results:
(1) The call "backs out" without damaging anything, and the PC remains
(really, is backed up to) the address of the call. Upon returning
from the interrupt, the call is re-executed.
(2) The call cleans up and adjusts its arguments in such a way that it
can continue if the call is re-executed (analogous to BLT or
MOVSLJ), and the interrupt PC again points to the call.
(3) The call completes before the interrupt is granted, and the PC
points to the appropriate return (skip or not) from the call.
There a few calls that are uninterruptible, like an OUTSTR blocked in
the middle of a string (TRMOP 22, on the other hand, is interruptible
because its arguments were designed to allow interrupts--it's allowed
to adjust its argument block, which can point to an arbitrary
character position).
A "sleep"-type monitor call is considered complete if interrupted--it
returns prematurely--because it can't change its register contents.
You can disable individual interrupt channels for interlocking or
whatever. Originally, disabling a channel caused events to be
discarded rather than held pending, but that's been corrected.
We don't have the ability to generate interrupts on arbitrary
channels. The only directly invokable event is "wake," octal 120
(probably newer than the doc.) that's intended mainly to allow jobs to
poke one another.
It sounds like it might be useful to have an alternative architecture
that allows equal-priority events to interrupt one another
(essentially, to do away with the priority structure and treat each
event independently). But I get the impression that standard C wants
to go farther than that, to do away with the concept of an "interrupt
in progress" state, and I'm not sure I understand the usefulness of
such a concept.
Does UNIX and C consider an interrupt function to be atomic with
respect to its interrupt event? If a signal calls foo(), is another
occurrence of the same event supposed to recursively call foo()?
7-Aug-89 17:41:06-PDT,3549;001000000001
Mail-From: KLH created at 7-Aug-89 17:40:55
Date: Mon, 7 Aug 89 17:40:55 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: stuff about interrupts
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5630-3733"@CompuServe.COM>
Message-ID: <12516334872.21.KLH@NIC.DDN.MIL>
The trouble isn't one of interrupting TOPS-10 system calls (thank
goodness it backs out of them properly!), it's interrupting USYS calls,
which emulate Unix system calls. Such interrupts have to be deferred
until the end of the USYS routine, otherwise no interrupt handler can
ever use any USYS call. That is, no read(), write(), ioctl(), or even
signal() itself. This makes life much harder.
It sounds like it might be useful to have an alternative architecture
that allows equal-priority events to interrupt one another
(essentially, to do away with the priority structure and treat each
event independently). But I get the impression that standard C wants
to go farther than that, to do away with the concept of an "interrupt
in progress" state, and I'm not sure I understand the usefulness of
such a concept.
The C dpANS actually says very little about signals. It is possible
for many different kinds of implementations to satisfy the
"requirements" and thus signal() and raise() are basically almost
completely implementation dependent; as a specification, it's useless
for portability. My major motivation for wanting to simulate the Unix
environment is to allow for easy porting of software to and from Unix,
or at least POSIX-compatible systems. If you decide not to care about
that then the field is open to whatever you want to do. As you might
imagine, though, at the NIC we have found it quite handy to be
able to run our Internet user services and DB software (with TTY
interrupts, etc) on both TOPS-20 and UNIX with no source munging.
BSD Unix does have the concept of "interrupt in progress" in the sense
that normally a signal is blocked (masked off) while its handler is
processing that signal. Further instances of that signal will be
deferred until the handler returns. Other signals may or may not
interrupt that handler; normally they will unless the handler has
deferred those too. It is possible, given N signal bits, to simulate
the effect of N different priority levels, because each signal has a
mask word associated with it. It is also possible to have a non-transitive
scheme where A can interrupt B which can interrupt C which can interrupt A.
Does UNIX and C consider an interrupt function to be atomic with
respect to its interrupt event? If a signal calls foo(), is another
occurrence of the same event supposed to recursively call foo()?
C calls this "implementation-defined". UNIX traditionally has NOT been
atomic; that is, if you set it up right, it is certainly possible for
a second interrupt to recursively call its handler.
While BSD has the most flexible interrupt setup of the Unix systems
I'm familiar with, it is not necessary to emulate this fully (what I
did for TOPS-20 is moderate overkill) -- but it is good insurance.
Vanilla Unix is much worse, very crude; POSIX is supposed to improve
on this.
If you don't have any way to trigger interrupts, then emulating Unix is
going to be difficult. Just doing raise() correctly will require some
work. I have an idea for this, but will have to think about it
some more to see if it solves the race condition problems.
-------
10-Aug-89 18:32:42-PDT,1915;001000000001
Mail-From: KLH created at 10-Aug-89 18:32:36
Date: Thu, 10 Aug 89 18:32:36 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: KCC status (& usual qs)
To: ben@csi.compuserve.com, msnyder@csi.compuserve.com
cc: klh@NIC.DDN.MIL
Message-ID: <12517130712.29.KLH@NIC.DDN.MIL>
KCC is looking pretty solid at this point. What I'm going to do now is
attempt to build another TOPS-10 version here and make sure it can
recompile itself. When I fix the problems with that, I'll start
copying the new sources over.
However, I'd like to do this without flushing any of the old files, just
in case there are unexpected problems. Rather than use another set of
directories for the new KCC, I'd like it if you could just copy the
existing sources to a safe place (set up some other dirs of your own,
for example) so I don't have to worry about what I clobber in [311,47xx].
Let me know when it's safe to proceed.
One question I have to ask is what information you currently have about
ANSI C. Do you have a copy of the 7-Dec-88 draft? What references are
you using?
I encountered several surprises while recompiling existing code under
the dpANS rules -- various error messages and warnings that on the
surface seemed unfounded, but which after some careful re-reading
were verified to be consequences of the new regime. I figure that if
*I* am surprised, then the odds are good that you will be, too.
Also, while I am making some changes in the KCC user documentation,
I'm trying to avoid turning it into a C manual, and concentrating on
just the implementation-dependent behavior or details. Things are
different enough from the old KCC that I decided not to provide a
switch to permit full backwards compatibility -- this would have been
quite difficult, and mostly served to perpetuate buggy user code.
Have you come up with any other things for your list?
--Ken
-------
11-Aug-89 13:55:30-PDT,1040;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Fri, 11 Aug 89 13:55:12 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA21772; Fri, 11 Aug 89 16:54:57 -0400
Date: 11 Aug 89 16:02:46 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: KCC
Message-Id: <"CSI 5632-9403"@CompuServe.COM>
Ken -- I guess I'd better get my wish list ready for phase 3. It
seems to be rapidly approaching.
I've not touched your sources in [311,47xx]. Right after you uploaded
them, I copied them to [311,700xx] where I've played with them a bit.
I have a COM file in [,70003] called BUILD.COM that will either build
quick (-q) or not. I seem to recall having another parameter that
allows me to build a compiler that will recompile itself or not (by
defining MAXNODE). Anyway, you might look at it.
These sources in [311,700xx] have not changed substantially from
your original uploads. Unless you object, I'll let these suffice
cc: MSnyder
12-Aug-89 08:14:35-PDT,1061;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Sat, 12 Aug 89 08:14:32 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA14797; Sat, 12 Aug 89 11:12:33 -0400
Date: 12 Aug 89 10:49:46 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Char pointer question
Message-Id: <"CSI 5632-10832"@CompuServe.COM>
Ken -- An associate of mine had the following concern about ANSI C
compilers on 36-bit machines. I'll try and paraphrase it.
Somewhere in the proposed standard it says that a char pointer that
becomes void can be made back into a char pointer without losing any
information. The worry was about pointers to non-word-aligned character
data. Are there any anomalies with respect to this and non-9-bit character
pointers? The example cited in our hallway discussion had to do
with passing a pointer as an argument to a function and that function
using the pointer as a void one. I'm not certain I've explained this
well enough.
-- Benny
12-Aug-89 16:19:12-PDT,2486;001000000001
Mail-From: KLH created at 12-Aug-89 16:19:09
Date: Sat, 12 Aug 89 16:19:09 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Char pointer question
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5632-10832"@CompuServe.COM>
Message-ID: <12517630707.60.KLH@NIC.DDN.MIL>
Well, the standard says that (void *) is supposed to have exactly the
same representation as (char *).
The motivation for its invention, as best as I can gather, was to
have a pointer type that would be "invisibly" converted to any other
pointer type without complaint. At first they also thought it could
actually have a different, more "universal", representation, but this
turned out to lead to some logical inconsistencies with other parts of
the standard so that got flushed, considerably detracting from the appeal
the idea might otherwise have had.
Because PDP-10 pointers always carry their size info with them, I
would have liked to use (void *) as a no-op conversion. Since a (void *)
cannot actually be USED for anything (other than passing it around) until
converted, any actual conversion can be deferred until it's really needed,
instead of doing lots of pointless conversions between word-pointers and
byte-pointers while passing the thing around.
But anyway, what I decided to do was:
Conversions to (void *) from:
any integral type - no-op.
any word pointer - changes to 9-bit byte pointer.
any byte pointer - no-op (*NOTE).
Conversions from (void *) to:
any integral type - no-op.
any word pointer - flushes all P&S bits.
any byte pointer - no-op (*NOTE).
The conversions marked (*NOTE) are the only ones which differ from the
conversions to and from (char *), which are described in the CC.DOC
file.
I'm not sure whether this answers the question about "anomalies". Any time
you use a byte pointer with other than a 9-bit size, you'll have to be
careful. The only guarantees are that the library routines will work
with 6, 7, 8, or 9 bits; the mem*() functions will also work with 18 bits.
If you make up your own byte pointers with various sizes, by casting them
to (char *) from (int), you're on your own. At least KCC tries to stick with
the byte-pointer instructions whenever handling char pointers, so you can
normally still use C even if not the library.
--Ken
p.s. you didn't answer my Q about what references you have, so I can't
give you page numbers to look at or anything...
-------
13-Aug-89 16:21:50-PDT,582;001000000001
Mail-From: KLH created at 13-Aug-89 16:21:40
Date: Sun, 13 Aug 89 16:21:40 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: 311,47nn password changed?
To: ben@CSI.CompuServe.COM, msnyder@CSI.CompuServe.COM
cc: klh@NIC.DDN.MIL
Message-ID: <12517893311.60.KLH@NIC.DDN.MIL>
Did you change the password to those dirs? I can't log in to them
(the last time I used them was about June 13). I was hoping to
start the source transfer this weekend. I can still use 525,5 but
it isn't much good for our purposes.
Let me know when this is fixed, thanks.
--Ken
-------
14-Aug-89 05:12:06-PDT,497;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Mon, 14 Aug 89 05:11:57 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA29666; Mon, 14 Aug 89 08:11:45 -0400
Date: 14 Aug 89 07:45:37 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Change of address?
Message-Id: <"CSI 5633-1044"@CompuServe.COM>
Ken -- I notice your return address has changed. Do you prefer NIC.DDN.MIL
over SRI-NIC.ARPA?
14-Aug-89 05:12:09-PDT,563;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Mon, 14 Aug 89 05:12:00 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA29693; Mon, 14 Aug 89 08:11:55 -0400
Date: 14 Aug 89 07:43:55 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Passwords unchanged
Message-Id: <"CSI 5633-1041"@CompuServe.COM>
Ken -- I never changed the passwords to [311,47xx]. I just checked out
[311,4700] and [311,4701]. The passwords to these PPNs are the name of
your compiler.
14-Aug-89 14:49:27-PDT,919;001000000001
Mail-From: KLH created at 14-Aug-89 14:48:51
Date: Mon, 14 Aug 89 14:48:50 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Change of address?
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5633-1044"@CompuServe.COM>
Message-ID: <12518138555.19.KLH@NIC.DDN.MIL>
SRI-NIC.ARPA had its official name changed to NIC.DDN.MIL as part of the
overall transition to Domain Names. Should have happened long ago but
the NIC is a bit of a special case -- like making sure the index stays
in the same place while the contents change all around it. Once almost
everything has changed, it's OK to change the index.
SRI-NIC.ARPA will remain as a nickname for at least a year.
Eventually (not soon, but eventually) my address will become KLH@NISC.SRI.COM
so as to decouple it from a machine that, because it belongs to the govt,
has various annoying restrictions on its use.
-------
14-Aug-89 14:53:56-PDT,366;001000000001
Mail-From: KLH created at 14-Aug-89 14:53:24
Date: Mon, 14 Aug 89 14:53:24 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Passwords unchanged
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5633-1041"@CompuServe.COM>
Message-ID: <12518139384.19.KLH@NIC.DDN.MIL>
I thought the password used to be the name plus "fix"??
-------
15-Aug-89 03:12:41-PDT,638;001000000001
Mail-From: KLH created at 15-Aug-89 03:12:39
Date: Tue, 15 Aug 89 03:12:38 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: ANSI KCC on [311,47xx]
To: ben@CSI.CompuServe.COM, msnyder@CSI.CompuServe.COM
cc: klh@NIC.DDN.MIL
Message-ID: <12518273959.19.KLH@NIC.DDN.MIL>
Now showing at a DSK-in near you:
"ANSI KCC - the Movie (ing target)"
Featuring:
- 9 obscene triples (??- ??= ...)
- Heavy (#/##) foreplay
- 2 indecent tyke qualifiers
- 69 exotic locales
- 100's of naked prototypes
- 1 almost dead body
and other tidbits of equally dubious social redeeming value.
Joe Bob says check it out.
-------
15-Aug-89 03:46:36-PDT,1117;001000000001
Mail-From: KLH created at 15-Aug-89 03:46:33
Date: Tue, 15 Aug 89 03:46:33 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Some additional info
To: ben@CSI.CompuServe.COM, msnyder@CSI.CompuServe.COM
cc: klh@NIC.DDN.MIL
Message-ID: <12518280133.19.KLH@NIC.DDN.MIL>
[311,4700] (C:) contains the new .H files, plus a new LIBC.REL and KCC.EXE.
[311,4701] (CSYS:) has a new TYPES.H file.
The .RELs and sources are in the same places as before.
There is also a new CC.DOC in C:. It was tough trying to update that
file, since many of the changes are hard to explain in the absence of a
public pANS reference, and the structure of the pANS itself is a lot
different from H&S which is what CC.DOC is based on. I'll probably take
another whack at it sometime later.
The CSI-specific library stuff that isn't there is: getenv, signal/raise,
and random-access I/O.
I expect you will encounter a lot of type clash errors when you first
begin to use this version of KCC; the function arg checking is rather
fierce. Give it a shot and let me know what problems you run into!
--Ken
-------
17-Aug-89 09:06:25-PDT,443;001000000001
Mail-From: KLH created at 17-Aug-89 09:03:02
Date: Thu, 17 Aug 89 09:03:01 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Testing
To: ben@csi.compuserve.com
cc: klh@NIC.DDN.MIL
Message-ID: <12518862033.60.KLH@NIC.DDN.MIL>
Is mail getting through to you? I sent you a couple messages earlier
this week and am wondering if you got any of them, since no responses
have shown up here -- that's rather unusual.
--Ken
-------
17-Aug-89 13:34:15-PDT,2082;001000000015
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Thu, 17 Aug 89 12:57:38 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA15113; Thu, 17 Aug 89 15:55:20 -0400
Date: 17 Aug 89 15:20:53 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Some additional info
Message-Id: <"CSI 5635-4358"@CompuServe.COM>
Ken,
As a first attempt at testing the new ANSI compatible compiler, I
have attempted to have it rebuild itself and it's libraries. Results
were very positive, with only one problem I couldn't easily solve.
Congratulations!
It also appears as if you've made progress on the memory allocation
problems? I know we used to have to build two versions of the compiler,
one of which had static tables declared that were big enough to compile itself.
This time thru, I built the compiler without the "big" option (ie. with
small internal tables), yet it was able to recompile itself.
The one place I stumbled was in compiling onexit.c; this module
has not been changed this month, but it includes stdlib.h which has. The
new stdlib.h lacks a define for MAX_EXIT_FUNCTIONS, so I compiled using
the old stdlib.h. However, the compiler choked on the function declaration
onexit_t onexit(func) ((void *) func)(); /* I may have messed up parens */
complaining that the declaration of func conflicted with a previous
prototype. When I gave the command line option "-P=ansi" it went thru OK.
I am not familiar enough with prototypes to say whether this is correct,
but it certainly looks like a declaration that we could see again...
I did check and there was no other prototype for onexit besides the
declaration itself.
I have had a complaint from users of Gnu C (which I support on the VAX),
that it chokes when you mix new-style prototypes and old-style declarations
in the same module. Could this be a related problem? It's way beyond my
knowledge of the ANSI spec...
Cheers,
Michael
17-Aug-89 15:56:14-PDT,857;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Thu, 17 Aug 89 15:54:33 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA25308; Thu, 17 Aug 89 18:47:51 -0400
Date: 17 Aug 89 17:14:57 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: This & that
Message-Id: <"CSI 5635-5197"@CompuServe.COM>
Ken...
- I do not have a recent (maybe 1986) version of the draft
ANSI C standard.
- I'm eager to see ELLE. As I suppose this requires that random
I/O work, I'm wondering how random I/O is coming along.
- I don't want to be late with your check again. I've already
asked that it be generated. When do you want the 10-day
acceptance clock to start? Has it started already?
- Hmmm... what else am I forgetting?
...Benny
18-Aug-89 02:25:00-PDT,2659;001000000001
Mail-From: KLH created at 18-Aug-89 02:24:54
Date: Fri, 18 Aug 89 02:24:54 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Some additional info
To: MSNYDER@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5635-4358"@CompuServe.COM>
Message-ID: <12519051702.33.KLH@NIC.DDN.MIL>
It also appears as if you've made progress on the memory allocation
problems?
I didn't do anything special for this version. I did reduce the size of
a few of the static tables that I thought were a bit excessive. Given
time, there are several areas where improvement is possible.
The one place I stumbled was in compiling onexit.c;
I guess you were working from a different directory and didn't copy
everything. Note that LIBC.CCL and KCC.CCL both changed; some modules
were added and some went away. In particular, onexit() is now
atexit() in the current pANS. MAX_EXIT_FUNCTIONS no longer exists; atexit()
is required to support at least 32. Rather than try to guess why you got
an error message (there could be several reasons, all good), I'd suggest
just making your copies consistent. And if any programs use onexit, fix
them to use atexit instead.
[Note: I KERMITed only the new sources to [311,47nn], after which I
recompiled the entire library and compiler using old (non-ANSI) KCC.
I then used those to do yet another complete recompile (with ANSI features
in effect), and installed the results in 4700 and 4701. Being able to
rebuild itself is the only thing I can safely guarantee about KCC.]
I have had a complaint from users of Gnu C (which I support on the VAX),
that it chokes when you mix new-style prototypes and old-style declarations
in the same module. Could this be a related problem? It's way beyond my
knowledge of the ANSI spec...
There probably isn't any relation to onexit(). I can believe that
some compilers or programs might have a hard time with mixed styles,
however. It took me considerable time to fully understand what the
pANS required and then to make KCC handle those situations properly.
And this was when I thought I already understood it!
Ben just mentioned in a different message that he only has a 1986
version of the dpANS (the version I'm working from, which was
forwarded to ANSI for approval, is 7-Dec-1988). This could be a
problem; I don't know, offhand, of any published C books that
completely describe the current proposed standard (but then I rarely
glance at the C-for-the-masses cruft on bookstore shelves). Perhaps I
should take my pANS copy to a local photocopy service and mail one to
you.
--Ken
-------
18-Aug-89 03:45:24-PDT,1626;001000000001
Mail-From: KLH created at 18-Aug-89 03:45:17
Date: Fri, 18 Aug 89 03:45:16 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: This & that
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5635-5197"@CompuServe.COM>
Message-ID: <12519066331.33.KLH@NIC.DDN.MIL>
- I do not have a recent (maybe 1986) version of the draft
ANSI C standard.
Do you want me to send a copy of mine? Or do you have some recent
book that you consider sufficiently descriptive? (I haven't browsed
the PC section of a bookstore lately so don't know if there's anything
good out.)
- I'm eager to see ELLE. As I suppose this requires that random
I/O work, I'm wondering how random I/O is coming along.
True. Haven't started yet, though.
- I don't want to be late with your check again. I've already
asked that it be generated. When do you want the 10-day
acceptance clock to start? Has it started already?
As of the 15th I guess, since that's when I installed everything and sent
messages to that effect.
- Hmmm... what else am I forgetting?
Well, the one thing I would really like right now is a prioritized
list of what features or improvements you would like to have for the
3rd phase. You've mentioned a number of things here and there which
I've been collecting, but (as I suspected would be the case) en masse
they are just too much for the time & effort level of this phase.
Even my own list is too much by itself! I'm trying to ensure that
you'll be happy (or at least contractually satisfied) with the portion
I can finish by Sept 15.
--Ken
-------
21-Aug-89 05:40:23-PDT,577;001000000001
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Mon, 21 Aug 89 05:39:27 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA06277; Mon, 21 Aug 89 08:19:23 -0400
Date: 21 Aug 89 07:56:11 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Re: Some additional info
Message-Id: <"CSI 5637-1112"@CompuServe.COM>
>Perhaps I should take my pANS copy to a local photocopy service and mail one
>to you.
I'm sure that would be appreciated.
Michael
21-Aug-89 12:33:21-PDT,1140;001000000011
Return-Path: <msnyder@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Mon, 21 Aug 89 12:31:30 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA04561; Mon, 21 Aug 89 15:30:17 -0400
Date: 21 Aug 89 14:15:31 EDT
From: <MSNYDER@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: prototypes and fn decls
Message-Id: <"CSI 5637-4536"@CompuServe.COM>
Ken, here's a short example of the behavior I mentioned, where mixing of
function prototypes and old style declarations gives unexpected results;
void foo(short);
void foo(x)
short x;
{...}
"fru.c", line 3: Type of parameter "x" conflicts with prior prototype
To get this error message requires three conditions:
1) a prototype
2) a function declaration with argument list (not type list)
3) a parameter of a type that, by default, would promote to int.
Both KCC and GCC exhibit this behavior. We can't find anything in the
ANSI spec that explains it. This sort of code must happen all the time,
when people add prototypes to an existing program. What do you think?
Michael
21-Aug-89 12:52:04-PDT,1719;001000000001
Mail-From: KLH created at 21-Aug-89 12:51:55
Date: Mon, 21 Aug 89 12:51:55 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: prototypes and fn decls
To: MSNYDER@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-4536"@CompuServe.COM>
Message-ID: <12519952279.28.KLH@NIC.DDN.MIL>
To get this error message requires three conditions:
1) a prototype
2) a function declaration with argument list (not type list)
3) a parameter of a type that, by default, would promote to int.
Yes, this is one example of the surprises I alluded to.
The error message says exactly what is happening. The new-style
prototype declaration for "foo" has one parameter of type "short",
whereas the old-style definition is asking for one parameter of type
"int", which causes a type clash. The default promotion is quite real
for the purposes of prototype comparison, because the checks are
trying to make sure that both the calling code and function code have
the same idea of what size object is being passed on the stack. KCC
could let this go with a warning since the code isn't going to be any
different, but other implementations (that passed a short as 2 bytes
and an int as 4) would choke.
ANSI doesn't permit old-style declarations to avoid the promotions,
because doing otherwise would invalidate any old-style function calls
made outside the scope of a prototype declaration.
To solve this problem, either make the definition new-style, or change
the declaration and definition to both use the promoted parameter type.
The latter is what I usually do, since there is rarely any good reason
to use a parameter smaller than int.
--Ken
-------
22-Aug-89 10:53:44-PDT,530;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Tue, 22 Aug 89 10:49:00 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA06136; Tue, 22 Aug 89 13:48:00 -0400
Date: 22 Aug 89 13:02:12 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: o_scanf missing
Message-Id: <"CSI 5637-10272"@CompuServe.COM>
Ken -- o_scanf comes up undefined when a program calls sscanf. I'll
keep looking in case it's something we did.
...Benny
22-Aug-89 10:54:08-PDT,679;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Tue, 22 Aug 89 10:49:26 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA06318; Tue, 22 Aug 89 13:49:05 -0400
Date: 22 Aug 89 13:21:47 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Phase 3
Message-Id: <"CSI 5637-10427"@CompuServe.COM>
Ken -- I'm looking over a wish list for phase 3 work. I think the $3,000
may not go far. Two things that are important are
1 -- Use our memory managment routines
2 -- Have KCC use FILOP I/O and use extended channels
Is there any money left? Am I in the hole?
Benny
22-Aug-89 10:55:03-PDT,538;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Tue, 22 Aug 89 10:52:25 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA06689; Tue, 22 Aug 89 13:52:12 -0400
Date: 22 Aug 89 13:17:24 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Random I/O
Message-Id: <"CSI 5637-10389"@CompuServe.COM>
Ken -- Where do you see support for random I/O falling? Is this something
we should expect right away, or is this phase 3 stuff? Thanks!!
22-Aug-89 11:14:15-PDT,1278;001000000001
Mail-From: KLH created at 22-Aug-89 11:13:59
Date: Tue, 22 Aug 89 11:13:58 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Random I/O
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-10389"@CompuServe.COM>
Message-ID: <12520196592.28.KLH@NIC.DDN.MIL>
Ken -- Where do you see support for random I/O falling? Is this something
we should expect right away, or is this phase 3 stuff? Thanks!!
It's sort of both. Technically it is not required to be supported and
the compiler itself doesn't need it, but in practical terms it really
should be. But the pain of overlaying this model on top of TOPS-10 makes
it a system specific hack rather than just an upgrade.
In the absence of a specific priority list, this is what I'm working on,
and I hope to have it done by the end of the week.
I don't think there's any way to expect fseek() to work on a write-only
stream, because there isn't any way to modify just part of a disk block
without having it open for both read and write. So T10 can handle read mode,
and update mode, but not write mode. If it falls out naturally, I may add
pseudo-support anyway, so rewind() will work (but random seeks will clobber
entire blocks rather than single bytes).
-------
22-Aug-89 11:31:10-PDT,837;001000000001
Mail-From: KLH created at 22-Aug-89 11:31:06
Date: Tue, 22 Aug 89 11:31:05 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: o_scanf missing
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-10272"@CompuServe.COM>
Message-ID: <12520199708.28.KLH@NIC.DDN.MIL>
Ken -- o_scanf comes up undefined when a program calls sscanf. I'll
keep looking in case it's something we did.
No, it's my mistake. This is only for the new ANSI %p conversion so
it's unlikely to break anything, but I'll fix the reference shortly.
Since in effect you are beta testing this stuff, I expect more
oversights will turn up. Right now you have the only copy apart from the
development one; I want to get some TOPS-20s using it soon but things
are still changing so much that it might be a while.
-------
22-Aug-89 12:23:03-PDT,537;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Tue, 22 Aug 89 12:22:57 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA09254; Tue, 22 Aug 89 15:17:36 -0400
Date: 22 Aug 89 14:37:04 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Suggestion
Message-Id: <"CSI 5637-11006"@CompuServe.COM>
Ken -- Someone suggested that it would be nice if KCC could
generate a warning if a function call is made without a prototype.
Benny
22-Aug-89 15:39:47-PDT,699;001000000001
Mail-From: KLH created at 22-Aug-89 15:39:41
Date: Tue, 22 Aug 89 15:39:41 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Suggestion
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-11006"@CompuServe.COM>
Message-ID: <12520244964.28.KLH@NIC.DDN.MIL>
Ken -- Someone suggested that it would be nice if KCC could
generate a warning if a function call is made without a prototype.
I think you mean "without a prior declaration" rather than insisting on
using new-style prototypes for all declarations. In that case it would
be reasonable, although it might produce a lot of warnings for a lot of
software. (oh no, another switch...)
-------
22-Aug-89 18:44:44-PDT,550;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Tue, 22 Aug 89 18:44:33 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA07497; Tue, 22 Aug 89 21:44:27 -0400
Date: 22 Aug 89 21:30:31 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Validation suite?
Message-Id: <"CSI 5637-13098"@CompuServe.COM>
Ken -- Are you using any validation suite in testing KCC? I hope I haven't
asked and had this answered before. I apologize if I have.
Benny
22-Aug-89 18:44:48-PDT,721;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Tue, 22 Aug 89 18:44:42 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA07525; Tue, 22 Aug 89 21:44:38 -0400
Date: 22 Aug 89 21:28:36 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Thoughts on random I/O
Message-Id: <"CSI 5637-13096"@CompuServe.COM>
Ken -- With respect to random I/O and random seeks clobbering entire blocks
of data rather than single bytes; could you consider buffering disk blocks
in a local cache with the file open in dump mode? We have a BLISS library
that supports random I/O that way, and it seems to work. Just a thought.
Benny
23-Aug-89 01:51:20-PDT,1439;001000000001
Mail-From: KLH created at 23-Aug-89 01:51:18
Date: Wed, 23 Aug 89 01:51:17 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Thoughts on random I/O
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-13096"@CompuServe.COM>
Message-ID: <12520356302.28.KLH@NIC.DDN.MIL>
Ken -- With respect to random I/O and random seeks clobbering entire blocks
of data rather than single bytes; could you consider buffering disk blocks
in a local cache with the file open in dump mode? We have a BLISS library
that supports random I/O that way, and it seems to work. Just a thought.
Do you mean it does this with the file open write-only (ENTER but no
LOOKUP)??? Seems like the only reliable method of doing this would be
to use a temporary file open for update (R/W) and copying it to the
real filename when finally closed. Not something you want to do for
every file that a C program writes.
I don't have any problems with files open for update (both read and
write) since existing blocks can be read in and written over. I thought
it useful to keep a distinction between write-only (using buffered output)
and update (read-write, using dump mode) so that any performance gain
associated with buffered mode could be retained.
I'm not even aware of any existing programs that do seeks on a
write-only disk file, except for append mode which is a different
ballgame.
-------
23-Aug-89 02:18:28-PDT,2039;001000000001
Mail-From: KLH created at 23-Aug-89 02:18:27
Date: Wed, 23 Aug 89 02:18:27 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Validation suite?
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-13098"@CompuServe.COM>
Message-ID: <12520361246.28.KLH@NIC.DDN.MIL>
Ken -- Are you using any validation suite in testing KCC? I hope I haven't
asked and had this answered before. I apologize if I have.
Well, you did ask, but I don't mind. The answer is no, anything on
the market is going to be much too expensive for something that is
distributed essentially without charge. I do a number of different
things when I test KCC:
(1) It has to recompile itself and library with no change in the
resulting code. Real basic.
(2) I have a variety of small test programs which confirm that specific
things work. Some provoke errors intentionally to verify that
those things are caught. Normally I only need to target those
tests for the specific features that were changed. I think I
put some of them on [311,4714] for the library, but not the ones for
compiler testing since the only system-specific part of KCC is the
assembler/linker invocation.
(3) Rebuilding the large programs we run at the NIC (our DBMS for
example). Obviously if it works for all our software, it's
perfect for our needs.
Testing the compiler is easier than testing the library because the
language is much better defined and the output can easily be compared
with that of previous compilers. The library has such a diverse
domain and range that it's much harder to be thorough -- the math
routines, for example, were tested by other people and I haven't had
much to do with them. I've asked Nelson Beebe at Utah (who is a
floating-point maven) to check them out again; I think he might also
have access to some C test suites but can't remember if he actually had
his hands on one or not (there was some reason we couldn't use it but I
forget what it was).
--Ken
-------
23-Aug-89 12:00:47-PDT,2454;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Wed, 23 Aug 89 12:00:22 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA06425; Wed, 23 Aug 89 15:00:01 -0400
Date: 23 Aug 89 14:29:31 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: KCC
Message-Id: <"CSI 5637-17007"@CompuServe.COM>
Ken -- KCC received a lot of discussion at the managers' meeting
today. Please comment on any points of more-than-moderate agreement
or disagreement.
We have a new application for one of our big corporate clients, and we
want to write it in C. The staff that will write it is probably going
to write it first in Turbo C 2.0 on their PCs and then upload it to
our hosts and build the actual system using KCC. There is concern
about support, bug fixes, ambiguities in the standard, etc. Some
people want to buy the Plum Hall test suite. Others do not. (I don't.)
It's my opinion (and I think I've stated this before), that you'll
fix or help fix any serious problems with respect to ANSI compliance.
After all, you want this to be an ANSI compiler, as do we. There's only
a few days left in our acceptance window, and there's fear that support
will be hard to come by once our contractual obligations are finished.
While I don't want to take a lot of your time after the contract is
over, I feel I can electronically discuss matters with you. I suspect
too, that should a serious flaw arise you help with the fix. Maybe
what it boils down to is that we don't want to buy the test suite, but
if something comes up and we're stuck, we can consult with you.
There's also the notion of random I/O which I know you're working on.
I don't recall the exact wording, but you seemed to indicate that
random I/O was not necessarily part of ANSI. It was argued that
since fseek() and friends are in ANSI that random I/O was too. Would
you care to rebut? It led to the question, "What part or parts of
the standard will and will not be implemented?"
Some people are still fretting over prototypes, old vs new. I am
going to try to assemble a set of concerns and send them off to you.
Anyway, enough for now. I appreciate your comments on any and all
of the above.
P.S. Did you get / are you thinking about my message about about
FILOP. I/O and extended channel usage and using our memory management
stuff for phase 3 work?
23-Aug-89 13:21:25-PDT,1035;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Wed, 23 Aug 89 13:21:16 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA08960; Wed, 23 Aug 89 16:17:10 -0400
Date: 23 Aug 89 15:55:48 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Is this a bug?
Message-Id: <"CSI 5637-17660"@CompuServe.COM>
Ken -- Would you pass judgment on the following? Thanks.
The following program compiles without errors, as it should:
struct foo {
int (*function) (int);
};
static struct foo *mumble(int);
However, this program --
struct foo {
int (*function) (int xIsmyName);
};
static struct foo *mumble(int);
generates an error message to the effect that the storage class of a function
declaration "inside a block" must be "extern". Given that the error message
has no relation to the difference between the two programs, I think the
parser must have hiccoughed over the function prototype in the struct.
23-Aug-89 16:01:55-PDT,779;001000000001
Mail-From: KLH created at 23-Aug-89 16:01:49
Date: Wed, 23 Aug 89 16:01:49 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: Is this a bug?
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-17660"@CompuServe.COM>
Message-ID: <12520511136.28.KLH@NIC.DDN.MIL>
generates an error message to the effect that the storage class of a function
declaration "inside a block" must be "extern". Given that the error message
has no relation to the difference between the two programs, I think the
parser must have hiccoughed over the function prototype in the struct.
You got it. Structure/union declarations were not properly clearing a
leftover prototype scope. Fixed, will bring it over tonight (kermit
willing).
-------
23-Aug-89 17:36:01-PDT,5215;001000000001
Mail-From: KLH created at 23-Aug-89 17:35:58
Date: Wed, 23 Aug 89 17:35:55 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Re: KCC
To: BEN@CSI.CompuServe.COM
cc: KLH@NIC.DDN.MIL
In-Reply-To: <"CSI 5637-17007"@CompuServe.COM>
Message-ID: <12520528267.28.KLH@NIC.DDN.MIL>
Hmm, a lot of things. In slightly rearranged order:
There's also the notion of random I/O which I know you're working on.
I don't recall the exact wording, but you seemed to indicate that
random I/O was not necessarily part of ANSI. It was argued that
since fseek() and friends are in ANSI that random I/O was too. Would
you care to rebut? It led to the question, "What part or parts of
the standard will and will not be implemented?"
This is what I said:
It's sort of both. Technically it is not required to be supported and
the compiler itself doesn't need it, but in practical terms it really
should be. But the pain of overlaying this model on top of TOPS-10 makes
it a system specific hack rather than just an upgrade.
I didn't mean to imply that I would use an extreme interpretation of
the Standard to avoid implementing random I/O. As a practical matter
I certainly agree it is needed. But the extent of its reliance on
system-specific code makes it more of a porting issue. If you recall,
I had intended to get that part working for the first milestone, but
used up too much time just fighting alligators. It (as well as much
other Un*x simulation stuff) is not needed for bringing up KCC, so it
could be given secondary status at the time.
I don't know how to adequately answer the question of "what parts will
be implemented?" The pANS has an appendix section which lists over a
hundred points of implementation-defined, undefined, or unspecified
behavior. Perhaps the only valid response is "whatever you are willing to
expend the effort for". I've tried to keep you posted on what I feel
are the major holes in what I've done so far. These are seeking,
getenv, and signals. The first I'm working on, the second should be easy
if you think my suggested implementation for it is okay, and the third
is (as I feared all along) extremely difficult.
P.S. Did you get / are you thinking about my message about about
FILOP. I/O and extended channel usage and using our memory management
stuff for phase 3 work?
Yes. Use of FILOP. and extended channels should be straightforward. I have
avoided it up to now because I don't completely trust the PA1050 emulation
of that UUO and wanted to complete things as far as possible with the old
UUOs before adding any complications.
Use of the monitor core allocator UUOs may or may not be easy. I
asked for details on how it worked back when we discussed the KCC
lowcore usage issue, but think it got overlooked. The kinds of things
I'll need to know are:
Where is the core allocated?
What memory locations are referenced or updated?
How does it avoid the stack? How in general to steer it away from
reserved address space?
Does it include boundary overflow error checking?
Can it be used to allocate impure core in addresses above a
pure high segment? Can the segment be selected?
What do the overhead words look like?
With luck, there will be no show-stoppers.
My opinion is that it would be best to tackle I/O, FILOP., DSFNC$,
getenv, and signal() in that order, so as to get the most things
completed in the time left. A complete CSI version of signal()
probably would not be finished even if I did nothing else starting
right now.
our hosts and build the actual system using KCC. There is concern
about support, bug fixes, ambiguities in the standard, etc. Some
people want to buy the Plum Hall test suite. Others do not. (I don't.)
How much are they asking? Just curious.
It's my opinion (and I think I've stated this before), that you'll
fix or help fix any serious problems with respect to ANSI compliance.
After all, you want this to be an ANSI compiler, as do we. There's only
True enough. A test suite only finds bugs, it doesn't fix them. (It would
be nice if someone were to run KCC through such a suite, of course :-)
a few days left in our acceptance window, and there's fear that support
will be hard to come by once our contractual obligations are finished.
While I don't want to take a lot of your time after the contract is
over, I feel I can electronically discuss matters with you. I suspect
too, that should a serious flaw arise you help with the fix. Maybe
what it boils down to is that we don't want to buy the test suite, but
if something comes up and we're stuck, we can consult with you.
That seems reasonable. I don't have any problem fixing bugs with the
compiler itself; it's a fair exchange for finding the bug, since SRI
(and everyone else) will benefit. I'd certainly be interested in
working out a new agreement to deal with requests for features, or
problems with CSI-specific library code, if that is what you're
thinking of. We can talk about that later, I have to run errands now...
--Ken
-------
24-Aug-89 05:19:19-PDT,520;001000000001
Mail-From: KLH created at 24-Aug-89 05:19:15
Date: Thu, 24 Aug 89 05:19:14 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Transfer failed
To: ben@csi.compuserve.com
cc: klh@NIC.DDN.MIL
Message-ID: <12520656302.25.KLH@NIC.DDN.MIL>
What does this mean?
% MONNCI Network connection interrupted, possible data loss.
? MONUCN Unable to complete network connection recovery. Please redial.
I'll try to get the fix over later. I did get the new CSTDIO:SCANF.C
over and installed in LIBC.REL.
-------
24-Aug-89 06:51:41-PDT,1305;001000000001
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Thu, 24 Aug 89 06:51:36 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA06271; Thu, 24 Aug 89 09:46:01 -0400
Date: 24 Aug 89 09:25:05 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Misc
Message-Id: <"CSI 5638-1011"@CompuServe.COM>
What does this mean? Well, your message subject says it all -- The
Transfer Failed. One of the many network links supporting your
connection to our hosts went down.
Thanks for the reassurance on that matter of support. I hope that
is taken care of. (FYI - The Plum Hall test suite is $9500.)
I'll get that other info to you later today. I'll be gone tomorrow
for a long weekend, but will try to check in Saturday or Sunday.
As before, I'm not touching anything in [311,47xx]. When you
tell me something has changed, I'll copy it into [311,700xx] and
rebuild using .COM files in [311,70003]. I overwrote the few
things I had modified before, so I'll try to re-institute those.
I'll let you know about anything we change here.
All things considered, I think things are looking good. I hope you are
satisfied; I think we are (would management ever admit it even if they
were?).
Benny
24-Aug-89 08:06:55-PDT,1637;001000000001
Mail-From: KLH created at 24-Aug-89 08:06:47
Date: Thu, 24 Aug 89 08:06:46 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: Bug fix installed, other news
To: ben@csi.compuserve.com, msnyder@csi.compuserve.com
cc: klh@NIC.DDN.MIL
Message-ID: <12520686800.25.KLH@NIC.DDN.MIL>
I brought over a new CKCC:CCDECL.C and installed a new C:KCC.EXE.
This is in addition to the new CSTDIO:SCANF.C and C:LIBC.REL that I
mentioned in a msg to Ben yesterday.
This should fix the prototype-within-struct-declaration bug.
By the way, the version of KCC you have is not the latest one. At the
time I brought ANSI KCC over, I decided to use a slightly older
version that had been more thoroughly tested. Sometime soon (probably
after I deal with the I/O albatross) I'll bring the current sources
over (every file has some changes, otherwise I would have done it now
instead of just patching CCDECL).
The main difference is that the error reporting mechanism was cleaned
up internally and all errors were divided into 4 severity classes: notes,
advisories, warnings, and errors. I like it much better and think you
will too.
This will also include a "note"-class warning for calls to undeclared
functions, as requested. After trying it for a while, I'm still not
sure if I like it or not; in theory it is a Good Thing, but it is
quite disheartening to see a large existing package generate long
lists of complaints, especially for Unix system calls which typically
have no header file and are always known to return an int anyway.
After the new version gets there you can see what you think.
--Ken
-------
24-Aug-89 08:44:29-PDT,1249;001000000011
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Thu, 24 Aug 89 08:44:04 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA09190; Thu, 24 Aug 89 11:43:45 -0400
Date: 24 Aug 89 11:21:37 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Random problem?
Message-Id: <"CSI 5638-2121"@CompuServe.COM>
Ken -- Here's an interesting one.
...Benny
----------------------------------------------------------------------
/*
* Benny, other multiplicative congruential random number generators
* require a period (before cycling) of 2^32, but as this program reveals,
* the period on KCC is often less than 2^10.
* ps- This program does NOT cycle with Vax, Unix, and Micro C libraries.
*/
main()
{
int i,j,k,a[10][5],s[6];
printf("Type any of \"*[]+^<!#%&56789dfjpvBCKLPSVY\" to seed random\n");
srand(getchar()*137);
for(i=0,k=0; i<20000 && k<5; i++)
if(rand() == 22872044666) {
for(j=0;j<5;j++)
a[k][j]=rand();
s[k++] = i;
}
for(i=0;i<k;i++) {
printf("\nThis cycle begins with rand() call # %d\n",s[i]);
for(j=0; j<5; j++)
printf("%d\t",a[i][j]);
}
}
24-Aug-89 11:01:23-PDT,1531;001000000005
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Thu, 24 Aug 89 10:46:20 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA12569; Thu, 24 Aug 89 13:45:49 -0400
Date: 24 Aug 89 13:23:18 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Memory stuff
Message-Id: <"CSI 5638-3014"@CompuServe.COM>
See [311,22000]MEM.MAC. The routines in this module make up
the low level memory managment for most all of our needs. An
external called $HEAP decides where (what page) the heap starts
at. This way, if something is loaded at the heaps default page,
we can define $HEAP to LINK to have the heap put somewhere else.
Problems. As it currently exists, R$GMEM must not be interrupted
by anyone who may need to call R$GMEM. We plan to add a flag word
to act as a semaphore the alleviate this problem.
I'm inclined to think that using these routines is preferable to
DSFNC$ (given the flexibility using $HEAP), but it's arguable.
I suspect that this is something that could be changed without
too much effort if need be. You decide.
See if the discussion in the sources of MEM.MAC don't answer
your questions as far as using these routines go. If you'd
still like to use DSFNC$, I'll try and find answers as applicable
to DSFNC$.
I wrote a 2-line FORTRAN program in our XF4 language. It's in
HELLO.XF4[311,4717]. IRUn HELLO and then do a MEM command to
see your memory structure. Strictly FYI.
Benny
24-Aug-89 13:38:06-PDT,892;001000000015
Return-Path: <ben@csi.compuserve.com>
Received: from saqqara.cis.ohio-state.edu by NIC.DDN.MIL with TCP; Thu, 24 Aug 89 13:37:36 PDT
Received: by saqqara.cis.ohio-state.edu (5.61/4.890725)
id AA17173; Thu, 24 Aug 89 16:20:04 -0400
Date: 24 Aug 89 15:41:01 EDT
From: <BEN@CSI.CompuServe.COM>
To: <KLH@NIC.DDN.MIL>
Subject: Very_long_name_anamoly
Message-Id: <"CSI 5638-4133"@CompuServe.COM>
Ken
I don't know if you'd classify this is an error, but I do think the error
message generated is misleading...
The problem is that when you use very long macro names, they are not
expanded by the preprocessor and instead are passed onto the compiler
where an "unknown identifier" type error is reported. A sample program
which demonstrates this follows:
#define Very_Very_Very_Very_Very_Long_Name x
main ()
{
int x;
Very_Very_Very_very_very_Long_Name = 1;
}