Emulator vs simulator performance

[Jonathan Busby]

(06-05-2020 03:26 PM)David Hayden Wrote:  [snip]
The Saturn CPU is a pretty different from an x86.

I would put it as *extremely different* The only real similarity is that the x86 and Saturn family of processors both use a "dest = dest op source" machine code format for many of their arithmetical-logical operations,
although the Saturn has many "dest = source op dest" machine instructions as well

Quote:Emulating it might be harder than a more traditional one. Things like register fields might be hard.

If you're writing the emulator in a language like C, then dealing with register fields means dealing with a lot of bit-masking and bit-shifts ( except for maybe the Emu48 family of emulators which seem to perform decimal operations ( and apparently HEX mode operations as well ) in a nibble serial
manner if I'm not mistaken. This might explain why some of the emulators are so slow with respect to emulating Saturn machine code arithmetic and comparison instructions )

Quote:And if the Saturn BCD arithmetic doesn't translate well to x86 then that could be a problem.

The BCD instructions on modern x86 CPUs are legacy instructions that have been relegated to the CPU's microcode ROM, and are therefore very slow.

The 32-bit x86 CPUs only have instructions that operate on two packed BCD digits at a time. For example :

Code:

MOV AL, 42h
MOV CL, 33h
ADD AL, CL
DAA

which adds packed BCD 42 to 33, or :

Code:

MOV AL, 42h
MOV CL, 33h
SUB AL, CL
DAS

which subtracts packed BCD 33 from 42 .

The "DAA" and "DAS" instructions stand for "Decimal Adjust for Addition" and "Decimal Adjust for Subtraction" respectively.

In AMD64 / x64 "long mode", the above DAA and DAS instructions are not available, having been used as part of the 64-bit instruction set encoding.

In C, especially on a 64-bit x64 machine, it's faster to use a little bit-twiddling and arithmetic trickery to perform packed BCD arithmetic. ( a quick google search turns up many solutions for addition and subtraction of packed BCD integers in C using only bitwise operations and arithmetic, eg. see this Wikipedia solution in C which uses just ten
bitwise and arithmetic operations ( no multiplication or division ). Also, I do have a vague memory of a bitwise solution that only used *six* operations, but I can't remember where I when I saw it and I can't seem to reproduce it "de novo" either :/ . On many ARM processors, even the above ten operations
can be reduced to just *eight* operations because of many ARM processors' "0-cycle" barrel-shifter which one gets for free with most ARM arithmetic or bitwise instructions )

( EDIT #1 : The above statements about ARM-based processors' "free" or "0-cycle" barrel-shifter may not be entirely accurate, as I haven't done much ARM assembly language in a long while. I believe that the previously "free" shift operation may incur some performance penalties on more modern ARM processors, although I'm no expert on ARM assembly, so I'm not sure )

Quote:Also, it's my understanding that the 42s is implemented in SysRPL. That adds another layer of complication and slowdown compared to assembly language.

Indeed RPL on Saturn CPU's involves at least *three* levels of indirection a lot of the time

Quote:As I recall working with C on a 50g, the speed difference there is something like native C code is about 5x faster than Saturn assembly, which is about 5x faster than SysRPL, which is about 5x faster than User RPL. Those values may vary somewhat, but I do recall specifically that C code is about 100x faster than userRPL on the 50g.

That sounds about right

Regards,

Jonathan

P.S. The formatting seems to be messed up in the preview of this post with long lines running off-screen which generates a scroll bar.