🚀 go-pugleaf

In article <1992Sep26.195920.25026@pony.Ingres.COM> jpk@Ingres.COM (Jon Krueger) writes:
>Charles Lasner writes:
>> SKED really doesn't give you much of a PDP-8-specific viewpoint
>
>True, it gives you a state language viewpoint.

Yes, at much sacrifice of certain kinds of capability, which was a necessary
requirement at many other installations.  More power if you could "live" under
SKED; we and the other places I consulted for could not.

>
>Had it given you more of a PDP-8-specific viewpoint,
>its users probably wouldn't have been able to master it,
>and their programs probably would have been either trivial
>or incorrect.  The nice thing about SKED was how it made
>realtime data acquisition and process control of multiple
>concurrent processes accessible to nonprogrammers through
>use of the state language.  It could and later did run
>on other machines.

Users didn't write the programs at the installations I worked for; I did.

>
>Still, SKED's historical and technical connection to 8's is
>well established.  The 8 was reliable and affordable enough
>for a lab to buy one of its very own.  It's hard to explain
>to youngsters what a revolution that was.  You couldn't do
>realtime stuff with your slice of the department's timesharing
>machine.  Suddenly, you could afford to buy a machine to
>dedicate to automating Skinner boxes.  The 8 was also fast
>enough to do reasonable amounts of I/O getting and putting
>things from your lab device.  DEC documented enough of the
>hardware, interfaces, and operating system that you could
>write a system like SKED.  They kept the 8 standardized
>enough that most 8 programs ran on most 8's, a property
>found only in the mainframe world up until then.  And they
>sold enough that you weren't on your own.  Hard to explain
>to folks now how amazing that was too -- "you have an 8?
>Wow!  We have an 8."

That's true; and it also allowed me to take the guts of my code from one
machine to another where the "application layer" of the real-time code
was all that was different, since the interrupt-level is constrained to
be nearly identical in each case.

The only variance has to do with whether the Lab clock was to be put into
whichever of its several modes made more sense for the application.  BTW,
some of the applications were beyond the capabilities of the hardware
provided in the LAB-8/e series, and required the addition of non-standard
modifications to the clock to allow two clock board sets.  Additionally,
multiple D-A converters were often needed to display certain real-time
calculations.

My main point is that the -8 was used for lots of real-time applications,
including certain things where SKED would literally get in the way.  There's
a world of difference between caring about 10's of microseconds versus
10's of milliseconds.  A lot of ornate programming is needed to get the
performance out of the machine that it's capable of.

Real-time is what you make of it; some people were happy with the limited
world of LAB-8/e BASIC, and others were happy with the "canned" packages
provided by DEC that were, as far as I/m concerned, glorified demo programs,
such as the "Time Interval Histogram" program and its ilk.  Moreover, the
quality of the code in some of these programs was quite below "par" compared
to the code myself and others wrote both before and since these programs
became available.

Some of what I refer to is the so-called "skip chain" interrupt handling.
This is an inefficient technique whereby actual SKP instructions are used to
skip over jumps (perhaps indirect to make them even slower) where the SKP's
are themselves skipped over should a device flag be raised.  Perhaps it's
insignificantly easier to follow, or it conforms to someone's notion of
"structure" but regardless, it unnecessarily raises the interrupt latency.
Moreover, some programs require an aspect of unavailable API, namely that
an interrupt routine needs to be interruptable lest a higher-priority
device be interrupting.  In this case, a "recursive" interrupt handler is
required so that after the device has been "tamed", the rest of the device
servicing is guaranteed to be a lower priority than a potential interrupt
from another device.  Priority can't be finely controlled, but you can do
things like make sure that a trivial and unimportant blurb printing routine
outputting to the terminal on interrupt doesn't materially slow down the
ability for the clock to give you clock-counter readouts from the clock buffer
at crucial times, or to get additional A-D channels started soon enough before
the sampling rate exhibits a jitter, etc.  (Ever debug a real-time program
with an oscilloscope?  I have.  I had to ensure that tasks that "woke up"
periodically didn't impact negatively on sampling rate by inducing jitter, etc.
and the best way was to watch the automatic a-d start pulse generated by the 
clock, etc.)

Yes, SKED has a place in applications for the -8, but hardly in the
realm of certain "faster" real-time applications.  User flexibility can
mean program impossibility sometimes.

>
>-- Jon
>--
>Jon Krueger  jpk@ingres.com  

cjl