🚀 go-pugleaf

A summary so far:  Ken Baer (baer@percival.UUCP) objected that the new RKM
is wrong when it says that arguments to some routines are shorts.  Bryce
Nesbitt (bryce@cbmvax) points out that the RKM is correct inasmuch as such
routines look at only the lower most 16 bits of the register with their
arguments.
     Dave Haynie (daveh@cbmvax) speculates that Manx may have its
C->Assembler glue routines wrong.  This may be true: in a call to
Draw(rastport, x, y) where x and y are shorts, Manx pushes shorts onto
the stack but pulls off longs for the D0 and D1 contents when compiled
with 16-bit ints.  The code stub
{
    long rp;		/* dummy */
    short x, y;
    Draw(rp, x, y);
}
generates for the Draw() the code:
	move.w -8(a5),-(a7)
	move.w -6(a5),-(a7)
	move.l -4(a5),-(a7)
	jsr    _Draw

where _Draw does:
	movea.l 4(a7),a1
	movem.l 8(a7),d0-d1

and then jumps to the Draw entry point.  Does Lattice 4.n/5.n do this
"correctly" if we are agreed that shorts are, in fact, correct?

In article <15751@oberon.USC.EDU>, papa@pollux (Marco Papa) writes:
>
>"Any actual argument of type float are converted to double before the call;
>any of type char or short are converted to int;"
>                    ^^^^^                  ^^^
>I myself have been using the Draw(rp, x, y) function with x and y declared
>either as SHORT or as LONG with no apparent problem [my programs were compiled
>with +L so that SHORT and LONG have different size].

Yes, but int and LONG have the same size, so this code will work fine
with the (faulty) Manx glue routines.  And herein is the real problem:
nearly all Amiga code out of CBM so far was written with a 32-bit length
for ints, so SHORTs were promoted to ints before the library code was
executed anyway.  Should we now take it to be OK for routines such as
Draw() for which the RKM specifies SHORT arguments to actually be called
with 16-bit arguments in an environment where sizeof(int)=16 bits?
--
Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge
RCKG01M@CALSTATE.BITNET       ecphssrw@afws.csun.edu
swalton@solar.stanford.edu    ...!csun!afws.csun.edu!ecphssrw