On a PDP-11 there were 8 registers, R0-R7, with R6 being the (default) stack pointer and R7 being the program counter.
There were 8 address modes for each register.
So a src/dst instruction used up 12 bits for the src/dst+modes, a single register instruction used 6 bits.
You could load the registers directly at addresses 177770 through 177777 on the front panel. So if your program was 5 words long, you could load that into registers R0-R4, then load R7 with the address 177770 and execute.
> Also, somebody contributed reduce() to Python way back in the 90's, as well as other functional idioms. He wouldn't have added that himself -- it was never his preferred style.
> He preferred a more imperative style. But he allowed those contributions, and then slightly regretted it later.
That would explain why they're so inconvenient to chain.
I went down a rabbit hole a few summers ago and I ended up writing a calculator from scratch in assembly for RISC OS. Interesting experience having GUI routines at the syscall level
I've never really been a math person, either, which is why I thought I was going to hate discrete math in college. I mean, it wasn't always the easiest thing ever, but it was a lot more intuitive to me than continuous math. And that's all programming is, materialized discrete math.
When I was pretty young, I saw someone (I don’t remember who actually) show me that an odd number squared is always odd [1].
I remember thinking it was the coolest thing ever to be able to know properties for all numbers, without having to test any of them.
[1] most people here already know this, but for posterity, let’s define odd numbers as the expression 2k + 1. Now we square the expression which expands to 4k^2 + 4k + 1. We can factor this to 2(2k^2 + 2k) + 1. We can set the parenthetical expression to u, so we now have 2u + 1, which looks a lot like our original expression, showing it will always be odd.
reply