Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FPC for DOS / FreeDOS (DOSX)

posted by marcov, 14.04.2008, 21:59

> It seems that OpenWatcom is faster to compile than GCC. And its
> output gets about 85% of GCC's speed. But yeah, I do wonder why no C
> compiler ever bundles all the .H files into one big database (since they
> aren't updated often).
.h files interpretation are bound to all preprocessor symbols getting in. two #includes of the same header can have totally different preprocessor state (and thus preprocessed code) as result.

> > It is more from when I was young and had some BBS software in assembler
> > long ago
>
> If people still used 486s or non-superscalar architectures (e.g. VIA ?),
> they'd probably all be assembly programmers.

I doubt that. It was already waning in 486 times.

> But since clock speed (and cpu improvements) have all gotten better, it's less of an issue ... in
> most cases. Still, I wonder who is completely satisfied with 100% of their
> programs and thinks they don't need to be any faster. (Any
> compiler/compressor could be ideally faster.)
Any non trivial assembler code too. So there is no difference there _if_ you are willing to invest disproportio

> > Well, maybe if you invested the same amount of time in the HLL code as
> in
> > your handtuned assembler, than it would.
>
> No. The compiler is inherently limited, pure assembly is not. It doesn't
> mean you can't optimize at the HLL level (search Google for C
> optimizations), but their generic optimizations don't always pan out.
I'm not the kind that says throw your fastest code, and the compiler will figure it out. But your statement is the other extreme.

> > The point is not the assembler,
> > but the invested time to speed it up. Most engineers don't want to
> invest
> > those magnitudes of time for something that is old hat in two years.
>
> The problem here is that you're assuming everyone has newest, latest Core
> 2 "Penryn" processors with quad cores, etc.

You assume what I'm presumed to assume, how odd. You don't know me.

Note that I turned away from assembler when I had a 486 DX2/80, except for really reusable routines. I turned away from that with my

> BTW, assembly doesn't usually get slower with newer processor upgrades.
Yes it does. (based on a per cycle basis). E.g. pre pentium assembler doesn't take register stalls into account. Not taking prefetch into account can hurt, similar with branch prediction (the branch taken is a simple heuristic, if your handcoded assembler does otherwise, it hurts).

For an assembler programmer you don't seem to know much about this !?!?!?!

> > If you finish such project for larger pieces of software, you can start
> > rewriting it for newer processors before it is finished.
>
> Sure, if you have infinite amounts of money and are willing to upgrade
> your cpu. Most people don't do that, however.
I hardly consider a CPU of Eur 40 "infinite amounts of money". Let alone, that I had a 486 when I stopped being obsessive about assembler (admitted, a fairly heavy one, at least for that generation)

> > I do agree they could speed up some very much used primitives (and
> > compression is certainly one of them) on x86, and keep the C code for
> the
> > rest (and afaik most compression already contains asm)
>
> Only the best compressors have asm speedups. The rest just wimp out and
> say, "Good enough" (and that's probably fair in some cases). But just FYI,
> there are reasons why Zip/Gzip (Deflate) and BZip2 (BWT) are still
> popular despite much better compression available: low memory footprint
> and fast.
I know. I used paq over 10 years ago, and squeezed it into my 16MB of ram. Decoder availability is another one btw.

> The YASM and NASM I use are DOS/DJGPP compiles, and DJGPP is not the best
> optimizing compiler (although fairly good). So that makes a difference
> too.
I'm no real wizard, but afaik gcc optimizes fairly decently with generic optimizations, but largely misses a decent CPU dependant peephole optimizer.

Still, I'd expect an assembler to be speed bound on a different level than asm optimization.

> "Bare" Assembly (language) is of course superior because without it you
> can't run anything!

Well, that is because you have a 486. With the introduction of the P6 cores (PPRo+) that changed.

Post reply
 

Complete thread:

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