Hi,

Can anyone tell me what would happen if a call was made to SBC without a call to SEC first?

Thanks,

Andrew

The result would just be one less than you were expecting. Occasionally you might even intentionally do a CLC before SBC to save a step if you would otherwise want to subtract one more after the operation. http://www.6502.org/forum/viewtopic.php ... compliment might help.

Well,

The simple answer would be that it would depend on what state the preceeding code has left the carry bit in. If it has been left set the answer will be what you would expect; if it has been left clear, it will be one less.

So, unless are really struggling to save bytes/cycles AND can be 150% certain what state the carry will always be in, you'd be well advised to explicitly put the carry in a known state using SEC (or CLC if you want to subtract an extra 1).

Of course you might be trying to write some very clever code where the result of the subtraction needs to be affected by some previous code leaving the carry in one state or the other, depending upon a port line state for instance. But that could be the slippery slope of hard to follow and fix, not to mention unreliable spaghetti code......

> But that could be the slippery slope of hard to follow and fix, not to mention unreliable spaghetti code......

That's where heavy commenting comes in. There should be far more text in the source code explaining than there is of actual instrucions. Unfortunately I seldom see that in others' code. Writing complete comments beside the instructions, I sometimes find bugs before they have shown up in execution, even if the program initially seems to work fine. This comes from having to explain details that I might otherwise think I can gloss over, and make sense of it as if to explain it to someone who is not familiar with the insides (which might be my own situation a year or more later when I need to come back to it to make improvements). It's just part of making reliable, maintainable code. The extra time spent commenting definitely pays for itself in the long run.

Back to the C flag and SBC-- There's a reason the SEC is not integrated into the SBC instruction. If you're dealing with numbers of 16 bits or more, you'll typically start with SEC before subtracting the least-significant byte; but then you leave the C alone for the next-to-least significant byte and so on, or you'll get wrong results sometimes. For example, in $1E49-$1A81, you start with C set and do the $49-$81, getting $C8 and a clear C flag. If you again did SEC before subtracting the high byte, the high byte result would be 4 instead of 3 and your overall result would be $4C8 instead of the correct $3C8. It works just like on paper.

I completely agree with you Garth.

My code is full of comments with references as to where I got the information. The reason I ask half the questions I ask is because I look at other people's code that's not documented and there's no explaination for what they've done. And, since I have one of these inquisitive minds, if I can't find supporting documentation, I ask.

Thanks again for your help.

Andrew

Look at my contribution under heading "Help with making ..." for all these concepts (SBC BCD etc ) applied to a concrete case!

OK, I'm being pedantic here, but by these dogmas a simple 16 bit subtraction

1) is "unreliable spaghetti code"

2) and needs to be heavily commented to explain what's going on.

The context was one of telling what the C flag's meaning from a previous operation was, or why you'd start the subtraction with CLC instead of SEC, or something that might be a little unconventional. I did work one time with a man whose comments sometimes were just reiterating what the mnemonic said, like "Set carry flag." after SEC. That's just wasteful clutter because it does not introduce any new information. But anything that's not immediately clear from the code itself should be explained in the comments.

Sure.

My point is that one should probably be circumspect about applying these
rules, they're not absolute.

So I think it's appropriate to note in the coments that the carry flag
will always be set but it strikes me as a little nutty to make it explicit with
and SEC instruction (unless there's some good reason to of course, eg
you're branching here) just because of some rule about what "unreliable
spaghetti code" looks like (because you might some day want to branch
here for some reason).



hmm
As to the above example I'd include the comment even if I thought it
should be immediately clear from the code

The example of 16 bit subtraction was meant as a ridiculous extreme.
So I, (and I assume, you) would consider a full blown tutorial on muti-
byte arithmetic, detailing what happens with the carry flag, as probably
a bit of overkill.

However, part of my dogma is 'there's no such thing as too many comments'
so I certainly wouldn't argue that it would necessarily be too much.

My comment about "slippery slope" etc did of course relate to when the state of the carry before an SBC is depenant upon something a bit more out of the ordinary than multi-byte arithmetic - which is why I put the comment about "possibly a port line state" in.

I'm in complete agreement that it's next to impossible to have too much source code commenting - but as has been said, there's no point if it is no more than STBA commenting (i.e. Stating The B****y Obvious) like "set the carry". But at the same time it mustn't be too abstract from HOW the code does what it does (e.g. "mask off relay control bits so they are not affected when front pane LEDs are updated") by just what concentrating on what it achieves (e.g. "change front Panel LEDs")[/quote]

My comment about "slippery slope" etc did of course relate to when the state of the carry before an SBC is depenant upon something a bit more out of the ordinary than multi-byte arithmetic - which is why I put the comment about "possibly a port line state" in.

I'm in complete agreement that it's next to impossible to have too much source code commenting - but as has been said, there's no point if it is no more than STBA commenting (i.e. Stating The B****y Obvious) like "set the carry". But at the same time it mustn't be too abstract from HOW the code does what it does (e.g. "mask off relay control bits so they are not affected when front pane LEDs are updated") by just what concentrating on what it achieves (e.g. "change front Panel LEDs")[/quote]

And one of these days my brain and fingers will sort out their sync problem!