Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Videocard BOOT?
From: Paulo Marques
Date: Tue Oct 26 2004 - 06:22:01 EST
Antonino A. Daplas wrote:
On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
Helge Hafting <helgehaf@xxxxxxxxxxxxx> wrote:
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
Helge Hafting <helgehaf@xxxxxxxxxxxxx> wrote:
That's fine. What I meant, was please make it independent of the
VESA framebuffer driver, because one might want to use an
acellerated driver when one is available.
Oh, it already is. The VESA driver is not actually done yet so the only
drivers using VideoBoot right now are the accelerated ones ;-)
If these get in (emulator with/without the video boot), I'm willing to
modify the vesafb driver.
Well, I played with the emulator last night to see if I could reduce the
code size, so that it would be easier to make it to the official kernel.
I only took ops.c and did some transformations, like using a single
function to make several operations based on the opcode, instead of a
separate function for each opcode, etc.[1]
This is the result. Before:
Size of stripped libx86emu.a: ~74kb
ops.c source code lines: 11682
ops.o .text size: 36136
ops.o .data: 1312
After:
Size of stripped libx86emu.a: ~57kb
ops.c source code lines: 5908
ops.o .text size: 19320
ops.o .data: 1280
If the same treatment is applied to ops2.c and prim_ops.c, I believe it
would be possible to have a functional emulator for about 32kb of kernel
code size, which seems pretty reasonable to me and could solve a lot of
problems.
The decrease in source code size also helps maintenance, since there is
not so much repeated code has it was before.
Of course, these changes are optimizing the emulator for code size, and
not execution speed. I haven't done any benchmarks to see if there is a
noticeable difference in speed.
[1] The worst offenders were actually constructions like:
FETCH_DECODE_MODRM(mod, rh, rl);
switch (mod) {
case 0:
...<some code>
addr = decode_rm00_address(rl);
...<some more code>
break;
case 1:
...<exactly the same code as above>
addr = decode_rm01_address(rl);
...<exactly the same code as above>
break;
case 2:
...<exactly the same code as above>
addr = decode_rm10_address(rl);
...<exactly the same code as above>
break;
case 3:
<diferent code to handle register-register ops>
break;
}
This could be easily changed to:
FETCH_DECODE_MODRM(mod, rh, rl);
if (mod < 3) {
...<some code>
addr = decode_rmXX_address(mod, rl);
...<some more code>
} else {
<diferent code to handle register-register ops>
}
simply by making a new decode_rmXX_address function that handles the mod
parameter. There were more than 20 of these, and some of them were
pretty big.
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/