That is an interesting statistic. What else is amazing is how much could be done with a 1MHz processor and 64kB of RAM.

I have now set the swap space set to ‘Windows manages’. I thought I had it set that way, but when I checked it was set to 6GB.

For some reason I am reminded of the time I recommended a 4MB RAM board be purchased for a 286 machine. All the apps the user needed to have running just would not work with the machine’s original RAM. The additional RAM was on a PCAT card not the motherboard.

What amazes me is how *little* we can accomplish, in comparison, when armed with a 4GHz CPU and 64 Gigabytes of RAM...

It makes one wonder where we are going with all this computing horsepower.
Artificial realities just around the corner.

After letting this project sit for a few months, I went back and reviewed it and found a bug in the processor. Absolute address branches were not sign extending the address as they should be. I was amazed this was not hit as an issue when running software, but all the code must be using relative addressing which was correct.

I had to search for this project, started a related project.

Spent a chunk of time on a new project rfPower, innovating the nPower project to have a 96-bit data-path and 48-bit instructions. 256 registers. nPower was strictly a 32-bit machine. Some things are altered from nPower. The process will be to get some sort of basic instruction set working, then add to it later. I want to experiment with software register renaming, given that hardware renamers are quite huge.

There are so many registers to support vector operations and to hopefully allow software renaming of registers. In a modern OoO design the number of registers is often into the hundreds; they’re just not all visible to the programmer. Doing renaming with software means the registers needs to be exposed.

The condition register is made of six flags instead of four. The flags work differently than on the nPower. There is cf (carry), vf (overflow), nf (negative), zf (zero) flags but also ‘sf’ for sign and ‘so’ for summary overflow. The sign flag ‘sf’ works in conjunction with the zero flag to allow cascaded compares to be formed. This was mainly to get immediate compares that could compare whole double-words using multiple compare instructions. A cascaded compare looks like:

After the first compare the remaining compares are NOPs unless the first compare result was equal. The compares keep going as long as the result was equal. The process should work with compares larger than a double-word size as well.
Compares now do both signed and unsigned comparisons at the same time, so there is no need to have two sets of compare instructions. This freed up a couple of opcodes.

Shifted immediates are handled differently. Rather than separate instructions for a shifted immediate, an immediate shift count is included in the immediate instruction. Immediates can be shifted in increments of 20 bits up to 140 bits.

The CRxxx instructions are made more powerful. They can combine up to three Cr registers with logic operations. For example:


Seven more branch registers were added in addition to the link register. It is no longer possible to branch to the count register; a branch register may be branched to instead.
Instructions formats are looking like (not all shown):

How do you do indexing and induction variables that go with them ? (int) a[j] or (float) a[x,y]
How do compare for a NULL pointer or a invalid pointer ?
A zero pointer?

Comparing for a NULL pointer can be done with the CMPDI (compare double-word immediate) with the pointer in Rs1 and zero for the immediate.

Multi-dimension indexing would need to be calculated with a multiply instruction. Referencing the variables done with load and store instructions (were not shown).
There is both register indirect and indexed addressing like the PowerPC. But the index address mode may also have the index register scaled.