[hatari-devel] Hatari patches for bitplane conversion

[Eero Tamminen]

Hi,

On Wednesday 22 July 2009, Kåre Andersen wrote:
> Further investigations...
>
> > On 7/22/09, Kåre Andersen <kareandersen at gmail.com> wrote:
> > nFrameSkips is somehow never initialised, add a =0 and everything is
> > fine...  How can this be different on different platforms?
>
> So, remembering previous thoughts on the subject, and the sound init
> problems on OS X a while back, I looked up how the ELF and Mach-O
> binary executable formats work.
>
> ELF zeroes out BSS, Mach-O has, as far as I can tell, no such
> requirement.

Apple's own documentation:
http://developer.apple.com/documentation/Performance/Conceptual/CodeFootprint/Articles/MachOOverview.html

States this:
"Uninitialized static data is in the __bss section of the __DATA segment."
...
"The ANSI C and C++ standards specify that the system must set uninitialized
static variables to zero."


> Please don't rely on uninitialized values...

It's not an uninitialized value.

Both static local and _all_ global variables are guaranteed to be
initialized, to zero if nothing else is specified.  Otherwise the compiler
doesn't conform to ANSI-C standard.

(I tried to Google for an ANSI-C standard reference, but found only
some mails where it's stated.  You can check it from the Kernighan &
Richie "The C program language" (*The* C book, for c89), section
4.9, Initialization.)


> It can happen to anyone, and I cant get gcc to warn me about these
> (globals) with -Wuninitialized.

No, you cannot.  -Wuninitialized warns about unitialized automatic
(non-static local) variables and that option is already enabled by -Wall
used by Hatari.  As I stated above, global variables are initialized by
definition.


> Still, I am sure it can be avoided in the future... :)
>
> On another note, i have put memcmp() per line into my converter, and
> indeed it does help a bit. Next up is changing the blitted rectangle
> to changed areas only. The compares eat a bit of CPU on their own, but
> the stress on the X server is much reduced in "good" cases, so I will
> keep improving on this code. Trying to come up  with some good
> heuristics as to when to blit, when to compare and so on. Nice and
> fuzzy suggestions are very welcome.. :)

int ChangedLines[MAX_SCREEN_LINES];

Before entering the converter, do:
	memset(changed, 0, sizeof(changed));

In the converter, if memcmp() detects line to be changed, set a value
for corresponding offset in ChangedLines.

The on blit do something like this:
---------
	line = 0;
	while (line < MAX_SCREEN_LINES) {
		while (!ChangedLines[line] && line < MAX_SCREEN_LINES) {
			line++;
		}
		startline = line;
		while (ChangedLines[line] && line < MAX_SCREEN_LINES) {
			line++;
		}
		if (line > startline) {
			Screen_BlitLinesBetween(startline, line);
		}
	}
--------


	- Eero