macro mycall reg,func
        {
        call func
        }

macro xyz num*
        {
        org 20000h
        mycall edi, f 
        }

use16
        xyz 0
main:   jmp main


f:      ret

    

flat assembler  version 1.64
2 passes, 6 bytes.
    

flat assembler  version 1.67.21  (15360 kilobytes memory)
test64\bug2.asm [14]:
        xyz 0
test64\bug2.asm [10] xyz [2]:
        mycall edi, f 
test64\bug2.asm [4] mycall [1]:
        call func
error: invalid value.

    

        org 20000h
        mycall edi, f 
        }
        use16 
    

jmp dword f    

Actually it's the opposite - it was the bug of earlier versions of fasm that was fixed recently. With "use16" your jump defaults to 16 bits, and "org 20000h" makes the addresses invalid for 16 bits. If you want to generate 32-bit jumps (with 66h prefix), you need to do it like:

Code:

jmp dword f    

Code:

        org 20000h
        mycall edi, f 
        }
        use16 
    

I don't think this can work. use16 limits code addressing and
org to 64 KB.

also I cannot change it via redefining the jmps as that
will interfere with the 64 bit code

NTOSKRNL_VXE wrote:

Code:

        org 20000h
        mycall edi, f 
        }
        use16 
    

I don't think this can work. use16 limits code addressing and
org to 64 KB.

"call f"

can have only 1 possible meaning, so fasm should really
disambiguate automatically as there is a clear
disambiguation,

I have literally hundreds of jmp and loop statements in
my 32 bit code,

I either have to do that via earlier versions of fasm or
go through endless code changing to dword,

as it would clear the upper 16 bits of EIP.

"jmp label" and "jmp dword label" are both relative so there is no problem. In fact FASM still encodes with rel8 if possible, it only adds the prefix to the instruction. I still can't find the thread but if I remember right the problem is that without the prefix the CPU does "IP = IP + rel" but since the address doesn't fit in 16 bits there is situations where it will not work and for that you need "EIP = EIP + rel" which is done by the address size override prefix.

Quote:

also I cannot change it via redefining the jmps as that
will interfere with the 64 bit code

purge the macros when you reach 64-bit code. Sure that the code without address size override worked good? There was some situations where it worked bad but I can't find the damn thread.

Quote:

also I cannot change it via redefining the jmps as that
will interfere with the 64 bit code

purge the macros when you reach 64-bit code. Sure that the code without address size override worked good? There was some situations where it worked bad but I can't find the damn thread.

That jump would be impossible to encode with rel8/rel16, you have no choice other than rel32 but that is a different problem that the one Tomasz says. Suppose you want to jump from $10000 to $10100, then the calculus would be "$10000 + $100 = $10100", BUT since we are not using the adress size override this will happens: "($10000 + $100) AND $FFFF = $100". $100 obviously is not the expected target so here is of mandatory use the address size override.

db $66
ret    

LocoDelAssembly: just RETD mnemonic is enough (see manual's section 2.1.6). As for the experiments, I made them too (also in long mode), when I realized there was a mentioned bug - and I recall it is documented by both Intel and AMD manuals.