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 marcov, 11.09.2011, 02:33
(edited by marcov on 11.09.2011, 13:20)

> > 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).
Nothing is going to happen anytime soon. But I expect some of the old archs to be killed in the coming years. Simply because new enduser (or even workstation/basic server) hardware isn't made anymore for them.

> Anyways, you still have to use GCC if you want other frontends (e.g. Ada)
bleh.

>>But I don't think the Pentium (IIRC) has many "new" instructions
> useful for random compiles (RDTSC, CPUID).

Did the 5V Pentium 60/90 have those? IIRC they were a bit funky too. I still have one of those. (admitted, as key-ring hanger though, it is not "operational" anymore :-)

> Can't remember, perhaps you
> meant something odd like CMPXCHG8B ???
That one _is_ important; to create CAS iirc, for threadsafe queues.

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

PPro's were cool. Much faster, gigantic full speed cache (P-II was only half speed, but in the beginning when they competed against P-I and the difference was much bigger), and most importantly, the first true multiprocessor.

I might still have two somewhere (200MHz, 256kb), from a Proliant 1500.

> 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).
Yup, afaik Via C3 doesn't either, and they are actually not that old. (as in were sold after 2000, specially in all kinds of embedded configurations. Afaik we got ours in 2003)

We had one as firewall till a few months back, and early this year the firewall distro (smoothwall) changed to 686, and got into trouble.

But then we changed ISP, and the new modem has a firewall internal.

(gcc story skipped

true, most instructions of 486,pentium, pentiummmx are not commonly generated by compilers)

> 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.)
Netburst wise I've only a Pentium-D (and actually never owned a P4), and while it has an XP, it is used mostly in 64-bit mode.

> 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.
Well, I think that is the rationale. i686 scheduling covers the biggest chunk (mainly i5,core2 and core mono and pentium M, but also the older Ppro/II/III.
AMD can also handle it fine. The only realistic problem is netburst, and the real exectional bits like VIA C3)

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

SSE2 is not as common as e.g. cmov. Maybe in time...

> 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.
Some like AES,popcnt,lzcount,crc32 are mostly for specialistic (hand coded assembler) code.

Stuff like AVX is nearly always useful in memcpy/move() routines (but maybe not on AMD's upcoming bulldozer, since it eats two core's vector units there), and even compiler generated in expanded (inline) versions of that routine for low bytecounts.

> 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.
My experience is that most normal (non benchmark) programs are limited by

1) the heap manager
2) move/memcpy
3) other similar primitives like "search for a byte in block of memory", on C probably a special "search for byte 0 in block of memory" variant.

But move definitely matters. In 2003..2006, a team reprogrammed the lowlevel assembler of Delphi (which was pretty much at the level of 486 P-I) of such routines to optimized MMX/SSE(2) using, and that could matter 40% on memory copy easily.

And that was very, very noticable in my work app (image analysis, lots of image copying going on)

> (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.
Moreover many programs detect processors. So such a tool could detect e.g. SSE(2) RTL, codec or encryption routines and conclude that the program needs SSE2, while in reality there are fallbacks for older CPUs.

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

That is nonsense. If you can turn it off, it doesn't matter. Works the same in pascal.

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

Some do, but most ship production releases without. Not because of speed reasons btw, but more to avoid the chance that a customer gets an error that was not necessary.

> 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.
Please. This is sixties technology, there are libraries full of prior art. IMHO FUD.

> 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.
I would search the problem more in the standards. Doing unique things is simply discouraged. GCC has some more stuff, (Wirthian stuff like said range checks, nested procedures) but that is probably because the backend is/was also used for wirthian languages, and the concepts were therefore already supported by the middle layer.

Post reply
 

Complete thread:

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