CompuServe Thread

#Bruce Dawson Review

7 messages in this thread
#28986From: colin foxJan 5, 1989 1:27 PM
There is nothing stopping you from being completely explicit in your programming. Assemblers aren't supposed to change your code if you are totally explicit. If you say BRA.L the assembler won't (shouldn't) optimize it to a BRA. If you say ADDI it won't (shouldn't) optimize it to an ADDQ. It's only when you leave your instructions as slightly ambiguous that the assembler thinks you mean "go ahead, optimize this". If you say BRA.S and it doesn't work out to be a short branch, then the assembler still tells {j BRANCH OUT OF RANGE or some such, it doesn't change it. — Colin — ps. Do you like it when the assembler changes MOVE.L #val,A0 to MOVEA.L #val,A0 ? — Colin —
#29011From: Bill HawesJan 5, 1989 5:32 PM
Colin, I normally do specify the full instruction coding for my assembly statements, and expect the assembler to complain if one of them (e.g. bra.s) isn't feasible. As long as it doesn't actually change anything, I'm happy. As for move.l #val,a0 vs movea.l #val,a0, I normally code all moves to address registers as movea — this serves as a reminder to me that the condition codes are still valid after the move. My currecnt assembler (CAPE) doesn't complain about the move.l form, though I wish it did. Bill
#29063From: Richard Rae/SYSOPJan 5, 1989 10:32 PM
You guys have finally gotten my curiosity up to the point that I had to try this. First I coded: FRED BRA.L DAVE BRA.S FRED DAVE RTS The Aztec AS did NOT change the long branch to a short. Then I ripped out the BRA.S FRED. No change. Now here's where it gets interesting: I changed the long branch to a short. Guess what the result was? 0000: FRED BRA.S DAVE 0000: 4E75 DAVE RTS You got it, son: it optimized the short branch right out of existence! Now granted the short branch was a NOP (so was the long branch; why didn't it touch THAT?), but by golly, maybe I had a REASON to put that in there. No warning at all, it just ripped it out. I have to say I'm not happy about this. I wonder what else AS has changed in my code without telling me? Come on Manx, the optimization should be done in the C COMPILER, not the assembler! Sheesh. Rick
#29083From: John DraperJan 6, 1989 12:21 AM
Rick, That's an interesting one. I wonder what would happen if you had a BSR in there instead of a BRA? I have seen this technique used to call a subroutine twice. -larry
#29195From: Richard Rae/SYSOPJan 6, 1989 7:55 PM
Good question. Apparently the assembler is smart enough to understand that this is NOT the equivalent of a NOP, as it leaves the BSR in the same position alone. Rick
#29201From: Dean BrownJan 6, 1989 8:04 PM
Rick, A short branch with a zero offset is illegal on the 68xxx processor series. This is because a long branch is coded as a short branch with a zero offset followed by the longword offset for the long branch. If you had a reason for putting it there, then you'd be better off using a NOP. -Dean
#29337From: Richard Rae/SYSOPJan 7, 1989 3:58 PM
Aha… I hadn't looked at 68000 OPCODES that closely yet. Thanks for that piece of information. (Explains why AS treated the short branch differently from everything else, but it doesn't explain why it didn't flag it as an error, or at least warn me.) Now that we've gotten out of general programming philosophy and into 68000 specifics, it's obvious that I'm in way over my head here, so I'm going to step out of the discussion before I say something _stupider_. You guys want to talk 680x or 804x/5x/8x, give me a yell… meanwhile I'm going to go back to quietly studying 68000. 8) Rick