RE: [AD] small typo in bmp.c

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> Maybe in terms of the actual layout in disk files, but if you
> shorten that field in Allegro it will make no difference to the
> size of the structure (it'll be followed by two bytes of
> padding), and if it's always sent to/from disk using pack_iputw
> and pack_igetw, it will have no effect on the functionality
> either.  It will only have effect if the struct is read from
> disk or written to disk as a single block of data.

And Shawn's portability tips at
http://www.talula.demon.co.uk/allegro/porting.html state that writing or
reading a struct like that is unwise.

There's a good reason why it's an int rather than a short. To handle 16-bit
values (ie. shorts) in Protected Mode, all x86 processors must use a prefix
opcode before each instruction that would otherwise handle 32-bit values.
This actually slows the program down, even though fewer bytes are being
manipulated.

And before you ask, Allegro can never be used in Real Mode :-P

I wonder if there is an appropriate place in the docs to make this point
about why ints are faster than shorts. I too used to use shorts all the time
because I was unaware that they were slower.

Ben Davis



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/