Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

seven programming languages on one floppy (Developers)

posted by Rugxulo Homepage, Usono, 02.04.2023, 08:08

> > > So the first constraint - can it be a FAT12 1.44
> > > MB floppy image on USB stick instead of a real
> > > physical floppy?
> >
> > A bootable USB is more realistic, but I'm trying not to go too far where
> > everything is AMD64 or ARM64 with gigs of RAM and terabytes of disk
> space.
>
> Absolutely.
Just for comparison, look at this:

* Slackware 11 (PACKAGES.TXT; Fri Feb 23 04:51:07 UTC 2007)
* Slackware 15 (PACKAGES.TXT; Wed Feb 2 08:23:14 UTC 2022)

> (2007)
> PACKAGE NAME: gcc-3.4.6-i486-1.tgz
> PACKAGE LOCATION: ./slackware/d
> PACKAGE SIZE (compressed): 3962 K
> PACKAGE SIZE (uncompressed): 9170 K
> PACKAGE DESCRIPTION:
> gcc: gcc (Base GCC package with C support)
> (2022)
> PACKAGE NAME: gcc-11.2.0-i586-2.txz
> PACKAGE LOCATION: ./slackware/d
> PACKAGE SIZE (compressed): 21388 K
> PACKAGE SIZE (uncompressed): 133720 K
> PACKAGE DESCRIPTION:
> gcc: gcc (Base GCC package with C support)
I know some people will make all kinds of excuses for things like this. And I get it, things change, development isn't cheap, time is always short, and things improve at a cost.

BUT ... do we really need 14x the bloat? Do we do 14x the tasks? (Don't say yes, it's not true. People choose to change requirements, yes, but that's not because life demands 14x more work than it used to. Although if you take improved compression into account, it's only 5x worse.)

I'm not saying nobody has tried to fix, improve, or avoid such problems (Busybox?). I know it's not easy. I know there are alternatives (TCC or PCC or SmallerC or OpenWatcom).

(quoting colorForth's Rationale):
> Megabytes of software may be required for historical compatibility, but
> sometimes we need a fresh start. ColorForth provides the necessary capability
> with kilobytes of code. At boot, it copies disk into RAM. Then compiles the
> macros that emulate the stack machine that Forth expects. As applications are
> requested, they are compiled.
 >
> A Forth application can take 1% the code employed by the same application
> written in C.
What I'm resisting is the idea that everything must be "-O2 -finline-functions -falign-functions -funroll-loops" (not specific to Slackware, just making a point). They say premature optimization is the root of all evil. I don't think most .C files need to be heavily optimized. It's a very simplistic and flawed idea that "everything" must be optimized at "-O3" or that all code paths are widely used. And 20% smaller (but slower) for something that only takes 5 seconds isn't worth increasing anyways. People assume it's faster (without proof), but it's not. So 5% increase in speed for 20% increased size isn't worth it for short runs.

But most people aren't engineers writing their own OSes and compilers, so compatibility is important. I'm not saying throw everything away. BUT I'm sure it could be much smaller (and use less RAM) without being terminally slow. In other words, there's no reason to totally ditch C just to use more efficient code generation.

In some ways, the answer is scripting languages (e.g. AWK) that (usually) don't generate (byte)code. One interpreter with ten scripts is probably smaller than ten compiled binaries. But that's not always feasible because of third-party libraries.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 79 users online (0 registered, 79 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum