#108 DEBUG - Arithmetic expressions should be allowed as address input in commands like dump, unassembly and others.

[Oliver]

In Digital Research's SID86 it is possible to use arithmetic expressions as
input for address values that are given to dump (D), fill (F), unassembly (U)
and other commands:

#dCS:0,F+F
0957:0000 B8 5A ... ; etc.
0957:0010 50 BA ... ; etc.

#lCS:20-#10,20
0957:0016 INT 21
0957:0018 MOV DX, 010D
...
0957:0020 RET
#

In SID L corresponds to DEBUG's Ucommand for unassembly.
CS is the code segment as usual.
The offset used here is 20-#10which is an arithmetic expression and means hex value 20 minus decimal value 10.

In DEBUG.EXE from FreeDOS, arithmetic expressions are not allowed as input, this gives an Error:

-dCS:0,F+F
        ^ Error

It would be nice, if that could be implemented in FreeDOS' DEBUG.EXE too.

[E. C. Masloch]

This is implemented in lDebug as the expression evaluator. Any command that parses numbers uses the expression evaluator, as described in the manual: https://pushbx.org/ecm/doc/ldebug.htm#parnumber

The assembler is special in that it doesn't use the expression evaluator by default. However, if you surround an expression with round parentheses like (...) then this is parsed by the expression evaluator and the calculated result is handled like an immediate number by the assembler.

[Oliver]

That's good to hear. I really like your LDEBUG. And i also hope here, that this will be implemented in FreeDOS's DEBUG too.

But there is one thing, SID also allows to use ASCII characters in an arithmetic expression when they are surrounded by inverted comman:

#DS:0,F+'G'
....

Such thing doesn't seem to work in a current version of LDEBUG.

But now i also have a question about LDEBUG. Is is possible to set up variables in LDEBUG and use them in arithmetic expressions?
Something like this:

-set ending=15
#D DS:0,F+$ending

[E. C. Masloch]

Mentioned elsewhere but you can use #'G' to input a text codepoint as a number.

As to the other question, in lDebug for now you get 256 scalar dword variables named V0 to VFF which can be used freely for any purpose. They can be written to using the R command, and read in any expression. V0 to VF are aliases to V00 to V0F.

The symbolic build allows specifying symbols with arbitrary names, to arbitrary segmented addresses. It is not considered ready yet though.

[Oliver]

Thank you for the information.
The thing with scalar dword variables sound good.

Is it correct that these variables cannot yet be used in the assembly command?

I tried several combinations, since it's a DWORD, I assume the bytes above it will be truncated if the register is smaller like AX.

-R V0
V0 00000000  :4
-A
MOV AX, V0
MOV AX, 'V0'
MOV AX, (#V0)
MOV AX, [V0]
MOV AX, $V0
MOV AX, %V0%

All give an error message.

And
MOV AX, (#'V0')
does work, but this seems to be the expression evaluator anyway like you mentioned in another thread.

h (#'V0')
3056   decimal: 12347

If i check that with h he value that comes out from there also matches the above MOV statement in the unassembly. So yes, it is the expression evaluator and definitely not the V0 variable with the 4 as value.

Then i have another question, is it possible to list all variables that have received a value. So all variables that are defined or not 0?

I'm excited about the symbolic build. I will test it as soon as it is usable.

[E. C. Masloch]

Is it correct that these variables cannot yet be used in the assembly command?

No, the V variables can be used in the assembler. You need to enter the input as in mov ax, (v0). As you observed V0 is a dword variable; if its value is above FFFFh then the assembler will reject this instruction. (Negative dword values are rejected too, but if you have r v0 -1 then mov ax, (word v0) will work to truncate the negative value to 16 bits.)

MOV AX, (#'V0') expands the text "V0" to the codepoints 56h "V" and 30h "0". This uses the expression evaluator's string literals type of expression term. You want an expression with a variable term instead. Variables include the DCO (Debugger Common Options), DAO (Debugger Assembly Options), AAO (next default assembly offset), V variables, PSP variables, all 8/16/32-bit debuggee registers, and many more.

Then i have another question, is it possible to list all variables that have received a value. So all variables that are defined or not 0?

RV lists the original 16 V0 to VF variables, unconditionally, along with some process-related variables. RVV displays all V variables in groups of four per line, skipping any lines with all-zero values.

I'm excited about the symbolic build. I will test it as soon as it is usable.

Interest noted.

[Oliver]

Thank you for your answer.

[E. C. Masloch]

I added an Extension for lDebug which will dump assembled machine code bytes in hexadecimal after any successful assembler command, install it using ext aformat.eld install.

I also added set.eld and variable.eld which as mentioned in https://sourceforge.net/p/freedos/feature-requests/93/?page=1#93d6/154a/fd12/494e/401d/dfe2/30f2 allow to use text variables. The variable ELD can actually be installed residently as well, in that case any %vldvariable% occurrences in all regular debugger commands (but not assembler lines) will be replaced. (I am considering to add a replacement for assembler commands too.)

[Oliver]

I added an Extension for lDebug which will dump assembled machine code bytes in hexadecimal after any successful assembler command, install it using ext aformat.eld install.

That's a neat feature. Thank you!

Regarding set.eld and variable.eld, I use the other thread.