Hi
Do you know why it happens ?
Hutch, where is the problem ?
I have a lot of LOCAL IndexLst but i dont get any error message.
Why ?
If it is LOCAL it is valid only inside that particular proc ( should be !).
So, what is the problem or where is it ?
Thanks :t
Quote
Microsoft (R) Macro Assembler Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: C:\calcula_78\Calcula68.asm
***********
ASCII build
***********
C:\calcula_78\Rcl05.inc(891) : error A2005:symbol redefinition : AuxBuffer
_
Assembly Error
Prima qualquer tecla para continuar . . .
«««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
AnalyseSymbolicSingleType proc pRclStr:DWORD, pVarType:DWORD
LOCAL AuxBuffer[$TOTALofSTACKBUFFER128]:BYTE <<<<<<- line 891 <<<<<<<<
LOCAL IndexLst:DWORD, IndexFirst:DWORD
push ecx
push esi
push edi
;-------------------------------------------
; AuxBuffer
;-------------------------------------------
ALIGNLOCALPOINTERedi AuxBuffer, $LENofSTACKBUFFER128
; ALIGNLOCALPOINTERedi is a macro to align the address in edi by 16
...
_exit: pop edi
pop esi
pop ecx
ret
AnalyseSymbolicSingleType endp
«««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
Check for a global variable with the same name.include \masm32\include\masm32rt.inc
.data
AuxBufferG db 1000 dup(?) ; call it AuxBufferG, and it's OK
.code
MyTest1 proc
Local AuxBuffer[80]:BYTE ; no problem ...
ret
MyTest1 endp
MyTest2 proc
Local AuxBuffer[80]:BYTE ; ... to use it locally ...
ret
MyTest2 endp
HelloWorld macro
LOCAL AuxBuffer ; ... or in a macro
AuxBuffer=1
print "hello world"
ENDM
start:
HelloWorld
exit
end start
Change "AuxBuffer" to "Aux_Buffer" and see if it makes any difference. If not the problem is elsewhere.
Quote from: hutch-- on November 23, 2016, 12:59:07 PM
Change "AuxBuffer" to "Aux_Buffer" and see if it makes any difference. If not the problem is elsewhere.
Hi
Hutch, thanks
Yes if i change the name it works correctly. But my problem is to understand why it happens.
And
Jochen gave the correct answer.
note: i dont like aaa_bbb names. Unfortunately i violated my own rules about names of labels and i got
this problem or i found out the bug.
See you :t
:icon14:
Quote from: jj2007 on November 23, 2016, 11:55:48 AM
Check for a global variable with the same name.include \masm32\include\masm32rt.inc
.data
AuxBufferG db 1000 dup(?) ; call it AuxBufferG, and it's OK
.code
MyTest1 proc
Local AuxBuffer[80]:BYTE ; no problem ...
ret
MyTest1 endp
MyTest2 proc
Local AuxBuffer[80]:BYTE ; ... to use it locally ...
ret
MyTest2 endp
HelloWorld macro
LOCAL AuxBuffer ; ... or in a macro
AuxBuffer=1
print "hello world"
ENDM
start:
HelloWorld
exit
end start
Hi
Jochen, yes i have
a global with the same name and it is the bug.
My own rule to write labels is to
start with underscore: _AuxBuffer, etc.
But
inside macros or LOCAL variables i
dont use underscore: AuxBuffer.
Unfortunately i violate that rule and i found out the bug.
Thanks Jochen
See you :t
You are welcome :icon14:
You get used to these problems with both assemblers and compilers. Having used a BASIC compiler for some of my work for years, this particular one is case insensitive and as such uses a large number of reserve words so one of the first things you do is change the variable name to see if that is the problem. Generally MASM in either 32 or 64 bit has less than helpful error messages (screens of chyte streaming past) so you learn a few tricks around it, one is the keep track of your naming system for variables.
Glad you solved the problem.
Quote from: jj2007 on November 24, 2016, 07:55:36 AM
You are welcome :icon14:
Very nice to see you here
Jochen :t
:icon14:
By the way, the answer to my question is: YES it is ! :biggrin:
And so, i was righ when i established that set of rules many years agoto write labels in assembly: start with underscore if it is not inside macrosor it is not a LOCAL variable. It seems that it never fails.
Quote from: hutch-- on November 24, 2016, 09:25:07 AM
You get used to these problems with both assemblers and compilers. Having used a BASIC compiler for some of my work for years, this particular one is case insensitive and as such uses a large number of reserve words so one of the first things you do is change the variable name to see if that is the problem. Generally MASM in either 32 or 64 bit has less than helpful error messages (screens of chyte streaming past) so you learn a few tricks around it, one is the keep track of your naming system for variables.
Glad you solved the problem.
Thanks and glad to see you here.
Yes i solved the problem and i understood it.
I want to say to you that i am writing assembly and
you are guilt for that. :biggrin: :biggrin:
Thanks for all, Hutch-- :t
Hi
I am thinking now that my question may be not a bug. It seems that the macro assember
assumes that we cannot choose a local name equal to a global name (defined in .DATA or .DATA?).
Do you know the rules, Jochen ?
In any case think about the label "_exit" inside a procedure. We may write _exit in
all procedures because it is particular or LOCAL label: it is valid only inside that
procedure. Following this fact, any other label defined using the word LOCAL would be
considered as a local, so an exception to the general rule. But not, the macro assembler
refuse it.
That's all
Good luck :t
note: i have another case where the defined LOCAL variables dont work
correctly. When the procedure is called it closes the program (TheCalculator) before starting
my first instruction push ebx, etc. I replaced only all locals Name[nbytes]:BYTE
by global names defined in .DATA? and all works correctly. By the way, i replaced
also by local names defined by me using this schema (it works correctly):
ProcA proc ; prolog and epilog none
push ebp
sub esp, lenstackbuffer
mov ebp, esp
; now push ebx, esi, edi, ,,,
...
; now pop ...,edi, esi, ebx
add esp, lenstackbuffer
pop ebp
ret 4*N
ProcA endp
stk0_varA = 0 ; here i use names aaa_bbb !!! :biggrin: :biggrin:
stk0_varB = stak0_varA + lenofA
...
stk0_varK = stk0_varK-1 + lenofK-1
where the adresses are defined by
lea esi, [ebp+stk0_varK] (this is an example).