This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IF statement in assembly

I'm wondering, Does assembler support if staments? (like a C program) Tried something very simple:

org 0h
sjmp BEGIN

org 50h
BEGIN:
	IF R0 == #45
		MOV A, #54
		CPL A
	ELSE
		MOV A, #45
		CPL A
	ENDIF
END

After building and enter debug mode I found this code seems to be a #ifdef like statement instead of a C like if-then-else statement. Did I do something wrong or the assembler does no support if statement?

Parents
  • jl		MACRO	x, y, addr
    [...]

    A hint regarding all those macros: cjne is better for most of these than subb or xrl. In particular, you can easily get three exits from a single macro: one for a < b, one for a == b, and one for a > b. And the content of the accu at exit from the macro will be one of its operands, rather than their difference.

Reply
  • jl		MACRO	x, y, addr
    [...]

    A hint regarding all those macros: cjne is better for most of these than subb or xrl. In particular, you can easily get three exits from a single macro: one for a < b, one for a == b, and one for a > b. And the content of the accu at exit from the macro will be one of its operands, rather than their difference.

Children
  • A hint regarding all those macros: cjne is better for most of these than subb or xrl. In particular, you can easily get three exits from a single macro: one for a < b, one for a == b, and one for a > b. And the content of the accu at exit from the macro will be one of its operands, rather than their difference.

    Obviously, but CJNE doesn't accept just any operands. The macros as they're written, on the other hand, will accept any Rn, #data, or direct in either x or y parameter.

    True, they may not be as efficient as possible, but the couple of extra machine cycles is a small price to pay to have intuitive instructions that work for any type of operands.

  • "True, they may not be as efficient as possible, but the couple of extra machine cycles is a small price to pay to have intuitive instructions that work for any type of operands."

    The implication behind the question is that the OP wants to use assembler because he believes it will be more efficient than 'C'.
    Thus, making the assembler inefficient to match the convenience of 'C' entirely defeats the object!

    This also serves to illustrate the fallacy of assuming that something written in assembler will inherently be more efficient than something written in 'C' - you can easily write inefficient assembler if you choose to (or if you don't have the skill to do otherwise).

    As Hans-Bernhard said, if you want the convenience of 'C' - then use 'C'!!

  • The implication behind the question is that the OP wants to use assembler because he believes it will be more efficient than 'C'.
    Thus, making the assembler inefficient to match the convenience of 'C' entirely defeats the object!

    This also serves to illustrate the fallacy of assuming that something written in assembler will inherently be more efficient than something written in 'C' - you can easily write inefficient assembler if you choose to (or if you don't have the skill to do otherwise).
    Its not like one would haphazardly sprinkle the "if" macros all over. They're simply useful comparisons instructions that replace commonly used code sequences and, if at all, sacrifice one or two machine cycles.

    Further, before one so quickly abandons assembler for C at the first requirement of convenience, one might consider there's a reason its called a "macro assembler" and take advantage of it...unless of course they lack the skill to realize this.