an old idea whose time has come again

[jeff at abnji.UUCP]

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			|
			+---------------------------------------+