I'm trying to use the ax51 standard macro assembler to find a way to determine if a symbol or label is already defined. Something like the following pseudo code:
if label "table_abc" is defined, do nothing, else do the following: table_abc: DB 1 DB 2 DB 3 endif
I somehow thought the following could work but alas it does not: IF NOT :DEF:table_abc table_abc: DB 1 DB 2 DB 3 ENDIF
-> LABEL NOT PERMITTED, SYNTAX ERROR
My code is 100 percent assembler code so I try to not use the C preprocessor. But if there is no other way, a C preprocessor code example would help as well.
EFM8BB31, Silicon Labs Simplicity Studio v3, Keil 8051 v9.53 debug
if a label is defined twice you shoul dget an assembler/linker error. why add Mickey Mouse stuff to catch what is already being caught?
The assembler/linker error catch is not able to decide whether additional code has to be processed or not. It only can abort the assembly. The user/developer could manually uncomment the addional code (function_abc) if the error occurs but that's not very user-friendly is it? The assembler is supposed to do it automatically.
macro assembler to find a way to determine if a symbol or label is already defined
It really should have been totally obvious to you why that cannot work: neither symbols nor labels are in any way related to macro processing. They simply don't exist yet at the time macros are handled. It says so right at the start of the documentation's chapter on assembler macros, too!
And no, switching to C macro preprocessing will not change that in any way.
It still works with the C precompiler in this way:
#ifndef DEF_table_abc #define DEF_table_abc table_abc: DB 1 DB 2 DB 3 #endif
It would have been nicer with a macro assembler solution but I guess I can get used to some C preprocessor lines. Thanks for the comments.
No, that construct doesn't "work", because it does not do what you originally said you wanted to do. It does not detect whether a label is defined ... it checks whether a macro is defined. That's really quite a different thing.
Nor does it fulfill the underlying secret goal you revealed later, about taking care of things the user might have forgotten to do. This construct will still fail just as badly as an unprotected label definition, because a user who didn't know they were supposed to define that label will be equally uninformed about the need to define some macro, on top of that.
You are right, this solution won't help for an uninformed user. Thanks.