#define (from C) in Python

Santiago Romero sromero at gmail.com
Fri Nov 13 07:21:00 EST 2009


> > #define STORE_nn_rr(dreg) \
> >                         r_opl = Z80ReadMem(r_PC); r_PC++;\
> >                         r_oph = Z80ReadMem(r_PC); r_PC++; \
> >                         r_tmp = dreg; \
> >                         Z80WriteMem((r_op),r_tmpl, regs); \
> >                         Z80WriteMem((r_op+1),r_tmph, regs)
>
> Someone writing such code and calling it C should be taken
> behind the barn and shot.

 That code is mine and maybe you should look the context
before doing such kind of affirmations.

 In the Intel Pentium and P-II ages, I started to wrote the
very first Spectrum emulator in C. With that "cpu power", emulators
had to be written in ASM to be capable to emulate the destination
machines at 100% full speed in multitasking systems.

 In the emulation world, every CPU cycle you can save is gold,
and writing the above code as inline code saved lots of CALLS,
PUSHs/POPs (parameters to stack), and RETs. That allowed ASpectrum
to run 100% speed on old computers and even to be ported to the
Sega Dreamcast's 200Mhz CPU.

 Think that Z80ReadMem() can be called up to 6 times in each
emulated CPU-cycle. Saving 6 CALLs, 6 PUSHes, 6 POPs, and 6 RETs
in each cycle of the 3.500.000 of Hz **did** make the difference
that allow Aspectrum to run at 100% speed in ancient machines.

 Obviously, I prefer to write well structured code but I had to
sacrifize SIZE by SPEED (size as inline code is included in the
binary executable file).

 Each coding technique has their application environment and using
inline macros, like loop unrolling or using "register" variables
fall bellow all the techniques needed to write a fast emulator.

 Now I'm porting the emulator to a scripted language, so I need
even more previous design ideas before starting to code, so that
I can achieve (I hope I'll be able to do it with this group's help)
100% cpu speed in an standard desktop PC.

> >  But it seems that is not possible :-(
>
> Thank getenv("DEITY") not!

 Well, I don't agree with that, "constants" and "macros" wouldn't
hurt python, when using them in the right situations.

 Thanks a lot anyway for all your help :-)




More information about the Python-list mailing list