18 Sep
2015
18 Sep
'15
4:34 p.m.
On 18/09/15 14:31, Mouse wrote:
|
| The single exception is that we will not publish the list of "system
| killers" outside of Digital. All questions about "system killers",
| even ones asking if there are any, will be answered "No Comment". The
| reason for this is to protect customers (from their users) by
| providing absolutely no information on the subject. In addition, this
| "no comment" policy will be published along with the lists of
| architecture discrepancies.
This evidences a vast faith - now shown to be
misplaced - in the
inability of the black hats to discover things without DEC's help; the
notion that such a policy _would_ protect customers from their users
depends on DEC being the only source of such information.
I did have access to an internal NOTES conference within DEC that had
some of that sort of information in it. There were details of various ways
in which some VAXes didn't fully adhere to the architecture spec. Some
of these were fixed and some were granted a waiver (i.e. deemed to be a
permitted departure).
I only remember seeing one thing that could be described as a
"system killer" although I don't remember any of the details.
A "system killer", however, was (basically) a way of causing a
hardware error (basically a crash) from user mode. If any existed
then there was basically no way to prevent a user from causing
it to happen. Anything that could be fixed in software didn't count:
that's just a common or garden software bug. Something like
the Intel floating-point bug also wouldn't count (since all you'd
be killing would be your own calculation).
So if there were any "system killers" of that sort DEC would have
a very good reason not to ever discuss them, at least until all the
hardware in the field had been updated. I presume that by the time
that the MicroVAXes started to appear, it would have been prohibitively
expensive to recall a whole class of processor and replace them.
Antonio
arcarlini at iee.org