Shrinking the kernel with a hammer

Posted Mar 6, 2018 10:23 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Shrinking the kernel with a hammer by epa
Parent article: Shrinking the kernel with a hammer

About 10 years ago, give or take - I don't have a git clone to hand to go spelunking, but you're looking for the removal of include/asm-arm26 to see when it was deleted.

to post comments

Shrinking the kernel with a hammer

Posted Mar 6, 2018 12:51 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Found it:

commit 99eb8a550dbccc0e1f6c7e866fe421810e0585f6
Author: Adrian Bunk <bunk@stusta.de>
Date:   Tue Jul 31 00:38:19 2007 -0700

    Remove the arm26 port

    The arm26 port has been in a state where it was far from even compiling
    for quite some time.

    Ian Molton agreed with the removal.

Shrinking the kernel with a hammer

Posted Mar 7, 2018 21:43 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

Ah, yeah. I can understand nobody wanting to maintain a 26-bit(!) arch.

Shrinking the kernel with a hammer

Posted Mar 8, 2018 8:48 UTC (Thu) by epa (subscriber, #39769) [Link]

It's a full 32-bit CPU with 32-bit registers, 32-bit address space, and 32-bit data bus; just the program counter is 26 bits. So executable code needs to be in the lower 64 mebibytes of the address space. Data doesn't have that restriction (in the instruction set architecture; I don't think any machine was built using a CPU with this instruction set and more than 16 megs of RAM).

(The same register contained the 26-bit program counter and six flag bits. I believe this was to reduce the amount of saving and restoring needed for responding to interrupts: you could save the whole CPU state apart from the registers in a single 32-bit operation. With 64-bit CPUs I wonder whether the same technique could make a a comeback: I can see the need for a huge address space for data, but surely it wouldn't be much of a hardship if executable code had to be located in the bottom 281 terabytes...)