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 marcov(R), 12.07.2014, 14:43

> > > > 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!

Despite one of the most longlived versions, it was doomed from the start. Basically with 1.0.6 core pretty much stopped workin on the 1.x branch, the differences between 1.0.6 are mostly critical fixes and user contributions.

I also used it of course, since by then trunk IDE was still unusable (though the compiler was better).

> 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:

People mostly work on the ELF targets yes. Afaik most of the formerly cygnus projects are under stewardship of RedHat. (gcc,gdb, probably also binutils)

Windows lags too, though not as bad as ten years ago, now it is mostly functional.

Afaik there is no functional GNU binutils for OS X. Only for the OSS version, Darwin, and that is a minority target. (probably held up by a few passionate users). Apple binutils (pre LLVM) were not based on GNU, but own development on top of early 90's BSD tools.

> DJGPP gets very little, if anything, from them.

That's POV. One might as well say DJGPP gives very little, if anything, to them, apparently.

> 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.)

I assume the few *nix COFF targets have retired by now, or is that a console game binary format?

> 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.

Such things might be a problem with djgpp-fpc combined linking. But I hope the internal linker will long term fix a lot of the small hurts, as well as that the linker is automatically available on each target.

> > 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.

I meant vs windows where the number of symbols quickly goes through the roof due to the windows headers.

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

It was, but not in all scenarios.

> > 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?

Not really a official, fixed policy. Currently I'm release manager, and I usually wait till Linux,Windows and OS X are uploaded and confirmed working by a few users/devels.

If OS X is hit by a major version transition it sometimes uploaded later(but usually more during the RC than the final release).

But usually FreeBSD (because I package it, and it rarely breaks because it is so similar to Linux and has a handful of users) and OS/2 (Tomas) are quick too.

Dos is also quite often slow to upload with the Release candidate, but typically done by Tomas or Pierre as a matter of routine for the final release. Dos (I should say go32v2 now, to avoid future ambiguity with "msdos" which is the 16-bit target) is however quite often hit by last minute changes and repackages. More than any of the other targets.

Note that linux means a .tar.gz, and not the distribution formats (.deb, .rpm) in recent times those are *always* late.

> > 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.

Hmm. As you know I'm no binary size maniac, but even that is a bit simplistic. DPMI has tighter limits than Linux, and Linux/ELF _got_ section smartlinking

> 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.

Yes. A big difference. We are in the same boat.

> > 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.

A library programmer can't be responsible for a target not holding up its own belt and not implementing features to actually reduce footprint. In real bad cases you might convince him to do a workaround, but for the little amounts it's simply "too bad, fix your target!".

> > 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

Wanted: restructure bootup code to pascal.

That means it an still contain asm, but handled by the compiler's internal assembler. That probably that needs binary format assembler pseudo instructions added to the compiler's internal assembler though.

Currently only Linux has this (has the most architectures).


Complete thread:

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