Re: [openMSX-devel] Again...

[Patriek L. <pat...@dd...>]

Maarten ter Huurne wrote:
>The cart as a whole is different hardware, but the mapper is the same.

It might be... Depending on the amount of address lines available. Has 
anyone opened up a Xanadu cart and see if there are any unused address 
lines on the mapperchip?

>Code duplication is bad code. It is hard to read (much more code, so 
>harder to find what you are looking for) and it's a maintenance nightmare.

The solution to this are macros. (OH the HORROR!)

>I think "the spirit of openMSX" is only to emulate the hardware 
>accurately, it does not specify how.

If it doesn't specify how, the joystick emulation might as well be seperate 
from the PSG emulation, like it is in many other emulators...
I thought openMSX would be not only a common emulator, but by emulating the 
hardware as close to reality as possible, also becoming a full 
documentation of MSX hardware.

In the case of V9938 and V9958, I think it's a good idea to use the same 
code, because a V9938 can easily be replaced by a V9958 and even the 
technical manual of a V9958 is only an addition to the V9938's.

But come on, we're talking mappers here. They are all neatly specified in a 
case statement. Different if-then's within and surrounding that case 
statement have only a cluttering effect! (both in readability of the code 
and execution-wise)

>If the same behaviour can be implemented using parameterisation, that has 
>my preference. Seen from the emulated MSX, it doesn't matter whether a 
>feature is implemented using case selection / separate classes or using
>parameterisation. So we should choose the one which leads to the best code.

So in your opinion the 'best' code is not the 'clearest and fastest' code?
What you describe as the 'best' code, with almost no duplication through 
parameterization, might in many cases not even be the 'shortest' code after 
compilation!

And talking about performance... Each if-statement introduces a conditional 
jump statement in assembly. On most (if not all) modern processors, a jump 
statement (especially a conditional one) can be a HUGE performance killer.
In the case of the mapper emulation; many games write to themselves dozens 
of times each frame!

I don't think they teach this in school... But making sure even the small 
details run reasonably fast (and not just 'reasonable') does make a 
difference. Several smallies make a biggy!
Optimizing using profiling alone is such a big mistake...

But, suit yourself...

Greetz,
         Patriek