Comment by miohtama
4 years ago
The real question, what these kind of articles do not ask, is why Turbo Pascal was smaller?
Hand written assembly was optimised, Pascal is easy to compile language, but there are a lot of other things
- Segmented 16 bit pointers - No graphics or images - Limited OS - no glibc, could only save A: and C: drives - Computers could not hibernate or sleep - Computers did not have periheral devices or needed special software: printer, mouse - No network - No multitasking - No portability
For the editor itself
- No autocomplete - No colours - Not very useful error messages - VI like navigation experience (got much better in 5 years with Turbo Vision IDE framework)
Also
- All documentation was in a dead tree format
For the good reference point on sizes, the bible text is 4-5 MB.
"no glibc" makes programs bigger; they have to contain their own library. Presumably, that small TC executable made some DOS/BIOS calls; that would be its OS-supplied library. That gives you things like file I/O and reading the keyboard.
Anyway I don't think you're quite explaining it (in spite of a good effort and nice points) because, look, the mere hash table module in my TXR language has 30K of machine code. This happens to be 32 bit x86:
It's just a bunch of hash table functions.
I cannot say, oh, my hash table functions are almost bigger than Turbo Pascal 3 for MS-DOS because of documentation (there isn't any), autocomplete (none and not applicable) or because I have networking, multitasking (also not applicable).
I mean, Turbo Pascal 3 probably has some internal hash table itself, and provides an entire language and IDE, in the same space as my hash table stuff.
/bin/ls on Debian 11, x86_64:
What are the amazing features in ls? It does ANSI color and probably something with extended attributes; so, ooooh! that must be why it's four times bigger than Turbo Pascal 3?
I'm not sure what code size has to do with networking and multitasking. Size coding requires technique and caring about size. In the case of hash.c it's likely because the hash function has unrolled loops and is being inlined into all the functions that use it. It'd also reduce size a lot if a loop were used to iterate over the names and function pointers during initialization. I normally gain an intuition for these kinds of things because I have a keyboard shortcut that shows me the assembly of whatever code I'm writing, but I had to implement that feature into my editor myself, so I'm not sure how many other people do that. Bloat also isn't a mandatory price of the modern age we love. For instance, languages exist for 64-bit architecture that have binaries less than 400 bytes in size.
> For instance, languages exist for 64-bit architecture that have binaries less than 400 bytes in size.
In V (https://github.com/vlang/v/) for example, with the currently experimental native backend, you can produce executables, that are < 400 bytes:
You are comparing apples to oranges. Fortran I developed in 1950s was 23K instructions. That was without fancy IDE and after spending 18 person years to develop. So, relatively, TP was obviously a very very tight code. Another comparison is GW Basic which was 80KB and so more than 2X in siz even though Basic is simpler language.
What bugs me is that even though vast majority of work is now outsourced to OS and external libraries and tremendous advances are made in compilation tech, our generated binary sizes are no where close to hand coded assembly. I mean not even close. For example, hello world manual assembly should take about 142 bytes. However, even assembler will spit out whooping 9KB binary for hello world in assembly language! Hello world in C will cost you a binary size of mind numbing 2000KB. https://drewdevault.com/2020/01/04/Slow.html
So put this perspective.
> Hello world in C will cost you a binary size of mind numbing 2000KB
2MB? I'm not sure where that number comes from. Maybe I misunderstand what you mean. I just tried compiling
with gcc on a Mac. The binary is 13340 bytes. Surprisingly big, but not 2000000 bytes! 1/150 that size.
> No autocomplete - No colours - Not very useful error messages
There were colours. And the library was small and well documented with embedded help files containing examples. So autocomplete was no blocker. Errors were fine as far as I remember. Perhaps you mean turbo c++?
Not in Turbo Pascal 3.0 though.
> Computers could not hibernate or sleep
My Thinkpad 300 would like a word with you. It can sleep to RAM and hibernate, done via apm if OS supports it or through keys, but basically everything is done by the BIOS and works fine with DOS.
As impressive as that laptop was, it was released in the 90s and whereas the version of TP we are discussing was the 80s.
It still begs the question why OS X’s touch command is larger. :)