Re: [AD] some questions

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Michael Bukin <M.A.Bukin@xxxxxxxxxx> writes:
> 1. Why unwrite_bank is in GFX_VTABLE, while read_bank and write_bank
> are in GFX_DRIVER?

Purely for speed reasons: logically it ought to be in the vtable. But these 
functions are called very frequently from down inside the drawing 
primitives, and since the bitmap pointer must already be loaded into %edx 
for the call, it is faster if I can get straight from that to the function 
pointer, rather than having to find another spare register for the vtable 
indirection. This allows the bank switch code to be:

   #define WRITE_BANK()    call *BMP_WBANK(%edx)

wheras the unwrite bank has to do:

   #define UNWRITE_BANK()  movl BMP_VTABLE(%edx), %eax ; \
			   call *VTABLE_UNBANK(%eax)

And, the latter one requires %eax to be free, which isn't usually true at 
the times when the bank switch is called. This overhead is less important 
for the unwrite and other vtable functions, since those are only needed at 
most once per primitive rather than once per scanline.

> 2. In version 3.9.26, could configure find that MMX is supported?

Yes. It didn't use to detect it in older versions even though my system 
supports it, but the current version works ok for me.

> Just I noticed that dummy constant is gone from the list of input 
> operands. AFAIK, when there are no inputs and outputs, gcc does not
> understand %%reg notation for registers and requires %reg notation.

Really? Well, it seems to work ok without any parameters: perhaps the two 
colons at the end of the asm statement are enough to switch the compiler 
into extended asm mode, even though there are no actual input or output 
variables?

> 4. I had to use standalone asm for making bank switching routines with 
> conventions used when ALLEGRO_GCC and ALLEGRO_I386 are defined (bitmap in 
> %edx, line in %eax).

I put a version of those in cmisc.c for use when compiling the C code on an 
Intel platform (becuse the asm bank switch convention is still needed in 
order to use drivers with asm implementations, like VESA and VBE/AF). It's a 
horrible hack, and would never be needed for any production code, but is 
useful so that I can compile and test the C drawing code on a DOS machine.

I wouldn't suggest you using that particular implementation, though: it 
works for testing, but because it can't see the defines in asmdef.inc, it 
needs to be manually changed to support different asm conventions (like 
whether or not to symbol names are prefixed with an underscore).

> I don't know how to do that.  It must be included only when this 
> convention is used, but __GNUC__ is not defined in asm with preprocessing, 
> so I can not test for that same condition which is used for including this 
> convention.  I can modify asmdef utility to output ALLEGRO_GCC and 
> ALLEGRO_I386 if they are defined, but it does not smell good.

I think that is the best option. Yes, it smells bad, but it works, and at 
least it keeps all the ugly stuff in that one file, which already 
reeks badly enough that a bit more crap won't be noticed :-)

I already do the same thing for passing defines like ALLEGRO_COLOR15 and 
ALLEGRO_MMX through to the asm code, because I think that is less error 
prone than trying to put them in a header which could be included from both 
asm and C sources.


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."