Borland C++ Inline Assembly Question

[Chris Huey]

The docs all say that you can use DB, DW, etc. assembler directives
with the in-line assembler. The manuals further state that these
variables will exist in the code segment. Exactly what I want.

But I have yet to figure out exactly the right way of declaring these
variables. I've tried:

asm {
var1: dw 0

var2 dw 0

}
neither of which get past an assembler error.

Any ideas?

Thanks!!!

Chris
--

[Christopher HILL]

First of all, if you are doing this in C/C++, then it is far easier to
declare the variables outside of the inline assembly blocks. Second, you
may not put lables inside inline assembly blocks.

Try something like this:

void func1(void)
{
int var1,var2;

asm{
mov ax,[var1] // access var1
add ax,[var2] // add var2 to it, or whatever...
jz jp1
...
}
jp1:
... and so on
}

Christopher Hill
Aiea, Hawai`i (O`ahu)

[Jeff Lait]

In article <Dn3ox...@tactix.com>, Chris Huey <c...@tactix.com> wrote:
>The docs all say that you can use DB, DW, etc. assembler directives
>with the in-line assembler. The manuals further state that these
>variables will exist in the code segment. Exactly what I want.
>
>But I have yet to figure out exactly the right way of declaring these
>variables. I've tried:
>
>asm {
>var1: dw 0
>
>var2 dw 0
>
>}
> neither of which get past an assembler error.
>

Borlands inline assembler, at the last version I used (3.0),
does not allow labels to be inlined. This means you'd have to write:
asm {
init code...
}
Loop:
asm {
loop body...
jle Loop
}
to do a loop. A similar problem exists here, though I am unsure
whether you can guarantee var1 properly labels the word in question
in the following code snippet:
var1:
asm {
dw 0
}
It seems needlessly risky to assume the compiler doesnt add any
code between the label and the data directive.
I would, however, question why you need this? Isn't it better
to us variables on the stack or at file scope? Not only does this make
matters such as reentrancy easier to deal with, it also allows the
surrounding c code to have access to the variables. Only use for this
would be selfmodifying code, IMHO, not something I'd want to do in an
inlined assembly chunk. That's what external assembly files are for,
where your example would work fine.

--
- Jeff Lait (SOL)

[Chris Huey]

Jeff Lait (jml...@undergrad.math.uwaterloo.ca) wrote:

: In article <Dn3ox...@tactix.com>, Chris Huey <c...@tactix.com> wrote:
: >The docs all say that you can use DB, DW, etc. assembler directives
: >with the in-line assembler. The manuals further state that these
: >variables will exist in the code segment. Exactly what I want.
: >
: >But I have yet to figure out exactly the right way of declaring these
: >variables. I've tried:

: >
: Borlands inline assembler, at the last version I used (3.0),

: does not allow labels to be inlined. This means you'd have to write:
: asm {
: init code...
: }
: Loop:
: asm {
: loop body...
: jle Loop
: }
: to do a loop. A similar problem exists here, though I am unsure
: whether you can guarantee var1 properly labels the word in question
: in the following code snippet:
: var1:
: asm {
: dw 0
: }
: It seems needlessly risky to assume the compiler doesnt add any
: code between the label and the data directive.
: I would, however, question why you need this? Isn't it better
: to us variables on the stack or at file scope? Not only does this make
: matters such as reentrancy easier to deal with, it also allows the
: surrounding c code to have access to the variables. Only use for this
: would be selfmodifying code, IMHO, not something I'd want to do in an
: inlined assembly chunk. That's what external assembly files are for,
: where your example would work fine.

Normally, I would just use local stack variables. But in this case,
I WANT the variables to be in the code segment (like the docs say will
happen). In this particular case, I want to save SS and SP in the
code segment, invoke INT 2E (backdoor to COMMAND.COM), then restore
SS and SP upon return (INT 2E saves only CS:IP). So, that's why I
"need" to do this. Reentrancy is not a problem or issue. And the
code is not self-modifying.

Chris
--