How correctly to write down command a kind in TASM "jmp dword ptr [offset label1+reg1+reg2*8]"? FASM 1.66 gives out a mistake "illegal instruction" on command "jmp dword [label1++reg1+reg2*8]".

Try jmp near dword [label+reg+reg*8]

Thanks, it works. But I have faced one more problem - in a 32-bit mode all is compiled wonderfully, and in x64-86 - is not present. Again returns a mistake "illegal size of address value". I use this source:

Code:

jmp near qword [Proc_Addr_Table+rax+rsi*8] ;------------------------------------------------------------------------------ Proc_Addr_Table:         dq Addr1         dq Addr2

Where is a bug? May be x64-86 mode does not support this command? Or this is mistake of the compiler?

Code:

format PE64 GUI         jmp qword [Proc_Addr_Table+rax+rsi*8] ;------------------------------------------------------------------------------  Proc_Addr_Table:          dq Addr1         dq Addr2 Addr1:         nop Addr2:         jmp $

Tells me "address sizes do not agree"

PS: Maybe AMD64 doesn't support 64-bit offset?

It does, of course It seems to be a bug in FASM. MASM 64 assembles it successfuly:

Code:

00000000  FF A4 F0                     jmp     qword ptr [Proc_Addr_Table+rax+rsi*8]            00000007 R  00000007                       Proc_Addr_Table:   00000007  0000000000000017 R           dq Addr1  0000000F  0000000000000018 R           dq Addr2  00000017                       Addr1:  00000017  90                           nop  00000018                       Addr2:  00000018  EB FE                        jmp $

This will work with absolute addressing only, there's no imm64+reg, nor RIP+imm32+reg addressing in AMD64 architecture which makes it impossible to generate such instruction with relocatable 64-bit addressing.

MazeGen:

Code:

jmp     qword ptr [Proc_Addr_Table+rax+rsi*8]

I use 'dumpbin' to example the coff64 object file generated by masm and found that, for the above instruction, it produced ADDR32 relocation. This is absolute 32-bit relocation which is feasible to use when the whole image lies below 2Gig of virtual memory.

fasm doesn't currently know such kind of relocations, sorry. It would need to have somehow specified that the resulting code can work only in low 2 GB, as it would affect encoding of other instructions aswell.
The 64-bit code generated by fasm is made to be position-independent.

Tomasz Grysztar wrote:

fasm doesn't currently know such kind of relocations, sorry. It would need to have somehow specified that the resulting code can work only in low 2 GB, as it would affect encoding of other instructions aswell. The 64-bit code generated by fasm is made to be position-independent.

Why not add some command line switch or directive to accompany "use64" and make it work like that, or is it such a bad idea?

Tomasz Grysztar wrote:

It would need to have somehow specified that the resulting code can work only in low 2 GB, as it would affect encoding of other instructions aswell.

Actually, m$ linker can do that, just use /base and /fixed switches. It also gives an error(or maybe warning) message if it's impossible to correctly resolve a ADDR32 relocation.

As I have understood, it is a problem on a straight line is connected with a mistake of the compiler and\or linker. Whether It is possible to hope, what in the future versions of FASM this situation somehow to change?

It's was intended and thoughtful behavior of assembler - I wanted to "promote" what in my opinion is a better way of using AMD64 architecture. Using 32-bit absolute addresses everywhere makes instructions larger ("xor al,[rip+0]" is smaller than "xor al,[dword 0]", and note that for "xor al,[dword 80000000h]" fasm even has to generate 67h prefix, to prevent the sign-extension), while using them selectivelly makes code unequable. You can force absolute addressing like in the above examples if you like - though it won't work with relocatable formats, as noted.
To make it work, there perhaps would be a solution to add some settings for relocatable formats, one to force generating code for low 2 GB, and maybe even one more for low 4 GB (with 67h prefix in such places).

I will try to invent some better solution, but as I would like the making of 2GB-limit-dependent code to be the aware choice of the programmer, and so perhaps leave the plain instruction of such type signalizing an error, it won't be so easy... Or should I depend on the linker/loader to warn the programmer?

It seems I myself did all the discussion I needed.
I will try adding support for such relocations as soon as I have some more time.

And perhaps at the same time I would finally add the FIXED option for the PE format, to replace those silly macros from the FAQ.

just an idea: isn't PE file without reloc section always "fixed"?

I recall there was some problem, because of which the fixed/relocatable cannot be changed "on-the-fly" during resolving. Some limitation of the current implementation... I will try to re-approach this problem, though.

On the other hand - some very old fasm versions were automatically generating fixups section at the end of executable if not told where to put it - I could bring it back while implementing FIXED option.

OK, it seems that because I forgot what were the problems, I managed to do it now and it appears to be working. Check out the 1.67.0 release - it supports the 32-bit relocations in 64-bit object format generated automatically by assembler in those situations when there's no other alternative (I decided I will rely on linker to warn the programmer about the code placing limitations, and thus fasm will obediently produce such instruction when told to, in case of object output). It also automatically switches the type of labels between fixed and relocatable depending on whether you include fixups data in PE, or not.

Both those solution require no additional switches and should (I hope) have no unwanted effects on the earlier-working sources. Please check it out carefully, though.

great, thanks. just wondering - how do you know whether there is or is not "fixups data"? one more pass, or prediction, or how?

Tomasz Grysztar wrote:

OK, it seems that because I forgot what were the problems, I managed to do it now and it appears to be working. Check out the 1.67.0 release - it supports the 32-bit relocations in 64-bit object............ Please check it out carefully, though.

I have kept a "Non 64 bit" version of FASM.., the 1.51 version of FASM... ?

Would it be usefull to add a "Non 64 bit" version of FASM in the main download page of flatassembler.net ????

For example, I can't download FASM 1.67 ( even if version 1.67 works surely very well ) because it contains too many "very complex" options (64 bit,macros,...)!!!!!!

vid wrote:

great, thanks. just wondering - how do you know whether there is or is not "fixups data"? one more pass, or prediction, or how?

Resolving as usual, the prediction is by default that there are no fixups, and if there were fixups in the previous pass, the prediction is that there are - simple.