OS_SpriteOp and 32bpp sprites
Kevin Bracey
kevin at bracey-griffith.freeserve.co.uk
Tue Nov 19 08:05:11 GMT 2002
In message <c2f096974b.druck at druck.freeuk.net>
David J. Ruck <druck at druck.org.uk> wrote:
> On 18 Nov 2002 Kevin Bracey <kevin at bracey-griffith.freeserve.co.uk> wrote:
> > In message <f75f46974b.Tony at mk-net.demon.co.uk>
> > Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> >> So, at the next update, I'll add osspriteop_read_pixel_colour_deep and
> >> osspriteop_write_pixel_colour_deep taking an unsigned int type for R5 as
> >> alternatives to these calls.
> >
> > There should be no need to make an alternate call, as with the current
> > callee-narrowing argument passing conventions, the compiler would always
> > have just passed a word-wide value anyway, regardless of the fact that the
> > function took a char. It would have expected the callee to do any required
> > narrowing.
>
> Eeeek! This is begging for problems with future compiler versions.
> Think boolean types.
But future compiler versions would require a newer version of OSLib, I would
have thought. And if the calling standard did change to caller narrowing,
that would be the thing that broke the code.
At present
extern void oslib_call(byte f);
called with
oslib_call(0x10000);
will (I believe) produce the code
MOV a1, #&10000
BL oslib_call
so it works regardless of the fact that it's declared taking a char. If we
changed to caller-narrowing (generally a good thing), it would change the
code to
MOV a1, #0
BL oslib_call
potentially breaking the code. You would have to change the prototype to take
an int to maintain old behaviour.
Any functions in OSLib that are declared as taking "narrow" parameters that
do not actually narrow them themselves in the OSLib veneer are potential
sources of code breakage if calling standards were to change.
So I maintain that on the contrary, it is safer to change the prototypes now,
to prevent problems in the future.
--
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/
More information about the oslib-user
mailing list