I only really understand the Unix model for processes, users, and
security, that, basically, each process runs in its own address space,
that the virtual memory hardware effectively enforces security, and
that some kind of interrupt mechanism allows one to call a privileged
library of functions (i.e. the OS kernel).
The Lisp machine, as I understand it, runs all code at the same
privilege level and in the same address space. While this results in
some architectural niceties like the integrated VM/GC, I'm not certain
how Genera or Medley could be a multi-user environment. In my mental
model of a LispM, code in any thread can side-effect the global
environment, or any interactive user has access to a debugger that can
edit the OS kernel, etc.
(I guess something that is also tripping me up is that in Unix, a
language run-time system is pretty separate from the underlying
operating system, whereas on a LispM, the OS and the run-time are
effectively the same thing.)
So my question is, are there any papers (be they research or memos or
software documentation) that describe the security model of a Lisp
machine? For that matter, are there any architectural descriptions of
a Lisp machine, e.g. processes and threads and memory protection and
things of that nature?
Kind regards,
#\Matthew
--
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
"We know for certain only when we know little. With knowlege, doubt
increases." - Goethe
In article <···············@eco-fs1.irtnog.org>,
Matthew X. Economou <········@irtnog.org> wrote:
>I only really understand the Unix model for processes, users, and
>security, that, basically, each process runs in its own address space,
>that the virtual memory hardware effectively enforces security, and
>that some kind of interrupt mechanism allows one to call a privileged
>library of functions (i.e. the OS kernel).
>
>The Lisp machine, as I understand it, runs all code at the same
>privilege level and in the same address space. While this results in
>some architectural niceties like the integrated VM/GC, I'm not certain
>how Genera or Medley could be a multi-user environment. In my mental
>model of a LispM, code in any thread can side-effect the global
>environment, or any interactive user has access to a debugger that can
>edit the OS kernel, etc.
It isn't a multi-user environment. It's a personal computer, with many of
the same security issues as Windows or MacOS.
>So my question is, are there any papers (be they research or memos or
>software documentation) that describe the security model of a Lisp
>machine? For that matter, are there any architectural descriptions of
>a Lisp machine, e.g. processes and threads and memory protection and
>things of that nature?
It has no security model or memory protection (although the virtual memory
system supports read-only pages, so that attempting to modify constants
can be caught).
You should be able to find papers on the architecture in the proceedings of
ACM Lisp & Functional Programming and/or ASPLOS conferences from the early
80's. However, I think these mostly discussed the unique, low-level
hardware features that supported Lisp execution; the runtime architecture
is not really very unique. Lisp Machine processes are more like what we
call "threads" these days -- just an execution stack without its own
address space.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
>>>>> On 27 Dec 2001 17:46:13 -0500, Matthew X Economou ("XF") writes:
XF> The Lisp machine, as I understand it, runs all code at the same
XF> privilege level and in the same address space. While this results in
XF> some architectural niceties like the integrated VM/GC, I'm not certain
XF> how Genera or Medley could be a multi-user environment.
The Lisp Machine refers to the computer system developed at the MIT AI
Lab, and the systems directly descended from it: the various Symbolics
machines and the TI Explorer series. Those all began with the original
source code from MIT. After a while, Symbolics wanted to name their
version of the software something other than "the system" or "the Lisp
Machine system", so they called it "Genera" to indicate its generality.
The Lisp Machine was a single-user system, and had no multi-user or
timesharing protection mechanism. The Lisp Machine was very much a
multi-processing system, though. However, because Lisp programs make
their references symbolically (rather than through explicit memory
pointers), the multiple programs didn't crash into each other.
That always seems to amaze people used to more traditional systems.
Perhaps the best reference would be the Symbolics documentation,
particularly the "Internals" book, which describes the scheduler
and the interfaces to it. It was essentially what is now known
as a "threads" type of system, although it called them "processes".
However, it does not describe the scheduling algorithms in detail.
It does talk a little about stack groups and sequence breaks, and
even invoking disk IO, but not about low-level traps, clocks, etc.
There was no security (such as logging in) associated with the user's
console: you just sat down and began working. You only had to supply
login information in order to access network resources (eg. files),
in which case the security was implemented on the network server end.
You could do whatever you wanted with the workstation itself.
(This is similar to the model used today by some Unix sites, such as
the Kerberos-based public workstations at some University campuses.
Everybody knows the root password -- so, what?)
The network interfaces to the system (eg. network servers) implemented
appropriate application-level security. For example, the file servers
used passwords and ACLs to implement traditional discretionary access.
Since these servers were written in Lisp, there was no chance of the
kind of security bugs (eg. buffer overruns) that have been so common in
the supposedly more secure operating systems of the last two decades.
The network servers on these Lisp Machine "systems with no security"
were actually far more secure than the corresponding ones on the
supposedly secure operating systems of today.
There is one story that you will hear that deserves some explanation.
Early versions of the network software included servers designed to
allow the machine to be taken over remotely (eg. for remote debugging),
and there was even an unrelated server that included that vulnerability.
This was where the server would call the function READ on the input, which
allowed the attacker to input any desired Lisp expression. This exploit
was fairly well-known, and intentional, and when it was eventually decided
to be a problem, rather than convenient or humorous, the server was "fixed".
Medley was something entirely different, relating to the Xerox systems.
Was this was the software that ran on their "D-Machines"? I think the "D"
stood for Dorado, and was maybe a follow-on to the early Alto workstation.
I don't know how Lisp-specific it was. I think they used a version of
INTERLISP (not MACLISP-descended). I don't know anything about the Xerox
machines, but maybe someone will chime in.
Copyright 2001 Chris Stacy.
From: Thomas Wager
Subject: Re: Multi-user security in a LispM?
Date:
Message-ID: <3C2C5694.8030306@ti.com>
Christopher Stacy wrote:
>>>>>>On 27 Dec 2001 17:46:13 -0500, Matthew X Economou ("XF") writes:
> Was this was the software that ran on their "D-Machines"? I think the "D"
> stood for Dorado, and was maybe a follow-on to the early Alto workstation.
> I don't know how Lisp-specific it was. I think they used a version of
> INTERLISP (not MACLISP-descended). I don't know anything about the Xerox
> machines, but maybe someone will chime in.
I don't know whether Medley was the name of the Xerox software. But
their software was based on InterLISP-D, where the "D" stands for
"display". So probably the "D" in "D-Machines" stands for the same, as
all of their Lisp machines had a graphical display (which was by no
means standard these times).
-Thomas
>>>>> On Fri, 28 Dec 2001 12:25:08 +0100, Thomas Wager ("Thomas") writes:
Thomas> I don't know whether Medley was the name of the Xerox software.
Thomas> But their software was based on InterLISP-D, where the "D" stands for
Thomas> "display". So probably the "D" in "D-Machines" stands for the same,
Thomas> as all of their Lisp machines had a graphical display (which was by
Thomas> no means standard these times).
The Lisp Machine (MIT) dates from 1975 and always had a large bitmapped
display. It was designed for Lisp (the CPU executed Lisp instructions),
and all of the software was written in entirely Lisp. The Lisp Machine
was one of the most powerful computers of its day, and featured a large
address space. It was a replacement platform for the AI lab, which was
previously using MACLISP and EMACS on PDP-10 ITS timesharing.
I don't know much about the Xerox stuff, and was hoping that some of the
Interlisp guys from Xerox (Larry?) would post some information to more
authoritatively answer your questions about the D-Machines...
I think the Xerox D-Machine came out around 1981 or maybe even years later.
It's name was the "Dolphin". Subsequent D-Machine models included the
"Dandillion" and the "Dorado", and other "D" names. I also recall
hearing that "D" stood for "Display", and seperately, that the "D"
in INTERLISP-D stood for "deep binding" (not sure I believe that one).
The D-Machines ran a version of Interlisp called INTERLISP-D, to distinguish
it from INTERLISP-10 (which ran on the PDP-10). I think the Lisp that was
named after the machine, not the other way around. The D-Machines were not
really Lisp Machines -- although they supported Lisp, their operating system
and other software was not written in Lisp; it was written in Mesa-Cedar.
The machine and microcode were designed for Mesa, although there was also
some microcode support for Lisp, and this was considered the cadillac for
Interlisp development. I don't know how large the address space was, or how
it otherwise compared in speed and features or to the MIT Lisp Machines.
Interlisp on D-machines was the environment where "LOOPS", the predecessor
(along with the MIT Lisp Machine's "Flavors") of CLOS was developed.
The D-Machine was based on experience with the Xerox Alto, from 1973.
(We had a few of these at MIT, most notably serving as the print spooler
for the Xerox Dover laser printer.) I am pretty sure that the Alto was the
first workstation - the first personal computer to have a (small) bitmapped
display, window system, 3-button mouse, and local network. However, it was
a very small computer, and you could not get much "work" done on this station!)
It had some decent games. The Alto did not support Lisp. I think the operating
software was hand-written in assembler and in BCPL. Some of the applications
were written in Mesa. The Alto was the first realization of Alan Kay's "Dynabook"
computer idea, and was where he demonstrated a new language called Smalltalk.
Medley is the name of a development environment that integrates Xerox Interlisp
and Xerox Common Lisp; it's a graphical environment including DEDIT/SEDIT/TEDIT.
Supported Platforms: DOS, Linux, UNIX. I don't know the history of Medley,
or exactly how some parts of it were (obviously) descended from Interlisp-D
on the D-Machines. Try <····················@venue.com> and tell her you
want the "bits and pieces" on Medley so that you can go, "ah so".
On Fri, 28 Dec 2001 15:28:09 GMT, Christopher Stacy
<······@spacy.Boston.MA.US> wrote:
> I think the Xerox D-Machine came out around 1981 or maybe even years later.
> It's name was the "Dolphin". Subsequent D-Machine models included the
> "Dandillion" and the "Dorado", and other "D" names. I also recall
Wasn't it "DandeLion"?
> Medley is the name of a development environment that integrates Xerox Interlisp
> and Xerox Common Lisp; it's a graphical environment including DEDIT/SEDIT/TEDIT.
Here is some more info:
http://Top2bottom.net/venue.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
You got most of it right, comments inline.
On Fri, 28 Dec 2001 15:28:09 GMT, Christopher Stacy
<······@spacy.Boston.MA.US> wrote:
>I think the Xerox D-Machine came out around 1981 or maybe even years later.
>It's name was the "Dolphin". Subsequent D-Machine models included the
>"Dandillion" and the "Dorado", and other "D" names.
Dolphin, Dorado (not many of these made it out of Xerox),
Dandelion/Dandetiger (based on the Xerox 8000 computer), and Daybreak
(based on the Xerox 4045).
> The D-Machines were not
>really Lisp Machines -- although they supported Lisp, their operating system
>and other software was not written in Lisp; it was written in Mesa-Cedar.
>The machine and microcode were designed for Mesa, although there was also
>some microcode support for Lisp, and this was considered the cadillac for
>Interlisp development.
Actually, there were a bunch of different microcodes loadable on the
machine, depending on which OS you wanted to run. Interlisp-D was the
OS, programming environment, language, the whole ball of wax. From
within it you couldn't really escape down to the machine.
> I don't know how large the address space was,
32Mb, later versions I think get to 64M. Being byte-code-interpreted,
the system had a *really* small footprint. The maximum memory on a
Dandelion was 3.5Mb, and the whole environment ran just fine on a
diskless Sun 3/50.
>or how
>it otherwise compared in speed and features or to the MIT Lisp Machines.
Lots slower on any machine that you could actually buy
(Dandelion/Tiger/Daybreak). Speedwise, it was
Dorado>Dandetiger>Dandelion>Daybreak, which was sorta wierd, since
chronological release was Dorado>Dandelion>Dandetiger>Daybreak, but
the Daybreak had a 19-inch monitor and was smaller.
>Medley is the name of a development environment that integrates Xerox Interlisp
>and Xerox Common Lisp; it's a graphical environment including DEDIT/SEDIT/TEDIT.
>Supported Platforms: DOS, Linux, UNIX. I don't know the history of Medley,
The versions were initially named after musical terms in
mostly-alphabetic order, and Medley was the "M" release from Xerox. At
about the same time that Medley came out an emulator for the microcode
was written in C, and this ran on Suns. So, Medley ran on either the
dmachines or on a Sun. A Sun 3 was approximately the same speed as a
dmachine, but subsequent Suns were *much* faster. Then the emulator
(being C) was ported to a bunch of other Unix platforms and to DOS.
The really freaky thing about this was that all of the architectures
were binary compatible. Code compiled on one machine (or even a system
image) would run on any other machine.
>or exactly how some parts of it were (obviously) descended from Interlisp-D
>on the D-Machines. Try <····················@venue.com> and tell her you
>want the "bits and pieces" on Medley so that you can go, "ah so".
Yeah, the folks at Venue/Top2Bottom are the final authority on the
current state.
...arun
>>>>> "AW" == Arun Welch <·····@removeme-anzus.com> writes:
[...interesting stuff deleted...]
>> or exactly how some parts of it were (obviously) descended from
>> Interlisp-D on the D-Machines. Try
>> <····················@venue.com> and tell her you want the
>> "bits and pieces" on Medley so that you can go, "ah so".
AW> Yeah, the folks at Venue/Top2Bottom are the final authority on
AW> the current state.
Also see this thread starting with:
http://groups.google.com/groups?hl=en&selm=3B05757F.D723D1E0%40removeme.gst.com
cheers,
BM
Arun> Actually, there were a bunch of different microcodes loadable on the
Arun> machine, depending on which OS you wanted to run. Interlisp-D was the
Arun> OS, programming environment, language, the whole ball of wax. From
Arun> within it you couldn't really escape down to the machine.
If that's correct, then the D-Machine would certainly qualify as a
Lisp Machine when running Interlisp-D. So, you could not run the
other (non-Lisp) operating system and application software without
rebooting the processor to a different microcode?
I know there was some support (not sure what) for Lisp in the microcode.
For some reason, I always thought that although Interlisp-D provided a
window system, it was running on top of a Ceder-Mesa-based kernel that
provided things like interrupt handling, instruction failures, paging,
disk IO, and otherwise managing the hardware at a low-level, and also
probably provided upper level services like a file system and network.
Having the Interlisp-D implementation call such kernel services, but
not allow the user to "escape from Lisp" and access them directly,
would give the illusion that it was "Lisp all the way down" to the
silicon as the MIT Lisp Machines were.
I'm just asking for clarification, because (as I indicated in my
first contribution to the subject) I really don't know anything
much about the Xerox machines.
By the way, I also stated that the Alto didn't support Lisp.
But looking at some literature, I think it really did (in the lab,
anyway) have some version (or at least subset) of an Interlisp
interpreter and development environment running on it at some point.
I believe the main lesson learned from that experiment was that the
machine was too small and underpowered to be useful that way, though!
On Sat, 29 Dec 2001 08:03:09 GMT, Christopher Stacy
<······@spacy.Boston.MA.US> wrote:
>I know there was some support (not sure what) for Lisp in the microcode.
>For some reason, I always thought that although Interlisp-D provided a
>window system, it was running on top of a Ceder-Mesa-based kernel that
>provided things like interrupt handling, instruction failures, paging,
>disk IO, and otherwise managing the hardware at a low-level, and also
>probably provided upper level services like a file system and network.
Nope, all that was in Interlisp. That's what made some of the ports of
the emulator really interesting. Running Medley on a DOS machine, for
example, instantly gave you a whole network stack, so you got TCP/IP,
XNS, and PUP on a machine which normally didn't have it. The file
systems weren't compatible with Mesa, so if you had a system set up to
run Interlisp you couldn't access files in a Mesa partition and vice
versa.
...arun
>>>>> On Sat, 29 Dec 2001 16:04:11 GMT, Arun Welch ("Arun") writes:
Arun> On Sat, 29 Dec 2001 08:03:09 GMT, Christopher Stacy
Arun> <······@spacy.Boston.MA.US> wrote:
>> I know there was some support (not sure what) for Lisp in the microcode.
>> For some reason, I always thought that although Interlisp-D provided a
>> window system, it was running on top of a Ceder-Mesa-based kernel that
>> provided things like interrupt handling, instruction failures, paging,
>> disk IO, and otherwise managing the hardware at a low-level, and also
>> probably provided upper level services like a file system and network.
Arun> Nope, all that was in Interlisp. That's what made some of the ports of
Arun> the emulator really interesting. Running Medley on a DOS machine, for
Arun> example, instantly gave you a whole network stack, so you got TCP/IP,
That sounds pretty cool. So of course now I am wondering, how was it ported?
>>>>> On Sat, 29 Dec 2001 19:18:46 GMT, Christopher Stacy ("Christopher") writes:
>>>>> On Sat, 29 Dec 2001 16:04:11 GMT, Arun Welch ("Arun") writes:
Arun> On Sat, 29 Dec 2001 08:03:09 GMT, Christopher Stacy
Arun> <······@spacy.Boston.MA.US> wrote:
>>> I know there was some support (not sure what) for Lisp in the microcode.
>>> For some reason, I always thought that although Interlisp-D provided a
>>> window system, it was running on top of a Ceder-Mesa-based kernel that
>>> provided things like interrupt handling, instruction failures, paging,
>>> disk IO, and otherwise managing the hardware at a low-level, and also
>>> probably provided upper level services like a file system and network.
Arun> Nope, all that was in Interlisp. That's what made some of the ports of
Arun> the emulator really interesting. Running Medley on a DOS machine, for
Arun> example, instantly gave you a whole network stack, so you got TCP/IP,
Christopher> That sounds pretty cool. So of course now I am wondering, how was it ported?
[Having phoned up one of the people who did it...]
By implementing (in C) a virtual machine that was similar to the
virtual machine provided by the Interlisp microcode on the D-Machine.
In Medley, however, some changes were made to the low-level interfaces,
with corresponding changes in the Interlisp environment. For example,
disk IO on the D-Machine was done by Interlisp code doing calls that
would set up the disk buffer and initiate a DMA transfer. Under Medley,
Interlisp uses a higher level interface than that (accessing a disk
file channel).
D-Machines are cooler than I ever knew, and were definitely Lisp Machines.
Christopher Stacy wrote:
> The Lisp Machine refers to the computer system developed at the MIT AI
> Lab, and the systems directly descended from it: the various Symbolics
> machines and the TI Explorer series. Those all began with the original
> source code from MIT.
Perhaps LMI should also be mentioned in this context?
--
>>>>> On Sat, 29 Dec 2001 02:23:50 +0200, Martti Halminen ("Martti") writes:
Martti> Christopher Stacy wrote:
>> The Lisp Machine refers to the computer system developed at the MIT AI
>> Lab, and the systems directly descended from it: the various Symbolics
>> machines and the TI Explorer series. Those all began with the original
>> source code from MIT.
Martti> Perhaps LMI should also be mentioned in this context?
Yes.
The Lisp Machines Inc. (LMI) Lambda was very similar to the MIT CADR.
(Very similar, but not all exactly the same microcode and macroinstructions.)
In particular, it implemented a cache, and also supported multiple CPUs.
The Lambda was packaged as a set of boards that plugged into a NuBus
machine. The host machine was designed for a 68000-based Unix box,
originally built by Western Digital, and acquired by Texas Instruments.
It represented the productization of the NuBus, which was developed
by the real-time systems group at MIT LCS (downstairs from the AI lab).
LMI also created a new architecture called the K-Machine, which was
further developed by GigaMOS, the short-lived successor to the assets
of Lisp Machines, Inc. The K-Machine was a chip; it was to embedded
in a Macintosh. Unfortunately, that never made it out of the lab before
GigaMOS was destroyed in a bizarre situation involving a major Japanese
investor and a scandal with the election of the Canadian Prime Minister!
TI produced the Explorer system, which was another NuBus workstation,
similar to the Lambda (but without multiprocessor capability);
the (pcb) processor was again very similar to the MIT CADR.
TI also eventually produced the same processor on a chip.
Through the course of some business deals, TI managed to effectively
subsume LMI, just before killing off that segment of the market...
The Symbolics LM-2 was a simply a repackaged (that is, PC board, rather
than wirewrapped) MIT CADR. This was their placeholder entry product
while developing their next version of the Lisp Machine, the 3600.
The 3600 was a new architecture and instruction set, 36-bits.
The 3600 family was developed in a series of technologies, including
gate-arrays, and several versions of proprietary busses.
Symbolics later introduced another new architecture: the Ivory chip.
There were several successively faster versions of the chip.
Ivory was available as a stand alone VME workstation, or as an embedded
full-system for SUN Unix (VME) systems and for the Macintosh family.
(Symbolics also had a number of other systems and architectures that
unfortunately never shipped, including a RISC machine.)
I think you can also probably still buy an XL-1200 VMEbus workstation
or a MacIvory system from the remaining/refurbished Symbolics inventory.
Finally, Symbolics produced a total emulator for their machine, which took
advantage of their embedding products' "life support" features: the result
was a Virtual Lisp Machine that ran on the DEC Alpha processor under Unix.
This product, called Open Genera, is still available today from the new
Symbolics company. Here are two papers about that:
<http://www2.thecia.net/users/ptw/LispM.html>
<http://www2.thecia.net/users/ptw/VLM.html>
The Symbolics software represented the most highly developed (by far)
and divergent child of the original MIT system, with massive additions,
although there was still a considerable amount of code that never changed.
You can see some pictures of a lot of these machines
(not just Symbolics) at this web site:
<http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics.html>
And, there are many other relevent interesting links on that web site!
I think there might have been another Lisp Machine, by some other company
called IMM or something like that. I don't know if it was ever released,
or anything about it, except that it was to have lots of (physical?) memory.
Christopher Stacy wrote:
> I think there might have been another Lisp Machine, by some other company
> called IMM or something like that. I don't know if it was ever released,
> or anything about it, except that it was to have lots of (physical?) memory.
As far as I remember from some papers at the time, the idea was to avoid
all this hassle with virtual memory systems by loading the machine with
something like 256 megabytes of physical memory, IIRC. This at the time
that a high-end Symbolics might have had 4 Megawords...
I'm not sure whether any were ever produced.
--
Martti Halminen wrote:
>
> Christopher Stacy wrote:
>
> > I think there might have been another Lisp Machine, by some other company
> > called IMM or something like that. I don't know if it was ever released,
> > or anything about it, except that it was to have lots of (physical?) memory.
> As far as I remember from some papers at the time, the idea was to avoid
> all this hassle with virtual memory systems by loading the machine with
> something like 256 megabytes of physical memory, IIRC. This at the time
> that a high-end Symbolics might have had 4 Megawords...
>
> I'm not sure whether any were ever produced.
I think the company was IIM (Integrated Inference Machines) in LA and Kim
Barrett was one of their lead people. I visited them in 1989 and can verify
that the machine existed and ran. I remember dimly that development of these
machines was mostly funded by government spook work to be used for image
analysis or something like that, but that IIM hoped to transfer the
technology into the commercial LM market as well.
In article <·················@pacbell.net>,
"Steven M. Haflich" <·······@pacbell.net> writes:
> I think the company was IIM (Integrated Inference Machines) in LA and Kim
> Barrett was one of their lead people. I visited them in 1989 and can verify
> that the machine existed and ran. I remember dimly that development of these
> machines was mostly funded by government spook work to be used for image
> analysis or something like that, but that IIM hoped to transfer the
> technology into the commercial LM market as well.
I too got to visit I2M in the LA garage about '89. I seem to remember they
had a card that plugged into a IBM PC. We visited them to evaluate the idea of
making a rad-hard version for space applicatons. (I worked at Harris Corp. at
the time.) The biggest obstacle (other than money!) was getting enough
rad-hard memory. As far as I know, nothing ever came of any of their work.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> I too got to visit I2M in the LA garage about '89. I seem to remember they
> had a card that plugged into a IBM PC. We visited them to evaluate the idea of
> making a rad-hard version for space applicatons. (I worked at Harris Corp. at
> the time.) The biggest obstacle (other than money!) was getting enough
> rad-hard memory. As far as I know, nothing ever came of any of their work.
I think "nothing" is definitely too strong a word. There was a patent
granted to IIM for their Lisp processor. Also, there are at least two
mentionings of IIM in the Common Lisp Hyperspec usually in the context
of describing current practice of Lisp systems.
http://www.xanalys.com/software_tools/reference/HyperSpec/Issues/iss197-writeup.html
http://www.xanalys.com/software_tools/reference/HyperSpec/Issues/iss260-writeup.html
Clearly something was happening.