[SDL] Another question about SDL_BlitSurface

aurelien marchand XaurelienX.XmarchandX at XresearchcapitalX.XcomX
Tue Aug 21 13:11:00 PDT 2001


"Mattias Engdegård" <f91-men at nada.kth.se> wrote in message
news:mailman.997274463.12663.sdl at libsdl.org...

> Please tell us about any errors or undefined constructs. SDL compiles
> cleanly (modulo a few warnings) with the quite picky Sun WorkShop C
> compiler, so I think it's mostly OK. I suspect there can be a bunch
> of illegal aliases, however, and it would be useful to remove them
> so we can use compilers with type-based alias detection.

Well, this are problems I've found so far (it compiles now, not tested
though):

extern DECLSPEC <function> (Not ANSI)

Macros like this:

#define SOMETHING(blah)
case 0: do { blah
case 3: blah
case 2: blah
case 1: } while (blah)

Those seem to be optimized doodaas, so I've stripped them out as much as
possible (SDL_memset4 also caused a few problems as well as th DUFFS_LOOP
stuff).

> >Sam, what the hell were you think when you wrote those DUFFS_LOOPS
things?
> >Everyone here in the office is damned confused about that
>
> It's just a macro version of the old and well-known Duff's Device,
> which does some "automatic" unrolling of loops in a compact way.

That implementation is on shakey ground. The ANSI C specification is very
vague when it comes to loops in that context. It *is* illegal in C++ to do
it that way.

> The problem is of course, as you no doubt have observed, that
> it's quite inefficient. It made some sort of sense for ancient
> architectures where unrolling was just to reduce the loop overhead
> (increment counter, test, branch), as opposed to modern architectures
> where unrolling is for increasing the basic block size and thus
> enable better scheduling inside the loop body.
>
> Since Duff's Device splits the loop body in several basic blocks,
> there is little win at all (a loss in fact, since compilers that
> vectorize, software-pipeline or unroll loops automatically are
> prevented of doing this).

> I have been thinking of fixing this in the SDL sources but I've
> not really wanted to change working code, and I've sworn that
> I will not allow that sort of thing to creep into SDL 1.3 :)

Well, at the moment I'm just tryign things out. If there is a performance
boost from the vectorC version, I'll clean the code up and strip out the
stuff that isn't needed. I'll stick the changes on the Codeplay website (as
well as binaries) when I'm happy with it.

As a side note, what's this I hear about a PS2 version of SDL? If it exists,
it might make sense to do a vectorC version as well (You might have seen the
press release by now)...


--
Mark 'Nurgle' Collins
Developer Support - Codeplay Ltd.
http://www.codeplay.com





More information about the SDL mailing list