Borlands TASM32 v5.x - QWORD arguments causing problems.

[R.Wieser]

Hello all,

I've got a (very old) Borlands Tasm32 v5.x , and it has a problem that has
been bugging me for the longest time: I can specify QWORD arguments for a
function, but than I'm only allowed to call those functions with constant
values for them.

Question: Does anyone (still) know of this problem, and if so perhaps how to
solve it ?

Remark: Work-arounds have ofcourse been found and used, but having to do
that still irks me.

Regards,
Rudy Wieser

** Minimal example (tested with TASM32 v5.0, 5.3 and 5.4):

TestFunc PROCDESC qVal:QWORD
TestFunc proc
arg @@qVal:QWORD

ret
TestFunc endp

@@qData dq 1234567887654321h

call TestFunc,12345678h 87654321h
-- Works (notice the space, not comma between the two values)

call TestFunc,[@@qData]
-- Error: Argument mismatch


** List file

3650 call TestFunc,12345678h 87654321h ;Works
1 3651 00000008 68 12345678 68 + PUSH 12345678H 87654321H
3652 87654321
1 3653 00000012 E8 FFFFFFE9 CALL TestFunc

1 3660 00000023 FF 35 00000004r FF + PUSH [@@qData]
3661 35 00000000r
1 3662 0000002F E8 FFFFFFCC CALL TestFunc

[JJ]

Post by R.Wieser
Hello all,
I've got a (very old) Borlands Tasm32 v5.x , and it has a problem that has
been bugging me for the longest time: I can specify QWORD arguments for a
function, but than I'm only allowed to call those functions with constant
values for them.
Question: Does anyone (still) know of this problem, and if so perhaps how to
solve it ?
Remark: Work-arounds have ofcourse been found and used, but having to do
that still irks me.
Regards,
Rudy Wieser
TestFunc PROCDESC qVal:QWORD
TestFunc proc
ret
TestFunc endp
@@qData dq 1234567887654321h
call TestFunc,12345678h 87654321h
-- Works (notice the space, not comma between the two values)
-- Error: Argument mismatch

Because the default operand size is 32-bit, the `[@@qData]` would be
equivalent to `DWORD PTR [@@qData]`. Thus, don't match the argument type.

[JJ]

I'm not sure if TASM is smart enough to convert a `QWORD PTR` argument into
two `DWORD PTR` PUSHes.

[R.Wieser]

JJ,

Post by JJ
argument type.

That should not be it. The "@@qData" has been created as "DQ" (DataQuad)
and "[@@qData]" is thus equivalent to "QWORD PTR [@@qData]", just like
specified in the called functions PROCDESC (QWORD). As such they should
match.

But, maybe you are thinking that "[@@qData]" causes a /pointer/ to be pushed
? It doesn't. It pushes the contents. (for a pointer I would need to use
"offset [@@qData]")

Also, the first list file part shows two 32-bit constants being pushed /and
accepted/ (using one or three 32-bit constants causes an error). The last
part shows the same, just now pushing the (two 32-bit parts of) contents of

Post by JJ
I'm not sure if TASM is smart enough to convert a `QWORD PTR`
argument into two `DWORD PTR` PUSHes.

:-) You only have to look at the posted list-file tidbits: It seems to shows
it does:

FF 35 00000004r ;High part \ of 64-bit memory-located value
FF 35 00000000r ;Low part / (offset into datasegment)
E8 FFFFFFCC ; call the function

Regards,
Rudy Wieser

P.s.
The last call, shown in the list file, ofcourse only shows up when I
remark-out the "PROCDESC" line. Otherwise that error is generated.

[JJ]

Post by R.Wieser
:-) You only have to look at the posted list-file tidbits: It seems to shows
FF 35 00000004r ;High part \ of 64-bit memory-located value
FF 35 00000000r ;Low part / (offset into datasegment)
E8 FFFFFFCC ; call the function

It PUSHes the data pointer, not the data itself.

[R.Wieser]

JJ,

Post by JJ
It PUSHes the data pointer, not the data itself.

:-) Believe me, it pushes the data.

Although I've not mentioned it, I've, before posting, (ofcourse) displayed
the argument in the called function (to make sure it does what should). As
show in my initial post, I used quite recognisable data, and that was what
was displayed.

Also, the opcode doesn't agree with you : FF 35 -> Push R/M32 (in this case
M32). If it would be an offset than it would be a simple constant, and
that is what the first "List file" block shows (68 12345678)

I think you're thrown off by the "r" at the end of the values. If so, than
remember that what I've shown is outof the .LST file /before/ linking (read:
the "absolute" adresses may still be moved around)

Regards,
Rudy Wueser