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
Paul Anderson <anderson@NRL-CSS> (01/14/85)
Yes, I still miss the old 1130. This was the machine that I was first trained on in college, the first assembly language I learned. Two months before I graduated from college, the engineering department received a donation on an IBM 1800 (the "real-time" version of the 1130), from a local company who didn't need it any more, and it took them quite a while to get it up and running. I like the 1130 assembly language better than the Z8000 or the 68000, and I'll trade either of these for an 1130 (almost) anytime. AH, nostalgia.
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-130dmt@ahuta.UUCP (d.tutelman) (01/18/85)
REFERENCES: <593@houxn.UUCP> Gee, diagnostics by ear. I have a similar story from software development for the #1ESS at the Indian Hill Bell Labs. We could tell if our software was about to crash the system if the relays in the trunk circuits started clicking in a certain pattern. We could sometimes halt things when they did that, in time to get a meaningful diagnostic dump (which you couldn't do AFTER it crashed). The reason was that the system recovery software (NOT part of what we were writing) was doing some reinitialization on the hardware if our programs went just a little insane. Dave PS - We also had an interesting visual diagnostic tool: an oscilloscope set up to display memory references as X-Y points on the screen. By watching the pattern on the screen, it was possible to detect impending disaster even faster than by listening to the clicks; however, you couldn't do this solo and still run the console.
tbm@hou2a.UUCP (T.MERRICK) (01/19/85)
One BTLer became famous for remotely diagnosing a relay board over the phone. He asked the complainer if the board went click click ---- click, or click----click click. The complainer did not know so the BTLer asked to hear the board over the phone. After listening he identified the wrong relay code and its board position. The next time a BTLer visited that office he could have anything he wanted. Tom Merrick ATT BTL MV
terryl@tekcrl.UUCP () (01/20/85)
Ah, yes, the good ol` IBM 1130. It too was the first machine I learned Fortran and assembler on, but we had an expanded 8k core system. I had a friend who wrote a program where if you put an AM radio on the console, it would play songs over the radio!!! And the songs were very recognizable.
rpw3@redwood.UUCP (Rob Warnock) (01/22/85)
Gee, I end up posting this about once a year... this time I'll keep it short.
Nearly 20 years ago at Emory University (where HAS the time gone?), we wired
a speaker to the "Zero Balance" light of an IBM 1410 (think of it as the Z-bit
of a Z-80). (That was experimentally determined to give "good sounds".) Two
results of this are worth noting:
1. The 1410 was used a lot for LONG (4-12 hour) linear and non-linear
regression analyses (i.e., statistics). The programmers quickly learned
that they could hear the main loop of the regression (*squishy* *squishy*),
and that it got faster and faster as convergence approached. Walk into the
machine room and you could tell how long it was until the job was going to
quit computing and start printing. Useful for students with classes to go to.
2. The IOCS (Input/Ouput Control System -- nothing so fancy as CP/M) would, if
it tried to access a card reader, punch, or printer that was off-line, print
a nasty console message and busy wait for the operator to come fix it. Since
IBM charged maintenance by on-line time, the management was insistent that
the units remain off-line until needed. Fortunately, the busy-wait loop gave
a characteristic loud, harsh *buzzzz* that was distinctly different from the
*squishy* *squishy* of the applications programs, allowing the operator to
wait down in the systems room where it was quieter and MUCH warmer than the
machine room (and which had a bed -- useful for students with no sleep).
Rob Warnock
Systems Architecture Consultant
UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD: (415)572-2607
USPS: 510 Trinidad Lane, Foster City, CA 94404jmoore@opus.UUCP (Jim Moore) (01/25/85)
I remember the old Quazar 98000 built back in the early teens. This clunker only had .5Gigabyte of main memory and 3Terabytes of secondary storage using an antiquated bubble memory device. The speech recognition system had a tiny 50,000 word vocabulary that only understood English and the most common European languages. On top of all this, it was crippled with a 1,500MIP cpu. If you needed to cross reference the library of Congress, you might as well go get a cup of coffee while it limped along. We bought these beasts because the Quazar company had gone out of business and it was all we could afford. It is amazing how much work people can get done with such archaic equipment when developement schedules and budgets are tight. (This note was uncovered in a layer that is carbon dated between 2100 and 2300 A.D.)