Metrowerks HC(SX)12 assembler and Code Warrior debugger

[electro]

Hello,

I have some trouble in setting the options of the macro assembler to make debugging as comfortable as possible:

First Problem: my assembly code relies heavily on macros and conditionnal assembly, and this is bad for the .dbg files used by the debugger:

   -  if I choose the option "print macro expansion in listing files", the .dbg files are invaded with the "else" and "endif" of the branches not taken by the conditionnal assembly (and when you have to skip several pages of such lines to see the next instruction debugging becomes tedious).

   - if I choose the option "dont print macro expansion", dbg files are much more readable, but it becomes impossible to see the stepping of the instructions of the macro in the source window (well, I can see the instructions in the disassembler window, but without comments and making up it is often difficult to understand what happens).

   - the solution would be to have a dbg file with ALL the microcontroller instructions genererated by the macro assembler, and ONLY the instructions. Does somebody know a way to get this ?

Second problem: labels generated by the assembler; I have many arrays declared like this:

ARRxxx:     dc.W $FF45, $EA56, ....

                   dc.W ............

                   dc.W ...............

In my view, all the values belong to the "array" ARRxxx, but the assembler only associates the first line to the label ARRxxx, the second and third lines are associated to labels like VAR000025,VAR00026, etc... Now, when debugging a routine which uses register X as pointer to the array, you drag X from register to data window, and you get the information : "VAR00026+3", but what is VAR00026 ? (ARRxxx+7 would be much more interesting).

Naturally, it is possible to declare all the array with a unique dc.W, but if the array is large, you must put all the values on the same line, making things unreadable (and you can no longer mix dc.W and dc.B in the same array).

The problem does not exist in code sections, where the assembler only uses user labels and doesn't generate its labels.

Do you know a way to reqire the assembler to use only MY labels ?

Sorry for the length of my questions, and for my bad english...........

Thanks.

Message Edited by electro on 2008-02-02 09:58 PM

[bigmac]

Hello,

On your first problem -

My understanding is that macros and conditional assembly are separate issues.  I am not clear whether you are attempting to use macros within a conditional assembly block, or use conditional assembly within a macro block.  I am not even aware whether the latter is possible.

I would normally choose the "don't print macro expansion" option myself, and this does not seem to create a problem for my conditional assembly - only the code for the option taken is shown in the listing file.  I should say that I use the HC08 assembler, and am assuming, perhaps incorrectly, that the HC12 assembler will be similar.

Perhaps you could generate a .lst file, in addition to the .dbg file, to see whether there is a difference in readability.

With lack of macro expansion in the listing, a possible work around during a debug session might be to maintain a reference hard copy listing of the macro definitions - easy to do if they are in a separate .inc file.  I make the assumption that each macro consists only of a few lines of code.  If considerably more complex, perhaps you really need to create additional sub-routines instead.

Regards,

Mac

[electro]

Hello
Thank you for your answer; macros and conditional assembly are separate issues. but they work together in a fine way, especially when using recursion. I give you an example, extracted from my code:

**************  apply fct to arg_1,...arg_n   (0 <= n <= 10)

apply     macro ; fct,arg_1,...,arg_n
              ifnc "\2",""
              \1 \2
              apply <\1>, <\3>,<\4>,<\5>,<\6>,<\7>,<\8>,<\9>,<\a>,<\b>
              endif
              endm

function     macro ; arg
                  ldaA \1
                  endm

**************  Now the code

progr      apply function,1,2,3,4

**************  produces the following listing (with option print macro expansion and macro calls)

progr      apply function,1,2,3,4
              ifnc "1",""
              function 1
              ldaA    1
              apply <function>, <2>,<3>,<4>,<>,<>,<>,<>,<>,<>
              ifnc "2",""
               function 2
               ldaA    2
               apply <function>, <3>,<4>,<>,<>,<>,<>,<>,<>,<>
               ifnc "3",""
                function 3
                ldaA    3
               apply <function>, <4>,<>,<>,<>,<>,<>,<>,<>,<>
               ifnc "4",""
               function 4
               ldaA    4
               apply <function>, <>,<>,<>,<>,<>,<>,<>,<>,<>
               ifnc "",""
               endif
               endif
               endif
               endif
               endif

**************  The expected listing would be:

progr       ldaA 1
                ldaA 2
                ldaA 3
                ldaA 4

Naturally, I use apply with functions doing more interesting things that the "function" given in the example ! (things can even be more involved, as function is generally a macro containing itself conditional assembly).

What is needed here is a directive "don't print lines with if, else, endif", independant of the directive "don't print macro expansions".

I have looked at the listing file, and seen that dbg files follow more or less what is done for lst files. You say that when you choose the option "don't print macro expansion" the code for the option taken is shown in the listing file. My problem is that with the HC12 assembler the listing shows ...nothing in this case, and that's my problem for debugging.
Well, I would not be so demanding for lst files, as I prefer to look at my source file than at the listing, but when I am debugging I have not the choice : the debugger imposes me the dbg file ...

Your solution to have a hard copy listing of the macro definitions is right for one level of macro, but when you have macros which call macros which call ... things become much more difficult.

I use also subroutines, but not exactly for the same purposes. When you want to pass complex arguments (especially functions), macros are irreplaceable. They permit a quasi-functional style of programming, while keeping the efficacity and flexibility of assembler. C is far from this...

Regards.

[bigmac]

Hello Alain,

With the "no macro expansion" option, I would presume that the listing should be identical with the code, i.e.

progr      apply function,1,2,3,4

If this is so, I would consider consistent.  If not so, perhaps the behavior is different because you are calling two macros in a concatenated fashion, or perhaps because of conditional assembly within the maro.  Macro names do appear to be treated a little differently than other labels.  For example, using ifndef directive for a macro name does not seem to work - the following is problematic (I recall there was an error message).

  ifndef  func1

func1:    macro

          ; macro contents

          endm

  endif

A separate lable neede to be created for the ifndef.

  ifndef  _func1_

_func1_:

func1:    macro

          ; macro contents

          endm

  endif

So perhaps there may be other subtle behavioral differences within macro definitions.

I must say that I would be uncomfortable with your complicated use of macros, and particularly the recursion.  Recursive operation is difficult to understand on a good day.  The only reason recursive use of a sub-routine might be considered would be if it resulted in a significant saving of code size.  However, with macro use there can be no saving at all.

My personal approach to macros is to use them only if it make the functionality of the program operation clearer to me, and where the use of an additional sub-routine would be inefficient.  Consequently, my macros tend to be quite simple.  For example, the following macro would avoid the direct use of a mask value.

   set_bitA  2  ; Set bit 2 in accA

With your previous code example, the following sequence would be equally as meaningful to me, and might avoid some of the listing and recursion issues.

progr  function 1

       function 2

       function 3

       function 4

Regards,

Mac

Message Edited by bigmac on 2008-02-04 01:49 AM

[electro]

Hello Mac,

    You say recursivity is difficult to understand, but it depends on your background. When you are used to functional languages (ML,Haskell,...), where recursivity is almost the sole control structure, it becomes very simple and natural. I recognize that programmers used to imperative languages don't like recursivity too much... Anyway, as assembler lacks of control structures (except the for loop and conditional assembly), I use recursivity to implement what I need.

    Personally, when I program, my first concern is the readability (may I say "elegance"..) of my program. In this perspective, nothing is better (for me) than functional languages. Now, when I am also concerned by efficiency of code and the possibility to control I/O lines, I can forget my favourite ML, Haskell and other Lisp... And I discovered that the use of (perhaps complicated) macros allowed me to regain a flavour of functionality while using assembler. They make my program very readable (for me, once again), and preserve efficiency. The code generated is longer than with subroutines, but this is not really a problem with the size of todays flash memories. Nevertheless I use also subroutines when there are few and simple arguments. I am not a macro integrist...

    Anyhow, I suppose everybody may have his own philosophy about macros. I agree that I could solve my problem by restraining severely my use of macros, ultimately by using no macro at all.

    But I find it a pity to give up my favourite style of programming, not because it doesn't work, but only because the lack of an assembler directive (or the fact that I couln't find it) makes debugging uncomfortable.

    In fact, to get a listing without the if, else, and endif lines, the only workaround I found is to disable the printing of macro expansions. But I does want macro expansions to be printed. What I doesn't want is the noise around conditional assembly.

    I realize now that I should have formulated my question like this : do you know a way to disable the printing of if, else, and endif lines, and only those lines when generating listing and debugging files ?

Thank you for your time

[bigmac · Accepted solution]

Hello Alain,

---

electro wrote:

    I realize now that I should have formulated my question like this : do you know a way to disable the printing of if, else, and endif lines, and only those lines when generating listing and debugging files ?

Thank you for your time

---

The only method I can think of might be the judicious use of NOLIST and  LIST directives surrounding the code you don't wish to be listed.  Of course, this can make the appearance of the source code more messy.

Regards,

Mac