Babyl Options: Version:5 Append:1 Labels:KCC,RemindNow Reformat-Headers-P: Save Both Summary-Window-Format: Use Default  0, answered,, *** EOOH *** Rcvd-Date: 29-May-86 23:11:44-EDT Received: from SPEECH.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 May 86 23:11-EDT Date: Thu 29 May 86 23:11:04-EDT From: "John Wroclawski" Subject: Re: KCC To: SRA@XX.LCS.MIT.EDU Message-ID: <12210702303.33.JTW@SPEECH.MIT.EDU> KCC's been around for a long while. I didn't know he was still playing with it tho... Date: Thursday, 29 May 1986 23:56-EDT From: Rob Austein To: "John Wroclawski" cc: SRA@XX.LCS.MIT.EDU Re: KCC Yeah, I saw a version of KCC when I was still at Wesleyan. It was pretty poor in those days. BillW claims KLH and others at SRI have been working on it, adding extended addressing, etc. Bill claimed it was generating native code directly (instead of using FAIL), but he may have been confused. There are still some weirdnesses (strings are not the same thing as char[]s, one is 7-bit-5-per-word, the other is 9-bit-4-per-word). Thing is, if we can get a reasonably decent C compiler that will run on both 20x and ITS I will use it for the resolver and will make sure the resolver runs on both systems. Otherwise I may have to do it in MIDAS, which would be a pain. I've pretty much decided that the right thing to do is punt this mapped-into-kernal database idea; instead I'd have a VAF-style resolver using IPCF (Len Bosack claims IPCF is fast enough for any reasonable purpose). I'd probably want to keep a HOSTS3 table with Chaos and (maybe) some small amount of IP data, using the current CHANM% code, so that the machine could make use of the net while booting. Getting the database out of the kernal solves a whole bunch of problems (aside from the obvious one of ILMNRFs due to bogus pointers). It pretty much avoids all the locking problems, since there's just the one resolver. You can put seperate zones in separate files and do the zone transfer operation as an hourly batch job. The internal format can be a lot simpler too, like maybe just a text file and an associated binary hash table (which can be trivially rebuilt, easing maintainance). Paul's approach is needlessly hairy. I'd probably be willing to leave Paul's crock in place if I didn't have to implement something for ITS anyway. Since I do, I might as well do something useful for both systems and get this brainbubbled PASCAL code out of here. What the hell, I only wasted about six months of my life working on that lossage. BillW is so disgusted with Paul's thing that he is talking about doing a simple version of the IPCF resolver that just goes off and asks some bind to do the dirty work. Groan. Not for me, thanks, I -know- how crufty the bind code is.  0, answered,, *** EOOH *** Rcvd-Date: 29-May-86 23:11:44-EDT Received: from SPEECH.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 May 86 23:11-EDT Date: Thu 29 May 86 23:11:04-EDT From: "John Wroclawski" Subject: Re: KCC To: SRA@XX.LCS.MIT.EDU Message-ID: <12210702303.33.JTW@SPEECH.MIT.EDU> KCC's been around for a long while. I didn't know he was still playing with it tho... Date: Thursday, 29 May 1986 23:56-EDT From: Rob Austein To: "John Wroclawski" cc: SRA@XX.LCS.MIT.EDU Re: KCC Yeah, I saw a version of KCC when I was still at Wesleyan. It was pretty poor in those days. BillW claims KLH and others at SRI have been working on it, adding extended addressing, etc. Bill claimed it was generating native code directly (instead of using FAIL), but he may have been confused. There are still some weirdnesses (strings are not the same thing as char[]s, one is 7-bit-5-per-word, the other is 9-bit-4-per-word). Thing is, if we can get a reasonably decent C compiler that will run on both 20x and ITS I will use it for the resolver and will make sure the resolver runs on both systems. Otherwise I may have to do it in MIDAS, which would be a pain. I've pretty much decided that the right thing to do is punt this mapped-into-kernal database idea; instead I'd have a VAF-style resolver using IPCF (Len Bosack claims IPCF is fast enough for any reasonable purpose). I'd probably want to keep a HOSTS3 table with Chaos and (maybe) some small amount of IP data, using the current CHANM% code, so that the machine could make use of the net while booting. Getting the database out of the kernal solves a whole bunch of problems (aside from the obvious one of ILMNRFs due to bogus pointers). It pretty much avoids all the locking problems, since there's just the one resolver. You can put seperate zones in separate files and do the zone transfer operation as an hourly batch job. The internal format can be a lot simpler too, like maybe just a text file and an associated binary hash table (which can be trivially rebuilt, easing maintainance). Paul's approach is needlessly hairy. I'd probably be willing to leave Paul's crock in place if I didn't have to implement something for ITS anyway. Since I do, I might as well do something useful for both systems and get this brainbubbled PASCAL code out of here. What the hell, I only wasted about six months of my life working on that lossage. BillW is so disgusted with Paul's thing that he is talking about doing a simple version of the IPCF resolver that just goes off and asks some bind to do the dirty work. Groan. Not for me, thanks, I -know- how crufty the bind code is.  0,, RemindNow, *** EOOH *** Rcvd-Date: 4-Jun-86 19:19:16-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 4 Jun 86 19:18:42-EDT Date: Wed 4 Jun 86 16:14:16-PDT From: Ken Harrenstien Subject: Re: winning C compiler? To: SRA@XX.LCS.MIT.EDU cc: alan@AI.AI.MIT.EDU, billw@SU-SCORE.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message from "Rob Austein " of Thu 29 May 86 15:35:44-PDT Message-ID: <12212232057.29.KLH@SRI-NIC.ARPA> Yes. I am on the verge of wrapping up an overhauled KCC + library which conforms to Harbison&Steele's CARM book (such a simple statement, such a long project!), and we are using it for all of our production programs nowadays. In a couple of weeks (vacation plans, etc) a true distribution should be ready. This is meant to be the new KCC, rather than another offshoot of KCC such as Greg Titus' NMIT version is. I'm afraid I can't compare them myself as we don't have a copy here. You can retrieve the file "C:CC.DOC" from SRI-NIC if you want to get an overview. While the library is currently written for TOPS-20, it should be possible to adapt it to ITS without too much trouble. All of the conditionals and hooks are already there, and I always intended that it should be portable to other PDP-10 systems. There are still a couple of issues to be resolved, such as deciding which linking loader format to use on ITS -- DECREL or STINK? If you know other people who are interested in hacking this sort of thing, gather them up and we'll decide what should be done by who.  0,, RemindNow, *** EOOH *** Rcvd-Date: 4-Jun-86 19:19:16-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 4 Jun 86 19:18:42-EDT Date: Wed 4 Jun 86 16:14:16-PDT From: Ken Harrenstien Subject: Re: winning C compiler? To: SRA@XX.LCS.MIT.EDU cc: alan@AI.AI.MIT.EDU, billw@SU-SCORE.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message from "Rob Austein " of Thu 29 May 86 15:35:44-PDT Message-ID: <12212232057.29.KLH@SRI-NIC.ARPA> Yes. I am on the verge of wrapping up an overhauled KCC + library which conforms to Harbison&Steele's CARM book (such a simple statement, such a long project!), and we are using it for all of our production programs nowadays. In a couple of weeks (vacation plans, etc) a true distribution should be ready. This is meant to be the new KCC, rather than another offshoot of KCC such as Greg Titus' NMIT version is. I'm afraid I can't compare them myself as we don't have a copy here. You can retrieve the file "C:CC.DOC" from SRI-NIC if you want to get an overview. While the library is currently written for TOPS-20, it should be possible to adapt it to ITS without too much trouble. All of the conditionals and hooks are already there, and I always intended that it should be portable to other PDP-10 systems. There are still a couple of issues to be resolved, such as deciding which linking loader format to use on ITS -- DECREL or STINK? If you know other people who are interested in hacking this sort of thing, gather them up and we'll decide what should be done by who.  0,, *** EOOH *** Rcvd-Date: 20-Oct-86 18:11:14-EDT Mail-From: SRA created at 20-Oct-86 18:11:11 Date: Mon, 20 Oct 1986 18:11 EDT Message-ID: From: Rob Austein To: Paul Mockapetris Cc: BillW@SU-SCORE.ARPA, Stu Grossman , sra@XX.LCS.MIT.EDU Subject: GTDOM causes systems crashes in JOBCOF In-reply-to: Msg of 14 Oct 1986 21:35-EDT from Paul Mockapetris Sorry about delay answering this, folks, XX been sick and I been away. Date: Tuesday, 14 October 1986 21:35-EDT From: Paul Mockapetris Thanks for the hint about testing for a pending ^C. (I understand that there are other things that should do the same thing, but I'm not really a TOPS-20 guy and didn't know the right term.). This one's news to me. Somebody fill me in? Or maybe I should be on SU-TOPS-20@SCORE? It brings up the question of whether we can get together on a consistent set of domain code for TOPS-20. It'd be nice. Be warned that I have been working on some C code for ITS (JEEVES absolutely will -not- port there for fundamental reasons) and if I ever finish it and if it is a winner I may run it on Twenex too. I'd want to keep the user interface (user side of GTDOM% jsys) the same though, so that we can get some user network code written already. In fact, assuming that nobody else does anything particularly braindamaged, I hereby -promise- to keep the user jsys interface compatable. To start off I frankly admit that I am not a TOPS-20 system programmer. The announcement that I recently sent out (to a very limited audience) points at code that has real problems: It doesn't address the ^C issue Can't speak to this, not knowing what you're talking about. It doesn't even have a good set of mnemonics for the JSYS That I've got taken care of. See XX:MONSYM.MAC.46 (generation number tracks MIT monitor edit number). The JSYS interface should perhaps be like the MIT interface The interfaces are the same except for functions 11 and 12. Obviously I'm biased since I'm the person who changed it, but function 11 really can't be used the way you wrote it because it's allowed to randomly trash memory (no string length count). My changes to function 12 probably don't really belong on function 12 (should be seperate function); they're part of the support for the double-dip resolver invokation code. The JSYS code isn't up to coding standards No comment. Its based on 5.1 You mean 5.0, yes? 5.1 was 5.3 without the network code. The MIT/Stanford code is running pretty much unchanged on 5.4 and 6.1. I'm pretty sure the 5.4 code would run just fine on ISI's 5.machines with a few cosmetic changes. In fact I think my code already has a switch you can enable to change the names of the .UNV files it searches, which is the only problem I know about. A lot of these stem from the 5.1 problem; I just can't debug code here that is compatible with most of the external world, so frankly I haven't tried. The virtues of this code is that it has much better retransmission policies and logging (hence debugging) features, than those which were in the code on which your current versions are based. Without meaning to sound too obnoxious, this one is just your own damned fault. If you hadn't decided to lock me out of read access to your sources the MIT version would be a superset of your code. That's over and done now, but maybe you should keep it in mind in the future. The drawbacks to the MIT/Stanford code are that it lacks the recent resolver improvements (I am just assuming you haven't changed it much, correct me if I am wrong.), You're correct. Just bugfixes at MIT, and I believe this is also the case at Stanford. Oh, BillW did do some nice work searching the list of addresses returned during function .GTHSN so that it would return the most useful address for a multi-homed host (ie, if SCORE is looking for the address of NIC it should get the ARPANET address, not the MILNET address). plus the double-dip approach chews the stack. I don't understand the problem. Yes, the code uses about 80% of the UPDL while it's sitting in the resolver wait. So what? It does it once per resolve and it's not doing anything else while it's waiting (in fact, it's dismissed into the scheduler and not doing squat). The virtues are the ^c and better JSYS interface, plus any other improvements you have made. What I would like to see happen is that a single bunch of code emerges for TOPS-20. I think we can do this by sitting my resolver code upon a modified version of the MIT code. The JSYS code should collect the query name on the stack (to avoid the problems with TTY as input, etc), go NOINT, copy the query name from the stack to the search block, start the resolver, and while waiting for resolver completion periodically check for ^C et al a la Stu's method. If it sees a pending interrupt before the resolver completes (assuming DISMS busy wait), it marks the query as background (so the resolver releases the resources), allows interrupts, and gets blown away. I don't understand the bit about reading TTY input. I'm not sure that's a reasonable thing to have to do anyway; many jsi restrict their i/o designators to string pointers in the interest of simplicity. The whole point of the double dip method was that allowed you to behave like a normal piece of code and not have to busy wait or check for pending interrupts or whatever. If there is some new piece of data that says this method is bankrupt, please somebody tell me, but otherwise my opinions on the matter haven't changed and I want nothing to do with busy waits or dismissing with locks held down. The check for interrupt stuff naturally combines with some check for resolver restart code which I added to allow the ISI version to restart JEEVES on the fly. We could also allow a remap of the database to allow dynamic replaces of FLIP as a fairly straightforward exercise, given the system expertise to do the SMAP equivalent stuff. Now that would be real nice. I would just love to be able to restart the nameserver without having to crash XX! It hasn't been a high enough priority item for me to try to fix it, but I'm definitely interested. In any case, I would like to see a reasonable version available to the world at large. I don't think that any of the current versions are good enough. I agree. I like mine better than yours but would be the first to admit that both have problems. Some of them are shared problems. Eg, it really should not be necessary for a program to grok domain internal string format (length byte followed by data) to be able to do things like get the cannonical name of a host. There ought to be some function that takes asciz arguments and returns asciz results. Two choices: 1) Combine what we have. I'm not really competent to do the requisite system hacking even if I had a 6.X., but I'd be willing to reconcile the user level stuff and help with the GTDOM level stuff. Clearly the right way to go if people are willing to do the work. 2) Distribute one or both versions. If, for whatever reasons, we can't converge, will MIT/Stanford whatever agree to publicly distribute a 6.X version of whatever lineage? My code is free to all comers, with the understanding that the MIT patent office will sue the hind legs off of anybody who tries to copywrite or sell it for profit without prior agreement by MIT. The 6.1 specific stuff is also partially Stanford property; I don't know what their current policy is but I expect it isn't too different, especially considering the obvious mixed parentage of the code in question. All source code on XX is public read except where it is either a security risk to us or a violation of contract. Neither applies here. We might even be willing to handle tape distribution (probably unnecessary given that this is network specific code) at cost + beer money. I'd appreciate you comments. I'll be up at SRI for the rest of the week and will probably try to bang on the Stanford domain guru's doors. I really hope somebody can come up with a reasonable TOPS-20 version. Me too. Above acrimonious comments notwithstanding, I'd like to get something out in the field already. I'm willing to put some work into it, although not a whole lot. My C code is about 2/3 finished, assuming that the new SRI version of the KCC compiler and runtimes is more reliable than the old one from Stanford. If it looks like less work to finish the GTDOM% interface for that code I'll do that instead. I intend to keep using your nameserver in any case; I have no need or desire to write one of my own (well, maybe a stripped down TCP / Chaos-stream version for zone transfers, but that's a simple and special case). --Rob  0,, *** EOOH *** Rcvd-Date: 29-Oct-86 20:14:52-EST Mail-From: SRA created at 29-Oct-86 20:14:51 Date: Wed, 29 Oct 1986 20:14 EST Message-ID: From: Rob Austein To: klh@SRI-NIC.ARPA, ian@SRI-NIC.ARPA cc: sra@XX.LCS.MIT.EDU Subject: new KCC Could I get a tape copy of KCC? I've been trying to get it via FTP from SRI-NIC and from Sierra, but some of the files aren't world-readable and some of the sources are out of sync and the whole thing is a depressing mess. Should I send you a tape or send you money or what? I'd like to get this ASAP, I've got some domain code that I want to get debugged (the old Stanford KCC I have is so riddled with bugs that it's essentially useless for this). Thanks.... --Rob  0, answered,, *** EOOH *** Rcvd-Date: 29-Oct-86 20:47:23-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 29 Oct 86 20:47:20-EST Date: Wed 29 Oct 86 17:42:30-PST From: Ken Harrenstien Subject: Re: new KCC To: SRA@XX.LCS.MIT.EDU, ian@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12250794213.13.KLH@SRI-NIC.ARPA> When did you last try? As far as I know, everything is set up properly and I'd like specifics if it isn't. Retrieve the file KCCDIST:INSTAL.DOC for information. We are probably going to charge something like $100 for tapes as it is kind of a pain. There have been a couple of bug fixes to this release, so let me know after you have the stuff. Hmm, you aren't on INFO-KCC, are you? Otherwise you would have heard about the latest release...  0,, *** EOOH *** Rcvd-Date: 29-Oct-86 22:04:01-EST Mail-From: SRA created at 29-Oct-86 22:03:59 Date: Wed, 29 Oct 1986 22:03 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: Ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU Subject: New KCC In-reply-to: Msg of 29 Oct 1986 20:42-EST from Ken Harrenstien Date: Wednesday, 29 October 1986 20:42-EST From: Ken Harrenstien When did you last try? As far as I know, everything is set up properly and I'd like specifics if it isn't. Retrieve the file KCCDIST:INSTAL.DOC for information. I think all the code errors and sync errors are from the version from Sierra. The problems I've had getting the stuff from NIC are things like FTP trashing files (I've been retrieving with SET KEEP VERSION to try and keep generation numbers in sync, but when FTP loses on a transfer I end up with garbage even if I had a decent file before), at one point what looked like either a read protection error for every file I tried or else SS: was offline. Plus of course the usual hassles getting a connection to the machine at all. So except for the possible protection lossage it's not anything you did. The request for a tape was prompted by my housemate, who was getting tired of listening to me cuss as I experienced all these network hassles. We are probably going to charge something like $100 for tapes as it is kind of a pain. Well, the money isn't that much of an issue, but I'll try it again tonight at some dark hour and let you know if that wins. But some of the code isn't public read, is it? (Like KCCDIST:<.LIB.USYS>.) How do I get that stuff, or don't I? There have been a couple of bug fixes to this release, so let me know after you have the stuff. Hmm, you aren't on INFO-KCC, are you? Otherwise you would have heard about the latest release... Right, I'm not. Add me, please? I'm having a little more luck with the code I've already got since I got copies of LIBC and LIBCKX from NIC and recompiled/linked KCC itself to use extended addressing. Some of the code I'm using is reading a 40 page MONSYM.H file, which apparently eats more memory than's available in section zero. BTW, I have an implementation of FLD() (a la MACSYM.MAC) which is real handy for systems hacking. It's yours if you want it. In fact, being all of one line long, here it is, just hit your D key if you don't want it: #define FLD(bits,mask) ((((mask)&(-(mask)))*(bits))&(mask)) What are you using to generate your MACSYM.H and MONSYM.H files? I'm using the MIDAS syntax output from CVTUNV and reformatting it with TECO, but that's a bit of a pain. Thanks.... --Rob  0,, *** EOOH *** Rcvd-Date: 30-Oct-86 03:08:49-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Thu 30 Oct 86 03:08:43-EST Date: Thu 30 Oct 86 00:06:28-PST From: Ken Harrenstien Subject: Re: What happened this evening To: Vivian@SRI-NIC.ARPA, sys-staff@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA, sra@XX.LCS.MIT.EDU In-Reply-To: <12250622833.16.VIVIAN@SRI-NIC.ARPA> Message-ID: <12250864111.17.KLH@SRI-NIC.ARPA> KCCDIST on SS: is still trashed. In particular complains about bad directory format, and at least one other subdirectory, <.LIB>, is missing completely. This really makes me feel good when I just assured someone at MIT that KCCDIST contained our complete, consistent distribution and that he should get everything from there! Please flush that directory and completely restore it. It should not have had any changes for at least a couple of weeks.  0, answered,, *** EOOH *** Rcvd-Date: 30-Oct-86 03:14:23-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Thu 30 Oct 86 03:14:11-EST Date: Thu 30 Oct 86 00:12:23-PST From: Ken Harrenstien Subject: Re: New KCC To: SRA@XX.LCS.MIT.EDU cc: Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12250865188.17.KLH@SRI-NIC.ARPA> I'll add you to INFO-KCC. I just found that KCCDIST got royally messed up in a recent disk failure and someone neglected to restore it properly, so hold off on your transfer attempt until further notice. Sorry... I'll forward the NEWS.TXT file in another message so you'll know what the stuff contains. I don't think we use anything to generate MACSYM.H or MONSYM.H; we just took what Sierra had. Since most of our code is oriented towards portability and uses STDIO whenever possible, we haven't had much need for most of the OS symbols. As you noticed, the sheer number of them does cause problems.  0,, *** EOOH *** Rcvd-Date: 30-Oct-86 03:18:39-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Thu 30 Oct 86 03:18:36-EST Date: Thu 30 Oct 86 00:16:47-PST From: Ken Harrenstien Subject: news.txt To: sra@XX.LCS.MIT.EDU cc: klh@SRI-NIC.ARPA, ian@SRI-NIC.ARPA Message-ID: <12250865990.17.KLH@SRI-NIC.ARPA> On second thought you probably already have that (or have the latest C:CC.DOC) so it isn't necessary; you couldn't have made the extended version otherwise. Since you are presumably running with the stuff you got from our C: and SYS:CC.EXE I would suggest you stick with it until the 3rd distribution is ready, since there are a few bug fixes that will render the KCCDIST sources inconsistent with your current binaries (that is the price of gobbling things from C: instead of KCCDIST:).  0,, *** EOOH *** Rcvd-Date: 30-Oct-86 13:04:20-EST Mail-From: SRA created at 30-Oct-86 13:04:13 Date: Thu, 30 Oct 1986 13:04 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: Ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU Subject: New KCC In-reply-to: Msg of 30 Oct 1986 03:12-EST from Ken Harrenstien Ok, I will hold off on getting a new copy until I see a new distribution notice. I may write up the few lines of TECO code necessary to make MACSYM.H and MONSYM.H as an EMACS format library, since I'm tired of doing it by hand. It would be nice if things like fflush() worked "right" on network connections. This probably means using SOUTR% instead of SOUT%. Similarly, fclose() for TCP should probably do the kludge of using TCOPR% to send a FIN down the stream before closing it. In both of these cases the right place to do this stuff is probably down in close() and write() or someplace similar. Once I get a consistant set of sources I will probably code this up. Right now I'm just using my own network code with jsys() calls every four lines. Any changes I make you are of course welcome to. Thanks for the news, I'm relieved to know I wasn't halucinating although I'm sorry that the problem turned out to be a trashed disk. --Rob  0, answered,, *** EOOH *** Rcvd-Date: 30-Oct-86 14:49:14-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Thu 30 Oct 86 14:48:59-EST Date: Thu 30 Oct 86 11:43:17-PST From: Ian Macky Subject: Re: New KCC To: SRA@XX.LCS.MIT.EDU cc: klh@SRI-NIC.ARPA In-Reply-To: Message-ID: <12250990963.22.IAN@SRI-NIC.ARPA> i am using C code for a couple servers now. i used to use SOUTR's as the general-case output call, but that didn't seem right. then i put in a hook for "finish" at close time, that did the TCOPR; but then it was unnecessary for my application, since the C code was running as an inferior of the listening program, which did its own force and close after the inferior halted. the inferior just got its primary I/O redirected by the listener, and knew not to follow the re-direction and try to close the file itself. but perhaps that finish call (or _finish if an internal hook) ought to be put back in. dunno... --ian  0,, *** EOOH *** Rcvd-Date: 30-Oct-86 15:17:56-EST Mail-From: SRA created at 30-Oct-86 15:16:53 Date: Thu, 30 Oct 1986 15:16 EST Message-ID: From: Rob Austein To: Ian Macky Cc: klh@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU Subject: fflush() and SOUTR% In-reply-to: Msg of 30 Oct 1986 14:43-EST from Ian Macky The simplest sollution I can think of is to open the TCP connection in .TCMWH mode and then use SOUTR% for fflush(). This shouldn't load things too badly, and it has the advantage that the C code's idea of the buffering state has some vauge resemblance to reality. Chaosnet it shouldn't hurt to do SOUTR% all the time. This doesn't address people hacking tapes, but then I don't think the present code does either. I suppose another (really gross) way to deal with this would be a global variable that gets set to one or zero depending on whether the code wants SOUT% or SOUTR%. --Rob  0,, *** EOOH *** Rcvd-Date: 30-Oct-86 16:50:10-EST Mail-From: SRA created at 30-Oct-86 16:50:03 Date: Thu, 30 Oct 1986 16:50 EST Message-ID: From: Rob Austein To: bug-kcc@SRI-NIC.ARPA cc: sra@XX.LCS.MIT.EDU Subject: Bad generated code This might be the fault of the weird state my compiler/library etc are in. Here's what I get. Note the lack of an ADJSP at label "foo:" and the -2(P) offset in the LDB pointer. ---------------- Source file: ---------------- struct mumble { unsigned a : 2; unsigned b; }; foo(h) struct mumble *h; { int c; if(!h->a) return; } ---------------- FAIL output: ---------------- TITLE foo .REQUEST C:LIBc.REL $$CVER==<1,,1> INTERN $$CVER OPDEF ADJBP [IBP] DEFINE %CHRBP(A,M) < SETO A, ADJBP A,M > IFNDEF ERJMP,< OPDEF ERJMP [JUMP 16,] > OPDEF ERJMPA [ERJMP] OPDEF XMOVEI [SETMI] DEFINE IFIW TWOSEG 400000 RELOC 0 RELOC 400000 DEFINE %%CODE DEFINE %%DATA PURGE IFE,IFN,IFG,IFGE,IFL,IFLE,IFDEF,IFNDEF,IFIDN,IFDIF foo: LDB 4,[420237,,-2] CAIN 4,0 POPJ 17, POPJ 17, $$CPKI==0 INTERN $$CPKI $$CPKA==0 INTERN $$CPKA LIT EXTERN $$$CPU EXTERN $$$CRT INTERN foo END  0,, RemindNow, *** EOOH *** Rcvd-Date: 31-Oct-86 03:42:17-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Fri 31 Oct 86 03:42:14-EST Date: Fri 31 Oct 86 00:41:14-PST From: Ken Harrenstien Subject: Re: Bad generated code To: SRA@XX.LCS.MIT.EDU, bug-kcc@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12251132584.17.KLH@SRI-NIC.ARPA> Congratulations on finding a Real Bug. This has been fixed as of KCC 535. The problem was that whoever wrote the code to optimize out ADJSPs forgot to have it check for indexing in byte-pointer literals.  0, answered,, *** EOOH *** Rcvd-Date: 31-Oct-86 04:37:51-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Fri 31 Oct 86 04:37:16-EST Date: Fri 31 Oct 86 01:35:14-PST From: Ken Harrenstien Subject: Re: New KCC To: SRA@XX.LCS.MIT.EDU cc: Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12251142413.17.KLH@SRI-NIC.ARPA> As you say, the right place for any device-dependent stuff is in the lower-level "kernel" routines such as write() and close(). STDIO is supposed to use only those functions, in an attempt to keep it as portable as possible for unix-type systems. There is already a device-type index in the FD data structures, so special things can be done. I'd like to minimize those special things, though. For example, if you just open the connection in interactive mode, each SOUT% will force out the data as if a SOUTR% was done. You can still have complete control over the buffering, even with STDIO, by using setbuffer() and/or fflush(). Along the same lines, I'm not sure why the TCOPR% should be necessary to send a FIN, since CLOSF% of a TCP JFN is supposed to do this (as long as CZ%ABT is not set). As for MONSYM/MACSYM I'm trying to find out where those files came from. They are clearly machine generated. I suppose it would not be too hard to simply modify CVTUNV or (ideally) re-do it in C.  0,, *** EOOH *** Rcvd-Date: 31-Oct-86 13:07:22-EST Mail-From: SRA created at 31-Oct-86 13:07:20 Date: Fri, 31 Oct 1986 13:07 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: Ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU Subject: New KCC In-reply-to: Msg of 31 Oct 1986 04:35-EST from Ken Harrenstien All I can say about SOUT%/SOUTR% is that back about a year ago when I was (for some forgotten reason) doing FINGER protocol negotiations by hand from DDT, SOUT% did not work right (foreign machine never got query string) no matter what mode I used, but SOUTR% did work. The TCOPR% .TCFIN kludge is a well known screw in the TCP: device code (not in the BBN interface, this is something weird that DEC did that nobody has ever tracked down). Doing CLOSF% on a TCP: JFN does indeed send a FIN. But you will hang forever in the CLOSF% (waiting for the FIN on the input side of the bi-directional JFN). The three cannonical ways of coping with this are: get the other end to send you a FIN first (in which case CLOSF% doesn't hang), use TIMER% to break out of the CLOSF% then do a second CLOSF% with CZ%ABT set (which doesn't send a TCP RESET because the first CLOSF% already sent the FIN), or use TCOPR% to send the FIN by hand before going into the CLOSF% in the first place (which appears to work for some unfathomed reason). Of the three methods I find the TCOPR% one the least painful for use in generic programs. As you have probably noticed, the Twenex TCP code is somewhat, shall we say, eccentric. --Rob  0, answered,, *** EOOH *** Rcvd-Date: 31-Oct-86 13:24:35-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Fri 31 Oct 86 13:23:55-EST Date: Fri 31 Oct 86 10:18:25-PST From: Ken Harrenstien Subject: Re: New KCC To: SRA@XX.LCS.MIT.EDU cc: Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12251237658.17.KLH@SRI-NIC.ARPA> Well, inasmuch as SOUTR% is exactly like SOUT% except for certain devices (tape and TCP) it's OK to use that in write(). In fact this is just how UNIX handles raw mode output to magtape; each write() call outputs one record. As for the close(), I guess we can insert a special case for that. What bothers me is that the device type code for TCP: may differ depending on the particular site; our monitor here appears to use a Stanford conditional when it sets that value. Alternatively we could simply fix the case of CLOSF% on TCP:. I have looked at the code and suspect it can be fixed fairly easily (if it hasn't already been done for our version of the monitor).  0,, *** EOOH *** Rcvd-Date: 31-Oct-86 14:39:25-EST Mail-From: SRA created at 31-Oct-86 14:39:22 Date: Fri, 31 Oct 1986 14:39 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: Ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU Subject: New KCC In-reply-to: Msg of 31 Oct 1986 13:18-EST from Ken Harrenstien Date: Friday, 31 October 1986 13:18-EST From: Ken Harrenstien Well, inasmuch as SOUTR% is exactly like SOUT% except for certain devices (tape and TCP) it's OK to use that in write(). In fact this is just how UNIX handles raw mode output to magtape; each write() call outputs one record. Fine. As for the close(), I guess we can insert a special case for that. What bothers me is that the device type code for TCP: may differ depending on the particular site; our monitor here appears to use a Stanford conditional when it sets that value. I think that's just paranoia. DEC didn't put the symbol .DVTCP into MONSYM for some reason I have never figured out. I'm pretty sure all existing monitors use 025 for the value. You can always use #ifndef/#endif if you're worried about it. Alternatively we could simply fix the case of CLOSF% on TCP:. I have looked at the code and suspect it can be fixed fairly easily (if it hasn't already been done for our version of the monitor). If you are willing to do that it'd be a real win. You are probably one of the few people in the universe who has a chance of touching that code and living to tell the tale.... --Rob  1,, Rcvd-Date: 31-Oct-86 22:37:47-EST Return-Path: <@Score.Stanford.EDU:KLH@SRI-NIC.ARPA> Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP; Fri 31 Oct 86 22:37:30-EST Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 31 Oct 86 13:45:04-PST Date: Fri 31 Oct 86 13:44:19-PST From: Ken Harrenstien Subject: Device type 025? To: tops-20@SU-SCORE.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12251275139.17.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Friday, 31 October 1986 16:44-EST From: Ken Harrenstien To: tops-20@SU-SCORE.ARPA cc: klh@SRI-NIC.ARPA Re: Device type 025? There seems to be a conflict here. In MONSYM.MAC, the symbol .DVADS is defined as 025 for "AYDIN DISPLAY" (whatever that is). However, in the INIDVT table in STG.MAC (which sets up DEVCHR), 025 is used as the device type for the TCP: device. There is no .DVTCP symbol, although one would reasonably expect this. I find it hard to believe that the INIDVT table doesn't use symbolic .DVxxx constants, and even harder to believe that there is no .DVxxx for TCP:. This is for the 6.1 sources from Stanford. Considering the mess things are in, I'm not sure whether it is safe to write portable code which does a DVCHR% on a JFN to see whether it is a TCP stream or not.  0,, *** EOOH *** Rcvd-Date: 1-Nov-86 09:54:17-EST Return-Path: <@Score.Stanford.EDU:budd@BU-CS.BU.EDU> Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP; Sat 1 Nov 86 09:54:10-EST Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 05:40:01-PST Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id aa15685; 1 Nov 86 3:15 EST Received: by bu-cs.bu.edu (5.31/4.7) id AA16418; Sat, 1 Nov 86 01:46:54 EST Return-Path: Received: by bucsd.bu.edu (5.31/4.7) id AA26345; Sat, 1 Nov 86 01:46:48 EST Date: Sat, 1 Nov 86 01:46:48 EST From: budd@BU-CS.BU.EDU Message-Id: <8611010646.AA26345@bucsd.bu.edu> To: KLH@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA Subject: Re: Device type 025? I recall seeing that internal versions of 6.1 (pre release) used .DVNET (ie; the old NCP NET device) for TCP. You can always do a STDEV on /TCP/ to get a device designator. And determine the correct number from that. -phil  0,, *** EOOH *** Rcvd-Date: 1-Nov-86 04:03:29-EST Return-Path: <@Score.Stanford.EDU,@SUMEX-AIM.ARPA:MRC@PANDA> Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP; Sat 1 Nov 86 04:03:11-EST Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Nov 86 00:57:24-PST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 1 Nov 86 00:56:04-PST Date: Sat 1 Nov 86 00:43:12-PST From: Mark Crispin Subject: Re: Device type 025? To: KLH@SRI-NIC.ARPA cc: TOPS-20@Score.Stanford.EDU In-Reply-To: <12251275139.17.KLH@SRI-NIC.ARPA> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12251395085.7.MRC@PANDA> Ken - I agree that the absence of a .DVTCP symbol is a bug, but I don't believe it is a good idea to have device dependence unless it is absolutely necessary. That is, your routines that may run on more than just TCP streams should only use the device independent I/O jsi and *not* MTOPR%, TCOPR%, IPOPR%, etc. You should only have TCP-dependent code at a level which already knows that the stream is TCP. In case you didn't know, the preferred way to do a "push" on a TCP stream is to use SOUTR% instead of SOUT% when you want to push. This is device-independent. It requires a bit of discipline to be device-independent, but it is definitely possible. My network software is all device- independent. I have never needed to look up the device type via DVCHR%. I suspect this is true of DEC's programmers as well, which is probably why the DVCHR% types haven't been well-maintained. -- Mark --  0,, *** EOOH *** Rcvd-Date: 3-Nov-86 14:30:50-EST Mail-From: SRA created at 3-Nov-86 14:30:45 Date: Mon, 3 Nov 1986 14:30 EST Message-ID: From: Rob Austein To: Mark Crispin cc: klh@SRI-NIC.ARPA, sra@XX.LCS.MIT.EDU Subject: Device type 025? In-reply-to: Msg of 1 Nov 1986 03:43-EST from Mark Crispin As it happens the device dependent code KLH was talking about was something I suggested for the KCC low-level support code. Specificly, the kludge to do a TCOPR% .TCFIN call on a TCP JFN prior to closing it. I've looked at your code. You work around this lossage by using a TIMER% interrupt to get out of the hung CLOSF% call. That's not really appropriate for KCC, I think, which is why I suggested to Ken that he do it with TCOPR%. --Rob  0,, *** EOOH *** Rcvd-Date: 3-Nov-86 16:26:09-EST Mail-From: SRA created at 3-Nov-86 16:26:01 Date: Mon, 3 Nov 1986 16:26 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: KLH@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU Subject: winning C compiler? In-reply-to: Msg of 3 Nov 1986 14:13-EST from Alan Bawden It's been distributed for Twenex. I have a (slightly inconsistant) copy on XX. I don't think the ITS runtimes are finished. At this point it looks like the fastest path to getting code running on ITS would be to cross-compile C code to FAIL code on Twenex (with the right libraries) then assemble the FAIL code on ITS. Ugly, but it'll do to boostrap a copy of the compiler on ITS and debug the runtimes. Once that's done we can think about nice things like using MIDAS instead of FAIL. See XXSRC: KCCDIST.KCC; PORT DOC if you are interested in details. I don't know what Ken and Ian have been doing with this lately other than what's written in that file and in the comments alongside some of the runtime code. --Rob  0, answered,, *** EOOH *** Rcvd-Date: 3-Nov-86 17:45:59-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Mon 3 Nov 86 17:45:51-EST Date: Mon 3 Nov 86 13:43:49-PST From: Ken Harrenstien Subject: Re: winning C compiler? To: SRA@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU cc: KLH@SRI-NIC.ARPA, ian@SRI-NIC.ARPA In-Reply-To: Message-ID: <12252061482.14.KLH@SRI-NIC.ARPA> That's right, the ITS version of the runtimes isn't finished. There are still a couple of places in KCC itself which need some work in order to produce MIDAS code, so for the time being FAIL is the assembler of choice. If you read the last portion of PORT.DOC (about porting to ITS) you'll have an idea of the issues. The most important one, in my opinion, is STINK. I think the best way to proceed would be to modify STINK to understand DECREL format. We could conceivably modify the DEC loader to run on ITS, but I really want to avoid any source code legality problems. STINK will have to be fixed up anyway so that KCC can invoke it automatically with all the right arguments. One problem with MIDAS which I didn't mention is that MIDAS, unlike FAIL, makes no distinction between opcodes, labels, and random symbols (this is why OPDEFs are required in MACRO/FAIL). This means that there is a considerably greater chance of encountering a symbol conflict with MIDAS, for example if someone tries to write a function called "blt" or "move" or "setz". MIDAS also has many more pseudo names. Finally, remember that if KCC is ever spiffed up to output .REL files directly, those are going to be in DECREL format. Look around and think about it if you're interested.  1, answered,, Rcvd-Date: 4-Nov-86 18:35:01-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Tue 4 Nov 86 18:34:49-EST Date: Tue 4 Nov 86 14:38:59-PST From: Ken Harrenstien Subject: ITS LINK To: ALAN@AI.AI.MIT.EDU cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, KLH@SRI-NIC.ARPA In-Reply-To: <[AI.AI.MIT.EDU].114261.861104.ALAN> Message-ID: <12252333668.36.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Tuesday, 4 November 1986 17:38-EST From: Ken Harrenstien To: ALAN@AI.AI.MIT.EDU cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, KLH@SRI-NIC.ARPA Re: ITS LINK If we are real lucky, STINKR might be a STINK modified to know about DEC-type .REL files. I think it's worth looking into; at worst it might turn out to have a little more documentation in it, since AS would have had to learn something about STINK format. The obvious place to start looking is in the DM backup tape catalog. I guess that would mean restoring all of the .TAPE0 etc files somewhere and then searching them. The issue of the linking loader is really the most crucial problem. The C library can easily be fixed up for ITS; that's straightforward. FAIL already works on ITS, and there is even a STKTRN routine it can call which translates FAIL output into STINK format. But I have never actually tested it, and I'm not sure how reliable STINK is. I have looked at the STINK code recently, and it is a perfect example of how not to write programs -- pages of uncommented code, lots of funnies played with the stack pointer, lots of numerical constants... sigh. If there were just some description of STINK format somewhere it would be vastly easier to decide what to do. In particular, whether to stay with STINK or switch to DECREL. I wish we could load DECREL format files. It used to be possible with the DECUUO program. I looked at the current DEC linking loader source. It has nigh upwards of 15-20 modules each of which starts with two pagefuls of dire warnings about licensing and copyrighting and restrictions and stuff, which makes me uncomfortable. If we could dig up the source for an older version of LINK (say, from TENEX, or even from the ITS DECUUO stuff) then we could probably adapt it easily and live with that. An even more radical suggestion would be to adopt the GNU relocatable file format, and then simply run the GNU loader (written in C). This would have the advantage of being much easier to maintain, and allowing us to hack long symbol names, and that sort of thing. I suspect it is too much work for now, however.  1,, Rcvd-Date: 4-Nov-86 20:02:09-EST Mail-From: SRA created at 4-Nov-86 20:02:07 Date: Tue, 4 Nov 1986 20:02 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: ALAN@AI.AI.MIT.EDU, ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU Subject: ITS LINK In-reply-to: Msg of 4 Nov 1986 17:38-EST from Ken Harrenstien *** EOOH *** Date: Tuesday, 4 November 1986 20:02-EST From: Rob Austein To: Ken Harrenstien cc: ALAN@AI.AI.MIT.EDU, ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU Re: ITS LINK I don't think STINKR groks DECREL format. Its strengths were things like multiple automaticly relocatable PSECTS, which would allow us to have the high segment automaticly get put right after the low segment and thus leave much more of the limited one section address space for use by malloc() and the stack. Again, JTW is probably the only person who knows about this anymore. He also made it fairly clear that (1) he knows he's the logical person to work on this project and (2) that he doesn't have time. I suspect he's right on both counts.  1,, Rcvd-Date: 4-Nov-86 23:00:40-EST Received: from SPEECH.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 4 Nov 86 23:00-EST Date: Tue 4 Nov 86 23:01:39-EST From: "John Wroclawski" Subject: Re: ITS LINK To: SRA@XX.LCS.MIT.EDU, KLH@SRI-NIC.ARPA cc: ALAN@AI.AI.MIT.EDU, ian@SRI-NIC.ARPA Message-ID: <12252392408.38.JTW@MIT-SPEECH> *** EOOH *** Date: Tuesday, 4 November 1986 23:01-EST From: "John Wroclawski" To: SRA@XX.LCS.MIT.EDU, KLH@SRI-NIC.ARPA cc: ALAN@AI.AI.MIT.EDU, ian@SRI-NIC.ARPA Re: ITS LINK So, KLH is dead right as usual. STINKR is a Snyderism written in C some ages ago to support the portable C compiler he did for his MS thesis. It groks STINK format only, with the further kludge that it is able to do PSECT-like things when used in conjunction with a set of macros he wrote for MIDAS. It worked OK but not perfectly; since MIDAS doesn't -really- have multiple program counters it used an expanded highseg-loseg approach, with the obvious problems resulting if you made any one segment too big or used large negative offsets. It had a couple of other nice features, being able to run init code in the linked-image address space, etc. The source for STINKR is locked up in an encrypted file on an XX backup tape somewhere. We might find it but the only people that ever knew the key were AS and Elliot Moss. So it's not a great idea. But if someone finishes up the MIDAS code for KCC we could use it, at least for bootstrapping. I remember looking at STINK once a while back and deciding it was hopeless. I suppose it would be a little more reasonable if we had some documentation on the format. Apparently Alan has found some internal doc of some sort which might help. Does anyone hack FAIL anymore? How hard would it be to get it to accept long symbol names and spit out the appropriate "new" DEC Rel block types?  1,, Rcvd-Date: 5-Nov-86 03:00:52-EST Received: from AI.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Nov 86 03:00-EST Date: Wed, 5 Nov 86 03:02:33 EST From: Alan Bawden Subject: ITS LINK To: KLH@SRI-NIC.ARPA cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU In-reply-to: Msg of Tue 4 Nov 86 14:38:59-PST from Ken Harrenstien Message-ID: <[AI.AI.MIT.EDU].114530.861105.ALAN> *** EOOH *** Date: Wednesday, 5 November 1986 03:02-EST From: Alan Bawden To: KLH@SRI-NIC.ARPA cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU Re: ITS LINK Date: Tue 4 Nov 86 14:38:59-PST From: Ken Harrenstien ... FAIL already works on ITS, and there is even a STKTRN routine it can call which translates FAIL output into STINK format. But I have never actually tested it, and I'm not sure how reliable STINK is. I have looked at the STINK code recently, and it is a perfect example of how not to write programs -- pages of uncommented code, lots of funnies played with the stack pointer, lots of numerical constants... sigh. If there were just some description of STINK format somewhere it would be vastly easier to decide what to do. In particular, whether to stay with STINK or switch to DECREL. I wish we could load DECREL format files. It used to be possible with the DECUUO program.... Currently in JTW's possession is a file of handwritten documents that Moon and Penny found somewhere that seems to describe STINK format. It looks like it is written in Linear A to me, but perhaps he can make something of it. Is it really the case that DECUUO can no longer deal with DECREL files? (I've never done this, but apparently this is what SYS1;TS CCL is all about. It hasn't been changed since 1976.) [The DECSYS directory has been GFR'd severely while it lived on the KL. Maybe I should take the time to restore it completely.]  1,, Rcvd-Date: 5-Nov-86 06:04:03-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 5 Nov 86 06:03:59-EST Date: Wed 5 Nov 86 03:03:36-PST From: Ken Harrenstien Subject: Re: ITS LINK To: ALAN@AI.AI.MIT.EDU cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, KLH@SRI-NIC.ARPA In-Reply-To: <[AI.AI.MIT.EDU].114530.861105.ALAN> Message-ID: <12252469222.36.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Wednesday, 5 November 1986 06:03-EST From: Ken Harrenstien To: ALAN@AI.AI.MIT.EDU cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, JTW@AI.AI.MIT.EDU, MOON@AI.AI.MIT.EDU, KLH@SRI-NIC.ARPA Re: ITS LINK I re-discovered the STKTRN routine (in SAIL;STKTRN 39) and it, at least, is somewhat better commented, so it might help. Interestingly enough it appears to work not by using FAIL data structures, but by converting from ready-to-output DECREL format blocks into STINK format blocks! So it could perhaps be extracted into a separate program. Now all we need is the reverse-transformation routine! I looked at FAIL and I'd say that it is in good shape; it should be possible to build a new version of ITS FAIL from the latest source with little trouble. One thing to remember is that FAIL can apparently output either a STINK or DECREL format file with full relocatable hackery, whereas MIDAS can only do this for STINK format. Oh, MIDAS can output a DECREL format file, but it does not have the ability to do polish fixups etc in this format; the necessary code was never written (in fact, DECREL inside MIDAS is almost the same thing as an absolute assembly). Since all KCC needs is a fast assembler without hairy macros or anything, it looks like FAIL might be the better bet initially. About DECUUO -- I only meant that I had the impression DECUUO was semi-broken owing to the severe GFR-age. I imagine that if everything was restored, it would work as it used to. Of particular interest would be restoration of the linking loader source code! I'm not even sure if this ever existed, however; given the DECUUO simulation stuff, it would only be necessary to snarf the binary from a DEC system, and this may have been what MRC did. If anyone has contacts at DEC it may be possible to get permission to use the current LINK source. I can't see what they have to lose.  1,, Rcvd-Date: 5-Nov-86 17:00:21-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 5 Nov 86 16:59:41-EST Date: Wed 5 Nov 86 13:53:43-PST From: Ken Harrenstien Subject: Re: ITS LINK To: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: <12252392408.38.JTW@MIT-SPEECH> Message-ID: <12252587571.36.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Wednesday, 5 November 1986 16:53-EST From: Ken Harrenstien To: JTW%MIT-SPEECH@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Re: ITS LINK To answer JTW's question about FAIL, nobody really hacks it any more, in the sense that nobody hacks MIDAS any more; it is more or less mature and it basically isn't worth adding new features. It would be more useful to add direct .REL generation to KCC. the new long-symbol DEC block types aren't really used much, I suspect. Certainly DDT has no idea what to do with the resulting symbols, anyway!  1, answered,, Rcvd-Date: 7-Nov-86 22:18:39-EST Received: from SPEECH.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 7 Nov 86 22:18-EST Date: Fri 7 Nov 86 22:18:18-EST From: "John Wroclawski" Subject: Re: ITS LINK To: ALAN@AI.AI.MIT.EDU, KLH@SRI-NIC.ARPA cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, MOON@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].114530.861105.ALAN> Message-ID: <12253170947.32.JTW@MIT-SPEECH> *** EOOH *** Date: Friday, 7 November 1986 22:18-EST From: "John Wroclawski" To: ALAN@AI.AI.MIT.EDU, KLH@SRI-NIC.ARPA cc: ian@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, MOON@AI.AI.MIT.EDU Re: ITS LINK STINK is now somewhat documented; see .INFO.;STINK DOC. ITS FAIL produces STINK format output by default; I tried things out on a couple of very simple FAIL programs and it did the right thing.  0,, *** EOOH *** Date: Fri, 14 Nov 86 15:48 EST From: Rob Austein Subject: 8 bit characters? To: bug-kcc@SRI-NIC.ARPA cc: sra@XX Message-ID: <861114154833.1.SRA@WHORFIN.LCS.MIT.EDU> How difficult would it be to add support for 8-bit characters (-x=ch8 or some such)? It would be Real Useful for two reasons: 1) Certain things, eg UDP packets, have to be formatted into left justified 8 bit bytes because of operating system limitations. 2) It turns out to be extremely useful to have network data in 8 bit bytes even when it is coming from some stream protocol, because it is much easier to extract header fields by casting structs and extracting bitfields. Such header fields often cross byte boundries but rarely cross word boundries. In both of these cases I currently kludge things by using a five line assembly routine to convert from 9 to 8 bit pointers. But it would be real nice to just compile with the right switches and let the machine do the dirty work. Lot more portable too. Seems like it shouldn't be much trouble, especially compared to 7 bit bytes. --Rob  1,, Rcvd-Date: 14-Nov-86 20:50:13-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Fri 14 Nov 86 20:50:07-EST Date: Fri 14 Nov 86 17:50:09-PST From: Ken Harrenstien Subject: Re: 8 bit characters? To: sra@XX.LCS.MIT.EDU, bug-kcc@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: <861114154833.1.SRA@WHORFIN.LCS.MIT.EDU> Message-ID: <12254989909.16.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Friday, 14 November 1986 20:50-EST From: Ken Harrenstien To: sra@XX.LCS.MIT.EDU, bug-kcc@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA Re: 8 bit characters? Well, this would not be portable, anyway, since even for 8-bit-byte machines you cannot predict what the byte ordering is going to be! So your struct declarations aren't going to work (at least, not portably) and you will always need some machine dependent knowledge in order to combine bytes into integer values, etc. I'm not too thrilled about the idea of -x=ch8 because code compiled for 8-bit bytes won't necessarily match up properly with code compiled for 9-bit bytes. To be safe, everything (including the library) should be compiled with the same setting; but funny things will happen with the library (eg STDIO won't be able to read 36-bit or 9-bit files, and who knows what else). It is possible to win (eg as for 7-bit bytes) only if you know what you are doing and are real careful. It's true that most KCC code will work with 7,8, or 9, but the catch is "most". I'd say that using a hack routine to do your own casting conversion, as you seem to be doing now, is the best idea. A more ambitious notion would be to define additional types such as "char7" and "char8" (and I suppose "char9" for completeness). When using KCC these would be significant; for other systems a typedef or macro would convert them to simple "char". I'm not sure how useful these would be or whether it is worth messing around with more incompatible extensions to C; comments welcome.  1, answered,, Rcvd-Date: 11-Feb-87 00:48:09-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 11 Feb 87 00:47:34-EST Date: Tue 10 Feb 87 12:24:43-PST From: Ken Harrenstien Subject: Forthcoming KCC changes; comments? To: info-kcc@SRI-NIC.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12277999337.15.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Tuesday, 10 February 1987 15:24-EST From: Ken Harrenstien To: info-kcc@SRI-NIC.ARPA cc: klh@SRI-NIC.ARPA Re: Forthcoming KCC changes; comments? First, the news. I am almost finished with a new version of KCC which has some incompatible changes: (1) Functions that return structures now operate differently. (2) The "short" data type is now 18 bits (halfword) instead of 36. (3) Structure/union members of type "char" and "short" are compacted. (4) String literals are now normally 9-bit byte strings (not 7-bit). and, of course, several improvements: * Structure copying and returning is much more efficient, using in-line BLT or XBLT and sometimes avoiding the stack altogether. * Integer narrowing and widening is done properly in all situations. * Pointer constant initialization happens at load time rather than run time, reducing the size and startup overhead for C programs. * Unsigned integer arithmetic is completely implemented. And second, a request for feedback: I'd like to propose an extension which recent internal changes have now made possible, and see what you think. This extension would amount to adding 5 new KCC-specific data types which would be called "_KCCtype_charN" where N is one of 6, 7, 8, 9, or 18. These will act exactly like "char" except that the bytesize would be N rather than the default 9. Consider these declarations: _KCCtype_char8 packet[40]; /* An array of 8-bit bytes */ _KCCtype_char7 *arg = "text"; /* A pointer to an ASCIZ string */ _KCCtype_char18 useless; /* Same as "short useless;" */ _KCCtype_char6 tmp[] = "tmp"; /* An array of SIXBIT chars */ In addition, there will be two special cases of interaction between these types and string literals: (1) A 6-bit string literal will be stored as SIXBIT rather than using the low 6 bits of the ASCII char values. This does not affect integer values stored into 6-bit arrays. (2) A cast of a string literal to (_KCCtype_charN *) will be interpreted as a request to use N-bit bytes in the literal, rather than just operating on the pointer to the literal (the strict C interpretation). For example, (_KCCtype_char7 *)"text" Will produce a 7-bit pointer to a 7-bit (ASCIZ) string. Strict C would otherwise make a 7-bit ptr to a 9-bit string, which is kind of useless. Here are the pros and cons I could think of: PRO: * It will make it easier to write PDP-10 code which must interface with the operating system or non-C software. * It should be possible to completely flush the -x=ch7 switch, which (in my opinion) has too much potential for trouble, as it changes "char" to "_KCCtype_char7" EVERYWHERE, and certain things cannot be made to work right. CON: * It may cause problems when porting code from elsewhere which uses those identifiers. * It may tempt some people to write non-portable code when portable code would work just as well. The last two points are the reason why the type names are "_KCCtype_charN" instead of "charN". This almost eliminates the chance of identifier conflict, and forces lazy people to think twice. It also encourages them to use a #define or typedef instead (e.g. "typedef _KCCtype_char7 char7;") which makes programs both more readable and more amenable to porting. I would like comments on this proposed extension. In particular I need to hear from anyone who depends on -x=ch7, because I would like to flush that switch altogether. Thanks, --Ken  0, answered,, KCC, *** EOOH *** Rcvd-Date: 11-Feb-87 00:48:09-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Wed 11 Feb 87 00:47:34-EST Date: Tue 10 Feb 87 12:24:43-PST From: Ken Harrenstien Subject: Forthcoming KCC changes; comments? To: info-kcc@SRI-NIC.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12277999337.15.KLH@SRI-NIC.ARPA> First, the news. I am almost finished with a new version of KCC which has some incompatible changes: (1) Functions that return structures now operate differently. (2) The "short" data type is now 18 bits (halfword) instead of 36. (3) Structure/union members of type "char" and "short" are compacted. (4) String literals are now normally 9-bit byte strings (not 7-bit). and, of course, several improvements: * Structure copying and returning is much more efficient, using in-line BLT or XBLT and sometimes avoiding the stack altogether. * Integer narrowing and widening is done properly in all situations. * Pointer constant initialization happens at load time rather than run time, reducing the size and startup overhead for C programs. * Unsigned integer arithmetic is completely implemented. And second, a request for feedback: I'd like to propose an extension which recent internal changes have now made possible, and see what you think. This extension would amount to adding 5 new KCC-specific data types which would be called "_KCCtype_charN" where N is one of 6, 7, 8, 9, or 18. These will act exactly like "char" except that the bytesize would be N rather than the default 9. Consider these declarations: _KCCtype_char8 packet[40]; /* An array of 8-bit bytes */ _KCCtype_char7 *arg = "text"; /* A pointer to an ASCIZ string */ _KCCtype_char18 useless; /* Same as "short useless;" */ _KCCtype_char6 tmp[] = "tmp"; /* An array of SIXBIT chars */ In addition, there will be two special cases of interaction between these types and string literals: (1) A 6-bit string literal will be stored as SIXBIT rather than using the low 6 bits of the ASCII char values. This does not affect integer values stored into 6-bit arrays. (2) A cast of a string literal to (_KCCtype_charN *) will be interpreted as a request to use N-bit bytes in the literal, rather than just operating on the pointer to the literal (the strict C interpretation). For example, (_KCCtype_char7 *)"text" Will produce a 7-bit pointer to a 7-bit (ASCIZ) string. Strict C would otherwise make a 7-bit ptr to a 9-bit string, which is kind of useless. Here are the pros and cons I could think of: PRO: * It will make it easier to write PDP-10 code which must interface with the operating system or non-C software. * It should be possible to completely flush the -x=ch7 switch, which (in my opinion) has too much potential for trouble, as it changes "char" to "_KCCtype_char7" EVERYWHERE, and certain things cannot be made to work right. CON: * It may cause problems when porting code from elsewhere which uses those identifiers. * It may tempt some people to write non-portable code when portable code would work just as well. The last two points are the reason why the type names are "_KCCtype_charN" instead of "charN". This almost eliminates the chance of identifier conflict, and forces lazy people to think twice. It also encourages them to use a #define or typedef instead (e.g. "typedef _KCCtype_char7 char7;") which makes programs both more readable and more amenable to porting. I would like comments on this proposed extension. In particular I need to hear from anyone who depends on -x=ch7, because I would like to flush that switch altogether. Thanks, --Ken  1,, RemindNow, Rcvd-Date: 8-Mar-87 04:01:33-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Sun 8 Mar 87 04:01:12-EST Date: Fri 6 Mar 87 19:41:51-PST From: Ken Harrenstien Subject: New KCC is ready! To: info-kcc@SRI-NIC.ARPA Message-ID: <12284370371.19.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Friday, 6 March 1987 22:41-EST From: Ken Harrenstien To: info-kcc@SRI-NIC.ARPA Re: New KCC is ready! Finally, after a lot of sweat and blood, a new KCC is ready with all of the features previously mentioned, plus a few more. This should be the last incompatible version for a long time, although new (compatible) versions will continue to spring up. Even as you read this, some sources will already have changed; there is still a long list of good and interesting things to do. This snapshot has been made following the dictum that "better is the enemy of good enough" -- a good distribution now is more useful than a better one later. A new, consistent set of sources is available from the usual place, the KCCDIST: directory on SRI-NIC.ARPA. Likewise, the latest binaries (if that is all you want) are SYS:CC.EXE, C:*.*.0, and C:*.*.0. While things have been pretty thoroughly tested here, there is always a small possibility that new bugs will emerge when presented with the outside world; please send any comments, problems, and suggestions to BUG-KCC@SRI-NIC.ARPA. Here follows the relevant excerpt from NEWS.TXT that summarizes the changes: ----------------------------- 03/06/87 KCC 557, LIBC 124: <2,,1> Third formal distribution snapshot IMPORTANT: this version of KCC is incompatible with previous versions! The way that structures are returned from functions has changed, and the layout of "char" and "short" objects in structures has also changed. In order to enforce this, the symbol $$CVER has been updated, and any attempt to load .REL modules which have been produced by incompatible versions of KCC will cause LINK to complain with an error message similar to this: %LNKMDS Multiply-defined global symbol $$CVER Detected in module PRINTF from file C:LIBC.REL Defined value = 1000001, this value = 2000001 This is easily remedied by re-compiling old modules. Fortunately, no further incompatible changes are expected to be necessary. Nothing has really changed from the user's viewpoint. However, there are several new features available, and some inefficiencies corrected. The noteworthy changes are listed below, very briefly; as usual, CC.DOC should be consulted for more complete and informative details. KCC: --------------------------------------------------------------- KCC - Bug fixes: A multitude of minor bug fixes too trivial to mention, almost all having to do with incorrectly optimized code. One that wasn't trivial was that {char c, *cp = &c;} used to produce an (int *)! KCC - Incompatible changes: * "shorts" are now 18 bits long (halfwords), with sizeof(short) == 2. * The mechanism for returning structure values from functions is different. This is an internal change, invisible to the user, which is much more efficient than the previous method. * Structure members of type "char" and "short" are now packed differently (more compactly). Any structure using these types will be laid out differently in storage. * Integer narrowing and widening is now done properly in all situations. This may cause incorrectly written code to behave differently. * Implicit arithmetic conversions now follow the ANSI value-preserving rules rather than the old K&R and H&S unsigned-preserving rules. Ambiguous code may behave differently. * "float" values are no longer automatically converted to "double", except for function arguments. This conforms to the ANSI draft. * The "signed" keyword (introduced by ANSI) has been implemented. * "volatile" and "const" (also new from ANSI) are now reserved words (but unimplemented). KCC - Extension: New data types: 5 new data types have been introduced, which act like "char" but with different byte sizes. You can now manipulate signed or unsigned bytes of 6, 7, 8, 9, or 18 bits. This is non-portable and intended strictly for PDP-10 machine-dependent code where efficiency is desirable. KCC - Efficiency improvements: The change to the structure handling mechanism falls in this category. Structure copies used to always take two subroutine calls and two copies; they now use a single in-line BLT (or a series of single-word moves, whichever is best), and are much faster than element-by-element copying. KCC's constant initialization code has been improved to the point where almost all constants are now initialized at load time rather than at run time; a similar mechanism eliminates the code that used to generate string constant pointers. You will see a significant difference with code that uses many string literals; both startup time and program size are reduced. KCC's pointer arithmetic for byte pointers is MUCH better. Pointer comparison and subtraction formerly used subroutine calls and many, many instructions; both now use a handful of in-line instructions and some magic numbers. There are no more calls to internal run-time subroutines. All of the operations which used to require this are now compiled in-line, including double-int and int-double conversion, pointer operations, and structure copying. KCC - unsigned and signed data: KCC now fully supports "unsigned int" operations. Some code that uses unsigned integers will now compile differently. Division in particular needs many more instructions. Any integer type, "char" in particular, may be declared as "signed" and will behave accordingly. KCC - Switch changes: -L= Passes in the command string to the linking loader. -v= (Verbosity) has been expanded; see CC.DOC. -v alone prints out everything, including the loader command string. -l Libraries loaded with the -l switch are now loaded in /SEARCH mode (they evidently weren't before). KCC - Miscellaneous -d=sym now produces a *.CYM file instead of *.SYM, to avoid conflicts with LINK output files. -P=ansi+kcc is now the default. The effects are minor and documented in CC.DOC. The three new ANSI keywords of "signed", "const", and "volatile" are recognized, although only the first has any real effect. LIBC: --------------------------------------------------------------- More minor bug fixes to the LIBC stdio routines. open() now attempts to track down and expand logical device names completely (thus performing what the monitor should be doing but isn't). Thus, open("X:subdir/filename.ext",0) will work even if X is a search path. Previously only the first device/directory could be tried. This permits KCC #includes to work with C: defined as a search path. malloc() no longer allocates pages 770-777 (non-extended) or 37770-37777 (extended), so that obsolete forms of DDT can be mapped therein.  0,, KCC, RemindNow, *** EOOH *** Rcvd-Date: 8-Mar-87 04:01:33-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Sun 8 Mar 87 04:01:12-EST Date: Fri 6 Mar 87 19:41:51-PST From: Ken Harrenstien Subject: New KCC is ready! To: info-kcc@SRI-NIC.ARPA Message-ID: <12284370371.19.KLH@SRI-NIC.ARPA> Finally, after a lot of sweat and blood, a new KCC is ready with all of the features previously mentioned, plus a few more. This should be the last incompatible version for a long time, although new (compatible) versions will continue to spring up. Even as you read this, some sources will already have changed; there is still a long list of good and interesting things to do. This snapshot has been made following the dictum that "better is the enemy of good enough" -- a good distribution now is more useful than a better one later. A new, consistent set of sources is available from the usual place, the KCCDIST: directory on SRI-NIC.ARPA. Likewise, the latest binaries (if that is all you want) are SYS:CC.EXE, C:*.*.0, and C:*.*.0. While things have been pretty thoroughly tested here, there is always a small possibility that new bugs will emerge when presented with the outside world; please send any comments, problems, and suggestions to BUG-KCC@SRI-NIC.ARPA. Here follows the relevant excerpt from NEWS.TXT that summarizes the changes: ----------------------------- 03/06/87 KCC 557, LIBC 124: <2,,1> Third formal distribution snapshot IMPORTANT: this version of KCC is incompatible with previous versions! The way that structures are returned from functions has changed, and the layout of "char" and "short" objects in structures has also changed. In order to enforce this, the symbol $$CVER has been updated, and any attempt to load .REL modules which have been produced by incompatible versions of KCC will cause LINK to complain with an error message similar to this: %LNKMDS Multiply-defined global symbol $$CVER Detected in module PRINTF from file C:LIBC.REL Defined value = 1000001, this value = 2000001 This is easily remedied by re-compiling old modules. Fortunately, no further incompatible changes are expected to be necessary. Nothing has really changed from the user's viewpoint. However, there are several new features available, and some inefficiencies corrected. The noteworthy changes are listed below, very briefly; as usual, CC.DOC should be consulted for more complete and informative details. KCC: --------------------------------------------------------------- KCC - Bug fixes: A multitude of minor bug fixes too trivial to mention, almost all having to do with incorrectly optimized code. One that wasn't trivial was that {char c, *cp = &c;} used to produce an (int *)! KCC - Incompatible changes: * "shorts" are now 18 bits long (halfwords), with sizeof(short) == 2. * The mechanism for returning structure values from functions is different. This is an internal change, invisible to the user, which is much more efficient than the previous method. * Structure members of type "char" and "short" are now packed differently (more compactly). Any structure using these types will be laid out differently in storage. * Integer narrowing and widening is now done properly in all situations. This may cause incorrectly written code to behave differently. * Implicit arithmetic conversions now follow the ANSI value-preserving rules rather than the old K&R and H&S unsigned-preserving rules. Ambiguous code may behave differently. * "float" values are no longer automatically converted to "double", except for function arguments. This conforms to the ANSI draft. * The "signed" keyword (introduced by ANSI) has been implemented. * "volatile" and "const" (also new from ANSI) are now reserved words (but unimplemented). KCC - Extension: New data types: 5 new data types have been introduced, which act like "char" but with different byte sizes. You can now manipulate signed or unsigned bytes of 6, 7, 8, 9, or 18 bits. This is non-portable and intended strictly for PDP-10 machine-dependent code where efficiency is desirable. KCC - Efficiency improvements: The change to the structure handling mechanism falls in this category. Structure copies used to always take two subroutine calls and two copies; they now use a single in-line BLT (or a series of single-word moves, whichever is best), and are much faster than element-by-element copying. KCC's constant initialization code has been improved to the point where almost all constants are now initialized at load time rather than at run time; a similar mechanism eliminates the code that used to generate string constant pointers. You will see a significant difference with code that uses many string literals; both startup time and program size are reduced. KCC's pointer arithmetic for byte pointers is MUCH better. Pointer comparison and subtraction formerly used subroutine calls and many, many instructions; both now use a handful of in-line instructions and some magic numbers. There are no more calls to internal run-time subroutines. All of the operations which used to require this are now compiled in-line, including double-int and int-double conversion, pointer operations, and structure copying. KCC - unsigned and signed data: KCC now fully supports "unsigned int" operations. Some code that uses unsigned integers will now compile differently. Division in particular needs many more instructions. Any integer type, "char" in particular, may be declared as "signed" and will behave accordingly. KCC - Switch changes: -L= Passes in the command string to the linking loader. -v= (Verbosity) has been expanded; see CC.DOC. -v alone prints out everything, including the loader command string. -l Libraries loaded with the -l switch are now loaded in /SEARCH mode (they evidently weren't before). KCC - Miscellaneous -d=sym now produces a *.CYM file instead of *.SYM, to avoid conflicts with LINK output files. -P=ansi+kcc is now the default. The effects are minor and documented in CC.DOC. The three new ANSI keywords of "signed", "const", and "volatile" are recognized, although only the first has any real effect. LIBC: --------------------------------------------------------------- More minor bug fixes to the LIBC stdio routines. open() now attempts to track down and expand logical device names completely (thus performing what the monitor should be doing but isn't). Thus, open("X:subdir/filename.ext",0) will work even if X is a search path. Previously only the first device/directory could be tried. This permits KCC #includes to work with C: defined as a search path. malloc() no longer allocates pages 770-777 (non-extended) or 37770-37777 (extended), so that obsolete forms of DDT can be mapped therein.  0,, KCC, *** EOOH *** Rcvd-Date: 13-Mar-87 02:07:18-EST Mail-From: SRA created at 13-Mar-87 02:07:17 Date: Fri 13 Mar 87 02:07-EST From: Rob Austein Subject: KCC type extensions To: SRA@XX.LCS.MIT.EDU _KCCtype_char6 _KCCtype_char7 _KCCtype_char8 _KCCtype_char9 _KCCtype_char18  0, answered,, KCC, *** EOOH *** Rcvd-Date: 16-Mar-87 16:45:33-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Mon 16 Mar 87 16:45:28-EST Date: Mon 16 Mar 87 13:46:47-PST From: Ken Harrenstien Subject: Re: RESET% To: SRA@XX.LCS.MIT.EDU cc: Bug-KCC@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12286927173.16.KLH@SRI-NIC.ARPA> The RESET% isn't executed by jsys() as it is part of the low-level startup (look at the SSTART: label). I suspect that what you are seeing is yet another aspect of the brain-damaged way that TOPS-20 cleans things up; all that RESET% really seems to do is say "hey, do this if you've got a spare hour or two, will you" and then comes right back to the user program, which then tries to do something that fails because the cleanup hasn't yet actually been done! This often happens for JFNs. MIDAS, for example, is too fast for TOPS-20 and if you give a new MIDAS command the same as a previous one (which was interrupted) then you will often fail, because the old output-file JFN has not yet been cleared away. Most programs don't encounter this problem as it takes them a while to get around to doing whatever it is they are supposed to do. I bet you never knew that DEC software was designed to be slow!  0,, KCC, *** EOOH *** Rcvd-Date: 16-Mar-87 20:57:17-EST Mail-From: SRA created at 16-Mar-87 20:57:15 Date: Mon, 16 Mar 1987 20:57 EST Message-ID: From: Rob Austein To: Bug-KCC@SRI-NIC.ARPA cc: sra@XX.LCS.MIT.EDU Subject: Another bug for you (unions and structs, wrong code generated) I must admit that this is one of the more amusing compiler errors I can recall seeing. It is clearly on drugs by the time it gets to the return() statement.... Here's the C code: unsigned a,b,c,d; int atoina() { union { int number; struct { unsigned : 4; unsigned a : 8; unsigned b : 8; unsigned c : 8; unsigned d : 8; } address; } crock; crock.number = 0; crock.address.a = a; crock.address.b = b; crock.address.c = c; crock.address.d = d; return(crock.number); } And here's the FAIL code: TITLE kccbug .REQUEST C:LIBc.REL $$CVER==<2,,1> INTERN $$CVER OPDEF ADJBP [IBP] DEFINE %CHRBP(A,M) < SETO A, ADJBP A,M > IFNDEF ERJMP,< OPDEF ERJMP [JUMP 16,] > OPDEF ERJMPA [ERJMP] OPDEF XMOVEI [SETMI] DEFINE IFIW XBLT==<020000,,0> TWOSEG 400000 RELOC 0 RELOC 400000 DEFINE %%CODE DEFINE %%DATA PURGE IFE,IFN,IFG,IFGE,IFL,IFLE,IFDEF,IFNDEF,IFIDN,IFDIF %%DATA a: BLOCK 1 b: BLOCK 1 c: BLOCK 1 d: BLOCK 1 %%CODE atoina: PUSH 17,[0] MOVE 4,a DPB 4,[341017,,1] MOVE 5,b DPB 5,[241017,,1] MOVE 6,c DPB 6,[141017,,1] MOVE 7,d DPB 7,[41017,,1] MOVEI 1,0 ADJSP 17,-1 POPJ 17, $$CPKI==0 INTERN $$CPKI $$CPKA==0 INTERN $$CPKA LIT EXTERN $$$CPU EXTERN $$$CRT INTERN a INTERN b INTERN c INTERN d INTERN atoina END --Rob  0,, KCC, *** EOOH *** Rcvd-Date: 17-Mar-87 23:53:20-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Tue 17 Mar 87 23:53:16-EST Date: Tue 17 Mar 87 20:55:04-PST From: Ken Harrenstien Subject: Re: Another bug for you (unions and structs, wrong code generated) To: SRA@XX.LCS.MIT.EDU, Bug-KCC@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12287267283.17.KLH@SRI-NIC.ARPA> Boy, that one was tough. It's fixed now in the latest installed CC on SRI-NIC (see the INFO-KCC message). There were two separate problems, one having to do with unnamed bitfields in structures (this fouled up the too-clever trick that was being used to know whether struct/union parsing was at the start of a word or not!), and the other having to do with some more oversights in the peephole optimizer -- among other things the common subexpression code only had a limited knowledge of what instructions modified memory, and didn't realize that byte pointers could point to the same thing as normal instruction addressing. I am slowly fixing all of that by using tables which completely describe the behavior of every instruction, but full conversion will take quite a while. At least the fixed code now does better optimization than before!  0, answered,, KCC, *** EOOH *** Rcvd-Date: 20-Mar-87 03:24:19-EST Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP; Fri 20 Mar 87 03:24:15-EST Date: Fri 20 Mar 87 00:24:03-PST From: Ken Harrenstien Subject: KCC on ITS? To: sra@XX.LCS.MIT.EDU cc: klh@SRI-NIC.ARPA Message-ID: <12287829617.25.KLH@SRI-NIC.ARPA> Just noticed in one of your recent messages on ITS that you mumbled something about compiler conversion. I assume you were talking about KCC. Have any promising hackers shown up who are willing to brave the foul innards of STINK, etc. in return for fame and... well, just fame...? Once again, the problem is not the ITS support, which is easy to spiff up, or the assembler, since either MIDAS or FAIL can be used -- it is the linking loader, or lack thereof. I suppose if people are willing to always invoke STINK by hand, though, it would be workable. (ugh)  1,, Rcvd-Date: 25-Apr-87 03:46:58-EDT Mail-From: SRA created at 25-Apr-87 03:46:56 Date: Sat, 25 Apr 1987 03:46 EDT Message-ID: From: Rob Austein To: JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA, Moon@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU Subject: STINK for ITS KCC In-reply-to: Msg of 7 Nov 1986 22:18-EST from "John Wroclawski" *** EOOH *** Date: Saturday, 25 April 1987 03:46-EDT From: Rob Austein To: JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA, Moon@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU Re: STINK for ITS KCC So I seem to recall that somebody (KLH?) thought there was still some unsolved problem involved in having an ITS KCC invoke STINK. Maybe I'm dense, but what's wrong with stuffing the link script down a corelink then invoking STINK with JCL telling it to use that corelink file as input? Or even just translating "TTY:" opened in read mode to the corelink for STINK if for some reason the JCL thing doesn't work? We're not trying to be tasteful here or anything, are we? I'm out of town for the next week, so do expect a quick answer to any reply. --Rob  1,, Rcvd-Date: 25-Apr-87 05:03:41-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Sat 25 Apr 87 05:03:29-EDT Date: Sat 25 Apr 87 02:05:42-PDT From: Ken Harrenstien Subject: Re: STINK for ITS KCC To: SRA@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA, Moon@AI.AI.MIT.EDU cc: KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12297274383.19.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Saturday, 25 April 1987 05:05-EDT From: Ken Harrenstien To: SRA@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA, Moon@AI.AI.MIT.EDU cc: KLH@SRI-NIC.ARPA Re: STINK for ITS KCC Well, there IS an unresolved problem, but it doesn't have much to do with STINK invocation. As you point out, there are various hacks that can be used to pass strings to STINK (and twiddling STINK to make this simpler isn't much of an exercise). The problem has to do with how the C library routines are loaded. I'm not sure how to do it. There is, I believe, no such thing as a library of .REL files; STINK does not know how to search a library (the block type is there, but it is a no-op). There seem to be only two ways to do it: First, load the complete library .REL file, every time. Second, have a directory with all .REL modules in it, and check each and every .REL file in that directory to see if its definitions match any of the symbols needed by the program. This requires that the JCL to STINK specify each one of these filenames. I'm not even sure if the first approach is possible, since I'm not sure how to construct that single .REL file in the first place. As far as I know, ITS has no notion of a library file (containing more than one library module). The second approach might be do-able by keeping a sort of @ file in the directory, which can be gobbled by the invocation process, so that KCC doesn't have to know about all the files itself. It will, however, be rather slow. Whether this is unacceptable I don't know, but it will certainly not be as fast as a traditional library file search, and won't encourage people to use C. It would sure be nice if STINK knew how to do a real library search. It would sure be nice if anyone could hold his nose long enough to accomplish this or anything else. There is one other monkey wrench to consider. Namely, it is probably not a good idea to use MIDAS. The reason for this is that MIDAS does not distinguish between label symbols and opcode symbols. Thus you will be in deep shit if the C programmer has routines called things like "move" or "push". FAIL and MACRO differentiate the two usages (this is why their OPDEF pseudo is needed to define new ops). ITS FAIL is able to translate DECREL output into STINK-format output, but whether it does the right thing for library entry point linkages/requests I don't know. Actually, none of them is perfect since there is always the danger of a pseudo-op name conflicting with a user symbol (e.g. IFE, IFL, etc); only if KCC produced a binary REL directly could this be avoided (and if KCC were to do this, what format do you think it would use? Yep, DECREL.) For the time being we may simply have to ignore this problem and hope there are not too many conflicts; the UNIX AS assembler may not be immune to conflicts either. If anybody has ideas, please speak up... To give you some notion of what we are talking about, here is a listing of the current C library. The first name on each line is the module name, and all other names on the line are entry points. Sorry about the 132 column format. Listing of Modules and Entry points Produced by MAKLIB Version 2B(104) on 23-Apr-87 at 12:15:55 ************************** DSK:LIBC.REL[4,116] Created on 23-Apr-87 at 12:13:00 ABORT ABORT ATOI ATOF ATOI ATOL BSEARC BSEARC CLOCK CLOCK CPU $$$CPU CPUTM .CPUTM CRT $$$CRT $KCCID $STACS $STOFF $ZERO ..EXIT .EALLO .EDATA .END .ETEXT CTERMI CTERMI CUSERI CTIME ASCTIM CTIME DIFFTI GMTIME LOCALT MKTIME TIMEZO CTYPE .CTOIN .CTOLO .CTOUP .CTYP1 GETCWD GETCWD GETWD GETENV GETENV JSYS JSYS MALLOC CALLOC CFREE CLALLO FREE MALLOC MLALLO REALLO RELALL .FREE. .MEMOR .PALLO .PFREE MEMSTR BCMP BCOPY BZERO MEMCHR MEMCMP MEMCPY MEMSET MKTEMP MKTEMP ONEXIT .N.EXI .EXIT. ONEXIT PERROR PERROR PFORK PFORK QSORT QSORT SETJMP LONGJM SETJMP STRING STRCAT STRCHR STRCMP STRCPY STRCSP STRLEN STRNCA STRNCM STRNCP STRPBR STRPOS STRRCH STRRPB STRRPO STRSPN STRTOK STRSTR STRTOD STRTOL STRTOU STRUNG STR000 STR001 STR002 STR003 SYSTEM SYSTEM URT EXIT ERRNO .EXIT .RUNTM .VFRKF .NFORK .GETJC URTSUD .URTSU ACCESS ACCESS BUFPOS .BUFPO OPEN CREAT OPEN .GTJFN .OPENU .RLJFN .UIOCH .UIOCN .UIOCP .UIOEO .UIOFD .UIOFL .UIOFX .UIONO .UIOPB .UIOPO .UIOTY .UIOUF CLOSE CLOSE READ READ READLN STAT STAT XSTAT FSTAT XFSTAT .DVTYP .RCUSR .GTFDB .WHOAM WRITE WRITE LSEEK LSEEK TELL DUP DUP DUP2 FORK EXECL EXECLE EXECLP EXECV EXECVE EXECVP FORK VFORK GETPID GETPID PIPE PIPE RENAME RENAME SBRK BRK SBRK SIGNAL KILL SIGNAL SIGSYS SLEEP PAUSE SLEEP TIME FTIME GETTIM TIME .GLTAD .TADL2 .TADU2 UNLINK UNLINK WAIT WAIT CLEANU .CLEAN FCLOSE FCLOSE FDOPEN FDOPEN FFLUSH FFLUSH .PRIME FGETC FGETC .READA FGETS FGETS FILBUF .FILBU FOPEN .SIOS .FILE. FOPEN .MAKEF .FREEF FPUTC FPUTC .WRITE FPUTS FPUTS FREAD FREAD FREOPE FREOPE .SIOFL .SETFI FSEEK FSEEK FTELL FTELL FWRITE FWRITE GETS GETS GETW GETW PRINTF FPRINT PRINTF SPRINT PRF.BI PUTS PUTS PUTW PUTW REWIND REWIND SCANF FSCANF SCANF SSCANF SETBUF SETBUF .SETBU SETLIN .SOBUF SETVBU SOPEN SOPEN UNGETC UNGETC ABS ABS ACOS ACOS ASIN ASIN ATAN ATAN ATAN2 ATAN2 CEIL CEIL COS COS COSH COSH EXP EXP FABS FABS FLOOR FLOOR FMOD FMOD FREXP FREXP LABS LABS LDEXP LDEXP LOG LOG LOG10 LOG10 MODF MODF POW POW RAND SRAND RAND SIN SIN SINH SINH SQRT SQRT TAN TAN TANH TANH SIGN SIGN XMANT XMANT POLY POLY XEXP XEXP GETHST GTHENT GTHNAM GTHADR SETHOS ENDHOS GH.HOS GH.ADD GH.HEN  1,, Rcvd-Date: 25-Apr-87 10:04:13-EDT Return-Path: Received: from AI.AI.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Sat 25 Apr 87 10:04:11-EDT Date: Sat, 25 Apr 87 10:07:06 EDT From: Ed Schwalenberg Subject: C symbols conflict with Midas pseudos To: ALAN@AI.AI.MIT.EDU, sra@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU, klh@SRI-NIC.ARPA, ian@SRI-NIC.ARPA, moon@SCRC-STONY-BROOK.ARPA Message-ID: <191008.870425.ED@AI.AI.MIT.EDU> *** EOOH *** Date: Saturday, 25 April 1987 10:07-EDT From: Ed Schwalenberg To: ALAN@AI.AI.MIT.EDU, sra@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU, klh@SRI-NIC.ARPA, ian@SRI-NIC.ARPA, moon@SCRC-STONY-BROOK.ARPA Re: C symbols conflict with Midas pseudos KCC could prepend an "underscore", but then we'd be reduced to 5-character identifiers. So how about doing this only in the conflicting case? Since the set of Midas symbols that might cause conflict is known, and fairly short, it should be easy for a filter to clean up KCC's assembly-language output by changing symbols that are in conflict: DEFINE: PUSHJ P,AOS would become DEFIN%: PUSHJ P,AOS% It would even be possible for the filter to save the translations and later patch up the symbol table of the MIDAS output so you can conveniently say DEFINE/ to DDT. (AOS/ wouldn't work, but hey...). On the library issue, there are compilers that work by simply loading the entire library into one big .o file. This has two bugs: it wastes core, and it promotes names like "printf" to reserved-word status. Does STINK have the capability, known as -r to Unix ld, which says: "Link these objects together, but put out another object, which may still have undefined symbols in it"? If so, it would be simple to link all the user's .o files in that way, then examine the undefined symbol table of the resultant .o file for names which are in the library index, and run STINK again with the big .o file containing the user's code and the necessary set of "library" objects. I suggest these approaches because they require no changes to existing programs. They are simple, and can be written in any language of your choice (Lisp, Snyder C, and Midas come to mind). I have long forgotten what little PDP10 assembly language I knew, so I can't help with most of the problems you folks are working on, but I can write C programs of the sort mentioned above. If you agree it's the right thing, I'll be glad to write them..  1,, Rcvd-Date: 25-Apr-87 20:48:57-EDT Return-Path: Received: from AI.AI.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Sat 25 Apr 87 20:48:53-EDT Date: Sat, 25 Apr 87 20:51:13 EDT From: Ed Schwalenberg Subject: C symbols conflict with Midas pseudos To: ALAN@AI.AI.MIT.EDU, klh@SRI-NIC.ARPA, ian@SRI-NIC.ARPA, Moon@SCRC-STONY-BROOK.ARPA, sra@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU Message-ID: <191153.870425.ED@AI.AI.MIT.EDU> *** EOOH *** Date: Saturday, 25 April 1987 20:51-EDT From: Ed Schwalenberg To: ALAN@AI.AI.MIT.EDU, klh@SRI-NIC.ARPA, ian@SRI-NIC.ARPA, Moon@SCRC-STONY-BROOK.ARPA, sra@XX.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU Re: C symbols conflict with Midas pseudos Hmmm. Another way around the whole relocation mess would be to maintain "objects" and libraries as Midas code, and just do an absolute assembly of the whole thing. I remember claims from the distant past that Midas could absolutely assemble all of ITS about an order of magnitude faster than STINK (I think) could load all of WAITS.  1,, Rcvd-Date: 27-Apr-87 18:16:18-EDT Return-Path: Received: from STONY-BROOK.SCRC.Symbolics.COM by XX.LCS.MIT.EDU with TCP/SMTP; Mon 27 Apr 87 18:16:15-EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125567; Mon 27-Apr-87 18:12:04 EDT Date: Mon, 27 Apr 87 18:11 EDT From: David A. Moon Subject: Re: STINK for ITS KCC To: Ken Harrenstien cc: SRA@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA In-Reply-To: <12297274383.19.KLH@SRI-NIC.ARPA> Message-ID: <870427181149.3.MOON@EUPHRATES.SCRC.Symbolics.COM> *** EOOH *** Date: Monday, 27 April 1987 18:11-EDT From: David A. Moon To: Ken Harrenstien cc: SRA@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA Re: STINK for ITS KCC I think we've successfully used DEC's TOPS-10 LOADER, under DECUUO, to build programs runnable under ITS in the past. Unless someone has made that stop working, it might be the way to go. Remember that for right now we are only talking about making one, single C program run on ITS, so issues that would make it inconvenient to deal with a broad spectrum of C programs shouldn't be allowed to interfere.  1,, Rcvd-Date: 27-Apr-87 19:13:22-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Mon 27 Apr 87 19:13:06-EDT Date: Mon 27 Apr 87 16:14:34-PDT From: Ken Harrenstien Subject: Re: STINK for ITS KCC To: Moon@SCRC-STONY-BROOK.ARPA cc: SRA@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: <870427181149.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12297953201.19.KLH@SRI-NIC.ARPA> *** EOOH *** Date: Monday, 27 April 1987 19:14-EDT From: Ken Harrenstien To: Moon@SCRC-STONY-BROOK.ARPA cc: SRA@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Re: STINK for ITS KCC Well, I thought about the T10 loader. Trouble is, I believe it is very old, without some things we now need, and I don't think there is any source, or anything. There is also the MAKLIB program to consider. I'm not sure what "one program" this is that you are talking about, but assume it is SRA's domain stuff. If true, you could simply maintain software on a T20 and cross-compile it for ITS -- just need a trivial hack to dump out a DEC .EXE program image into an ITS SBLK image, with symtab mungage. No need to worry about any ITS-ification other than run time issues for the program in question. KCC has a multitude of switches and options for cross-compilations. On the other hand, that's not as "interesting". It's OK for bootstrapping, and OK for dull serious stuff where time is important, but that's not really the reason (I thought) we were having fun talking about how to port KCC, and it doesn't buy us any interesting new capabilities. There is one other tack, which is to take the CURRENT sources for LINK and MAKLIB and fake them into thinking they are running on a PDP-10, actually ITS DECUUO. While this would be something of a license violation, I'm not sure it's any worse than DECUUO's stuff, and I doubt DEC will care much about ITS anyway. (I feel safe suggesting this because I'm comfortably out of reach of any backfires.) Not only would this make everything work, and considerably simplify the task of porting KCC, it also buys you lots of loader bug fixes and many new features that were added since the time of the last T10 hackery. Ed's message gave me an idea about how to resolve symbol conflict problems with MIDAS. Simply invent a "user symbol space" block, called U or C or whatever, and do all the assembling in some other, also standard, block. Every KCC-generated symbol will always have C" prefixed to the symbol. Thus, I hope, you can freely generate stuff like: C"POP: BLOCK 1 C"MOVE: MOVE 1,C"POP ... Viva MIDAS!  1,, Rcvd-Date: 28-Apr-87 01:19:40-EDT Received: from SPEECH.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 28 Apr 87 01:19-EDT Date: Tue 28 Apr 87 01:20:38-EDT From: "John Wroclawski" Subject: Re: STINK for ITS KCC To: KLH@SRI-NIC.ARPA, Moon@SCRC-STONY-BROOK.ARPA cc: SRA@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA In-Reply-To: <12297953201.19.KLH@SRI-NIC.ARPA> Message-ID: <12298019843.25.JTW@MIT-SPEECH> *** EOOH *** Date: Tuesday, 28 April 1987 01:20-EDT From: "John Wroclawski" To: KLH@SRI-NIC.ARPA, Moon@SCRC-STONY-BROOK.ARPA cc: SRA@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA Re: STINK for ITS KCC From: Ken Harrenstien Subject: Re: STINK for ITS KCC Well, I thought about the T10 loader. Trouble is, I believe it is very old, without some things we now need, and I don't think there is any source, or anything. There is also the MAKLIB program to consider. I'm not even sure it handles library searches... We don't have the sources, but the thing's so simple it could probably be disassembled. MAKLIB sources we have; it runs under the emulator on twenex too, so it'll probably run under DECUUO almost right off. I'm not sure what "one program" this is that you are talking about, but assume it is SRA's domain stuff. If true, you could simply maintain software on a T20 and cross-compile it for ITS -- just need a trivial hack to dump out a DEC .EXE program image into an ITS SBLK image, with symtab mungage. Actually we should create this technology anyway, it seems like an easier way to port the compiler itself than copying FAIL files over and assembling them on ITS, or whatever. On the other hand, that's not as "interesting".... Ah, a man after my own heart. But we do need that domain stuff. There is one other tack, which is to take the CURRENT sources for LINK and MAKLIB and fake them into thinking they are running on a PDP-10, actually ITS DECUUO. The current LINK sources comprise some twenty zillion pages of grotty code conditionalized for TOPS10 and TOPS20 which assemble into a 100+ page (tops20 page -> 50 ITS page) program that knows how to do everything except scratch your back. (really. It can draw pretty little graphs of the overlay structure of your program on a plotter...) But it -can't- do the one thing that would be really nice, which is to automatically relocate the high segment to give you the maximum possible amount of free memory. I don't think attempting to port this crock is worth the trouble. Lets get some sort of cross-compilation method working and write a simple little loader in KCC.  1,, Rcvd-Date: 28-Apr-87 01:25:24-EDT Return-Path: Received: from STONY-BROOK.SCRC.Symbolics.COM by XX.LCS.MIT.EDU with TCP/SMTP; Tue 28 Apr 87 01:25:20-EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125834; Tue 28-Apr-87 01:27:09 EDT Date: Tue, 28 Apr 87 01:26 EDT From: David A. Moon Subject: Re: STINK for ITS KCC To: John Wroclawski cc: KLH@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA In-Reply-To: <12298019843.25.JTW@MIT-SPEECH> Message-ID: <870428012658.0.MOON@EUPHRATES.SCRC.Symbolics.COM> *** EOOH *** Date: Tuesday, 28 April 1987 01:26-EDT From: David A. Moon To: John Wroclawski cc: KLH@SRI-NIC.ARPA, SRA@XX.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU, Ian@SRI-NIC.ARPA Re: STINK for ITS KCC Date: Tue 28 Apr 87 01:20:38-EDT From: "John Wroclawski" Lets get some sort of cross-compilation method working and write a simple little loader in KCC. Now -there's- a smart suggestion! Not only is this practical, but it seems like the right point in the lifetime of the pdp-10 architecture for it to acquire a linking loader that isn't a piece of shit.  0,, KCC, *** EOOH *** Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Mon 11 May 87 21:37:17-EDT Date: Mon 11 May 87 18:14:17-PDT From: Ken Harrenstien Subject: New CC.EXE available To: info-kcc@SRI-NIC.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12301645011.18.KLH@SRI-NIC.ARPA> A new version (561) of SYS:CC.EXE has been installed at SRI-NIC and can be FTP'd. This mainly fixes a couple more unusual optimization bugs, and is not a new source distribution.  0,, KCC, *** EOOH *** Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Mon 11 May 87 21:17:04-EDT Date: Mon 11 May 87 18:17:42-PDT From: Ken Harrenstien Subject: Re: ADJSP 17,1 in the middle of a function call? To: SRA@XX.LCS.MIT.EDU, Bug-KCC@SRI-NIC.ARPA cc: KLH@SRI-NIC.ARPA In-Reply-To: Message-ID: <12301645633.18.KLH@SRI-NIC.ARPA> This bug is now fixed by the new version (561). It was a real pain, otherwise it would have been fixed sooner -- was busy with other things. Next bug, please...  0,, KCC, *** EOOH *** Rcvd-Date: 27-May-87 11:56:12-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Wed 27 May 87 11:56:05-EDT Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Wed 27 May 87 08:47:46-PDT Date: Wed 27 May 87 09:48:17-MDT From: "Nelson H.F. Beebe" Subject: Screen management To: roode@BIONET-20.ARPA cc: BEEBE@SCIENCE.UTAH.EDU, INFO-KCC@SRI-NIC.ARPA X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Message-ID: <12305736278.21.BEEBE@SCIENCE.UTAH.EDU> Volume 1 of mod.sources (available at SEISMO for FTP) has PCURSES, a public-domain version of CURSES, which is probably the best way to go now for screen management, since it is available on all Unix systems, in VAX VMS C, and at least 2 commercial (~$125) versions on the IBM PC (see the June 87 issue of Computer Language, p. 144). PCURSES needs sgtty.h, which KCC does not yet have, but may soon.  0,, KCC, *** EOOH *** Rcvd-Date: 29-May-87 15:44:10-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Fri 29 May 87 15:44:02-EDT Date: Thu 28 May 87 15:15:20-PDT From: Ken Harrenstien Subject: Re: KCC Libraries To: ROODE@BIONET-20.ARPA cc: Golub@BIONET-20.ARPA, KLH@SRI-NIC.ARPA, info-kcc@SRI-NIC.ARPA In-Reply-To: <12305650663.15.ROODE@BIONET-20.ARPA> Message-ID: <12306068881.50.KLH@SRI-NIC.ARPA> To add to Nelson's reply: we are working on s/gtty() and ioctl() now, so it shouldn't be long. As for the idea of using a sharable runtime segment for the library routines, this notion has been entertained for a while but the mechanics have yet to be worked out; the library itself is changing all the time. It has been suggested that we find a way to use the FORTRAN runtime library for access to their versions of various math functions; doing both at once would be an interesting problem. If you have a specific proposal to contribute, please get in touch...  0,, KCC, *** EOOH *** Rcvd-Date: 3-Jun-87 03:05:48-EDT Return-Path: Received: from SRI-NIC.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Wed 3 Jun 87 03:05:38-EDT Date: Wed 3 Jun 87 00:04:55-PDT From: Ken Harrenstien Subject: [Ken Harrenstien : New plan for signal() and BSD sigvec()] To: sra@XX.LCS.MIT.EDU Message-ID: <12307476010.15.KLH@SRI-NIC.ARPA> You aren't on BUG-KCC but I thought you might have something to say about this stuff... --------------- Mail-From: KLH created at 2-Jun-87 23:40:50 Date: Tue 2 Jun 87 23:40:50-PDT From: Ken Harrenstien Subject: New plan for signal() and BSD sigvec() To: bug-kcc@SRI-NIC.ARPA cc: klh@SRI-NIC.ARPA Message-ID: <12307471625.15.KLH@SRI-NIC.ARPA> I have been wrestling with various ideas on how to most satisfactorily implement the 4.3BSD Unix sigvec() mechanism (which includes the old V7 signal() as a subset). The existing signal code in the KCC library is only a partial implementation and has several deficiencies, e.g. only one signal can be handled at a time, and the "system calls" cannot return EINTR; moreover, their data structures can be horribly messed up. The details of the scheme I came up with are too long to relate in this message, particularly when I'm not sure who has an interest in the outcome. If you would like to read my current thinkpiece and comment on it, the file is PS:SIGNAL.PLAN on SRI-NIC.ARPA and should be accessible via anonymous FTP. A brief summary: I propose to have all PSIs at a single level, and have the PSI handler do DEBRK%s as quickly as possible after adjusting various global masks and variables. No signal handler will run at interrupt level. All features of the V7 and BSD scheme can be implemented, including signal masks and many independent handlers. The primary difficulty is having no obvious way to transparently resume execution of a user-code JSYS interrupted by a signal. If this interests (or worries) you, please read the file and send comments! --Ken  1,, KCC, Rcvd-Date: 30-Jul-87 09:08:02-EDT Mail-From: SRA created at 30-Jul-87 09:08:00 Date: Thu, 30 Jul 1987 09:08 EDT Message-ID: From: Rob Austein To: Bug-KCC@SRI-NIC.ARPA cc: sra@XX.LCS.MIT.EDU Subject: So, you guys only use GENERATION-RETENTION-COUNT == 1, huh? *** EOOH *** Date: Thursday, 30 July 1987 09:08-EDT From: Rob Austein To: Bug-KCC@SRI-NIC.ARPA cc: sra@XX.LCS.MIT.EDU Re: So, you guys only use GENERATION-RETENTION-COUNT == 1, huh? [PHOTO: Recording initiated Thu 30-Jul-87 8:58AM] MIT TOPS-20 Command Processor 5(312160)-2 XX>ty t.c #include main(argc,argv) int argc; char *argv[]; { int i; for(i = 0; i < argc; ++i) printf("argv[%d]=\"%s\"\n",i,argv[i]); } XX>v -oa XX: -OA.CMD.1;P777700 1 1058(7) 15-Jun-87 02:00:41 SRA .2;P777700 1 224(7) 15-Jun-87 23:55:51 SRA .FLUSH-LIST.2;P777700 1 1098(7) 15-Jun-87 01:56:28 SRA .3;P777700 1 1109(7) 15-Jun-87 23:54:24 SRA Total of 4 pages in 4 files XX>t.exe -oa.*.* argv[0]="T" argv[1]="XX:-OA.CMD" argv[2]="XX:-OA.CMD" argv[3]="XX:-OA.FLUSH-LIST" argv[4]="XX:-OA.FLUSH-LIST" XX>pop [PHOTO: Recording terminated Thu 30-Jul-87 8:59AM]