[ih] ruggedized Honeywell 516 ARPANET IMP cabinet top lifting hooks (Was: The IMP Lights story (Was: Nit-picking an origin

[Jack Haverty]

Back around 2013, Bernie, Dave Walden, Ben Barker, and many others 
helped with a project to resurrect the early IMP code.  It was part of a 
legal activity involving the IMP as evidence of prior art in a patent fight.

As part of that, I did a "deep dive" into some of the IMP functions, to 
document exactly how certain IMP functions were accomplished.  I had 
never worked on the IMP code, or programmed a Honeywell minicomputer.   
I knew something about what the IMP did, but but not how it did it.

As always, the ultimate documentation is the code itself.

One of those IMP functions was the "reload from neighbor" process that 
was the first instance, that I'm aware of, of a computer downloading 
code from another computer using the network - the IMPs did that even 
while those computers were actually responsible for running the network 
itself.

The IMP code is the most complex, and innovative, piece of software I 
have ever seen.  It's also the "tightest" of coding and efficiency.  It 
uses "every trick in the books" and takes advantage of the details of 
how the hardware actually worked.  It also violates many modern 
programming principles, e.g., by using self-modifying code to store 
state information.

If anyone is interested...  Below is my "deep dive" analysis of the way 
in which the IMP actually accomplished reloads from some other IMP, 
which would occur either on command from the NOC or in response to 
failures such as crashes, checksum errors of the code itself, timeouts 
of the watchdog timer, and other such events during ARPANET operation.

The code analysis below refers to the IMP code from the early 1970s, 
which was recovered from an old listing and is now online at 
https://walden-family.com/impcode/c-listing-ps.txt   Anyone who wants to 
read the "functional trace" below will find it useful to have that file 
for reference.

==============================================================

Functional Trace – RELOAD

RELOAD is a procedure whereby a running IMP requests that one of its 
neighbors transmit back to it a copy of the bulk of its own core memory, 
and deposits it into its own memory, replacing what is there at the 
time. Some data is placed into memory (locations that will not be 
overwritten, to indicate to the “next” program that its predecessor 
asked for a reload – a “message from the dead” in effect.)

It then goes into a wait loop, ignoring all external activity. After a 
time, it drops out of the wait loop and does some simple checks to see 
if the reload process has completed (i.e., the neighbor IMP actually 
responded appropriately). If not, it attempts another reload, possibly 
from a different neighbor, and will continue to ask for reloads until 
one completes properly.

On completion, the IMP goes to its INIT routine, as if it had just 
started up, resets all I/O interfaces, and begins processing. Using the 
“message from the dead”, it reports to the NOC that a reload has just 
happened (as opposed to a power-up or power-fail restart.

The specific steps taken are:

 1.

    Entry is made at WDTM2 or WDLOD. If WDTM2 is used, the IMP will
    reload from the modem specified by the contents of the A register.
    If WDLOD is used, the IMP will select a modem line at random to
    request a reload. There are many ways to get to these entry points
    from other places in the code where the logic determined that a
    reload was appropriate. One form of entry is as a result of the
    watchdog timer firing, and the interrupt being handled at WDTM,
    which drops into WDTM2 to trigger a reload from a random neighbor.
    Regardless of how you get here, the result is a reload and restart.

 2.

    All interrupts are disabled except the clock. The host configuration
    (HOST34) is saved in location 46. At WDLUP, a call is made to the
    CLEA subroutine to clear all I/O interfaces. This is accomplished by
    changing all interrupt handlers to be handled by the watchdog timer
    handler itself (at WDT1), then issuing OCP commands to all hardware
    modem and host interfaces to unpatch the interface (the WDT2 loop).
    The software then enables interrupts and executes a wait loop for
    600 msec., by entering at WDT1.

 3.

    During that 600msec., interrupts will occur from the various I/O
    interfaces in unpredictable order. Each such interrupt suspends the
    600ms wait loop, and is handled by the same code as an interrupt to
    location WDT1, which starts its own 600ms wait loop after
    re-enabling interrupts. This processes continues, with each new
    interrupt suspending the current 600ms loop.

 4.

    Eventually interrupts stop happening, and some handler (whichever
    one got the most processor time) exits from its 600ms loop at loc
    1206. At that point (loc 1210-1212) it blocks all future interrupts
    and returns to LD8 with all I/O quiescent, all lines unpatched, and
    all interrupts disabled.

 5.

    Selction of the neighbor now occurs from LD8. If it is a random
    reload, the clock is read (loc 1043) and several bits used as a
    random number of modem interface to use.

 6.

    LD11 builds a request packet at SENDC, for transmission to the
    neighbor IMP. It contains the flags SNDCOR and LINETS which define
    it as a reload request. Similarly, OCP instructions are prepared for
    the appropriate modem output by placing the I/O instructions into
    the MIOTBP area (ModemImpOutputBufferPointer) for that specific
    modem, identifying the SENDC packet just constructed as the data to
    be sent.

 7.

    At loc 1053, a similar computation is made to create an appropriate
    instruction for the input side of the same modem interface,
    instructing it to place the next arriving data from that modem into
    locations from CORELO to COREHI. As defined in the listing, this
    covers the memory from location 60 to location 30000, comprising all
    of the IMP memory except for a few locations below location 60. One
    of these, locn 44, is used to convey the HOST34 info to the next
    resident program as described in (2).

 8.

    At loc 1057, the code jumps to the appropriate location to initiate
    output of the SENDC request packet on the selected modem line. E.G.,
    if modem 1 had been selected, the M1OUT instruction at LD1 would be
    executed to initiate output on modem 1.

 9.

    Continuing at LD12, a timeout loop is run (LD12 and LD13, using locn
    44 and 45 as a counter), allowing time for the request packet to be
    sent. When the timeout completes, the input instruction appropriate
    for the modem is executed (the X register specifies the modem being
    used). This initiates the process for data incoming on that modem
    line to be transferred directly into this IMP's memory (presumably
    the contents of the remote IMP's memory from CORELO to COREHI if it
    responds as expected). Note that this will result in the replacement
    of the instructions now being executed. Programmer and operator
    discipline guarantees that the new contents of these instructions
    will be identical., and this particular release contains several
    code fragments that reflect the existence of several different
    releases which might be present in any IMP. The code at LWAIT
    replicates the wait-loop function, but it is never called in this
    process. Most likely it represents where similar code resided in
    memory in an earlier release of the IMP software. Such techniques
    were used to permit new releases to be installed and tested, and
    then “rolled back” if needed.

10.

    Program operation continues at LD5 where a timer is set up using
    locations 44 and 45 (which will not be overwritten). After some time
    (long enough to transfer the entire memory contents, which are being
    placed directly into memory by the activity of the I/O processor
    attached to the same memory as the main CPU), the loop exits. It is
    now presumably running the new instructions just loaded from the
    remote IMP.

11.

    At LD7, a simple check is done to see if the I/O processor has
    indicated that input was performed into the entire memory (i.e., did
    it write all the way to COREHI). If not, something happened to
    corrupt the load, and control is passed back to WDLUP to repeat the
    reload process. Note that locn 47 still contains the number of the
    particular modem to use, or zero for a random reload. The next
    reload might be requested from a different IMP.

12.

    If the input did completely fill the IMP memory, it is likely to be
    a successful reload. At location 1106 it selects the SKS (Skip if
    Ready Line Set) appropriate for the modem just used, and stores that
    instruction in location 777 (which is outside of the “page 1”
    protected memory). It then transfers control to loc 777 to execute
    that instruction.

13.

    Operation continues at location 1000 or 1001, depending on the state
    of the modem's ready line. If an error is indicated, control is
    transferred to WDLUP, where a reload procedure is again initiated.
    Otherwise processing continues at location LD10.

14.

    At location LD10, the machine executes a sequence of instructions to
    restore the interrupt system parameters. It then transfers control
    to INIT – where the IMP performs its normal power-up starting
    procedures. However it is now running the software which it received
    from its neighbor IMP during the RELOAD process. This could be the
    same release, e.g., in response to a reload requested because of a
    watchdog timer interrupt. Or it could be a new release of the
    software, (re)loaded in response to a command to this IMP to request
    a reload.


To understand the entire process of reloading, the activities taken in 
the “other” IMP are also relevant. Assuming that the “other” IMP is 
running the same release 3050 of this listing, it takes the following steps:


 1.

    The packet sent by the IMP (I'll use the term LOADEE) requesting a
    reload arrives at the IMP (I'll use the term LOADER to identify this
    IMP) and is processed as a normal packet. The routine DIPE (p 93)
    processes all incoming packets, regardless of which modem they
    arrived from. At locn 10333, the Header of the just-received packet
    is examined for the SNDCOR and LINETS bits. Since the LOADEE set
    those bits in the outgoing packet (see step 6 above), the packet is
    characterized as a load request and processing continues at M2IRQC

 2.

    At M2IRQC (p 99), locn 11121 and 11122 set the SNDCOR bit in the
    SIHY flag table, in the slot for the particular modem being
    serviced. The SIHY table is one of the “page 0” variable areas used
    for communications between IMP modules. In this case, the input
    processor (M2I) here is leaving instructions for its corresponding
    output processor (I2M) on the same modem line to send an I-Heard-You
    (IHY) packet (which have high priority).

 3.

    After any current output operation completes on that modem, or after
    the timeout procedures trigger an I-Heard-You packet to be sent, the
    output handler for that modem will be triggered. In either case, the
    processing will come to I2MNUL to construct and send an IHY packet.

 4.

    At loc 12226, the SIHY entry is examined to detect the SNDCOR
    indicator bit, and processing is immediately diverted to I2MCOR to
    perform a core reload instead of sending an IHY.

 5.

    I2MCOR creates instructions for the I/O processor for that modem to
    transmit the contents of the LOADER's memory from CORELO to COREHI.
    These must of course have the same values as in the LOADEE, or the
    instructions won't go into the right places. The instructions at
    12262-12265 place the memory limit values into the locations
    specified by MOPX and MOP1, as instructions to the particular
    modem's I/O processor specifying where the packet to be sent is stored.

 6.

    Control is transferred to I2MDUN (p 111), where an appropriate
    instruction for the I/O processor is selected and stored into loc
    12476, where it is executed. This starts the I/O processor sending
    the contents of CORELO to COREHI out the particular modem interface
    to the LOADEE.

 7.

    The I2M interrupt handler completes at I2MQUT and returns control to
    whomever it interrupted via the IRET return location.

 8.

    The I/O processor will eventually complete the transmission of the
    core image and simply wait for the next output task, which will
    likely involve the handshake as the LOADEE program initializes and
    establishes contact with all of its neoghbors, including LOADER.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250827/121a0502/attachment.asc>