Line numbers in an ASM block: Unpredictable results

[Lance Edmonds]

I find ERADR completely acceptable, and it offers improved resolution over line numbers (per line, not per line number).


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Hans Ruegg]

Thank you again for your hints, although the problem seems not to be
that easy.
Tom, a JMP over the line number makes the number "invisible" to ERL,
so there would be no sense in inserting the number at all.
I tried the following code which generates a Division by Zero Error:

ON ERROR GOTO errHandler

10 PRINT "Program Start"

! PUSH AX
! PUSH BX
! MOV AX, 3768
  ! JMP pastNumber
20
pastNumber:
! MOV BL, 0
! DIV BL
! POP BX
! POP AX

30 PRINT "Program ends here."
END

errHandler:
PRINT "Error "; STR$(ERR); " in Line "; STR$(ERL)
END

Output was: "Error 11 in Line 10"
Without the JMP, output was (as expected): "Error 11 in Line 20".

Maybe the conclusion is still to completely avoid line numbers in
assembler blocks and to apply other debugging techniques?

Regards,

Hans Ruegg.

[Tom Hanlin]

If the line number is in the middle of your asm code, it may cause unexpected results.
I'd suggest avoiding this entirely, but you may find it safe to explicitly JMP over
line numbers.


------------------
Tom Hanlin
PowerBASIC Staff

[Lance Edmonds]

PUSH DS and SI before the line number, and POP them again afterward. However, if you jump to that line number from elsewhere, the stack frame must have those two registers PUSHed already or the stcak will be desynchronized by two unbalanced POP's.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Hans Ruegg]

Thank you very much for your explanations!

DS and SI are preserved earlier in the code, but are not restored
before inserting the line number. So if I understand your comments
correctly, it is possible to refer to a line number with ERL,
provided I restore the registers before inserting the line
number?

Hans Ruegg

[Bob Zale]

One other problem with the code you posted is that you did not preserve the DS and SI registers. Perhaps you did so earlier and it's just not shown, but...

Good luck with this.

Bob Zale
PowerBASIC Inc.



------------------

[Bob Zale]

1- Labels are followed by a colon, line numbers are not.

2- When you reference ERL in a program, each occurrence of a line number must cause code to be generated to track it. It is the programmer's responsibility to ensure that the status of the machine is maintained. Don't put anything in between source code lines which may disrupt it.

3- This is a bug in your source code, not in PowerBASIC.

Regards,

Bob Zale
PowerBASIC Inc.



------------------

[Hans Ruegg]

This week I spent about five hours tracking a strange bug in a
program with over 2000 lines. I had several inline assembler
procedures which manipulate data in several arrays, and always
the same array at the same position was overwritten with two
bytes of data I had no idea where they came from.
Finally I discovered by accident, that these strange two bytes,
taken together as an integer value, corresponded exactly to the
value of a line number I had inserted between two assembler
statements for error tracking purposes. It looked somehow like
this:

...
! CLD
! LDS SI, CS:currentPtr    ;(this is a CS variable declared earlier)
8020                       '(this is the line number causing the bug)
MyLoop:
! LODSB
! XOR AH,AH
! TEST AL, 1
...

You won't believe it: I removed the line number (8020), and everything
worked perfectly!!

Now this leads me to some questions, of course:

- Is it an error to insert line numbers between assembler statements?
- How does the compiler interpret resp. misinterpret this number?
(I am still not able to explain how the value of the line number gets
into a data array when the code is executed.)
- If it is an error, why does this code compile without an error message?
- Does it make sense at all to apply ERR and ERL to code written in
inline Assembler? (I thought at least some errors, such as numeric
errors or disk write errors, could be trapped like that, but maybe I am
wrong. The program referred to makes heavy use of conventional memory,
so I cannot run it in PBD.)

I hope somebody can enlighten me about this point.
Thank you!

Hans Ruegg