tomc@mntgfx.mentor.com (Tom Carstensen) (06/23/88)
I could not get the MPW C compiler to produce the following
assembly code:
PUSH.L $09EE
_SetClip
and I was using the C statement:
SetClip( (RgnHandle) 0x09ee );
it always produced:
PEA $09EE
_SetClip
I finally got it to use PUSH.L by the C code:
RgnHandle temp
temp = 0x09ee;
SetClip(temp);
. . .
return(temp);
The return is there so the temp would not get optimized out,
or it would use PEA again.
PEA is quite different the PUSH.L, if I'm not mistaken. Is
this a bug, or am I just being stupid.
:------------------------------------------------------------:
: Tom Carstensen Usenet: tomc@mntgfx.MENTOR.COM :
: Mentor Graphics Delphi: CARSTENSEN :
: GEnie: CARSTENSEN :
: :
: If you are sick and tired, of all your dreadful :
: dimensions, let me stretch your TIME! :
: - Time Operator :
:------------------------------------------------------------:
dan@Apple.COM (Dan Allen) (06/25/88)
In article <1988Jun22.112228.462@mntgfx.mentor.com> tomc@mntgfx.mentor.com (Tom Carstensen) writes: >I could not get the MPW C compiler to produce the following >assembly code: > > PUSH.L $09EE > _SetClip > >and I was using the C statement: > > SetClip( (RgnHandle) 0x09ee ); > >it always produced: > > PEA $09EE > _SetClip > >PEA is quite different the PUSH.L, if I'm not mistaken. Is >this a bug, or am I just being stupid. This is another of the Greenhills C "Optimizations". Notice that pushing (or rather, moving in the 68xxx parlance) $09EE has the same end result as Pushing the Effective Address $09EE. It happens to be a couple of cycles shorter... but the code becomes unreadable until you know what it is doing. Dan Allen Software Explorer Apple Computer
jimc@iscuva.ISCS.COM (Jim Cathey) (06/25/88)
In article <16163@tut.cis.ohio-state.edu> elwell@saqqara.cis.ohio-state.edu (Clayton Elwell) writes: >Well, I wouldn't say you are being stupid, but a PEA of an absolute >address just pushes that address onto the stack. The PEA instruction >takes the same amount of space as a MOVE.L, but on at least the 68020 >it can take less time (1 clock less for worst case). I suspect that >this is a peephole optimiziation of some sort. Actually, a PEA of that particular address will be shorter than the MOVE.L because the address was <32K. The 68000 has a short absolute address format so the PEA turned out 4 bytes in length, versus the MOVE.L at 6 bytes. Smaller _and_ faster, not a bad trick, no? That's one reason the Mac OS's variables are all in low memory. All references to them end up shorter. This was particularly important when cramming all that OS into the original ROM. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
wrs@Apple.COM (Walter Smith) (06/25/88)
I thought this was stabilized, but people are still confused, so let's get this straight once and for all. MOVE.L $09EE, -(SP) puts the contents of location $09EE on the stack. MOVE.L #$09EE, -(SP) puts the number $09EE on the stack. PEA $09EE also puts the number $09EE on the stack. SetClip( (RgnHandle) 0x09ee ); passes the number 0x09ee as a RgnHandle to SetClip, thus generating MOVE.L #$09EE, -(SP) or PEA $09EE _SetClip The correct C code, SetClip( *(RgnHandle *)0x09ee ); dereferences the RgnHandle pointer 0x09ee and passes the contents to SetClip, thus generating MOVE.L $09EE, -(SP) _SetClip I hope this will take care of the confusion. - Walt -- Walter Smith Apple Computer wrs@apple.com Special Projects (408) 973-4015 Disclaimer: Anyone who thinks I might be representing Apple Computer, Inc. in any official capacity on Usenet, of all places, has a serious attitude problem.
larryh@tekgvs.TEK.COM (Larry Hutchinson) (06/25/88)
In article <16163@tut.cis.ohio-state.edu> elwell@saqqara.cis.ohio-state.edu (Clayton Elwell) writes:
-Well, I wouldn't say you are being stupid, but a PEA of an absolute
-address just pushes that address onto the stack. The PEA instruction
-takes the same amount of space as a MOVE.L, but on at least the 68020
-it can take less time (1 clock less for worst case). I suspect that
PEA of a short address (+/- 32k) takes two words while a MOVE.L takes
three, so this is a win on any 68k processor.
Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 50-383, Beaverton, OR 97077
UUCP: [uunet|ucbvax|decvax|ihnp4|hplabs]!tektronix!tekgvs!larryh
ARPA: larryh%tekgvs.TEK.COM@RELAY.CS.NET
CSNet: larryh@tekgvs.TEK.COM