[Coco] Devastated. Long term OVCC project falls short

[James Ross]

Walter said: 
> On Windows the assembly 6309 CPU runs about 1-1.5% SLOWER!
> On Linux the assembly 6309 CPU runs about 45%-50% SLOWER!!!

Wow, that is something else!!  

Good job on all your work on OVCC.  I have not had the time to play with it yet, but I hope to someday in the near future.  And kudos on making the OVCC GitHub site public.  

Those are quite surprising results, for sure.  I see why you were taken aback. 

I wonder why the assembly version for Linux would be that much slower than the Windows version.  There’s got to be something weird going there – there should not be a big difference between the two running essentially the same native code (at least on same class of processor)

I possibly should not comment on the ASM code as I have not delved into enough to be giving anyone advice.  But  ... here goes, ha!   

A tidbit I have read about in more than one place, I believe, is that there is a penalty for accessing partial registers (i.e. 16bit and possibly 8bits) in 32/64 bit modes.  Whether or not that would account for all the slowdown from the compiled C, I don’t know.  But you should be able to find information on that somewhat easily.

Whether or not I am right or not about this, (I think I am, but I am but not certain!!)  But --- if a person wants to squeeze the absolute best performance at the assembly level don’t deal with (i.e. r/w and process) any data values that are not the same width as the data bus.  And make sure that all your data is aligned at the same data width.  

So, in 32bit mode, do everything in 32bits.  In 64bit mode, do everything in 64bits.   That would include instead of using a byte array (8 bits) for the CoCo RAM/ROM use 32bit or 64bit word arrays instead, to represent each byte. 

If I ever have the time, I’ll play with this some.  

james