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