cr0 ? Sometimes used to check for floating point emulation on dos.coderJeff wrote:
dl, di, si, cl, bl, al, bp, sp, dx, cx, bx, ax, edx, edi, esi, ecx, ebx, eax, ebp, esp, st, cs, ds, es, fs, gs, ss, mm0, mm1, mm2, mm3, mm4, mm5, mm6, mm7, xmm0, xmm1, xmm2, xmm3, xmm4, xmm5, xmm6, xmm7, xmm8, xmm9, xmm10, xmm11, xmm12, xmm13, xmm14, xmm15, word, dword, qword, fword, mmword, oword, r8, r9, r10, r11, r12, r13, r14, r15, r8w, r9w, r10w, r11w, r12w, r13w, r14w, r15w, rax, rbp, rbx, rcx, rdi, rdx, rsi, rsp, tbyte, xmmword, ymmword, zmmword, ah, axl, bh, bpl, bxl, ch, cxl, dh, dil, dr0, dr1, dr2, dr3, dr4, dr5, dr6, dr7, dxl, eip, eq, ge, gt, le, lt, ne, r8b, r9b, r10b, r11b, r12b, r13b, r14b, r15b, r8d, r9d, r10d, r11d, r12d, r13d, r14d, r15d, rip, sil, spl, ymm0, ymm1, ymm2, ymm3, ymm4, ymm5, ymm6, ymm7, ymm8, ymm9, ymm10, ymm11, ymm12, ymm13, ymm14, ymm15, zmm0, zmm1, zmm2, zmm3, zmm4, zmm5, zmm6, zmm7, zmm8, zmm9, zmm10, zmm11, zmm12, zmm13, zmm14, zmm15, zmm16, zmm17, zmm18, zmm19, zmm20, zmm21, zmm22, zmm23, zmm24, zmm25, zmm26, zmm27, zmm28, zmm29, zmm30, zmm31
'#pragma reserve' statement to reserve backend keywords
Re: '#pragma reserve' statement to reserve backend keywords
Re: '#pragma reserve' statement to reserve backend keywords
Commit [92a904]:
I don't understand the result (not duplicated) logic for this one couple:
while '(extern)' is equivalent to '(asm, extern)' or '(extern, asm)', see commit [92a904],
and therefore must be duplicated as for:or for:
It is as if '(extern)' induces only extern and not asm too.
In the second example (for x86_64) of the #PRAGMA RESERVE documentation page, if I replace:
#pragma reserve(asm) xyz
with:
#pragma reserve (extern) xyz
I see that fbc emits to the backend compiler a decorated 'xyz' symbol (XYZ$) in the inserted ASM block.
Therefore '#pragma reserve (extern) symbol' does not add 'symbol' to the list of reserved words for the inline assembler.
Duplication test for all possible couples of statements '#pragma reserve ...':
fbc: '#pragma reserve (extern) symbol' reserves global asm symbols
- sf.net #515: show a warning if a public sub or a shared variable have the same name as global asm keywords (x86 and x86_64 only)
- can also use '#pragma reserve (asm,extern)' where 'asm' is for inline asm in ASM blocks and extern is for public symbols
Code: Select all
#pragma reserve symbol0
#pragma reserve (asm) symbol0 '' OK
#pragma reserve symbol1
#pragma reserve (extern) symbol1 '' OK
#pragma reserve symbol2
#pragma reserve (asm, extern) symbol2 '' OK
#pragma reserve symbol3
#pragma reserve (extern, asm) symbol3 '' OK
#pragma reserve (asm) symbol4
#pragma reserve (extern) symbol4 '' OK ???
#pragma reserve (asm) symbol5
#pragma reserve (asm, extern) symbol5 '' duplicated
#pragma reserve (asm) symbol6
#pragma reserve (extern, asm) symbol6 '' duplicated
#pragma reserve (extern) symbol7
#pragma reserve (asm, extern) symbol7 '' duplicated
#pragma reserve (extern) symbol8
#pragma reserve (extern, asm) symbol8 '' duplicated
#pragma reserve (extern, asm) symbol9
#pragma reserve (asm, extern) symbol9 '' duplicated
Code: Select all
#pragma reserve (asm) symbol4
#pragma reserve (extern) symbol4 '' OK ???
and therefore must be duplicated as for:
Code: Select all
#pragma reserve (asm) symbol5
#pragma reserve (asm, extern) symbol5 '' duplicated
Code: Select all
#pragma reserve (asm) symbol6
#pragma reserve (extern, asm) symbol6 '' duplicated
In the second example (for x86_64) of the #PRAGMA RESERVE documentation page, if I replace:
#pragma reserve(asm) xyz
with:
#pragma reserve (extern) xyz
I see that fbc emits to the backend compiler a decorated 'xyz' symbol (XYZ$) in the inserted ASM block.
Therefore '#pragma reserve (extern) symbol' does not add 'symbol' to the list of reserved words for the inline assembler.
Re: '#pragma reserve' statement to reserve backend keywords
You got it.fxm wrote:Therefore '#pragma reserve (extern) symbol' does not add 'symbol' to the list of reserved words for the inline assembler.
#pragma reserve (asm) symbol
- shared variables and module level procedures named 'symbol' are OK
- but if 'symbol' is used in an ASM block, don't replace it with any expression, just pass it to the assembler as is
#pragma reserve (extern) symbol
- shared variables and module level procedures named 'symbol' are NOT OK and could interfere with the backend (gcc/gas/etc)
- show a warning
#pragma reserve (asm,extern) symbol
#pragma reserve (extern,asm) symbol
- do both
- don't replace with expression in any ASM block
- show a warning if used as shared variable or module level procedure
Example 1: #pragma reserve (asm)
Code: Select all
#pragma reserve (asm) cqo
'' shared variable is OK
dim shared cqo as integer
sub proc naked()
asm
'' but don't replace 'cqo' if used in an ASM block
cqo
ret
end asm
end sub
- Warning for use of backend symbol
Code: Select all
#cmdline "-gen gcc"
#cmdline "-restart"
#pragma reserve (extern) typedef
sub typedef alias "typedef"
end sub
- this example probably only applicable to DOS, as marcov suggests. I didn't test. And causes illegal instruction on win32. But it did compile.
Code: Select all
#pragma reserve (asm,extern) cr0
'' warn if cr0 is used as global (extern is reserved)
'' or this can cause bad code generation in the backend
dim shared cr0 as ulong
scope
'' use of cr0 in local scope is OK - it gets a private unique name in assembly
dim cr0 as ulong
dim tmp as ulong
'' don't confuse asm's cr0 with our local cr0 variable (asm is reserved)
asm
mov eax, cr0 '' <-- passed to assembler as-is
mov [tmp], eax
end asm
print bin( tmp, 64 )
end scope
Re: '#pragma reserve' statement to reserve backend keywords
Ok, I will update the documentation accordingly.coderJeff wrote:You got it.fxm wrote:Therefore '#pragma reserve (extern) symbol' does not add 'symbol' to the list of reserved words for the inline assembler.
[edit]
Done:
- KeyPgPpPragmaReserve → fxm [update]
Last edited by fxm on Oct 30, 2021 11:47, edited 2 times in total.
Reason: Update.
Reason: Update.
Re: '#pragma reserve' statement to reserve backend keywords
You will have to update 'changelog.txt':
- fbc: '#pragma reserve (extern) symbol' reserves globalasmsymbols. fbc shows a warning if a reserved symbol is used for a public sub or shared variable in the global namespace
Re: '#pragma reserve' statement to reserve backend keywords
Jeff,
I thought there would be no warning for the case where the symbol ('test2') is used as the name of a private procedure?
Code: Select all
#pragma reserve (extern) test1
#pragma reserve (extern) test2
Sub test1() '' warning: Use of reserved global or backend symbol, test1 => OK
End Sub
test1()
Private Sub test2() '' warning: Use of reserved global or backend symbol, test2 => NOK
End Sub
test2()
Re: '#pragma reserve' statement to reserve backend keywords
Even though it is private, the internal name mangling could still be 'TEST2', so it is still potentially exposed to the backend compiler - gas/gcc/etc.fxm wrote:I thought there would be no warning for the case where the symbol ('test2') is used as the name of a private procedure?
Depends on target and calling convention:
- win 32-bit stdcall results in the symbol as '_TEST2@0' emitted to the backend.
- win 32-bit cdecl results in the symbol as '_TEST2' emitted to the backend.
- other targets / 64-bit results in the symbol as 'TEST2' emitted to the backend.
Not sure how precise we should be with this feature depending on target. If cross compilation compatibility is a goal, where we'd like to avoid some source working on one target but crashing on another, seems like the implementation is OK.
Related: '#pragma reserve ([asm][,extern]) symbol' is also case insensitive.
FYI, I didn't do much testing with COMMON/EXTERN/STATIC statements, or ALIAS clause.
Re: '#pragma reserve' statement to reserve backend keywords
So 'changelog.txt' to update ?
.....
- fbc: '#pragma reserve (extern) symbol' reserves global symbols. fbc shows a warning if a reserved symbol is used for apublicsub or shared variable in the global namespace
.....
- sf.net #515: fbc: show a warning if apublicsub or a shared variable have the same name as global asm keywords (x86 and x86_64 only)
.....
Re: '#pragma reserve' statement to reserve backend keywords
Ah, my bad. Yes, probably 'module level' would be closest?fxm wrote:So 'changelog.txt' to update ?
To be honest, I'm still trying to sort it out. Under to hood, scope resolution is hard to follow:
- global namespace (or not)
- module level (or not)
- implicit main scope (or not)
- procedure scope (or not)
- explicit scope (or not)
- public export (or not)
Out of all the combinations (within the compiler), there's only about 5 or 6 valid ones that the user actually sees or would care about.
Re: '#pragma reserve' statement to reserve backend keywords
Yes for 'coderJeff wrote:... probably 'module level' would be closest?
Because 'public' associated with the word 'procedure' is confusing by thinking more to contrary of 'private', rather than 'global namespace' or 'global scope'.