I would need to truncate the 32 bit pointer and use lowest part in the first, 16 bit section of code.
Now, I need to have PECOFF/ELF object file format with custom linking and custom further processing.

Is it possible to combine 16/32 bit code in such a manner for standard object files? Or what would be the best way to do it? Create 2 separate files, one is with 16 bit code, second with 32 bit and make some custom linking?
What are my options? Probably having several sections or something like that?

With fasm you can combine code with different bitness in any object format, but you need to find a way to switch the OS to a mode for running the code.

In general for raw hardware.
(Redesigning my old hobby os. Previously I used raw binary output - no problem with mixing code whatsoever. Now I'm going to compile it as object files to include code from other languages, hence I need to output an object file that would be later linked with other object files and then using objconv or something similar to produce raw binary again).

You will need some sort of call gate to switch execution modes. That part will be OS dependant.

For data accesses you can just access them normally in either mode.

You can setup your segment registers for each mode to overlap each other if that makes sense in your code. Or you can separate them entirely. For example you could put all your 16-bit code at <1MB and all the 32-bit code at >=1MB. It just depends upon your requirements for the OS and tasks it is performing.

You will need some sort of call gate to switch execution modes. That part will be OS dependant.

For data accesses you can just access them normally in either mode.

You can setup your segment registers for each mode to overlap each other if that makes sense in your code. Or you can separate them entirely. For example you could put all your 16-bit code at <1MB and all the 32-bit code at >=1MB. It just depends upon your requirements for the OS and tasks it is performing.

This is absolutely unrelated and redundant. I am aware about CPU modes and memory models (after all, I have working hobby OS); my question is entirely about object file format and output of FASM.

Probably it needs some rephrasing. I mean - you can set two sections in the one and same object file, whereas one section is 16 bit, another is 32 bit? And I should be able to reference (I mean in assembly) one section from another? But mapping of sections in memory can be different :-/ Will then cross-section references be resolved by linker, if sections are of different "bitness"?

Well sorry, I don't know what you have done, I was just trying to cover the bases here.

The thing to realise is that there is no object file format that defines anything to do with mixing bitness. Like I mentioned you will have to create your own.

Fasm can assemble code in any way you want, but the output format will have to be your design. You can enclose your code in ELF or PE if you wish to, but the format itself doesn't support any notion of defining different parts as having different bitness. That will be entirely on your decision as to how to mark each section for its associated bitness.

I think the simplest is to build the full 32-bit (or 16-bit) part and include it as a binary blob in the other, 16-bit (or 32-bit) part. Or simply concatenate the two parts. There isn't much connection between the two parts anyway (or you can minimize those).

I recall that OMF format should be able to contain both 16-bit and 32-bit code segments. Unfortunately I never attempted to make OMF support for fasm, though I still consider it one of the things I may make with fasmg in future.

I think the simplest is to build the full 32-bit (or 16-bit) part and include it as a binary blob in the other, 16-bit (or 32-bit) part. Or simply concatenate the two parts. There isn't much connection between the two parts anyway (or you can minimize those).

I came to the same conclusion. Seems I need to concat two different parts.

One problem I have is that I'm referencing 32 bit part from the 16 bit world. Like some of GDT/IDT entries stored in the 16 bit part have some references to 32 bit code and so on

but the format itself doesn't support any notion of defining different parts as having different bitness. That will be entirely on your decision as to how to mark each section for its associated bitness.

That's for sure. I could just switch FASM modes using use16/use32 on demand within one section.
Referencing points in the use32 part from use16 part is problematic. Say, I need offset of label in use32 portion, but in 16 bit notation (truncated).

Referencing points in the use32 part from use16 part is problematic. Say, I need offset of label in use32 portion, but in 16 bit notation (truncated).

Truncate won't work. I suggest to create a 32 bit output format, and in the 16 bit code sections you must use a translate table (or calculate the address in run time). All 32 bit labels must be translated into a 16 bit segment+offset pair to point to the same address in memory (up to limit of the 16 bit addressable address space of course).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum