[ros-dev] Re: DIB code generator

[Jan Jezabek]

Ge van Geldorp wrote:
> One of the things which has bothered me a bit is the code duplication we
> have in our DIB engine (subsys/win32k/dib). Most of the BitBlt routines in
> there are very similar. With the recent interest in optimizations a bunch of
> new (almost identical) routines were added. Don't get me wrong, I'm not
> saying that adding those optimizations was a bad idea, I'm just pointing out
> that we have a lot of code duplication.
> 
> There are 256 possible ROP codes, we support 1bpp, 4bpp, 8bpp, 16bpp, 24bpp
> and 32bpp, so in theory there could be 1536 routines with basically the same
> structure. I've been playing around with the idea to write a code generator
> which would generate the source code for those routines. That would cut down
> on the duplicated source code and associated maintenance problems (you only
> need to change the code generator) while still allowing optimized code for
> each individual ROP code.
> 
> Just to give you an idea what such a code generator would look like, I've
> attached my first attempt. Please note that it doesn't really try to
> optimize the generated code yet, it's just to give an impression. The code
> generated (16bpp only atm) is rather large, you can get it from
> ftp://ftp.geldorp.nl/pub/ReactOS/dib16gen.c if you like (or compile the code
> generator ("gcc -o gendib gendib.c") and run it).
> 
> A possible problem is that the generated code is quite large. When using the
> generated 16bpp code, size of win32k.sys increases by about 350kb.
> Extrapolating this for all bpps, it would mean that win32k.sys would triple
> in size.
> 
> So, I'm wondering what you guys are thinking. Should we basically trade
> memory for speed? Problem is that I can't quantify the speed increase at the
> moment.
> 
> Gé van Geldorp.
> 

Hi!

Couldn't this be done using C++ templates or - since ReactOS doesn't use 
C++ - preprocessor macros? This would make the code just as optimized as 
with the generator. OTOH I expect that debugging would be a little bit 
harder.

Regards,
JJ