The SC/MP looks like a rubbish CPU
Ooooh heresy :-) In its defence, decades on, this rubbish CPU is still guiding thousands of lifts ('elevators') up and down tall buildings and was ideal for small control operations having 5 bits on on-chip I/O. Nationals NIBL interpreter was a better implementation than many Tiny Basics, having a do-while construct, fixed program execution, indirection, I/O control, memory paging... it was (and is) a cheap and cheerful processor that hobbyists could afford to build and expand. I've built a few SC/MP systems and I like it!
Cheers
Phil
Bear in mind this was my opinion in 1976 or 77, looking at it as a machine to do general-purpose computing on, for example to target a Pascal (subset) compiler at. If you regard it as a replacement for random logic in an application where speed wasn't important then a different conclusion can be reached -- it looks pretty reasonable when compared with early PC or 8051, neither of which existed at the time.
Much the of ISA is very reasonable, even good. Being able to access +/- 127 bytes (or a calculated dynamic offset) from the PC or three other pointer registers with a single instruction is nice. The ability to write back the EA into the pointer register is nice. The "co-routine" nature of function calls is nice if you only need one level of call. Having 11 bytes of registers in a $25 CPU in 1976 is nice, vs 7 bytes in the 6502.
What isn't nice:
- being able to add an 8 bit offset to a pointer and have carries ripple from bit 7 up to bit 11, but not the remaining 4 bits is ... wtf? And the same for PC increment. That's completely needless penny-pinching, and the single biggest obstacle to running generic software. I suppose the justification is that if you only want to attach 4K (or less) of memory and not demultiplex the upper 4 address bits from the data bus then you can just assume that the top 4 bits are always zero because everything wraps. But ignoring them would work just as well. Or making sure your program didn't exceed the memory limits -- any program which does actually wrap almost certainly has a bug. The 6502 definitely wins here, even if the code to access at a known offset from a pointer is a byte bigger (but you can use a lot more pointers).
- the large amount of code needed to call a function at an absolute address, loading one byte at a time into the accumulator, swapping it with the hi or lo byte of a pointer register, save the old contents on the stack, then finally swap the pointer with PC. It's 11 bytes of code, on a machine with limited memory. The 6502 and Z80 use 3 bytes of code.
- very limited conditional branching. No branch on negative (need to branch positive around an unconditional branch), and no branches on carry or overflow set or cleared. Those require transferring the status to the accumulator, anding a constant, then branch on zero/non-zero. Maybe those are uncommon operations, I don't know.
- complement and add. My gripe is really just about the name, as in reality it's exactly the same as the 6502's subtract (SBC) instruction. With both, you need to set carry/link before a subtract.
- just the general slowness. Instructions take typically 3 to 5 times more clock cycles than the 6502, and both run at 1 MHz. The z80 takes a similar number of clock cycles to the SC/MP, but it runs at a higher clock speed. That 11 byte 7 instruction function call sequence takes 79 clock cycles. The 6502 takes 6 clock cycles. The z80 takes 17 clock cycles.
Ok, controller applications often don't need much speed. 50k to 100k instructions per second is fine. And they often don't need a lot of generalized nested function calls.
Home
Help
Search
Login
Register
