[hatari-devel] Hatari patches for bitplane conversion

Eero Tamminen eerot at users.berlios.de
Tue Jul 21 22:41:47 CEST 2009


Hi,

I noticed that the overlay LED code did still save&restore blits when both
the statusbar & overlay drive-led were disabled.  I hadn't noticed that
before because that code isn't used when statusbar is enabled (and
I run Hatari normally with it enabled because it doesn't slow anything).
With your mono test-code it was taking 20% of Hatari CPU usage.
I commited a fix for this.

Were you using Hatari with the Statusbar disabled?  If you did, is there
now a performance difference for you?


On Tuesday 21 July 2009, Kåre Andersen wrote:
> > If you would put them to separate object files, they would need to be
> > global functions and would have the normal function call overhead.  If
> > I remember correctly, a more important reason was that then the helper
> > functions in screen.c (which are called from the convertors) would then
> > need to be global and have the normal function call overhead too.
> >
> > (GCC / GAS don't support (yet) inter-object optimizations.)
>
> Ah yes, I remember now, that table declaring them static, effectively
> giving them file scope. But uhm, is this overhead really noticeable?

Well, I was trying to eke out everything from the conversion functions
I could without completely re-writing them (and removed nearly third of
the conversion code in the process which I think was earlier fairly
straight port from the intel ASM in Winston to C)...

But if you get the palette handling to be done more reasonably (especially
the Spec512 stuff) and still have the conversions with about the same
performance on Linux (still to be measured), I'd vote for cleaner code. :-)


> It seems you know GCC a lot better than me, so I wont argue, I just
> find it hard to maintain and it leads to all that code duplication. I
> keep thinking that these things should be dynamically linked and then
> the functors could be wrestled out from there... I am probably wrong

Current GCC linker is too stupid to do that kind of optimizations.
For the interested:
	http://gcc.gnu.org/wiki/LinkTimeOptimization


	- Eero



More information about the hatari-devel mailing list