gnu@hoptoad.uucp (John Gilmore) (07/31/86)
> Does anyone know of a successful or failed CPU design that was > significantly changed or built from scratch, because of outside influence? It seemed to me that the 68010 and 68020 were influenced by a paper that I wrote in December 1980 in Computer Architecture News. The paper was written as a byproduct of trying to design an APL interpreter for the 68000. Whenever I ran across something that was a major or minor pain, I'd write it down and think about it. I later compiled all these ideas into some semblance of order and sent it to John Wakerly of CAN as well as to the designers at Motorola. Over the years I've been watching to see how many of the ideas have gotten into chips and how many have fallen by the wayside. Of 29 suggestions, 3 were done for the 68010 (virtual memory, loop mode, rts with literal value). They did 10 more for the 68020 (better bitfield support, 32x32->32 multiply with overflow, 32/32->32 divide, scaled indexing, 32-bit bus, instruction cache, TST on all EA's, IEEE float, conditional trap, indirect jmp/jsr). Some of these were obvious, some were not. I was particularly surprised that the multiply and divide instructions turned out almost exactly as I had suggested them. FYI, the ideas that fell by the wayside were: * Document the architecture of the family, as well as the specifics of each implementation. * Signal Address Error if high-order address bits are used that don't appear on the physical pins (e.g. on a 24-bit bus, high bits other than 00000000 or 11111111 would trap). [It turns out Sun did this on their 68020 machines, to guarantee that programs which run today will run when the virtual address space gets larger.] * Use of Read/Modify/Write cycles in the bit manipulation instructions to avoid multiprocessor glitches * Instructions for converting BCD or Ascii to/from binary. The instruction amounted to "multiply and add" or "divide and store remainder", and you'd have to loop to convert the whole number. * Assigning another opcode for ORI and making the opcode all zeros illegal. [Happily, they left 0xFFFF likely to be illegal.] * Providing an on-chip identifier which can be stored by user code as a CPU ID for software protection. Even if it was only a 6-bit identifier, it's unlikely that a bootleg program you stole would have the right one out of 64 identifiers coded into it. * Providing a mode that would cause operate-to-storage instructions to use read/modify/write cycles (eg add to memory, or to memory). * Allowing CLR, NEG, NOT, ADDI, SUBI, CMPI to work on address regs. * Upon RESET, saving the old value of the PC somewhere before reading in the new one from location 4. It could be pushed on the new supervisor stack, but many systems won't tolerate a write here. Better to move it to some internal register like the cache address register. You're far more likely to want to know the PC than the contents of the cache address register when the system hung! * A mode that would cause overflows to trap, as in the IBM 360, rather than having to test with TRAPV after each instruction that might. * A mode that would cause word or byte operations to sign-extend the operand and work on the whole data register, like adding to address registers works now. * TAS/TST should set carry to the low bit of the operand. Cheap odd/even test and doesn't mess anything up. * Reverse subtract instruction * CARRY instruction to add the carry bit to bit 8 or 16 of a data reg, so after adding a byte to a long, you could do the carry in one instruction. * Extend SR to 32 bits since I had just filled it. * ABCD/ABCD trap on non-BCD data * No instruction should leave undefined condition codes (CHK and the BCD's still do). I'll leave it to you-all to figure out whether any of these are worth doing. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!