I'm creating an interpreter for a new programming language, and one of my main goals is portability.

The main download page says this about the FASM package for Unix/libc:



Does this mean that you can compile an FASM program to an object file (traditionally tagged filename.o) which can be linked by (for example) GCC?

In other words, could the same FASM code be used to create an object file that would successfully link on Windows, Mac OS X, and Linux? These are my three initial target platforms.

GCC can handle ELF, and i think it compiles for all three (but never tried it with Mac OS X). But implementation of libc can differ a bit, you might still need some tiny libc wrapper in some cases.

[content deleted]

Almost every compiler (except FASM, NASM and YASM) builds executables in two steps. First step is to build object file (there are various formats, mostly MS-COFF on windows and ELF on linux). Object files are intermediates, where code is compiled, but absolute addresses are not yet set. Second step is linking (with "linker"), which can link several such objects together, relocate addresses to final values, and build the final executable.

Main advantage of this approach is that it allows you to break your source into several modules (object files), so you don't have to always recompile everything, only the module you changed. You'd see this advantage if you would made some bigger project. Of course, there are other advantages.


I suggested using GCC just for linking, not compiling. You compile code to ELF object in FASM, and then link it to different executables for various OSes, using GCC.

Yes, absolutely.

[content deleted]

When you want to write portable ELF file, you must use interface that is present on all OSes. Of course 0x80 isn't. Such interface is libc - Standard C Library. That is present everywhere, with quite minor differences (but still there are some).

Anyway, using same ELF file to build for different OSes is *not* what it was intended for, and it only works to some extent, because existing implementations of C library are pretty similar at binary level. (C library is only defined on C source code level, and can be implemented in any way on binary level)

So - you don't use int 0x80. You use libc. For example you declare "printf" as external symbol, and then "call printf". Linker will relocate the address to actual address of actual printf function. For practical example of using libc, get libc version of FASM and study system.inc, for example.


object file references all stuff through names, not addresses. For example if you have "mov [var123], 100", object file doesn't generate any address. In object file you only have information that this instruction refers to symbol named "var123". This symbol can lie in same object file, or in another object file. During linking, all objects are pasted together, and address in this instruction is overwritten by actual address (RVA actually) of symbol "var123".

Also every object can have various sections, usually data and code. When linking, all data sections are merged into one big data section, and all code sections are merged into one big code sections. This is still one of problems of FASMers who use direct compilation to .EXE, but want to divide source into modules: they have to wrap data definitions in macros like "idata", to have them all collected in one place.

[content deleted]

I would think this would answer it:


This can run into problems... end up with multible versions - run into compatibility problems ... ect..



The user can still do this? but create there own funtions.. Then the OS Devel.. has the options to add to the lib or leave it out.. if not the os devel has no control over what is added or removed...

even in C you can create your own printf if you dont want to use the one provided..

1. You don't need to always recompile every entire code for executable, just the changed part. This saves considerable amount of time on useless recompilation.
2. You can distribute static libraries (eg. not dynamic, in separate file, like DLLs) without giving away their code, and/or without need for people to study and always recompile their code.
3. It offers good and time-tested platform for breaking code into multiple more/less independent modules, unlike using FASM to compile directly to executable.
4. It allows you to mix code from various languages into same executable. Priceless if you want to use library written in other language than the one you are using.


In that case, "editing" would be a stupid way to do it, more sane would be way used by FASM for example. But anyway, that only solves one point - OS portability (original topic of this thread), which object files aren't even supposed to solve. Main reason for using object files is what i have written up.

Vid, what would you suggest as the best way to write cross-platform FASM?

Imagist,

Define "platform".

Common ground for every x86-32/64 linker in existence?

Depens... but generaly speaking, it would be:

- Platform-specific "bottom" layer to wrap system functions to interface common for all platforms
- Platform-specific top-level file (the one you compile, with "format" definitions etc)
- Rest can be portable, included from all top-level files. This code can only call OS through the wrapper functions.

This is a way that FASM itself uses too, btw