I wanted a KIM-1 or a COSMAC Elf in the '70s, but I couldn't afford one as a kid. I eventually built a ZX81 kit from the proceeds of a summer job as my first computer.
The KIM-1 had a 6502, the Elf had an 1802, and the ZX81 had a Z80 processor, all 8 bit processors which were approachable for beginners.
I built an Elf when I was a teen. Would have been much harder if it weren't for a school friend who was also interested and who's dad was an EE -- got us the HP hex LEDs which were pretty expensive at the time. I had planned to go ahead with two banks of discreet LEDs, but having the HEX displays beat the heck out of having to translate binary on the fly.
I really had a blast with that thing. Programing the interesting ISA was fun. It almost felt like it had 16 words of RAM and several K of registers, since all memory I/O had to go through the D register. The best part was that you could use any of the 16 GP regs as the PC, so you could do primitive task switching.
The simple circuit made it just as fun to expand its hardware capability (bump to 2K of RAM, eventually 8K CMOS battery backed RAM, KC tape interface, Hex keypad, a 20ma. loop interface to a barely working Model 33, and finally I scored an 1861 to add video out)
I later got a Timex/Sinclair 1000 as a gift. Not nearly as fun from a hardware perspective (though I eventually upgraded the the external 8K RAM cartridge to 16k by piggybacking additional chips, connecting the chip select pins to the the board with flying leads). However, the Z80 was another fun CPU to program for. Much more advanced memory addressing and the shadow register bank made for some fun hacks.
Never did own anything 6502 based, which kind of bums me out since the first computer I ever programmed was 6502 based (CBM PET 2001), but I was a ways off from figuring out assembly at the time.
I wanted a C64 or a VIC, but couldn't afford one. Oh well -- once I saved up enough to buy a used CoCo I was spoiled for anything else for years to come -- the 6809 was the peak of 8-bit CPU design, IMHO.
What a great project. Like the MIT hackers who added opcodes when computers were discrete components.
I'm reminded of the NEC V20 which could replace the 8088 in the original IBM PC. You could pop out the 8088, pop in the V20 and get lots of interesting new opcodes.
The Vax had a polynomial evaluation instruction. It would barely be any more complicated to have such a thing produce the Calculus 101 derivative of a single variable polynomial.
Someone, somewhere, may well have done such a thing on some CISC machine.
CISC as a general approach lost out to RISC historically for specific reasons, but it's fun to think about.
I'm afraid my DEC assembly language study ended at the PDP-11, but it is edifying to know the VAX had such an instruction.
In some domains like numerical programming, ML, and graphics using SDF having a Calc 102 operation like a gradient op might be considered useful enough to include in a RISC instruction set, and the RISC entry on Wikipedia says this about the RISC-V architecture:
> The ISA is designed to be extensible from a barebones core sufficient for a small embedded processor to supercomputer and cloud computing use with standard and chip designer defined extensions and coprocessors.
Maybe a derivative op belongs in a math coprocessor?
> I'm afraid my DEC assembly language study ended at the PDP-11
You're better off; the PDP-11 was a beautiful ISA but the VAX was not, it was just a kitchen-sink approach, and is part of what motivated interest in the RISC approach.
If the VAX had simply been a clean 32 bit extension of the PDP-11, a lot of related history probably would have turned out interestingly different -- not that it would have stopped the RISC revolution, but still.
Specifically, the VAX CISC instructions overall, and the polynomial instruction in particular, were significantly slower than just using the regular VAX instructions to do the equivalent -- which was widely agreed to be unfortunate if not outright pathetic.
Nor was that particularly rare with CISC instructions. It's just a lot easier to make RISC instructions go fast, whether microcoded or not. It's typically not impossible to make CISC instructions optimally fast, but it's an extra cost in implementation and testing for the manufacturer, so it often got/gets comparatively neglected.
The Intel processor looping instructions re-fetched the instruction on every loop, so they didn't (and still don't, as far as I know) even save on the instruction fetch bandwidth.
Typical comment on that that I just found: "You should normally never use the loop instruction unless optimizing for code-size at the expense of speed, because it's slow. Compilers don't use it. (So CPU vendors don't bother to make it fast; catch 22.)" [1]
There was also a mindset issue (with both users and manufacturers) where it was viewed as a boost to assembly language programming to have fancy opcodes, although in retrospect that particular angle could have been just as easily addressed by the manufacturer with fancy assembly macros. I'm not sure why that was usually left to users.
> Maybe a derivative op belongs in a math coprocessor?
Sure, why not. Although theoretically it still needs to justify the opcode real estate and coprocessor silicon real estate and/or microcode space that it uses.
I personally like the concept of CISC, and I like things like Lisp machines, and I like GPUs, and so on. But they don't automatically justify themselves logically; it depends on the tradeoffs in each case.
Thanks again. Like you said it is fun to dream (ask the "Scheme Machine" guys sometime about how they would go about it now), but practically with technology like Julia's Zygote:
the efficiency of autodiff might be similar to that of an opcode anyway.
So, how did DEC do on the Alpha processor? I always heard good things about it--IIRC (I didn't) it was ~~based~~ to replace the VAX, but 64 bit. I learned PDP-11 assembler at RPI, during their college program for high school students in about 1984. We hand assembled code and really got to know the architecture.
By the way, back to the original topic, a bare-bones machine like the KIM-1 also required a lot of hand assembly.
I guess everybody is gone from this post too, but I wonder if there is a fixed point corollary to Godwin's law--if you post enough off topic comments, you reach the original topic again. :)
If I remember correctly, Windows 3.0 could not be used in VGA mode on an 8086 PC, because the VGA device driver used some 80286 instructions.
Nobody noticed, because VGA was mostly found in '286 & '386 level machines, and TBH Windows 3.0 was not really aimed at XT-class PCs (8088 & 8086).
But the NEC V20 & V30 implemented the additional Real Mode instructions from the 80286 — so if you replaced your Intel CPU with an NEC equivalent, suddenly you could use VGA on Windows 3.0.
10 comments
[ 4.4 ms ] story [ 27.1 ms ] threadThe KIM-1 had a 6502, the Elf had an 1802, and the ZX81 had a Z80 processor, all 8 bit processors which were approachable for beginners.
I really had a blast with that thing. Programing the interesting ISA was fun. It almost felt like it had 16 words of RAM and several K of registers, since all memory I/O had to go through the D register. The best part was that you could use any of the 16 GP regs as the PC, so you could do primitive task switching.
The simple circuit made it just as fun to expand its hardware capability (bump to 2K of RAM, eventually 8K CMOS battery backed RAM, KC tape interface, Hex keypad, a 20ma. loop interface to a barely working Model 33, and finally I scored an 1861 to add video out)
I later got a Timex/Sinclair 1000 as a gift. Not nearly as fun from a hardware perspective (though I eventually upgraded the the external 8K RAM cartridge to 16k by piggybacking additional chips, connecting the chip select pins to the the board with flying leads). However, the Z80 was another fun CPU to program for. Much more advanced memory addressing and the shadow register bank made for some fun hacks.
Never did own anything 6502 based, which kind of bums me out since the first computer I ever programmed was 6502 based (CBM PET 2001), but I was a ways off from figuring out assembly at the time.
I wanted a C64 or a VIC, but couldn't afford one. Oh well -- once I saved up enough to buy a used CoCo I was spoiled for anything else for years to come -- the 6809 was the peak of 8-bit CPU design, IMHO.
I'm reminded of the NEC V20 which could replace the 8088 in the original IBM PC. You could pop out the 8088, pop in the V20 and get lots of interesting new opcodes.
https://en.wikipedia.org/wiki/NEC_V20
Someone, somewhere, may well have done such a thing on some CISC machine.
CISC as a general approach lost out to RISC historically for specific reasons, but it's fun to think about.
I'm afraid my DEC assembly language study ended at the PDP-11, but it is edifying to know the VAX had such an instruction.
In some domains like numerical programming, ML, and graphics using SDF having a Calc 102 operation like a gradient op might be considered useful enough to include in a RISC instruction set, and the RISC entry on Wikipedia says this about the RISC-V architecture:
> The ISA is designed to be extensible from a barebones core sufficient for a small embedded processor to supercomputer and cloud computing use with standard and chip designer defined extensions and coprocessors.
Maybe a derivative op belongs in a math coprocessor?
You're better off; the PDP-11 was a beautiful ISA but the VAX was not, it was just a kitchen-sink approach, and is part of what motivated interest in the RISC approach.
If the VAX had simply been a clean 32 bit extension of the PDP-11, a lot of related history probably would have turned out interestingly different -- not that it would have stopped the RISC revolution, but still.
Specifically, the VAX CISC instructions overall, and the polynomial instruction in particular, were significantly slower than just using the regular VAX instructions to do the equivalent -- which was widely agreed to be unfortunate if not outright pathetic.
Nor was that particularly rare with CISC instructions. It's just a lot easier to make RISC instructions go fast, whether microcoded or not. It's typically not impossible to make CISC instructions optimally fast, but it's an extra cost in implementation and testing for the manufacturer, so it often got/gets comparatively neglected.
The Intel processor looping instructions re-fetched the instruction on every loop, so they didn't (and still don't, as far as I know) even save on the instruction fetch bandwidth.
Typical comment on that that I just found: "You should normally never use the loop instruction unless optimizing for code-size at the expense of speed, because it's slow. Compilers don't use it. (So CPU vendors don't bother to make it fast; catch 22.)" [1]
There was also a mindset issue (with both users and manufacturers) where it was viewed as a boost to assembly language programming to have fancy opcodes, although in retrospect that particular angle could have been just as easily addressed by the manufacturer with fancy assembly macros. I'm not sure why that was usually left to users.
> Maybe a derivative op belongs in a math coprocessor?
Sure, why not. Although theoretically it still needs to justify the opcode real estate and coprocessor silicon real estate and/or microcode space that it uses.
I personally like the concept of CISC, and I like things like Lisp machines, and I like GPUs, and so on. But they don't automatically justify themselves logically; it depends on the tradeoffs in each case.
[1] https://stackoverflow.com/questions/46881279/how-exactly-doe...
https://github.com/FluxML/Zygote.jl
the efficiency of autodiff might be similar to that of an opcode anyway.
So, how did DEC do on the Alpha processor? I always heard good things about it--IIRC (I didn't) it was ~~based~~ to replace the VAX, but 64 bit. I learned PDP-11 assembler at RPI, during their college program for high school students in about 1984. We hand assembled code and really got to know the architecture.
I guess everybody is gone from this post too, but I wonder if there is a fixed point corollary to Godwin's law--if you post enough off topic comments, you reach the original topic again. :)
Nobody noticed, because VGA was mostly found in '286 & '386 level machines, and TBH Windows 3.0 was not really aimed at XT-class PCs (8088 & 8086).
But the NEC V20 & V30 implemented the additional Real Mode instructions from the 80286 — so if you replaced your Intel CPU with an NEC equivalent, suddenly you could use VGA on Windows 3.0.