ITS Internals Manual

From Computer History Wiki
Jump to: navigation, search

There is some documentation for Incompatible Timesharing System, but principally oriented towards the users and programmers thereof (see links below). This page attempts to provide at least the high-level portions of a manual which describes how the kernel of the system is organized.

Note: This page is under construction.

Basics

  • Jobs
    • User variables/user blocks
    • Interrupts
    • How they get started
  • Memory management
    • Exec address space
    • Paging
  • File system
    • Directories; TUTs
  • I/O
    • Terminals
      • Terminal-type independent output
    • Graphical displays
    • Virtual devices
    • Disk controllers
    • Misc and sundry custom devices
  • Daemons
  • Bootstrapping
  • Networking

Jobs

ITS terminology for what is know generally known as a process is job. A 'child process' is an inferior job and the parent is the superior. The top-level job, HACTRN, can normally handle eight inferiors, though this isn't a hard limit.

A job has an address space, consisting of 256 pages of 1024 words each. Each page may individually be mapped to some backing store, and have access read/write bits set. Backing store is normally anonymous core memory or files, but it can also be PDP-6 or PDP-11 memory.

Jobs can be created by the system itself, see How system jobs get started, or by a user application opening a file on the USR: device which creates an inferior. The superior can read and write the inferior core image with normal .IOT read/write calls, and there is a LOAD system call to specify an on-disk file core image to load.

Daemons

PEEK output, showing 4 system jobs

On ITS, a "dragon" is a permanent system job, and a "demon" is a temporary system job which is started on demand; this terminology is somewhat different (in both in the distinguishing characteristics, as well as in the actual words used) from the classic daemon terminology. ITS also has both classic daemons (which are ordinary processes, which load their code from the file system, run in the same CPU mode as normal user processes - and thus have a private address space), and what we are calling 'system processes' [temporary placeholder - I need to send that email to COFF] (whose code is statically linked in with the kernel, and thus loaded into main memory at bootstrapping time, and run in 'executive' mode, and thus share the kernel's address space).

On startup, ITS starts a job called SYSJOB (would this be considered a 'dragon' in ITS terminology?), which does some system tasks (complete list here) as a regular job; it is something of a 'system process' as its code is part of the kernel - but it appears to run in user mode (there some confusion over this; see here). It runs in user mode, in part, because ITS does not allow jobs to do system calls from exec mode.

There is also a system process called the CORE JOB, which before paging used to shuffle processes around in core, but which now allocates main memory to jobs that need it, and also takes care of user variable blocks, which have to be allocated consecutively, by shuffling those around.

Other daemons include COMSAT (the mailer daemon); NAMDRG, which maintains the list of logged in users which appears on all free Knight TV consoles, and PFTHMG DRAGON, which maintains usage (time logged on, and CPU use) statistics. At least one ITS machine, DM, had a 'batch' daemon.

How system jobs get started

One of the things the SYS JOB does when it starts is to run SYS; ATSIGN DRAGON which is a central daemon. This dragon is also called TARAKA and lives in the CHANNA directory (names taken from the book "Lord of Light"). TARAKA is responsible for starting other dragons in there, which start with the file name RAKASH. One of those is RAKASH CNAVRL which launches COMSAT .

When ITS wants to start a system job (does that term mean a 'system process', or is it a daemon?), it calls NUJBST with the SIXBIT job name in T. The core image in SYS: ATSIGN T will be started. This is used to start (all?) HACTRN; the Arpanet NETRFC handler; the TCP handler; the CHAOS agent; and demons.

T is stored in a ring buffer, and is read out on a "slow clock" tick by USTART. A new job is created, and its user PC is set to 1. The job accumulators are loaded with code from NUSTCD, which opens the file, calls LOAD, and jumps to the starting address. In ancient times, the NUSTCD code would first try the file on the SYS: device, and then fall back to the UT2: device; this is a remnant from when ITS ran off DECtape with the system tape mounted on unit 2.

Graphical displays

  • Type 340 point-plotting display
  • Evans&Sutherland LDS-1
  • Color scope
  • Knight TV
  • Logo TV
  • Imlac PDS-1

Terminals and controllers

  • The AI PDP-6:
    • The console TTY device was modified to add four more lines.
    • GE Datanet 760 controller with four CRT consoles.
    • A few ARDS terminals.
  • The AI KA10:
    • TK10 — 16 low-speed lines.
    • Systems Concepts DK-10: 16 medium-speed lines with DMA.
    • Datapoint 3300 CRT terminals.
  • The DM KA10:
    • "Morton box" controller with 32 very high-speed lines.
    • Imlac PDS-1 "intelligent terminals", or actually full minicomputers.
  • The ML KA10:
    • "Morton box".
    • One Imlac PDS-1.
  • The MC KL10:
    • Many lines attached to two DH11's and one DL11 (main console LA36) on the main front end PDP-11/40 attached to the DTE20.
    • Many lines attached to a DH11 and one DL11 (not sure what that was connected to) on the IO/11 front end PDP-11/40 attached to the DL10.
    • One Imlac PDS-4.
  • All KS10:

Disk controllers

  • Analex
  • Data Disc M-6
  • Custom controller for IBM 2311 drives
  • Custom controller for IBM 2314 compatibles
  • Systems Conceps DC10
  • RP10
  • RH10
  • RH11

The horrible hack hack

ITS has a spartan "HACK HACK" comment in two places. This is taken from the ITS 672 from 1971: 

TTYCHN==4       ;TTY CHANNEL
SDCHN==4        ;DISPLAY SPECIAL CHANNEL
DISCHN==6       ;DISPLAY DATA CHNL

LOC 40+2*TTYCHN
        JSR TTYBRK      ;TELETYPE, GETYPEIN AND ALL MANNER OF MISC
        JSR DRECYC      ;HACK HACK

LOC 40+2*DISCHN
        BLKO DIS,DBLKOP ;340 DISPLAY BLKO
        CONO PI,4000+200_<-SDCHN>       ;HACK HACK

The display data interrupt is handled by a BLKO instruction to feed words to the Type 340 display. The magic hack happens when the BLKO instruction overflows, which executes the next instruction. DEC documentation is restrictive about what instructions may go there — typically, a JSR — and strongly forbids any IOT instruction. But here we have a CONO instruction that triggers a display special interrupt on a lower priority channel. The processor remains in interrupt overflow mode, so it executes the second interrupt instruction — JSR DRECYC.

External links

Retrieved from "http://gunkies.org/w/index.php?title=ITS_Internals_Manual&oldid=31984"