Abgeschickt von ukslim am 19 Oktober, 2000 um 10:26:51:
Antwort auf: Re: too bad zsnes source isnīt available... von Alien8 am 18 Oktober, 2000 um 18:12:46:
Just to back up what SonicBlur has already said:
"ASM" is not a single language. Every CPU (or every family
of CPUs) has its own set of low-level instructions,
and ASM is a human-readable version of those
instructions. Hence, you get X86 ASM, SH4 ASM,
68000 ASM, PowerPC ASM etc, and they're all
different. Converting ASM into machine code is
a very simple matter, because you're telling the
CPU *exactly* what to do.
(It's because of this non-trivial difference between
processors that we need emulators in the first place).
When you write C, the C compiler converts the logic
of the C code into ASM, which in turn gets converted
to machine code. C is a high-level language
, which means it does not vary depending on the
target processor. It's the compiler's job to know
about your target processor and create the right
sort of ASM.
It is also the compiler's job to try
and make sense of your code, and to optimise the
ASM so it does the job as fast as possible, while
retaining the logic you coded. A simple example
might be: when you use a variable in C, the
compiler might decide that the value will be stored
in a register (a small piece of memory right there
on the CPU) or in main RAM. Registers are fast but
scarce, RAM is plentiful but slower. The compiler
has to make decisions as to how often that variable
is going to be accessed, and although it can analyse
the C code, it doesn't know as much about that
variable as the programmer would have.
So, C: it's easier to write than ASM because it
deals in high-level things we understand like FOR and WHILE
loops (while ASM deals in low-level things like
"Branch to memory address 0x12AF if the value at
the top of the stack is not zero"). C code can
be compiled to many different ASM languages, so it
ought to never become obsolete.
A human being can write ASM directly, but it's harder
work, and if you move to a different CPU you have
to start again. OTOH, because you have fine-grained
control over how the chip does things, you can
write code which runs much faster.
Blimey, I seem to be writing an essay.
Both SNES9X and MAME were written in C, mainly
because portability was a major goal for them. That's
why we have SNES9X and MAME on Mac, PC, UNIX, Amiga etc.
There's even a MAME port to Kodak digital cameras!
Having said that, since ASM CPU emulation cores
written in X86 ASM were available, SNES9X and MAME
both allow you to use these if you happen to be
compiling for an X86 target, which means you get a
speed benefit as well.
FWIW, MAME also chose C because they intend to be
a documentation project above all else. Their C code
is effectively a historical record of what a Pac Man
board was like. An ASM implementation would be a
less valuable historical record, because while C is
reasonably self-explanatory, ASM requires you to
first understand the target chip.
ZSNES runs like lightning, because it was hand-coded
in ASM. Good on 'em, but to gain that speed, they
sacrificed portability. Doing the same thing for the
Dreamcast's SH4 would basically mean starting
all over again. Someone might be mad enough to do
it, but in truth I don't think the SH4 is a
mainstream enough platform to tempt anyone to do it.
In truth, I'd prefer it if the clever bastards who
write all this fantastically fast hand-optimised
ASM were to turn their hand to compiler writing.
I'm sure C compilers could do a lot more optimisation
if only someone were to think about it a little.
NB It's entirely possible that DreamSNES does not
even have compiler optimisations turned on: it's
beta code after all; maybe Marcus wanted to leave
debugging info in there, in which case the code
*will* be slower, but it'll be easier to debug.
Getting faster code for the full release would
then just be a matter of adding -09 to the
compiler flags.