I’m playing a bit with the delayed expansion for the HLL functions, but the FASTPASS creates some problems for testing.
There are a two errors on compiling (v2.08) without FASTPASS: OPATTR2 and PROLOG2.
I think i have found a solution for this:
voidDefineFlatGroup(void)/**************************/{if(ModuleInfo.flat_grp==NULL){/*can't fail because <FLAT> is a reserved word */ModuleInfo.flat_grp=CreateGroup("FLAT");ModuleInfo.flat_grp->sym.Ofssize=ModuleInfo.defOfssize;//ModuleInfo.flatgrp_idx=ModuleInfo.flat_grp->e.grpinfo->grp_idx;#ifdefFASTPASS}#else}else{ModuleInfo.flat_grp->sym.isdefined=TRUE;}#endif}voidProcInit(void)/*******************/{ProcStack=NULL;CurrProc=NULL;procidx=1;DefineProc=FALSE;#ifndefFASTPASSModuleInfo.prologuemode=PEM_DEFAULT;ModuleInfo.epiloguemode=PEM_DEFAULT;#endif/*v2.06:noforwardreferencesinINVOKEif-Zneisset*/ModuleInfo.invoke_exprparm=(Options.strict_masm_compat?EXPF_NOLCREATE:0);#ifAMD64_SUPPORTunw_segs_defined=0;#endif}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OPATTR2.ASM is included in the Regress subdir in JWASM’s source code. It test different usage of .TYPE, and the type FLAT fails if not defined:
;--- test .TYPE
.386
@what macro xx
dw .TYPE xx
endm
_TEXT segment use32 'CODE'
@what FLAT
_TEXT ends
end
This works in the first pass, but fails in the second because the ModuleInfo.flat_grp->sym.isdefined is cleared on init the second pass. When parsing start over, DefineFlatGroup(void) is called again, but fails to define FLAT.
The PROLOG2.ASM has the problem; works in pass one but fail in second pass:
;--- prologue generation
;--- first instruction after PROC contains a macro function!
.386
.model flat, stdcall
option casemap :none
@prologue macro procname,flag,parmbyte,localbyte,reglist,userparms
if flag
if parmbyte + localbyte
push ebp
movzx ebp,sp
endif
if localbyte
add esp,-localbyte
endif
endif
for r,reglist
push r
endm
exitm %localbyte
endm
CStr macro text
local x
.const
x db text,0
.code
exitm <offset x>
endm
.code
x1 proc a1:dword
ret
x1 endp
option prologue:@prologue
p1 proc uses ebx esi x:dword
ret
p1 endp
p2 proc uses ebx esi x:dword
invoke x1, CStr("abc")
ret
p2 endp
p3 proc uses ebx esi x:dword
.if ( eax == 1 )
.endif
ret
p3 endp
end
The problem with a delayed expansion of an <expression>is that it demands a rescan of the source code to work properly. This could be achieved with removing the FASTPASS code for testing.
The syntax of the while (<expression>) { <statement> }, <statement> is executed repeatedly as long as the value of <expression> remains non-zero. The test takes place before each execution of the <statement>. The implementation of this will be:
A delayed expansion of <expression> will demand (among other things) a reset of global counters (counter = counter + 1), so the rescan of the source code is ideal for testing.
Using FASTPASS and expand delayed code seems to mess up a few other things as well. When a function call is expanded, the last expanded line is repeated after <expanded expression>. A test to determine if this happened:
p = LineStoreCurr->line;
<expand expression>
if (p != LineStoreCurr->line)
LineStoreCurr->line[0] = ‘;’;
I see the FASTPASS code have been around for some time, so it is probably not a big priority to make it work without this. However, it could be a good thing (since it already there) to keep it for testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I’m playing a bit with the delayed expansion for the HLL functions, but the FASTPASS creates some problems for testing.
There are a two errors on compiling (v2.08) without FASTPASS: OPATTR2 and PROLOG2.
I think i have found a solution for this:
And now this fails:
Error A2141: Statement not allowed inside structure definition
> but the FASTPASS creates some problems for testing.
Perhaps you should explain what the problems are … in a bit more detail
> There are a two errors on compiling (v2.08) without FASTPASS: OPATTR2 and PROLOG2.
I have no idea what OPATTR2 and PROLOG2 are.
> I think i have found a solution for this:
Without knowing the problem I cannot judge your "solution".
OPATTR2.ASM is included in the Regress subdir in JWASM’s source code. It test different usage of .TYPE, and the type FLAT fails if not defined:
This works in the first pass, but fails in the second because the ModuleInfo.flat_grp->sym.isdefined is cleared on init the second pass. When parsing start over, DefineFlatGroup(void) is called again, but fails to define FLAT.
The PROLOG2.ASM has the problem; works in pass one but fail in second pass:
The problem with a delayed expansion of an <expression>is that it demands a rescan of the source code to work properly. This could be achieved with removing the FASTPASS code for testing.
The syntax of the while (<expression>) { <statement> }, <statement> is executed repeatedly as long as the value of <expression> remains non-zero. The test takes place before each execution of the <statement>. The implementation of this will be:
A delayed expansion of <expression> will demand (among other things) a reset of global counters (counter = counter + 1), so the rescan of the source code is ideal for testing.
Using FASTPASS and expand delayed code seems to mess up a few other things as well. When a function call is expanded, the last expanded line is repeated after <expanded expression>. A test to determine if this happened:
I see the FASTPASS code have been around for some time, so it is probably not a big priority to make it work without this. However, it could be a good thing (since it already there) to keep it for testing.
> This works in the first pass, but fails in the second because the ModuleInfo.flat_grp->sym.isdefined is cleared on init the second pass.
What does "fails" mean? I used the jwasm debug version ( which allows to disable FASTPASS with -d7) and cannot see any problem with FLAT.
Well,
could be written
if this should be tested with a debug switch.
But then you have to rewrite the runtest.cmd file to include the -d7 switch (maybe you have, I don't).
I was thinking of changing the
to
and then runtest.cmd.
> I used the jwasm debug version ( which allows to disable FASTPASS with -d7)
jwasm -bin type.asm
jwasm -d7 -bin type.asm
jwasm -bin prolog2.asm
jwasm -d7 -bin prolog2.asm
Ok, I see the FLAT problem now. This is kinda special case. Simplest "solution" probably is:
Masm and jwasm don't behave identically here, but I don't know if I like what Masm does:
After all, result 32 in .type means "defined", so why is there no "FLAT defined" message?
The GROUP DGROUP seems to work but FLAT behave different
> The GROUP DGROUP seems to work but FLAT behave different
Yes. DGROUP is just an automatically ( by the .MODEL directive ) generated symbol; FLAT is a reserved word, that exists from the very beginning.
Before I forget (and mess up your tracking system again ;-), I inserted this in the coff section:
Ok, I also checked the "prolog2" thing - your fix is correct and needed.
And the COFF .file value fix is now also the default. This entry might vanish in a later version - Masm v8 does not write this symbol anymore.