Hacker News Reader

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:

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.

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

That's a total of 37 byes including the string.

I might be missing something, but you're still relying on the BIOS to have the graphical representation of those letters. Right?

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.

I also started as a programmer on a C64. BASIC didn‘t get you very far, so assembly it was. The machine code monitor, all the three letter mnemonics and ??? when it couldn‘t disassemble are fond memories.

When I switched to the PC I had great hopes but outright hated it after a short while. All this restrictions on the registers were confusing. The segment modell even more. And good graphics required programming the VGA cards bitplane modes [1] which still makes me dizzy when I think about it. Wished I had an Amiga.

Programming the 6510 and VIC and SID was so smooth in comparison.

[1] In these modes the bits making up a single pixel where not in the same place. To manipulate a single pixel you had to manipulate several bits in different places of the RAM without affecting the adjacent bits in the respective words. Crazy stuff.

The segment model was the thing I really hated. It didn't help that the DOS program that I sold for a number of years sort of ran out of in-memory space for data and I ended up doing a bunch of whacky things with segments rather than rewrite it from scratch. Which I eventually started to do but, at that point, it didn't make sense to put the work in.

Didn't the Amiga's graphics system also use bitplanes?

Yep, sure did.

But with AGA chipset the Amiga got chunky pixels (e.g. write palette index to the framebuffer as in VGA).

That was supposed to be a feature of AAA. I do not think AGA supported chunky pixels.

Yep, but for complexity, nothing matched HAM (hold and modify) mode, except maybe the aftermarket DCTV, the details of which escapes me, but I recall it having separate chroma and luminense.

Edit: found some info on DCTV: https://retrocomputing.stackexchange.com/questions/2201/how-...

Zero-page instructions also helped alleviate the problem of not having many registers.

>"How can you possibly write anything with only three registers?!"

AFAIK you can even go down to 1 register, which is how stack machines work. You might even say it’s 0 registers because it’s not something you can directly access.

There are many simple microcontroller architectures with only one register, usually called A (accumulator) or W (work register). You just need to constantly load memory to and from the register, nothing weird in that. Sometimes they will call their memory locations registers, in which case they have lots of registers - the terminology gets quite unclear when everything is on the same chip anyways.

A true stack machine does not have any registers, so that would be 0.

RPN calculators are simple stack machines.

A one-register machine is not the equivalent of a pure stack machine.

Wikipedia has a section on accumulator machines: https://en.wikipedia.org/wiki/Accumulator_(computing)#Accumu...

Assuming Wikipedia's article on the PDP-8 is correct, the PDP-8 had just two public registers: the program counter, and the general-purpose 'accumulator' register.

I was going to say "Man, that'd be terrible to work with!" And immediately realized I'm no different than those 8088 guys in that class :) You work with what you have.

The answer is, of course, that the 0-page is a full set of 255 registers.. you just have to know how to use the X/Y/Accumulator to access them properly ... ;)

I worked at Prime Computer (a minicomputer company) in Detroit when I was 19. Ford was converting their car design program, PDGS (Product Design Graphic System) to Prime. It ran on 16-bit 32K CDC computers. The program was huge and used overlays to swap different features in and out from disk as the user clicked on menu options on a vector display. For the young tikes here, a vector display is like a traffic control display: it draws perfectly straight lines, perfect circles, by moving an electron beam over a continuous phosphor-coated screen. No pixels.

By contrast, the Prime minis had a Multics architecture with virtual memory (no overlay swapping!), something like 8MB of memory, a 32MB disk drive (16MB fixed, 16MB removable cartridge) and could support 2 vector displays on 1 computer. Happy days!

So yeah, for us oldsters (I'm 58), modern software often seems very bloated.

Saturn assembly programming (HP48 calculator) even had a concept of a "nibble". You had to chose which portion of the data you wanted to access. The CPU only supported working with 4 bits at a time.