[fpc-devel] Questions regarding m68k-atari target

[Karoly Balogh]

Hi,

On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:

> Yes, but i never used that "brown" tool. For one, i don't like its
> confusing naming convention (depending on gcc version, it is "brown",
> "extrabrown", "superbrown" etc). But more importantly, it needs an extra
> tool to be run after linking, which requires Makefiles to be changed for
> all projects that use it. That rules out most unix packages, where the
> Makefiles are generated by autoconf, Cmake or similar. Also the whole
> toolchain requires a script to be run on the mintlib (atari c-library)
> headers, which fails almost everytime something in mintlib changes. And
> they did not even manage to provide a gem library, or even a math
> library.

I don't have experience with it actually, I just know it's existence, so
your criticism is probably valid. I know it's somehow a demoscene-hacker
related project, which explains the silly naming... ;) People sometimes
indeed get too creative.

Calling an extra tool isn't an issue for FPC as the compiler knows how to
invoke various tools per platforms. We don't rely on Makefiles.

BTW, I've seen AROS solve the same problem (need to call another tool
after LD) by providing a really thin LD frontend, which just passed all
arguments to LD in the background, then calling the extra tool if the
linking succeeded. (In fact I think the postprocessing tool is the LD
frontend itself, I think.) Then no Makefiles need to be modified, and
postprocessing the linker output still works. So there's that solution.

> For fpc that would mean however you have to tell it somehow that it can
> use elf features like sections, even when using gas. I will give it a
> try at the weekend, i think fpc can be tricked by using -Avasm, but then
> replacing the symlinks to the assembler.

Changing these kind of things are one-or-two line changes inside FPC
actually. You're just facing how the defaults are wired.

The vasm assembler output is indeed quite compatible with GAS, inside FPC
vasm support is actually just a thin layer over the GNU assembler writer
(again, changing some defaults mostly), and we use vasm's "GNU as
compatibility mode" (-gas argument).

> If all else fails, i'm of course also ok with using vasm/vlink. There is
> only the problem of the too long filename of the assembler executable.
> That should be fixed i think, because it is also needed when running the
> *.ttp on TOS. And of course i have to find out what causes vlink to put
> that strange program flags in the header.

I'm sure this used to work, by naming the asm executable just "vasm.prg"
and the linker "vlink.prg". Or something. It was too long ago. I think
I'll just test under Hatari later today,  and see what happens. I'm sure
it would just need some minor fixes, if anything.

Cheers,
--
Charlie