Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

FREE Basic & Pascal (Developers)

posted by Rugxulo(R) Homepage, Usono, 12.07.2014, 04:38

> > > Last but not least, I assume LD got an update somewhere along the way.
> >
> > Nope, FPC 2.6.2 GO32V2 is still using old 2.17 from 2008,
> Laaca was comparing with FPC 1.0.10 which is from 2003.

1.0.10? Verboden!

I don't know if much has majorly changed since then (2.8??) and now (2.17). I honestly don't think it would make a difference at all!

I do know that Juan increased / fixed the max reloc limit circa 2.22-ish, and latest is 2.24r2. DJ is still COFF maintainer for us, but I don't know if he's done any "major" work on it in a billion years.

It seems that GNU (BinUtils, GCC) mostly only care for ELF with partial concern for other (tier two) platforms (Mac OS X: Mach-O, Windows: PE/COFF). DJGPP gets very little, if anything, from them. Even online LD changelog doesn't say "DJGPP" at all anywhere. Plus, MIPS ECOFF was removed in 2.24. (Similarly, GCC dropped "generic COFF" back in 4.5.x days, IIRC.)

BTW, I remember saying FPC didn't work with 2.19, but obviously nobody (nor I) ever fixed that nor delved deeper. So FPC may not work with newer ones. Ironically, I think the only impetus to upgrade BinUtils for DJGPP is probably the opposite: newer GCCs won't work with older ones.

> True, but since Go32v2 (and I assume DJGPP) programs are smaller, you can
> go the "generate one assembler file per symbol, and then AR them together"
> way.

I don't know if FPC GO32V1 is smaller output than FPC GO32V2.

DJGPP v1 was smaller than v2 because it had a separate GO32.EXE extender as well as lesser support (no LFNs, no symlinks, less POSIX, etc).

> FPC 1.x did that, and yes it is a bit slow, but not that bad on Go32v2.

Untested, but I still assume old FPC 1.x is faster just by virtue of doing less.

> FPC 1.9 and higher did the AS and AR step internally for (our) TIER 1 minus
> OS X.

What is FPC tier one? Linux + Windows on i386 or AMD64?

> Wrong. It happened because nobody created proper section smartlinking for
> those binary targets.

32-bit flat memory model (and virtual memory) implied that everything was practically "unlimited". So nobody cared about a few more megabytes. Besides, AFAIK, DJGPP was never commercially funded. It's always been very few volunteers. So the urge was even less, even back when Win9x was ubiquitous.

> A library programmer can't be required to assume responsibility for each
> and every dead or sleeping target because he wants to change a couple of
> lines. One might as well cease development of the library code.

First priority is just to get it working. But to imply that one isn't responsible for one's own code footprint is a bit naive. Just because nobody cares or takes initiative doesn't mean it's not worth doing.

> That being said we try to avoid making global decisions on FPC without
> testing them on both windows, OS X and Linux. This to avoid unixisms
> creeping in.
> Note that the internal linker should make it easier to create snapshots on
> non-dos, though probably still an AS is needed for the startup code. (but
> caching that near immutable file and replacing it with an dummy AS might
> work)

"Wanted: AS for bootup" :-P


Complete thread:

Back to the forum
Board view  Mix view
15111 Postings in 1359 Threads, 247 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum