Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Updated utilities (Announce)

posted by marcov(R), 04.09.2019, 12:00

> Aha, I don't know FP internals and though that it use standard binutils
> like DJGPP.

Assembler is only used for odd ball architectures. GNU (G)AS is simply a slowing factor. So most major targets have direct .o generation from the compiler.

For the linker, binutils is the default if possible, though for some targets there is no functional one (e.g. 16-bit msdos, where it is openwatcom).

But if binutils are either too buggy, or too slow, or miss platform dependent features(like resources and various other PE tables, but historically it was dead code elimination related where every function was packed into a separate .o and all those .o's to a .a), also the linker gets built in.

This strangely includes targets you wouldn't expect like windows 64-bit, since FPC ran on windows 64-bit before gcc did, so there were no binutils at the time.

Afaik internal linkers in the upcoming fpc3.2 are for the dos targets (16-bit msdos, go32v2) and windows 32/64 targets as well as i386/arm-wince. win16 is still worked on in trunk, so probably won't make the release.

So, in summary basically everything for non *nix is internal, and even for *nix major ELF targets (x86/x86_64) the assembler is internal.

With the release of Debian Buster there is a new problem. 32-bit Linux changed calling conventions and now requires a 16-byte aligned stack, and the caller to align it. (LD 2.31 and above)

There is still a dependence on windres on 32-bits windows (but gorc is used for win64). Somebody works on an own resource compiler on and off, but that goes slowly.

 

Complete thread:

Back to the forum
Board view  Mix view
16031 Postings in 1485 Threads, 271 registered users, 6 users online (1 registered, 5 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum