jeff@abnji.UUCP (01/11/85)
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 | +---------------------------------------+
geoff@desint.UUCP (Geoff Kuenning) (01/14/85)
In article <173@abnji.UUCP> jeff@abnji.UUCP writes: > 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???? Well, I wouldn't claim to *miss* the bloody thing, though I have fond memories. Let's remember, though, that that 16K Fortran compiler had *27* (count 'em) overlaid passes. Things like: pass 1 - lexical analysis of declarations, pass 2 - lexical analysis of code, pass 3 - parse integer declarations, pass 4 - put integer declarations into the symbol table (I'm making these up; it's been far too long to remember what they were. But you get the idea). -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
rb@houxn.UUCP (R.BOTWIN) (01/16/85)
[]
Ah, yes...Memories of my first machine....an old 4K 1130.
I miss it muchly...The techniques learned on that machine, at least for
me, predate any formal CS training, and are "instinctive" rather than
learned by rote...
We used to call SOCAL and LOCAL "cram and crunch"....and got around large
programming problems by making ALL variables COMMON. We had large
payroll systems, personnel systems, even large linear algebra matrix
manipulations using this technique.
The whole concept of linking, speed trade-offs using core-image
loads, relocating programs.....ah, yes.....that was the way to learn!
We even knew if we had diagnostics in our compile by the sound of the
old 1132 printer....It had a different "rhythm.".....I remember talking
on the phone from home to a friend at the computer...in the background was
the printer ker-chunking out a listing for him.....I heard the
unmistakable tones of a diagnostic report, and told him he had better
fix his bugs and re-compile....He thought I was psychic!
Rob Botwin, N2FC
.....{utah-cs|seismo|decvax}!harpo!eagle!hogpc!houxn!rb
ATT/IS Labs (201) 577-5016 (Cornet 8-270-5016)
FJ 1B-130