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, 13.04.2008, 23:36

> > True. But *nix overly biassed towards C (and its successor C++), due
> them
> > evoluating with eachother. It is not a logical measuring rod for
> > languages.
>
> HLLs are not evil. They can be very useful. I like the fact that I can
> easily recompile Bzip2 for my Pentium 4 or even my old Pentium 1. But no,
> even that doesn't help as much as I'd like. I still think it's too slow
> (well, more noticeable on my old 486). Even on modern machines, shaving
> time can be a blessing. (You don't compile -O2 when debugging do you? It
> takes much much longer. And don't forget "make": if speed wasn't
> important, we'd recompile the entire project from scratch instead of only
> that which was modified.)
Take e.g. delphi or other wirthian languages, and you'll see it otherwise. Slow compiling is a notorious C/C++ problem, not a HLL problem. It originates in the constant reinterpretation of headers and the fact that the compiler has to startup again for each bit of code (and yes, a compiler starts slower than an assembler. But the restarting for every file is not a requirement for any of them)

> > It's more managing the size of the code that I'm worried about.
>
> I wonder if you're drawing from your experience with VP here (complex,
> unmaintainable assembly).
No it's not. I only dove into the VP code for a day. (a bit more for the RTL parts)

It is more from when I was young and had some BBS software in assembler long ago, and spent months to tune a speedup a logfile analyser that the actual people that were using it turned out to schedule at night.

And in general, if projects get larger, you simply want to catch every bug where and when you can, _before_ you have to compile with debug info.

> Neither GCC nor OpenWatcom support inline assembly intrinsically (they
> need an external program).

Afaik gcc allows two kinds of inline assembler even. Directly inline (which is minimally parsed, and put through to the assembler), and a kind of register independant assembler (that is quite funky and scary btw) Don't know Watcom enough.

> But still, somebody did they heavy lifting for you, which you
> can't always rely upon. Sometimes you have to do it yourself.
So you don't use any software written by others on your 486?

> I don't know who thought that was a good idea. "Security vulnerability
> that might cause you to accidentally reboot and lose data ... okay we
> fixed it, now we're gonna force you to reboot." (!!!)
It's for use in corporations, where people till shortly never realised that computers used power, and left them on for weeks. No forced rebooting would kill vendors ability to push critical patches for outbreaks.

However while not 100% evil, they implemented it magnitudes too aggressive IMHO.

> If you are doing anything time-intensive (compiling, compressing, finding
> files), you will notice how slow things are.
> And a typical C compiler is
> just not always fast enough.

Well, maybe if you invested the same amount of time in the HLL code as in your handtuned assembler, than it would. 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. If you finish such project for larger pieces of software, you can start rewriting it for newer processors before it is finished.

And don't forget that the whole GNU stack is designed for portability. 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), but that is not a general rule that applies to all software.

> And in case you haven't noticed my previous posts, 7ZA + HX is
> much faster than p7zip (DJGPP).

And that proves exactly WHAT? THat you and japeth put in more time for some optimizing?

> It would be better if the compiler authors documented what was optimized
> and what still needed work.
Needs the analysis, and that is part of the optimization process too. If it was that easy, it was already done.

> Actually, from what I've seen, they tend to want to be self-hosting, so
> it's a layer upon layer upon layer.
There is always layering over assembler, if only to be able to abstract architecture.

> Please list your preferred compilers so that we can see which ones
> optimize the best in your mind. I use DJGPP (GCC) and OpenWatcom among
> others, both of which are good but could still ideally be better. And FASM
> or Octasm (both written in themselves) are faster than YASM (C) which is
> faster than NASM (C).
That only proves that you care more about speed than the YASM and NASM authors. Not that asm is superior

Damn, done it again. Now really, this is my last post on these endless discussions

Post reply
 

Complete thread:

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