Masm v8 and above apparently have problems with code like this:
.386
.model flat, stdcall
.data
table label dword
dd 0
dd 1
dd 2
SIZE_TABLE equ ( $ - table ) / 4
foo proto :DWORD
.code
invoke foo, SIZE_TABLE ;'invalid instruction operands' ????
end
It's no problem for Masm v6.1x. Anybody with a good proposal for a workaround?
this seems to work:
SIZE_TABLE TEXTEQU %( $ - table ) / 4
Yes, it works. Thanks!
Strangely enough, mov eax, SIZE_TABLE works fine.
This works with invoke, too:
table dd 0, 1, 2
SIZE_TABLE = lengthof table
... but I guess you have good reasons to choose a more exotic solution ;-)
Quote from: jj2007 on October 21, 2012, 04:36:27 AM
... but I guess you have good reasons to choose a more exotic solution ;-)
Yes - quite a few times there are entries enclosed in a if-endif block in the table.
Btw, the TEXTEQU workaround is not always compatible, because you can't make a text macro public. In such cases you need an additional helper equate.
Here is one more option, it works with ml 6.15...10 and JWasm:
include \masm32\include\masm32rt.inc
.data
bigger=1 ; test if
dummct=0
dummy CATSTR <dumstr>, %dummct
dummct=dummct+1
table label dword
dummy STRUCT
dd 0
dd 1
if bigger
dd 2
endif
dd 2
dummy ENDS
SIZE_TABLE equ dummy ;( $ - table ) / 4
dummy CATSTR <dumstr>, %dummct
dummct=dummct+1
table2 label dword
dummy STRUCT
dd 0
dd 1
ife bigger
dd 2
endif
dd 2
dummy ENDS
SIZE_TABLE2 equ dummy
foo proto :DWORD
.code
start:
invoke foo, SIZE_TABLE ;'invalid instruction operands' ????
invoke foo, SIZE_TABLE2
inkey " "
foo proc arg
print str$(arg), 13, 10
ret
foo endp
end start
Quote
table label dword
dd 0
dd 1
dd 2
SIZE_TABLE dd $ - table
And you can do what you want of SIZE_TABLE
Quote from: ToutEnMasm on October 21, 2012, 07:03:08 PM
Quote
table label dword
dd 0
dd 1
dd 2
SIZE_TABLE dd $ - table
And you can do what you want of SIZE_TABLE
Just Masm v8 has to be convinced yet:
table label dword
dd 0
dd 1
dd 2
;;SIZE_TABLE equ ( $ - table ) / 4
SIZE_TABLE dd $ - table
.code
push SIZE_TABLE*2 ;gives error 'constant expected'
:biggrin:
Quote from: japheth on October 21, 2012, 07:30:17 PM
Just Masm v8 has to be convinced yet:
Yves' workaround works with my version of ML 8, but it inserts a dword into the .data section.
Correction for mine:
SIZE_TABLE equ dummy/4
If you made it an exercice of syntax,this one is perfect
Quote
table dd 0,
1,
2
and all work
Quote
push sizeof table *2
invoke foo,(sizeof table /4)
:biggrin:
Quote from: jj2007 on October 21, 2012, 08:04:24 PM
Yves' workaround works with my version of ML 8, but it inserts a dword into the .data section.
I was kidding, jj. Perhaps you're living in Italy for too long now and have lost the non-existing German sense of humor? ( hint: the previous remark is also not to be taken too seriously ).
I was trying to assemble a pretty huge Masm application (COMView) with Masm v8, and finally managed ( after modifying a few dozen locations to the "textequ" style ) to assemble it without errors.
This doesn't mean that I'm having a running application now. As it turned out, Masm v8 tends to make procedures public even if you have declared them private ( either by OPTION PROC:private or directly in the PROC directive ). So I've given up for now.
Quote from: japheth on October 21, 2012, 09:37:03 PM
So I've given up for now.
I can recommend JWasm (http://www.japheth.de/JWasm.html) ;-)
Quote from: jj2007 on October 22, 2012, 02:26:52 AM
I can recommend JWasm (http://www.japheth.de/JWasm.html) ;-)
Thanks! However, I wanted to try Masm v8 because it does - or at least is supposed to do - something that jwasm cannot do yet: emit Codeview v8 symbolic debug info for a multi-module assembly application.
My suggestion is to get the Codeview v8 into jwasm for 32 and 64bit :)
(Joking.. well not really). Jwasm is far superior, CV8 is the only thing missing for me to move all my work over to jwasm.
On a side note.. i have a strange issue with one particular project. It will assemble and link perfectly with MASM. It Assembles perfectly with JWASM too, but when I try to link I get:
error LNK2005: _$$$00020@0 already defined in spatialflow.obj
For the life of me I can't find any duplicate definitions and masm doesn't seem to have any issues.
Quote
For the life of me I can't find any duplicate definitions and masm doesn't seem to have any issues.
I know well this one.
Can be in an interface definition
interface STRUCT
mafonction comethod2 ?
interface ENDS
mafonction proto
and masm disagree.
Quote from: johnsa on October 24, 2012, 10:38:59 PM
On a side note.. i have a strange issue with one particular project. It will assemble and link perfectly with MASM. It Assembles perfectly with JWASM too, but when I try to link I get:
error LNK2005: _$$$00020@0 already defined in spatialflow.obj
symbols starting with "$$$" are created by jwasm if line number information is to be generated ( -Zd or -Zi ) and there's code outside of a procedure ( see linnum.c ). Perhaps it's necessary to make this procedure explicitely "private". Simplest workaround: put the code in a "dummy" proc.
Hey,
I've tried manually searching for any code that might be outside of a PROC and cannot find it.
Is there any way to get a dump of that symbol and try to work out where in the source the issue lies? (I'd be quite happy to adjust the source if only I could find it! :)
John
John,
Its easy to do in MASM manually but if you are writing modules in MASM to use with C/C++ your code should only be within the procedures, not outside the PROC definitions that are common in MASM. You pick the PROC statements by a normal manual stack frame. The non stack frame procs are a bit harder to pick but if you know what alignment padding looks like and usually but not exxclusively the RET location you can find a non stack frame proc.
The latter comment is because some folks use a JMP to exit a proc, even though it leaves the CALL/RET matching unbalanced.
Quote from: johnsa on October 26, 2012, 12:47:01 AM
Is there any way to get a dump of that symbol and try to work out where in the source the issue lies? (I'd be quite happy to adjust the source if only I could find it! :)
There's the MS DUMPBIN utility: dumpbin /symbols <object_module>
I looked a bit closer to this issue - Masm also creates those $$$-symbols, and the number behind the "$$$" is the same as in jwasm. That number, btw, is the "procedure #", which starts at 1 and is incremented with every new procedure.
btw, I updated the v2.09 jwasm and fixed a "minor" problem with those symbols becoming public. It's not that much probable that the error you got will disappear, but still might be worth a try.
Here's the DUMPBIN tool in action:
COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
aaa4.asm
002 00000000 SECT1 notype Static | .text
Section length 1, #relocs 0, #linenums 2, checksum 0
004 00000000 SECT2 notype Static | .data
Section length 0, #relocs 0, #linenums 0, checksum 0
006 00000000 SECT3 notype Static | .drectve
Section length D, #relocs 0, #linenums 0, checksum 0
008 00000000 SECT1 notype () Static | _$$$00001@0
tag index 0000000A size 00000001 lines 0000008D next function 00000000
00A 00000000 SECT1 notype BeginFunction | .bf
line# 0008 end 00000000
00C 00000002 SECT1 notype .bf or.ef | .lf
00D 00000001 SECT1 notype EndFunction | .ef
line# 0008
00F 00000000 SECT1 notype External | _start
the .bf, .lf and .ef entries are COFF line number infos ( and will only be seen if the source is assembled with -Zd or -Zi ). All _$$$ symbols found in the list should be marked as "static".
and the source was:
.686
.model flat,stdcall
option casemap :none
.code
start:
ret
end start
Ok, well I had the earlier 2.09 which still caused the issue, I just downloaded the latest 2.09 pre now and tried again. The problem seems to have gone away! Assembled and Linked with both ML and JWASM. Awesome :)
OPTION PROC:PRIVATE
Seems MASM wants the procedure defined BEFORE it's actually used.
For example, this pseudocode generates Main1 and Main2 as "Public"
Main
Main1{}
Main2{}
Main1 PROC
...
Main2 PROC
...
However, rearranging the functions like this defines Main1 and Main2 as "Private"
Main1 PROC
...
Main2 PROC
...
Main
Main1{}
Main2{}
Thanks.
it's not a matter of public or private
it's a matter of forward or reverse referencing a symbol
this behavior changes a little, so it's hard to say when the assembler will not recognize a forward symbol - lol
generally, if i call a routine, it's ok - if i invoke it, it doesn't work so well
if you want to be sure, use a PROTOtype...
INCLUDE \masm32\include\masm32rt.inc
MyFunc PROTO
.CODE
main PROC
call MyFunc
inkey
exit
main ENDP
MyFunc PROC
print chr$('Hello'),13,10
ret
MyFunc ENDP
END main