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.