Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

LLVM for DOS/DJGPP? (Developers)

posted by Rugxulo Homepage, Usono, 10.09.2011, 23:34

> The multi architecture angle is going to be hard. But as said, LLVM is
> improving fast. (this might also be a stumbling stone for the other
> Net/OpenBSD since they generally support more architectures)
Yeah, I doubt they'll drop GCC any time soon. In fact, last I heard, they still used non-supported GCCs due to bugs or lack of architecture support (SPARC? VAX?) in newer ones (e.g. OpenBSD, 2.95.3, unlike other arches). Even Linux kernel stopped allegedly stopped supporting 2.95.3 since 2005 or 2006 because of (most) lack of C99 support. The "oldest" GCC still (barely) maintained is 4.4.x. They still haven't fully implemented C99, but they're fairly close by now. (And now they have to finish adding C++11, heh.)

> FreeBSD 9.0 has Clang in base (though ports can still use GCC).
Ugh, "ports", what a mess.

Anyways, you still have to use GCC if you want other frontends (e.g. Ada) since Clang only supports C, C++, Objective C. Unless you switch to .NET/Mono or Java/JVM (as many other compilers and languages support those nowadays). I hear that the GNAT-AUX fork for *BSD is good.

> This will probably put pressure on various packages to work with CLang over
> time (iow kill GCCisms that LLVM doesn't support). This in turn will make a
> move for Linux easier.
They seem to support most GCC extensions due to the huge existing codebase.

> > 586-only instructions are very very rare from compilers. You're more
> likely
> > to see 686 (CMOV..) or SSE2 (XMM) than anything else.
>
> Yes, specially since the very old (60 and 90 Pentiums) afaik miss
> instructions that later 486's and -clones have. Moreover Pentiums require a
> special optimization strategy.
>
> OTOH forcing PPro also rules out stuff like K6. Only K6-2 was PPro
> instruction compatible iirc.
Most people and compilers don't bother worrying with compatibility anyways (sadly). But I don't think the Pentium (IIRC) has many "new" instructions useful for random compiles (RDTSC, CPUID). Can't remember, perhaps you meant something odd like CMPXCHG8B ??? Even the 486 is barely different (CMPXCHG, XADD, BSWAP). PentiumPro is rare (servers? workstations?) because it was expensive. I'm not sure all PentiumPros even supported CMOVxx, hence a small dispute in GCC history over that incorrect "feature" for -march=i686. And those were slower for 16-bit plus also lacked MMX (unlike PII or P/MMX). GCC doesn't even bother targeting Cyrix, and VIA might as well not exist (old ones lacked CMOVxx but newer support even AMD64) due to rarity. And don't forget (older) Atom or (older) VIA, which were in-order (unlike newer), aka similar to 486 (pipelined but not superscalar).

GCC 2.7.2.3 (mid 1997) was the last official release to not support Pentium. And even it only just added extra alignment (since 486 was sensitive) to 386 code, so no instruction scheduling difference. In other words, there hasn't ever really been any "good" 486 support. Supposedly the Pentium support was vaguely better, but I never benchmarked. And it hasn't changed a lot since then. (In other words, developers don't care, it never gets fixed or improved, sadly. On to newest/latest/greatest, ad infinitum.) Remember that the EGCS (Pentium-improved) fork became official GCC 2.95. BTW, GCC does seem pretty good for Pentium 4 and (these days) Core 2, but again, YMMV re: benchmarking. (But -ftree-vectorize isn't as nearly as useful as you'd hope.)

Long story short, it doesn't matter. Most everybody (esp. in Linux) just uses "i686" (or "generic") anyways. Almost nobody targets "i386" or "i586" anymore. Honestly, it's pretty pointless as CMOVxx/FCMOVxx barely helps (if at all). i586 scheduling for U/V pipelines helps but hurts others. i686 out-of-order scheduling (4-1-1 micro-ops) is different from Pentium 4 (family 15, long pipeline, no barrel shifter). And of course Core 2 (family 6) is based upon Pentium-M, aka Pentium III, which complicates everything. And MMX(s) and 3dnow!(s) are (almost) deprecated anyways, so nobody barely supports them. FPU still gets some support (esp. due to tons and tons of legacy code, and GCC always assumes an FPU), but even that is considered old and abandoned by half of the world (esp. related to slow speed, non-scalable, despite being included on all processors since a long time). 3dnow!(s) will be removed from future AMD processors, even.

I think Clang/LLVM aims to support at least Pentium 4 and SSE2, but I'm not sure how well. AMD64 makes this more obvious. But AVX is out in the wild now (with AVX2 in development, wtf??) and SSE4.1, SSE4.2, and a bunch of other weird things (MOVBE, AES). Bah, it's a mess. Don't expect compilers to support all that for you.

Obviously, using DOS makes one appreciate simplicity, so I doubt using anything besides "-march=i386 -mtune=native" is worth anything except in rare cases. But you know, people want to "try" to have the fastest speed, smallest code (with C? ha!), etc.

(combining replies)

> Btw it there some exe/asm analyzer that will find what instruction set
> is required to run this code?
No, it's mostly impossible, esp. with packed or encrypted .EXEs. You'd have to run in a debugger (or via disasm) and blindly hope it catches everything. Just assume everything is i686, as most compilers don't handle anything more exotic than that. Don't forget that most compilers are pretty dumb/simple, they don't try to do too much tricky code generation stuff. GCC is more complicated than most but still lacks a lot. Like I said, I'd be surprised if there was ever a "true" 486-only or 586-only output from GCC via pure C code (without inline asm or other tricks) as I don't think it ever supported that (except maybe?? via builtins).

> BTW do you know if LLVM/Clang support runtime array bound check?
I don't think C (language proper) ever wants to support that because of speed reasons. There were some semi-related 3rd-party patches to older GCCs for that, I think (e.g. 2.7.2 on up), but I never tried (too painful to rebuild). IIRC, EMX and TCC had some (??) support, but I don't know how well. Most likely they only support compile-time checks instead of (slower) runtime. Of course, as you probably know, most Pascal-ish languages have such a feature, and usually they leave it on for debugging (or even permanently). But for C, I dunno. It might even be patented there (read a rumor to that effect somewhere), which sounds wrong but anyways .... GCC doesn't use patented technology for obvious reasons.

I think in C you're expected to write your own boundary-checking code if it's worth it to you and thus take less of a performance hit than a generic solution. At least that's their mentality, I think. Or perhaps they think assert() is good enough, who knows. Or Valgrind, Findbugs, etc. (external tools) etc.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22758 Postings in 2121 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum