Re: Emulator Project Question

[Doug Kwan <NOSPAMdkwanNOSPAM@gauge.transmeta.com>]

In comp.sys.apple2 Colin Klipsch <klipsch@mail630.gsfc.nasa.gov> wrote:

: I believe Metrowerks' Codewarrior also supports this now, as an
: extension, along with other gcc goodies.  Also, I believe that gcc
: supports case _ranges_, which can save some typing.

: ... if, as you say, you're willing to sacrifice portability.

Not necessarily. You could #ifdef those gcc extension and fall
back to ANSI C if you are not compiling with gcc.

: Agreed.  And yes, useless range checking is one drawback of employing
: a C/C++ switch statement as the opcode interpreter.  However, I've
: found that you can coax most compilers into eliminating _one_ of the
: comparisons if you do the following:

:   (1) Switch on an unsigned, not signed, value.
:   (2) Be sure to include a "case 0", even if its body is empty.

:> For performance tuning, you may still want to write a _small_ part
:> of your emulator in assembly of the host.

: Ah, now you have _definitely_ sacrificed portability!

It is a matter of abstration and layering. You could localize you
machine specific codes into a small set of files. There is also
a law prohibiting you from provide a generic version for all
architectures of a piece of codes together with a few versions
optimised for certain architecture with assembly.

In Unix, you could always use autoconf and appropriate #ifdef's.
I am not suggesting that one should write your programme 100% in
assembly.

There is portability problem even if you write in ANSI-C.
Operating systems and architectures could be different in subtle
ways like system calls semantics, endianity and data size.

: We largely agree here.  My thinking though is that today's computers
: -- in fact even yesterday's computers, going back ten years -- are
: easily fast enough to emulate an Apple II at its authentic speed, if
: you code the emulator in C/C++ and if you write the big bottlenecks
: (like the instruction interpreter, and the video renderer) in a style
: _resembling_ assembly language.  Here, it certainly helps to have
: programmed in assembly language before, preferably in one's reckless
: youth, and to know what sorts of practical jokes compilers like to
: play when they generate code.

I beg to differ. I wrote my Apple II emulator about 9 years ago (1992).
It first ran on a 40MHz (??) Sparc IPC workstation that did not make
1MHz. It was solely written in C. The reason I did dynamic emulation
it to break the 1MHz barrier. The PC those days had 286 or 386 mostly.
The clock speed was less than 100MHz.

At the time, the faster Apple emulator were written in assembly.
AppleWin came out around that time and I believe Mike O'Brien
used assembly in either the CPU core or the BitBlt codes.
 
It is trival to write a C based Apple II emulator these days to
be faster than 1MHz but definitely not 10 years ago. Machines
were lots slower and C compilers were worse too.

: As a personal choice, I wouldn't bother with assembly language
: anymore, except maybe at gunpoint.  (And even then, you'd have to give
: me a minute.)  It's just so time consuming to get right, to keep free
: of bugs, and of course, it doesn't port well at all.

I take a less extremist approach towards assembly. I generally
try to avoid coding in assembly but use it if it is the right
tool. There is a price to pay in terms of maintainability and
portability to pay so I don't so them unless the gain offset
the cost.

-Doug