Yes...so, anyway, here's a little test program regarding unacceptable uses of ASSERT, not completely exhaustive:
Code:
; Hobby Cross-Assembler Error Test 008g
; Messages\Assert Messages
; error: failures detected on first pass (BDD1)
; by Anton Treuenfels
; first created: 08/28/13
; last revised: 08/28/13
; warning(s): 1
; error(s): 6
; fatal: 0
; -------------------------------
.listfile
.errfile
; -------------------------------
.cpu "T_16_L" ; required psop
.org $1000 ; required psop
; -------------------------------
assert ; try to make it a label
assert .bit16 $1000 ; try to make it a label
assert = $1000 ; try to assign a value
assert .macro ; try to make it a macro name
.endmacro ; (empty)
.macro assert ; try to make it a macro name
.endmacro
; -------------------------------
.end
and here's the error file created:
Code:
; >>>>> Error in TEST008G.A
; 0029: assert ; try to make it a label
; - Unexpected blank field
; >>>>> Error in TEST008G.A
; 0031: assert .bit16 $1000 ; try to make it a label
; - Expecting operand: <.bit16 $1000>
; >>>>> Error in TEST008G.A
; 0033: assert = $1000 ; try to assign a value
; - Expecting operand: <= $1000>
; >>>>> Error in TEST008G.A
; 0035: assert .macro ; try to make it a macro name
; - Expecting operand: <.macro>
; >>>>> Error in TEST008G.A
; 0036: .endmacro ; (empty)
; - Matching block structure not found
; >>>>> Error in TEST008G.A
; 0038: .macro assert ; try to make it a macro name
; - Name already in use: <ASSERT>
; >>>>> Warning in TEST008G.A
; 0039: .endmacro
; - Definition ignored
1 Warnings detected
6 Errors detected
and I
used to think that was pretty good. But now I wondering if something like this might be even better:
Code:
; >>>>> Error in TEST008G.A
; - While processing pseudo opcode: <ASSERT>
; 0029: assert ; try to make it a label
; - Unexpected blank field
; >>>>> Error in TEST008G.A
; - While processing pseudo opcode: <ASSERT>
; 0031: assert .bit16 $1000 ; try to make it a label
; - Expecting operand: <.bit16 $1000>
; >>>>> Error in TEST008G.A
; - While processing pseudo opcode: <ASSERT>
; 0033: assert = $1000 ; try to assign a value
; - Expecting operand: <= $1000>
; >>>>> Error in TEST008G.A
; - While processing pseudo opcode: <ASSERT>
; 0035: assert .macro ; try to make it a macro name
; - Expecting operand: <.macro>
; >>>>> Error in TEST008G.A
; - While processing pseudo opcode: <ENDMACRO>
; 0036: .endmacro ; (empty)
; - Matching block structure not found
; >>>>> Error in TEST008G.A
; - While processing pseudo opcode: <MACRO>
; 0038: .macro assert ; try to make it a macro name
; - Built-in symbol, pseudo opcode, mnemonic or function name: <ASSERT>
; >>>>> Warning in TEST008G.A
; - While processing pseudo opcode: <ENDMACRO>
; 0039: .endmacro
; - Definition ignored
1 Warnings detected
6 Errors detected
I don't think it would cost too much to add the 'while' line in terms of code or execution time, which would provide a clue as to what the assembler thinks is going on (processing pseudo op, instruction mnemonic, or user macro). And when a name conflict occurs it's certainly possible to distinguish between a built-in and a user-defined one.
This is what BDD has done to me
He's got me all worried about that poor programmer who can't for the life of him figure out why his
utterly reasonable code won't work.
Login
Register
FAQ
Search
(and there are others). These are for single-precision multiply, unsigned mixed-precision multiply (ie, with a double-precision product), signed mixed-precision multiply, and take three single-precision numbers and multiply the first by the second to get a double-precision intermediate result and then divide it by the third number and get a single-precision final result.
