[LMH] Ooh, look! List traffic!

[Nyef]

On Thu, Mar 04, 2004 at 06:57:03PM -0800, Dan Moniz wrote:
>
> Which is an interesting point. I wonder how hard it would be to write the 
> emulator (or CPU) in Verilog (being somewhat higher-level and easier to 
> cope with than VHDL, at least for this task). I assume "hard", and that 
> would be an understatement. But possibly worthwhile.
> 
> Of course, there's the longer term problem of getting a monitor and input 
> devices to talk to it, which would be painful, and disks, file systems, a 
> running install, oh my!

Indeed. At this point we're approaching where I'd prefer we had the rights
to the source and disk images sorted out.

> Probably, now that I think about it, an FPGA-based Explorer processor on a 
> PCI card, with some interface glue would be the way to go.

I'd prefer a PCMCIA card, mainly because I mostly use laptops these days.

> Alastair, I should have asked you this years ago, but I've been somewhat 
> confused for a while as to where exploiter fit into the picture. E3 was 
> supposed to be an emulator, and exploiter was, what, your independently 
> developed emulator? And nevermore is the same sort of thing in CL (Mike 
> already asked this, but I had gathered as much from the code). For a while 
> now I've been confused as to what the relation was between E3 and 
> exploiter, but I never thought to ask. I always thought it was explained in 
> one of the previous list emails, but in infrequent and rather shallow 
> searching of my personal archive of lispm-hackers over the years, I never 
> found a mail with an explanation. I'm just curious, BTW, because this bit 
> of information has been missing from my picture of the development effort.

Okay, so here's how it happened...

Once upon a time, there was E3. And it was a wonderful idea. It could read
a load band and disassemble the first function in it, but that was about
all it could do. This is how it was when I stumbled across it.

Some months later, after some effort was invested in the standalone-E3
code, and SSDN2 started being converted to text files, E3 could read a
load bad and disassemble the first function in it, but that was about all
it could do.

For the past several months, the discussion had been about how to implement
function calling, since the first (well, second) instruction to execute was
a function call instruction. Unfortunately, I couldn't work on E3 because
it would throw my computer for a loop every time I tried to run it (nasty
kernel messages and everything). But I didn't like seeing the complete lack
of progress with people talking about how hard the next step was and not
doing anything about it.

During this time I had done some studying of various things like the load
band and the existing E3 source and such, and had some code for looking at
a load band a little more meaningfully than as a hexdump. So I wrote a
quick hack to read a load band, find the initial function, and then
"execute" the first couple instructions, just to see how hard it really
was. And it was -easy-. So I posted that first message to the list, trying
to say "come on, guys, it's not that hard, just write the damned code."

Nothing happened on the E3 side, but my curiousity wouldn't let me leave my
own quick hack alone for too long. So a little while later I had quite a
bit more working, made a tarball with my sources, and posted the first
version of exploiter. And soon another.

Now we get into some of the previously-undisclosed history:

At this point, John Morrison, by private email, asked about reconciling my
work on exploiter with E3 because there now appeared to be two projects
where once there was one. I explained my position (more accurately, ranted
for a bit), and gave a list of what I felt was wrong with E3. This was
Tuesday, May 21, 2002. Other things that happened on this day included me
figuring out how to run E3 without breaking my computer, and Robert
Swindells sending me the first unsolicited patch against exploiter. On the
following Thursday I exchanged emails with John again, with me explaining
why I was going to continue with exploiter and not try and fix E3.

This wasn't supposed to happen. There was a two and a half week window in
which -any- progress on E3 would probably have caused me to drop exploiter,
and which I would have welcomed as being a sign of exploiter succeeding at
what it was supposed to do. There was a two-day window in which John could
have done the same by fixing any two things on my list of complaints
(admittedly, neither of us knew that at the time, and he was busy with his
day job, and fixing the easiest two problems would have taken a few hours
at least).

After this point, very few if any changes were made to E3, and exploiter
gained a lot of momentum and carried it fairly well for a while.

So, from what I see, exploiter was the quick hack originally meant to light
the way for E3 that accidentally ended up killing E3 and taking its place.


The history of nevermore is actually recorded in the readme file in the
source distribution. It was originally a microcode disassembler that ended
up becoming an emulator. Unlike E3 and exploiter, nevermore is a microcode
emulator, which means that it will likely be slower than E3 or exploiter
would have been / will be, but also means that it should be able to run VM1
code if we ever find a disk image that old. There are other implications as
well, but I'm not really up to figuring them out right now.


This was probably more information than you really asked for, and I don't
know if it answered your questions or not, but... Whatever. I'm tired. I'm
going to bed.

--Alastair Bridgewater