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 Rugxulo Homepage, Usono, 12.04.2008, 20:52

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

> > I think you overestimate the work involved. You can use external
> libraries
> > just as in C. You don't have to reinvent the wheel for every project.
>
> It's more managing the size of the code that I'm worried about. That often
> is connected with the compiler checking the code.
I wonder if you're drawing from your experience with VP here (complex, unmaintainable assembly).

> Because they provide a minor macro system? So do most compilers, and most
> mature ones have a complete inline assembler built in. Often with lots of
> extensions to interface with the HLL (e.g. structure access)
Neither GCC nor OpenWatcom support inline assembly intrinsically (they need an external program). Of course, I think Digital Mars and Intel do. And Intel can vectorize very well (supposedly), but it ain't free except for Linux. But still, somebody did they heavy lifting for you, which you can't always rely upon. Sometimes you have to do it yourself.

> > (Gah, stupid Windows, "Updated blah, do you want to reboot ... [counts
> > down from 5 min. if I don't explicitly say NO!")
>
> Worse, if you postpone it, it will come back. At least on XP. In Vista you
> can luckily shut it up.
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 is indeed useful for speed and size reasons. C is not as fast as
> > assembly and definitely not optimal.
>
> That is a very crude remark, which is btw false from most perspectives.
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. If you don't mind or notice, that's your virtue, not mine. I don't have the patience to wait a thousand hours just to recompress something.

> The average x86 assembler is systematically slower than the corresponding
> C code. Simply because it has assumptions to keep it managable, it was
> originally for an older version of the architecture (how much cmov do you
> use? And do you always test for, and then use SSE2 to move memory?)
>
> Only a very small core of very highly optimized and frequently updated
> assembler is actually faster.
The PAQ8 series indeed sees a big increase in speed with the MMX or SSE2 assembly routines. And in case you haven't noticed my previous posts, 7ZA + HX is much faster than p7zip (DJGPP). Of course, the latter is also due to MSVC being slightly better than GCC at optimizations. But I also give Japheth a big dose of credit there, too. ;-)

> > (Although C compilers ain't
> > that bad anymore.) You do indeed have to tweak a lot if you want
> > speed (which adds up).
>
> Well, the tweaking being optional is the point of a HLL in the first
> place.
It would be better if the compiler authors documented what was optimized and what still needed work.

> > And anything ever is? No, but assembly is no worse. Heck, if you really
> > want, just mix the two and have the "best of both worlds."
>
> Nearly all runtime libraries have an assembler code somewhere for that
> reason, with primitives that greatly influence speed. (like memcpy,
> strscan etc). But that is something else than developing APPS in it.
Actually, from what I've seen, they tend to want to be self-hosting, so it's a layer upon layer upon layer.

> > It has its uses. And some people prefer it. It all depends what you
> want
> > and how much you know.
>
> See my other mail. People can do what they want to. They can even wave
> away productivity comments with a "I like the puzzle side of assembler".
> It is the totally crooked justifications that madden me.
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).

Post reply
 

Complete thread:

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