Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA Path: utzoo!watmath!clyde!cbosgd!ucbvax!info-vax From: info-vax@ucbvax.ARPA Newsgroups: fa.info-vax Subject: instruction set questions Message-ID: <3540@ucbvax.ARPA> Date: Wed, 28-Nov-84 19:03:42 EST Article-I.D.: ucbvax.3540 Posted: Wed Nov 28 19:03:42 1984 Date-Received: Thu, 29-Nov-84 06:13:37 EST Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 41 From: Provan@LLL-MFE.ARPA Isn't MovL foo,baz(r0) equivalent to (i.e., at least as good as) PushAB baz[r0] MovL foo,@(sp)+ ? And isn't DecB baz[r0] BEql ... equivalent to (i.e., at least as good as) CvtBL baz[r0],r1 DecL r1 MovB r1,baz[r0] TstL r1 BEql ... (other than r1 getting clobbered)? I'm asking because BLISS surprised me by producing the lower codes instead of the upper ones. Since BLISS usually optimizes reasonably well, I can't figure out why it would go out of its way to make worse code. I was particularly upset because in the first case I was anticipating a MovQ (since I was really moving two adjacent longwords) and in the second the subtract and check eql has to be AST reentrent. Anyone have any ideas why BLISS would do this to me? (By the way, in the second example, if the size is a longword instead of a byte, BLISS does the DecL in place as you'd expect it to.) If anyone wants to persue this more deeply, I'd suggest talking directly to me, since this is unlikely to be of interest to much of the list.