Hardware Hobbyists vs. Emulator Enthusiasts vs Replica Recreators
ray at arachelian.com
Sat Jun 20 10:59:05 CDT 2009
Andy Holt wrote:
> On the F8 after a jump instruction
> according to the doumentation the contents of the accumulator became
> in the real hardware they were very well defined, but totally wierd: the
> low order 8 bits of the jump address.
> after some discussion with the department who was teaching this micro, the
> emulator corrupted the accumulator
> but to a different value. So in one sense it was not a correct emulator;
> but in another it was a far more useful
> development tool
Depends on your goals, however, if any existing code took advantage of
the bug or at least invoked that bug, you should have implemented the
actual behavior, because otherwise that software will not run on the
emulator and would run on the hardware. Since you goal (or the rest of
your department) was to prevent someone from using the bug as a way to
optimize their code, that was the path you took.
Were you to try to build that emulator for historical purposes, you'd
want to faithfully emulate the bug.
In my own case, the guys that built the Lisa's MMU took advantage of
undefined 68000 behavior (the reference guide won't give you the exact
details, just says things like the PC value in a bus error stack frame
will be incremented by some number), and managed to build a way to
restart certain specific opcodes, and had built their compilers to emit
code that would limit itself to just those opcodes when accessing a page
of memory not previously accessed. That was the biggest pain of all in
getting it to work, until I disassembled their bus error routine and was
scratching my head as to why they were subtracting values from the PC on
the stack frame based on what opcode triggered the bus error; a light
bulb immediately light up over my head, and as soon as I made that
change, Lisa Office System immediately started to work. :-)
When looking at code in the Lisa boot ROM, you can find stretches of
code written in specific styles, some of them are better than others,
and what they're really good at is optimizing.
In run of code, you can easily tell what's been written by a human
writing tightly optimized assembly, and what a compiler generated. And
the stuff that's hand written, when it's really good will make you say
"What are they doing?" - two seconds later when you look things up in
the reference guide you see why their way is better. Sometimes you do
see naively written assembly too.
It's certainly very educating to look at code of that era. Modern code
is rarely so heavily optimized, and mostly comes out of a compiler,
which sometimes can do good optimizations that are very hard to even
follow. But in most cases, they emit a lot more code than needed.
More information about the cctalk