10 Jun
2005
10 Jun
'05
11:10 a.m.
Hi
I like the idea
I see some problem example we need the change
the soucre for each rop4
example blackness calling the color_fill
and some other problem with a gen.c
Quoting Ge van Geldorp <gvg(a)reactos.com>om>:
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.