Why do we insist on seeing the computer as a magic box for controlling other people?
Why do we want so much to control others when we won't control ourselves?
Computer memory is just fancy paper, CPUs are just fancy pens with fancy erasers, and the network is just a fancy backyard fence.
Tuesday, October 18, 2016
Some of my (too many) other blogs are also approaching interesting numbers.
Why is 2809 an interesting number to me?
I am a fan of the M6809 processor.
And you say, "So?"
Motorola could have jumped years into the future, if they had been willing to refrain from going head-to-head with the wrong-headed Intel engineers in their pursuit of featuritis.
The 68000 did not need all the fancy address modes from the 68020 on. For most of them, there was very little, if any, time advantage. The only real advantage was in maybe reducing register usage. Sometimes the fancy modes even took more instruction space than doing it with a few less fancy instructions. And getting a compiler to use fancy modes is always rather a headache.
What it needed was the full 32-bit branches and other things it got with the 68010 and the CPU32 parts.
And the other thing it really wanted was separate spill/fill caching on the A7 (return address) stack, to cut subroutine overhead to almost zero and push people to use run-times that split the return address and parameter stacks.
Oh, and, of course, on-chip memory management.
Those three things with the rest of what the 68K had would have basically eliminated all the competition. There would have been no need for the industry side-tour through riscville.
The 6809 could have benefited from a similar treatment: spill-fill caching on the return address stack, extending the indexes to 32 bits and running the integer math at 16 bits wide instead of 8+8, adding memory management.
I want to build a software simulator that would have those features. If I do, I'm thinking of calling it the 2809, "2" for two stacks instead of "6" for the 6800 ancestor.
Speaking of the 6800, even the 6800 (well, the 6801) with a spill-fill cached return address stack separate from the (S register) parameter stack would have cleared a lot of bottleneck code in function calls and made it easier to support high-level language run-times. (That is, made it easier to do high-level runtimes that wouldn't fight with the engineers for precious on-chip resources.)
And some other ideas for a stripped-down CPU capable of behaving itself cleanly in a multi-processing 32-bit and 64-bit address space run-time.
Drowning in daydreams brought on by a coincidence in the number of page views for this blog, which will soon be 2810 or so.
No wonder I have a hard time making a living.