Re: pascal system

["mdj" <mdj.mdj@gmail.com>]

mdj wrote:
> John B. Matthews wrote:
>
> > The UCSD UNIT model for separate compilation was one of the first to
> > enforce a rigorous contract between interface and implementation. In
> > particular, it used Pascal's type checking to verify subroutine
> > parameters. The original Mac toolbox interfaces were created using this
> > model, and we take it for granted now for large APIs.
>
> The really cute part was INTRINSIC UNITS, which you could store in
> SYSTEM.LIBRARY, providing true dynamic loading. There was a limit on
> the number of UNITS in SYSTEM.LIBRARY though, and even more
> restrictions if they contained external (assembly) code, although the
> specifics escape me.
>
> There was some non-UCSD extensions in Pascal 1.2 to make this mechanism
> a little more user friendly, as I recall.

Curiosity got the better of me so I had a look at the manual.

The extension basically allowed you to write a text file with the same
name as your program, except the extension .LIB, which listed the
libraries your program depended on. They would then be loaded at
runtime.

This was a lot easier that using SYSTEM.LIBRARY, which required using a
rather dodgy utility called, ironically, the Librarian, which would
allow you to package a new SYSTEM.LIBRARY with the old contents plus
yours.

There was a limit on how many you could have, and I wrote a lot more
UNITS than there was space for in the SYSTEM.LIBRARY :-)

It also reminded me of how the 128k system did it's magic. Under the
old 64k system, the p-machine lived in the language card, and the OS
loaded into upper memory below it. The space below was all you had for
program, stack and heap.

The 128k system used the bank switched area of auxiliary memory for os
+ program space so you had the entire main memory area (minus language
card) for heap + stack. This allowed some pretty massive programs, plus
considerably extended the symbol space available to the compiler,linker
and assembler.

Ironically the auxiliary language card remained unused, just as it did
in ProDOS despite being marked a reserved area.

I've always wondered, did 128k ProDOS applications encroach into this
area at all? It was annoying to use in many ways, but it'd be a handy
spot to store a few things these days, assuming application developers
played by the rules. I seem to recall a chunk of it being allocated to
third party RAM drivers at some stage

Matt