Re: Emulator, Inc

[Eric Smith <eric-no-spam-for-me@brouhaha.com>]

"Bryan Parkoff" <nospam@nospam.com> writes:
>     I believe that you must be a good C/C++ programmer that can write
> shorter routines that will make Emulator run much faster.  It is wasting a
> lot of time to write in assembly language.

If you don't need every last little bit of possible performance, yes,
the output of compilers will do just fine.  Given that KEGS on a modern
machine can simulate at 80 times the speed of a real GS, use of assembly
language for an Apple II simulator is probably not worthwhile.

>     I know that Pentium 4 has some problems, but I stay on Xeon Pentium III
> until Pentium 4 will be fixed.

What problems are these?

>     If you want to avoid using classes, I recommend to write global
> variables that are much easier to read that looks like classes.  Lets says,
> 
> class CPU
> {
>     DWORD m_Accumulator = 0x00;
>     DWORD m_XIndex = 0x00;
>     DWORD m_YIndex = 0x00;

If you expect your code to be portable to anything other than Windows,
*please* don't use DWORD etc.  Those are disgusting Microsoftisms.  The
C standard defines (in stdint.h) the types int8_t, int16_t, int32_t, and
int64_t as signed integers, and uint8_t, uint16_t, uint32_t, and uint64_t
as unsigned.

>     All 256 6502's OpCode routines stay in CPU_Run() by using goto statement
> rather than calling functions.

In my Atari vector game simulator from 1991, I found that avoiding function
calls was good on some platforms, but having huge functions with switch
statements containing lots of code, or gotos between blocks of code, was
bad on some platforms.  I won't claim that it is good code or that I would
write it the same way today, but the code is at:
    http://www.brouhaha.com/~eric/software/vecsim/
Note that the code is obsolete as MAME does a much better job (and actually
uses a few bits of my vecsim code).  I present it only as an example.

It's probably best to write the code to be as clear as possible for ease
of development and maintenance, so having separate functions is preferred.
You can define a preprocessor variable to control whether the separate
functions are inlined:

  #define INLINE inline
or
  #define INLINE

depending on the platform, then use INLINE in the function declarations.

> Three local variables are inside classes so
> it won't show global variables.

Local variables are good for helping the compiler recognize the scope
of the variable, and improving efficiency of register use.

Eric