1. I actually must write "dword" in order for the code to assemble at all.
2. There's an unnecessary operand size prefix generated for short (rel8) jumps.
3. It would be nice to be able to generate jmp/jcc rel16 instead of jmp/jcc rel32 when assembling 16-bit code into an ELF file. Perhaps, fixing this part alone would fix the two problems above.
Can this be fixed at least for relative jumps (and calls?) within the same assembly file? (This would not require supporting 16-bit relocations in the ELF format)
What this would give me is the ability to use FASM for compiling 16-bit-ish code with my C compiler in addition to NASM and YASM. When I say 16-bit-ish, I mean code for unreal mode. I can patch up the code in the linker to create far calls and the rest can work as-is.
1. Because the address pointer is greater than 64k
Not quite. The top 16 bits of EIP are ignored in (un)real mode. For relative jumps you only care about the distance fitting into 8 or 16/32 bits.
2. It is necessary because you need to convert the address to 32-bit
Only if this address ends up in the relocation table, which is not the case for jumps within the same section of the same assembly file.
3. You can, but you need to keep the address pointer below 64k
I don't need to do much special about it. As I said above, the E part of EIP is ignored in the CPU. All the functions produced by my compiler will be far-callable and limited to 64KB in size. I can always make their far address to have the offset less than 16 (I do it already for "huge" mode with NASM/YASM).
Why are you using ELF format?
I don't want to support many formats. ELF is perfectly suitable for what I'm doing.
ELF has no support for 16-bit code so you are using it out of its normal usage. In short don't do that.
Not quite so. Relative branches, at least the rel8 kind within the same section of the same assembly file, should just work and assemble without unnecessary "dword" or operand size prefixes. rel32 is excessive here, but it works too, however the "dword" requirement is extremely inconvenient. Not requiring "dword" would solve the biggest problem of the code simply not assembling. I can probably live with overly long instructions.
Joined: 16 Jun 2003
Location: Kraków, Poland
Not quite so. Relative branches, at least the rel8 kind within the same section of the same assembly file, should just work and assemble without unnecessary "dword" or operand size prefixes.
Not when the address is known to be 32-bit and potentially outside of 16-bit range. When you are using the ELF format, the base address for your section (the one that you can alter with ORG) is a 32-bit relocatable value, so the instructions are assembled to allow for this address to be a (potentially large) 32-bit number. This is the natural consequence of using the ELF format, revolution rightly pointed out that this really is not the right format to hold the 16-bit code.
If you need to assemble the code under a different assumption, you have to alter the base address so that assembler knows that it is not going to be a large value. For example:
Of course, when you make your base address a non-relocatable value, the assembler is not going to create any relocations for that code - but you stated that you don't need that.
Also, the "main" symbol defined this way is going to be exported as an absolute number (because we made it an absolute number). If you need to export it as an address in relocatable section, you have to modify it like this:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum