I have to admit, I am a little bit confused. I always thought that situation is straightforward.
Let's assume we have a following situation.



But recently I was looking at a code compiled by CC65. There is a following fragment of a main() function.



It is compiled as:



Can anyone explain me how does it works? It looks like bcs instruction points at itself, by using L001F label.
Can it be done that way? Will bcs simply jump to the next label (L001E in that case) if variable is less or equal than 0x10?

That is simply an endless loop if _variable >= 16. So that is equivalent to your C code. The compiler just decided to implement your endless loop twice.

No, you were on the right track the first time!

Firstly, the C code you wrote isn't functionally identical to the assembly code and secondly, CC65 doesn't produce very optimal code. CC65 still needs some of it's rough edges and documentation polishing and on my wishlist is support for floats and doubles (and I don't care what the whingers say about floats and doubles being slow on a 6502, they can go away).

BEQ branches when Z is set,
BCS branches when C is set.

you could have said "!=" in C instead.

It is a curious situation that the compiler implemented the endless loop twice, however.

I believe that "BCS" on the 65xx is equivalent to "BCC" or "BHS" from 680x/680x0-lands, which means branch if unsigned >= (assuming the flags were preconditioned by a compare or subtract instruction).

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

While it would have been no more efficient, it would have read better and been less confusing if the compiler code read:

_________________
Bill

BCS on the 6502 branches on carry set and BCC branches on carry clear. Subtraction clears the carry if the subtraction results in a borrow and sets it otherwise. Comparisons have the same effect on the carry flag as subtraction. In the following code snippet it may appear that nothing is subtraced from memory location COUNTER but because the carry flag is cleared, one is subtracted from COUNTER.

This example runs on easy 6502 http://skilldrick.github.io/easy6502/ as I think this will be easier to follow than my Forth assembler syntax.

Cheers,
Jim

I forgot to mention when you try this code on easy 6502 http://skilldrick.github.io/easy6502/, after assembling the code, click the monitor button and the debugger button. Single step through the code to see the carry flag and memory locations change.

I ran across this the other day. Just wish I found it sooner.
The SBC, TSX, and TXS Instructions of the 6502 and 6800
by B.T.G. Tan
Dr Dobbs Journal #79 May 1983 page 67 http://6502.org/documents/publications/dr_dobbs_journal/
It's in Volume 8.

page 280 of the .pdf file

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

BTW another way to read Mike's scans of DDJ is at the internet archive:
https://archive.org/details/dr_dobbs_journal

and then we can link directly to the article:
https://archive.org/stream/dr_dobbs_jou ... 9/mode/1up

Thanks for the tip!

Make _variable a volatile, to force the compiler to read it each time and prevent optimizing the infinite loop.

(Welcome to the forum ghedger42!)

It's great to see the Dr. Dobb's scans are being put to good use.

This particular article is also available as a separate PDF under Dr. Dobb's Selected Articles (suggested by Ed).

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

It seems quite an omission that it doesn't actually show you how to do stack-relative addressing on the 6502:



Of course, this doesn't support $01ff->0100 wrapping as PHA/PLA would, but that's usually a stack underflow anyway.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor