Re: Emulator, Inc

["Shawn B." <leabre@html.com>]

Assembly programming is not obsolete.  Intell and MS and other C/C++ tool
venders would like it to be so you can purchase their tools.  I've heard all
the arguments before.  In particular, I think assembly programming is a good
choice if 1) you know you aren't going to be changing platforms, 2) you need
absolute performance in your inner loops, and 3) it would be difficult to
achieve or not very efficient to achieve in a higher-level language.

It can be done in C/C++ rather easily.  Using Goto's in a single Run()
method is not a good practice, IMHO.  Instead, you can create inline C/C++
functions or macros that simulate the execution of an instruction.

The architecture I've chosen to for my 65c02 processor simulator (not an
emulator of a particular device, such as an Apple or Commadore) is to have a
CPU class and some enumerations.  Enumeration for the Opcodes and Address
modes.  Then a struct for the current opcode that keeps track of the
instruction, address mode, cycles, and size.  The CPU class has an
instance-level Status flag byte, opcode struct, the registers, a Fetch(), a
Decode(), and an Execute() (for executing the instruction).  That's
basically it.  This is meant to be a processor core, once again.

Now, I'm doing this in C#, so I don't have the option of inlining code or
asm instructions.  Fortunately, the C# compiler is smart enough to know when
to compile a function inline and when not to.  I purposely don't want to do
my project in C++ but have no problems doing so, it would perform better
because then I can do some specific optimizations rather than trusting the
IL but I've examined my IL output and the JIT'd code and it seems okay, okay
enough for a 1-5MHz 6502-65816 CPU.  That doesn't include sound and graphics
processing, but again, I'm only talking about a processor core (I'm
intending it to allow me real-time debugger while running my custom-made NES
and SNES games, realtime meaning I can change the program while it's
currently executing and being debugged).

Anyway,

Thanks,
Shawn


"Bryan Parkoff" <nospam@nospam.com> wrote in message
news:MqHhb.3861$3A6.1607@twister.austin.rr.com...
>     I have read Darek's website at http://www.emulators.com/.  Darek is an
> emulated programmer and he told me that he claims that C/C++ language is
the
> WRONG languge for Emulator Project.  He says that he focuses at assembly
> language for best optimization and performance.  It is almost impossible
for
> me to tell since he has been programming for over 17 years.  He always
> disagrees with many programmers for general Emulation.
>     The fact is that Assembler Language is obsolete that Microsoft and
Intel
> claim.  Both of them recommend to use C/C++ language.  The C/C++ compiler
> will do its job to optimize C/C++ source code.
>     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.
>     I know that Pentium 4 has some problems, but I stay on Xeon Pentium
III
> until Pentium 4 will be fixed.  I don't like Intel's rules for avoiding
some
> x86 instructions, but I am told that Visual C++ 7.0 will be recommended
> because C/C++ 7.0 has adjusted the optimization over Visual C++ 6.0's
> Compiler 6.0, otherwise I would buy Intel C/C++ Compiler 7.0 that will
plug
> into Visual C++ 6.0 or 7.0.
>     It is the way I can write shorter routines for my Emulator Project and
> then I compile and go into debugging mode.  I can read x86 disassembler
that
> it makes sense to me (I don't use inline assembler function or MASM 6.11).
> If it is in release mode, it will be difficult for me to understand by
> reading x86 disassembler because it is already optimized that it is not
the
> same as debugging mode.
>     I can tell that KEGS32 Project has a huge source code and have a very
> long routines.  It is not good for writing emulated practices.
>     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;
>     void CPU_Run();
>     void CPU_Initialize();
>     void CPU_Terminate();
> }
>
>     All 256 6502's OpCode routines stay in CPU_Run() by using goto
statement
> rather than calling functions.  Three local variables are inside classes
so
> it won't show global variables.
>
>     If you choose not to use classes, there is an alternative.
>
> DWORD CPU_Accumulator = 0x00;
> DWORD CPU_XIndex = 0x00;
> DWORD CPU_YIndex = 0x00;
>
> void CPU_Run();
> void CPU_Initialize();
> void CPU_Terminate();
>
>     It is global variable that begins with CPU_ instead of g_ for easy
> reading.  All functions are global functions.  It will reduce minor bugs.
> Use BYTE and WORD keywords are bad practices for Emulator because C/C++
> compiler always adds "AND" instruction to clear 32-Bits, 24-Bits, and
> 16_Bits.  DWORD is chosen so "AND" instruction is removed.  It can reduce
> x86's cycles and improve performance.
>     Do you know what I mean by examining debugging mode so you can see
> unneeded instructions?
>
>     I would like to discuss with some Apple II Emulator programmers via
> e-mails if it is possible.  It is not good to post Emulator Project
> Programming Practices on newsgroups because nobody is interested in
writing
> Emulator Project until they are interested to play released Apple II
> Emulator software.
>     Please advise.
>
>
> -- 
> Bryan Parkoff
>
>