Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

code density (Announce)

posted by Rugxulo Homepage, Usono, 17.09.2010, 23:06

> > [...] code density. [...]
>
> Output or input code density? :-P
Output. Wirth claims it easily was much much smaller than x86 in output code size. (Of course nowadays even he cares less since "RAM is so cheap" ... argh, I'm tired of hearing that.)

> > You know, a megabyte truly is
> > a lot of space. Even at worst, six bytes per instruction (8086),
> > 1024*1024/6 = 174762, or 640*1024/6 = 109226 or more realistically
> > 512*1024/6 = 87381.
>
> IBM's decision to reserve 384 KiB for BIOS and text/graphics buffer mapping
> be damned!
Tim Paterson's original machine(s) didn't have that limit. And rumor says IBM wanted to make it 512 kb, but MS complained. Blame bad compilers for hitting that wall so soon.

> > It's truly sloppy or crappy compilers that don't output small size
> anymore.
>
> I heard they're optimizing for speed now.
Then why is GCC so slow?? GCC is a pain to use, rebuild, etc. No way can anybody understand it all anymore, only various subsets, if even! I like GCC, but not that much! It could always be improved, slimmed down, etc.

Wirth (re)wrote a single-pass Modula-2 compiler (proper? not counting M-code interpreter?) in 5000 lines in 1984 or 1985 or so. Since it didn't need a billion separate passes due to memory limits, it was much faster and could compile itself in 45 secs. And yet even with modern machines rebuilding GCC takes ages (esp. on non-*nix, e.g. Cygwin)!! Sure assembly is mostly simple syntax and almost typeless, but I'm extremely glad it doesn't take years to build something. (Try rebuilding Menuet32 or OctaOS sometime. Even FreeDOS doesn't take nearly as long as rebuilding "modern" GCC. Old, simpler 2.7.2.3 is fast, though, primarily because things had to be fast back then. Nowadays you just throw more RAM, cores, 64-bit at it and hope it works.) Yup, we've jumped the shark.

Autoconf alone easily surpasses Wirth's compiler linecount!! Why do we need ten billion files, ten thousand defines, and a billion hacks?? Because everybody keeps adding everything and the kitchen sink: K&R, ANSI, C99, POSIX, 32-bit, 64-bit, extensions, portability, SIMD, AT&T or Intel, preprocessor, various backends, 586 and 686 and 786 optimizations, etc. etc. The source for the ACK compiler suite (pc, m2, cc) is less than 1 MB bzip2'd! Yet GM2 is like 56 MB gzip'd! Yeah, you could delete a lot of that, but similar gcc-core 4.1.2 (C only) is like 22 MB gzip'd, ugh. And gcc-core 2.95.3 was 9 MB gzip'd, if that tells you anything.

The whole Lilith machine was written in Modula-2, avoiding the need for ten million different languages and their associated tools, so it was much less complex. Of course, it was developed by a small group, not a big hodgepodge of everybody wanting to add their own stuff. Whether you like assembly or not, the advantage is that it's static, already defined, relatively simple, so you have your instructions and you make do (unlike certain HLLs which add more and more reserved words). However, obviously I dislike the idea that AVX, XOP, etc. are taking over, esp. since we're barely on the SSE4 bandwagon yet (blah), MMX and FPU are semi-obsolete, etc. (ARGH!) If all you want to do is reasonable computations, shouldn't 8086 (+ 8087) or 80386 be enough???

> > Or maybe it's the dumb linkers fault for not stripping the unused parts.
>
> Yes, you should strip unused parts. Think about TSRs. DOS functions
> Int21.31 or Int27, as utilized by most TSRs. These are stupid because a
> majority of TSRs don't need a PSP while installed. Most people don't care
> to relocate their TSR code in a way to free up all installation code
> either. Bonus spite if they don't even free their environment. (Besides,
> memory fragmentation.)
The simple truth is that "good enough" is the enemy of "better". If it's 80% good enough or covers 80% of the target audience, it's good to go. But then later someone else makes similar compromises, and now you've got 80% of 80%, and ever decreasing amount. Eventually you have one big abomination that does what nobody wants, and nobody can use it properly. Maybe this is why design by committee is so frowned upon. It's always easier to add than take away or simplify / unify everything.

Yeah, Clang / LLVM are considered "more modern" than GCC, and they are doing well, so it's not like nobody cares. (Written in C++ too. Good?? Bad??) And obviously other compilers exist. Still, the inertia of (despite everything) still making everything in C / GCC is daunting! :-/

Post reply
 

Complete thread:

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