It's funny how you can just adapt and work with whatever is available, and that becomes your norm. Especially when you don't even realize there are other options out there.
Another example of this, also quite relevant to the article, is the 64K address space of a 16-bit segment; to anyone who is used to HLLs, 64-bit address spaces, and gigabytes of RAM, it seems impossibly small. Even more so when you take a modern C++ compiler with all its default settings and produce a 72KB(!) "Hello World" binary.
One of the things you quickly realise when you work with Asm is that it's not impossibly small; everything is os just horribly bloated --- piles of abstractions upon abstractions, using gargantuan statically-linked library functions of which a tiny fraction of the bytes is actually executed, etc. Try writing a nontrivial utility in 16-bit realmode Asm, where a "Hello world" is around a dozen bytes, and you'll find that 64KB is actually quite a lot already. In particular, look at the 256b and below DOS categories in the demoscene:
Those effects were accomplished using fewer bytes of machine instructions than the text of this post, which is already over 1KB. Really makes you think.
Hello world in real mode is leveraging a bunch of code and data from the BIOS, so it's not quite as small as you're suggesting, but yes, bloat is the cost in general purpose abstractions.
Smart linking is related to GC. Not all the conditional and indirect edges in the control flow graph can be skipped by the linker's graph traversal, so you usually end up with lots and lots of unused code. And then there's all the sledgehammers being used on peanuts, just because they're there, like xpath to retrieve config values.
Not important, I just thought it'd be fun to write but:
> Hello world in real mode is leveraging a bunch of code and data from the BIOS
Not necessarily, you can avoid the BIOS calls by just copying the string directly to video memory:
mov ax, 0xB800
mov es, ax
xor di, di
mov ah, 0x07
mov si, hello
;; Load character, if zero, jump to end otherwise store
;; character and color in video memory
@@: lodsb
test al, al
jz @f
stosw
jmp @b
;; Halt and wait for interrupt
@@: hlt
jmp @b
hello: db 'Hello, World!', 00h
As far as I remember, the default VGA font is stored on the graphics card ROM and copied into the video memory by that same onboard ROM, not the motherboard BIOS, so no I don't believe so. I may be mistaken.
And that's why I love D. I can get fairly small binaries and still use powerful language constructs so that I can focus on the logic and not on the language.
Another example of this, also quite relevant to the article, is the 64K address space of a 16-bit segment; to anyone who is used to HLLs, 64-bit address spaces, and gigabytes of RAM, it seems impossibly small. Even more so when you take a modern C++ compiler with all its default settings and produce a 72KB(!) "Hello World" binary.
One of the things you quickly realise when you work with Asm is that it's not impossibly small; everything is os just horribly bloated --- piles of abstractions upon abstractions, using gargantuan statically-linked library functions of which a tiny fraction of the bytes is actually executed, etc. Try writing a nontrivial utility in 16-bit realmode Asm, where a "Hello world" is around a dozen bytes, and you'll find that 64KB is actually quite a lot already. In particular, look at the 256b and below DOS categories in the demoscene:
http://www.pouet.net/prodlist.php?type%5B%5D=32b&type%5B%5D=...
Those effects were accomplished using fewer bytes of machine instructions than the text of this post, which is already over 1KB. Really makes you think.