On Mar 15, 11:31pm, "Aleksi Suhonen a.k.a Metalite" wrote:
> }- If some people with '40 and RZ3 could look into RZ3SetHWCloc(): at the end
> }- of this function you'll find the following statements:
> }-         *(acm + (ACM_CURSOR_POSITION+0)) = x & 0xff;
> }-         *(acm + (ACM_CURSOR_POSITION+1)) = x >> 8;
> }-         *(acm + (ACM_CURSOR_POSITION+2)) = y & 0xff;
> }-         *(acm + (ACM_CURSOR_POSITION+3)) = y >> 8;
> }- now... if ANYONE has an idea why the above statements work for '30ies, but
> }- will just plain skip the third statement on a '40, *please* tell me...
> 
> Compiler bug maybe? Which brings a few questions up in me. I understand

  I don't think so.  I'm running the gcc supplied with NetBSD and looked
at the code generated for that sequence of code:

0000073a (_RZ3SetHWCloc+)00c8 subw @#000026c8 (_xpan+)0000,d3	[x -= xpan]
00000740 (_RZ3SetHWCloc+)00ce subw @#000026ca (_ypan+)0000,d4	[y -= ypan]
00000746 (_RZ3SetHWCloc+)00d4 moveb d3,a2@(12)			[x & 0xff]
0000074a (_RZ3SetHWCloc+)00d8 movew d3,d0
0000074c (_RZ3SetHWCloc+)00da lsrw #8,d0
0000074e (_RZ3SetHWCloc+)00dc moveb d0,a2@(13)			[x >> 8]
00000752 (_RZ3SetHWCloc+)00e0 moveb d4,a2@(14)			[y & 0xff]
00000756 (_RZ3SetHWCloc+)00e4 movew d4,d0
00000758 (_RZ3SetHWCloc+)00e6 lsrw #8,d0
0000075a (_RZ3SetHWCloc+)00e8 moveb d0,a2@(15)			[y >> 8]

  I don't see anything wrong with that code, which would rule out a
compiler bug.  I don't see anything that should cause any problems on
the 68040, unless it might be some kind of timing problem with the two
successive byte stores [a2@(13) and a2@(14)].

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA