Article 163112 of comp.os.vms:
OOOH, ahhh, more stuff about the 6600/7600.  Actually, about the
operating system and application programs.

First, the hardware implemented basic protection.  There was a base
address, which was added to all memory addresses used by the
program, and a limit address which specified the maximum address
that the program could use without causing an address violation.  As
with divide-by-zero, I think an address violation simply caused the CPU
to halt and PPU 0 had to figure out why.

Thus programs could easily be relocated in main memory and were
protected from each other.  There were no provisions for "read only" or
separated program/data spaces.  Programs (instructions) and data occupied
the same read/write address space, thus is was pretty easy to write
self-modifying code.

Each program saw a linear address space which started at address 0 and
went up to the programs "field length" (maximum address).  Typical
field lengths (set prior to program load via the RFL command) were
20-30,000 words.  Programs at our site were considered big if they needed
a field length over 50,000 words or so.  For comparison, I wrote a complete
interactive bulletin board system with loadable "device drivers" (for
terminal cursor addressing - kinda a "curses" package but with different
drivers for each type of terminal) and worked REAL hard to get it to run
in under 20,000 words.  The program was written entirely in COMPASS.
Reducing program size had a DRAMATIC effect on how "quick" and interactive
interactive programs felt.  20,000 words is about 150K bytes.  Remember,
the machine only had 256K (words) of memory total (or was it 131K?  I
can't remember if addresses were signed) so it didn't take but ten or
so 20K jobs to fill all of main memory.  Also, I don't think most places
had full memory compliments - I think we only had 131K (assuming you could
go to 256K).  Memory was expensive!

Whole programs (control points) were swapped out and back into memory, no
virtual memory here.  Swapout was called a "rollout" and could be a real
bear if you were trying to run interactively.  You program's chance of
getting rolled out and staying out for a long time were direct functions
of its field length.  I recall the operating system did a lot of work
to try and keep odd-sized memory holes from developing but when they did
it would start wholesale rollouts to de-fragment main memory.  If you had
an over-50K job and it got rolled out during a busy afternoon, you could
pretty much guarantee it wasn't gonna roll right back in.  The system would
pick a bunch of smaller jobs instead.

Anyway, the first 100 words of a program's address space were used for
communication with the operating system.  When the system loaded a program
it transferred control to the program by starting the program at address
100 (plus or minute 10 words, I don't remember exactly).

Within the first 100 words was data the program could look at to find
out about itself.  Stuff like jobname, priority, field length, username
were all stored by the system there.  In addition, the programs "Exchange
Package" was stored by the system there.  The exchange package consisted
of all the hardware information needed to save and restore the program's
state (such as register values, the program counter, etc.).  There was
a special machine instruction, used by the system monitor, that basically
took an exchange package and loaded it into the CPUs registers.  How
many people out there remember the wonder and joy of retrieving your
Fortran job only to find that, instead of the output you expected, you
got an "Exchange Package Dump" instead?  That was the system's way of
telling you that your program had faulted (divide by zero, field length
violation, etc.).  You looked at the printed out exchange package and
found the PC and the register contents.  You usually had to know a good
deal about what the Fortran compiler did with various registers to figure
out what went wrong.

The most important location within that first 100 words was address 1.

If a program wrote the three-letter name of a PPU program into the word
at location 1, then the system monitor would attempt to find a PPU
program of that name and load it into an available PPU for you.  That's how
you made a system call.

The first 100 words were really close to Unix's "User Area" for people
familiar with the kernel.  The big difference is that, under Kronos, the
"User Area" was within the processes address space while under Unix (at
least V7) only the kernel could read it.  Under Kronos a process could,
by design or error, shit all over its first 100 words.  That produced an
exchage package dump pretty quickly.

I've really got to get back to work...

greg
--

greg		greg@indiana.edu	http://gtravis.ucs.indiana.edu/