cross
|
|
response 26 of 28:
| 
Mar 6 04:40 UTC 2009 |
Software bugs are defects by definition, but we must be careful to
define what we mean by "defective." In some pedantic, absolute
sense, yes, the software is defective if it has a bug in it --- but
that's the same kind of defective that a car is if, say, it has a
spark plug that doesn't fire one out of every few-million times or
something similarily insignificant, or if a plastic knob breaks off
of the stereo or something. That component is defective, but the
car is not overall.
Regarding Macro.... It seems I was thinking about the MACRO
facilities avilable under TOPS-20, not TOPS-10 (which was probably
rather more primitive). This document goes into more detail about
it: http://tenex.opost.com/hbook.html
In particular, not the section on "Implementation Language" that I
quote below, though the entire thing is pretty interesting. Of the
four most common operating systems for PDP-series computers (TOPS-10,
TWENEX/TOPS-20, ITS and SAIL) I'd still say that TOPS-20 is the
most interesting, followed closely by ITS. There were some ideas
in TOPS-20 that *still* are not in "modern" systems. And ITS had
some good ideas that have, unfortunately, fallen by the wayside
(e.g., PCLSR).
-->BEGIN QUOTE<--
Implemention Language
Almost all system code for the 36-bit architecture machines had
been written in MACRO since the first boot routine of the PDP-6.
Because of its regular structure and powerful set of operations,
36-bit assembly language was reasonably pleasant to write in, and
so less pressure existed for a higher level language than on most
other machines. BLISS was gaining some adherents in some parts of
DEC, but its various peculiarities (e.g. the "dot" notation and use
of underscore for the assignment operator in the early -10 version)
generated major resistance elsewhere. Hence, new TOPS-20 code was
written in MACRO, as TENEX had been.
During the development of release 1 and continuing thereafter,
various features were added to the MACRO programming conventions
used in TOPS-20. These were mostly implemented by macros, and they
gave certain higher-level language capabilities to MACRO. The first
of these involved mechanisms for representing data structures in
one place (i.e. a "header" file) such that the representation would
cause appropriate code to be generated for references. This started
out as a simple macro to select "left half" or "right half" of a
36-bit word (instead of an explicit HLxx or HRxx). Next came macros
to select the correct bit test instruction (TLxx, TRxx, TDxx) for
the mask at hand. Eventually, the macros were capable of defining
and representing complex multi-word record-type structures with
fields of various sizes.
Secondly, macros were used to provide procedure-call and automatic
(stack) storage using named variables. A procedure entry point could
be declared using symbolic names for the parameters, and these names
would expand to the appropriate stack reference when used in an
instruction. Similarly, local stack storage could be defined
symbolically and local registers saved automatically. These conventions
greatly reduced the occurrance of explicit stack PUSH and POP
instructions and the bugs that often resulted from them.
Finally, macros were implemented to provide control structures
without explicit use of labels. Semantically, these resembled typical
language IF/THEN or IF/THEN/ELSE constructs, and arbitrary nesting
was permitted. As a result, a typical page of TOPS-20 code using
these conventions often contained only one label -- the procedure
entry point.
All of this made for better programming, but it did not, of course,
remove dependence on the PDP-10 instruction set. Portability was
not an objective we thought to be concerned with until much too
late.
-->END QUOTE<--
|