Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site abnji.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!mhuxv!abnji!jeff From: jeff@abnji.UUCP Newsgroups: net.micro,net.micro.cpm,net.lang.c Subject: an old idea whose time has come again Message-ID: <173@abnji.UUCP> Date: Thu, 10-Jan-85 16:21:07 EST Article-I.D.: abnji.173 Posted: Thu Jan 10 16:21:07 1985 Date-Received: Sat, 12-Jan-85 01:18:19 EST Sender: jeff@abnji.UUCP Organization: ATTIS, NJ Lines: 104 Xref: watmath net.micro:9032 net.micro.cpm:3326 net.lang.c:3804 Reply-To: abnji!jeff Organization: The New Jersey State home for the terminally bewildered [shift to the left! shift to the right! pop up! push down! byte! byte! byte!] The IBM 1130 (a 16 bit machine, 60's vintage) running Disk Monitor Version 2 (mod 10 July 1971) had a linker/loader with some very desirable options. My suggestion as to how to handle '$' in identifiers is to push that problem as low as possible. The 1130's linker had the 'equate' option that specified the substitution of subroutines during the building of a core load form: *equat(sub1,sub2),...,(subm,subn) substituted sub2 for sub1 so 'C' programs would use something like: *equat(sys_read, SYS$READ) This means that all references to the subroutine up to the link pass would be the 'C' name (7 char maximum, per K&R). Only at the link pass would machine-dependent features such as longer name lengths and funny characters be available. Only- what name would stay in the symbol table for the debugger to use? This has the advantage of moving the problem out of the 'C' language and into the loader which I am under the impression is quite machine dependent anyway. << The following is of interest to systems that don't swap or page or are very memory limited >> Yes folks, the 1130 supported overlays and in a painless way, that was transparent to the coding. If the program size exceeded available core (yes - I said core) then the call was altered to call 'FLIPR' which would read in the subroutine into the overlay area (in not already there) and pass execution to the desired subroutine. There were SOCAL (System call loaded on call) and LOCAL (subroutines loaded on call). (There was a distinction between system and user subroutines). memory was mapped as: +--------------+ | main program | +--------------+ | subroutines | including FLIPR +--------------+ | local | size of largest LOCAL +--------------+ | socal | size of largest SOCAL +--------------+ | common | +--------------+ The linker would try the following in building a core image 1) build everything in memory if it doesn't fit 2) SOCAL some of the less-frequently used system routines if it still doesn't fit 3) SOCAL all the system routines if it still doesn't fit 4) gives up Now, just tell it what subroutines you are willing to have loaded on call by specifying the option *local main1,sub1,sub2,sub3,...,subn where main1 is the main program sub1,... are the subroutines to be loaded on call If there was more than one main program (one passed execution to another by 'chain', similar to 'exec')you coded *local main2,sub1,sub2,sub3,...,subn for the other main program, and so on. and re-link. No need for recoding or recompilation. I see this as being very necessary for running large programs on CPM machines which are usually restricted to 64K. Whitesmith's "C" has no such ability, restricting program size to actual memory size. Manx's "C" has an overlay ability, but has to be explicitly called by the calling program. (Aha! Now you see why its in net.micro! ) Now for real fun. If you coded a non-blank in column 26 of the //XEQ card (that invoked the linker/loader) that allowed a LOCAL to call another LOCAL. This required special programming to pass a link word [mainline program address] since there was no stack thus all non-common variables were lost when overlaid. This restricted the LOCAL call LOCAL to assembly language only. Of course, load although not-called were called NOCAL and were coded: *nocalmain1,sub1,...,subn but that's a nothing special. Rhetorical question: Why don't any of the 'modern' loaders offer these wonderful options? Let's see you run a Fortran compiler and non-trivial program in 16K!!!!! P.S. I have pieces of the 1130 all over my apartment, including the front panel. Does anybody else miss the beastie???? +---------------------------------------+ | Jeff 'oh no -- not another' Skot | | at beautiful downtown Somerset NJ | | AT&T Info Systems | | ..!abnji!jeff | +---------------------------------------+