[LispM-Hackers] Outageness

[Nyef]

On Tue, 26 Feb 2002, Paul Fuqua wrote:

> Excuse me, I'm laughing.
>
> It's probably a reasonable request, but it doesn't have a reasonable
> answer.  What you really want is the processor spec (never made public,
> so far as I know), plus some other internal documentation that was never
> made public, plus some internal information that was never written down
> except as a program.

Somehow I'm not suprised, but I figured that I didn't have much to lose by
asking, and there was a chance I'd learn quite a bit if I did so.

I can probably figure things out without it, it'll just take longer...

> The microcode assembler really had no syntax.  Each instruction was
> either a label or a list of symbols whose values were ORed together to
> make the instruction word.  (Well, there were extra parens added to
> differentiate register destinations from register sources, and others
> for LDB expressions, but that's about it.)  Most of the symbols came
> from def-elroy.lisp and ravfmt.lisp and ravsym.lisp, which I think are
> in sys:ubin; or sys:ucode; if they made it to released source.

This is almost exactly what I needed to know about the microcode assembler
syntax. I can make the rest up as I go along. Thank you.

> Anyway, that gets into the question of what level you want to emulate an
> Explorer at.  If you stick to the macroinstruction level, you don't
> really need exact details of the microcode.  If you emulate microcode,
> you also have to worry about emulating the boards, since the controllers
> for disk and display and ethernet are all NuBus devices that respond to
> values read and written at particular memory addresses.

It also gets into the question of why you're emulating the explorer at the
level you're emulating it at. If writing a microinstruction level emulator
would tell me something about the system, or about microcode in general,
why not do it?

> I'm in the macroinstruction camp, but at the same time I worry about
> things like paging (which can probably happen transparently behind the
> scenes) and GC (which is partly behind the scenes and partly in
> instructions like %gc-scavenge).

I certainly agree that for an emulator usable to run the system _as a
system_, you most likely will want a macroinstruction level emulator.

But a microinstruction level emulator could be easier to write (since the
instruction set is simpler), and may be useful in it's own right (for
answering questions about how the system does certain things).

> If I ever get my Explorer put back together and get my home PC updated
> to FreeBSD 4.5, I'll try to do a microcode disassembler and contribute
> something more than hot air.
>
>                               pf

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net