reRE: [OT] RE: Windows version

SDL Development
1

No, 100% faster means that it takes 100% less time to run,
thus finishes
instantly. Since VectorC is guaranteed to be > 1000%
faster, it means
it completes at least a fortnight before it starts!

actually

100% faster = + 100%, means it runs at 200% of the original speed = twice as
fast
1000% faster = runs at 1100% of the original speed = 11 times as fast

But, To stay on topic, I think compiling SDL with an optimizing compiler
could be interesting, especially for the software blitters (unless they’re
allready hand-optimized in assembler of course. I’m not sure about this,
because I can compile SDL in VC++ without NASM installed, I guess there are
ASM & C versions). I, myself, am quite a c+±ist, so VectorC (C only)
wouldn’t be of much use for me.> -----Original Message-----

From: Mattias Engdeg?rd [mailto:f91-men at nada.kth.se]

2

“Dominique Biesmans” <Dominique.Biesmans at Telepolis.Antwerpen.be> wrote in
message news:mailman.997270263.10801.sdl at libsdl.org…

But, To stay on topic, I think compiling SDL with an optimizing compiler
could be interesting, especially for the software blitters (unless they’re
allready hand-optimized in assembler of course. I’m not sure about this,
because I can compile SDL in VC++ without NASM installed, I guess there
are
ASM & C versions). I, myself, am quite a c+±ist, so VectorC (C only)
wouldn’t be of much use for me.

Well, after finding some really scary code in SDL (which isn’t ANSI legal,
or illegal), a vectorC compiled version might be a way off (we’ve got to
rewrite the compiler to get it working). Having a version of SDL that
compiles will also help when the Linux that may or may not be developed
(still not decided) comes out…

As to C++, that’s coming in version 2 (due out in a couple of months).

Sam, what the hell were you think when you wrote those DUFFS_LOOPS things?
Everyone here in the office is damned confused about that (quote: “The
person who wrote that must be a lunatic”)… (note: no compiler on the
planet will be able to optimize those, so I’m going to rip them out and
write a version that can be vectorized),–
Mark ‘Nurgle’ Collins
Developer Support - Codeplay Ltd.
http://www.codeplay.com

3

But, To stay on topic, I think compiling SDL with an optimizing compiler
could be interesting, especially for the software blitters (unless they’re
allready hand-optimized in assembler of course. I’m not sure about this,
because I can compile SDL in VC++ without NASM installed, I guess there are
ASM & C versions). I, myself, am quite a c+±ist, so VectorC (C only)
wouldn’t be of much use for me.

If VectorC can beat the Hermes blitters by compiling the C fallback
functions, I’ll buy a copy today.

–ryan.

4

Well, after finding some really scary code in SDL (which isn’t ANSI legal,
or illegal), a vectorC compiled version might be a way off (we’ve got to
rewrite the compiler to get it working).

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.

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.

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 :slight_smile:

5

Dominique Biesmans <Dominique.Biesmans at Telepolis.Antwerpen.be> wrote:

actually
[ snip explanation of how percent works ]

Heavens, Dominique, has your irony-meter run out of batteries?

6

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 would not be shocked, however, to learn that a lot of the win32-specific
code in SDL is also VisualC-specific, too.

–ryan.

7

“Mattias Engdeg?rd” 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 (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 :slight_smile:

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

8

“Mark Collins” <m.collins at codeplay.com> wrote:

extern DECLSPEC (Not ANSI)

No, DECLSPEC is defined in begin_code.h

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

That is legal C (assuming you add a switch() of course), and has been
so since the K&R (pre-C89) days, when Tom Duff came up with his device
(in 1983 I believe).

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.

No, ISO C (and ANSI for that matter) is very clear about it, nothing shaky
there. See section 6.8.4.2 of the latest C standard (ISO/IEC 9899/1999)
Whether it’s illegal in C++ is irrelevant since SDL is written in C,
but I think it’s legal in C++ as well. If you can quote the parts of
the C++ standard where it says it’s illegal, do so.

9

“Mattias Engdeg?rd” wrote in message
news:mailman.997278782.14870.sdl at libsdl.org…

“Mark Collins” <@Mark_Collins> wrote:

extern DECLSPEC (Not ANSI)

I don’t mean DECLSPEC as such, just the whole statement. extern isn’t
needed, and causes problems on strict compilers.

No, DECLSPEC is defined in begin_code.h

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

That is legal C (assuming you add a switch() of course), and has been
so since the K&R (pre-C89) days, when Tom Duff came up with his device
(in 1983 I believe).

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.

No, ISO C (and ANSI for that matter) is very clear about it, nothing shaky
there. See section 6.8.4.2 of the latest C standard (ISO/IEC 9899/1999)

We spent quite a bit of time searching through the ANSI C specs (as you can
imagine, we do have them on hand). The spec doesn’t actually say it’s
illegal, but it doesn’t say it’s legal either…

Whether it’s illegal in C++ is irrelevant since SDL is written in C,
but I think it’s legal in C++ as well. If you can quote the parts of
the C++ standard where it says it’s illegal, do so.

It’s illegal in C++ because it can cause execution to change scope without
constructing, and C++ guarentees that everything is constructed. It might
compile, but it shouldn’t.

Nurgle

10

“Mark Collins” <m.collins at codeplay.com> wrote:

extern DECLSPEC (Not ANSI)

I don’t mean DECLSPEC as such, just the whole statement. extern isn’t
needed, and causes problems on strict compilers.

What compilers? It is perfectly legal C. Read the Standard, sections
6.2.2 and 6.9 if you don’t believe me.

Note that a strictly conforming compiler is allowed to warn about
anything, as long as it still compiles a program if the latter is correct.
It can complaing about your indentation style, music taste, or just that
it’s Thursday.

We spent quite a bit of time searching through the ANSI C specs (as you can
imagine, we do have them on hand). The spec doesn’t actually say it’s
illegal, but it doesn’t say it’s legal either…

It does say it’s legal. It follows logically from the standard definitions.
I have already quoted chapter and verse; you should be able to read for
yourself.

It’s illegal in C++ because it can cause execution to change scope without
constructing, and C++ guarentees that everything is constructed. It might
compile, but it shouldn’t.

Again, quote relevant part of the C++ standard. There is no scope
problem; nothing is declared. In fact, I just found Duff’s Device in
Bjarne Stroustroup’s The C++ Programming Language, 3rd ed.

Also, the first thing you find when you google for Duff’s Device is
http://www.lysator.liu.se/c/duffs-device.html, which you no doubt have
read.

11

I routinely cross compile SDL using gcc. The win32-specific code is not
VisualC-specific.

Unfortunately, in order to generate valid DLLs in win32, you MUST use at
least one non-ansi feature (to mark functions as exported).

-RayOn Wednesday 08 August 2001 09:00, you wrote:

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 would not be shocked, however, to learn that a lot of the win32-specific
code in SDL is also VisualC-specific, too.