They apparently existed from 1969 to around late 1970ish or perhaps early 1980ish, during which time they made computers which were open to Microcode programming by the end user -- they even gave the end user a manual on how to do it:
What other systems did they build similar to the PALM?
I remember as a young kid buying a quite large (~3ftx4ftx3ft) IBM minicomputer that was just filled with those modules at a local thrift shop during the late 80s.
No keyboard or screen, although I seem to remember it had an 8in floppy drive.
Its been so long I can hardly remember it, but I distinctly remember those cards with the square metal cans, many of them socketed. It had a really nice set of schematics and service manual inside the case also.
edit: After some google digging, it must have been something like a 3274 terminal controller.
This is tremendously interesting, if it would have worked (and if I could time travel), then I would have wanted it!
10 or 15 years ago I was reading the classifieds, and a local company was dumping an entire mainframe system with terminals. I don't remember which one it was, but I think I looked up the model numbers and I found it was something like a $150,000 mainframe system ten years earlier. The price? Make an offer! I probably could have had it for a couple of hundred bucks and U-Haul rental charges!
But yeah, I would have wanted one of those if it worked!
Despite my parents being computer illiterate, I'm glad they were pretty understanding. I never had any IBM experience but I had spent plenty of time on MicroVAX, HP 9000 and later with Sun. I did a number of local pickups (ahh the memories of trying to shuffle a HP9000/835 down Columbia tower and into a dodge caravan) of hardware and knew a person who worked with Sun in Seattle who would sell me old demo stock for a $1. I spent years trying to get rid of it all, no one would take it even for free, and unfortunately had to recycle most of it. Although the Paul Allen museum bought some of DEC Alpha stuff. It just cost too much electricity to even play with.
The Xerox Alto had a custom CPU that used microcode extensively - the CPU actually did most system management tasks like re-blitting the entire screen for every new frame and managing disk I/O, and only when it wasn't handling these scheduled tasks did it execute an "emulation" task that actually executed arbitrary code.
In the sense that you have microcode presenting a high-level instruction set that internally is executed as a low-level instruction set, yes. (There are clearly implementation differences, so if you'd pedantically want to find a distinction there are plenty.)
It would be interesting to see a history of CPUs in terms of their layers of abstraction. When was something like "MOV AX, BX" invented, and how far is that from physical ones and zeros (ons and offs) in the silicon? Obviously I'm not a CS graduate.
A CPU's registers is where all of the "bit transformation" (adding, subtracting, multiplying, dividing, branching) work that Computers do, is done. Registers are like very small scratchpads, typically 32 or 64 bits (or 4 bytes/8 bytes) wide. Computers with as little as one main register for calculation, and another register for which instruction in memory is executing (instruction pointer) are possible. CPU's as low as 4 bits have existed (Intel 4004), although there's no reason electronically a CPU could use less bits than that (well, in order to execute a program, you need an address in memory, and for that you need more bits for larger addresses, i.e., more memory). Every electronic calculator from the 1970's is a computer IF it had memory, conditional instructions (if results of last calculation were greater than zero, go to (change instruction pointer) to this new address, otherwise, continue with next instruction. MOV AX, BX is an abstraction for programmer consumption only, a CPU's basic instructions are something like:
1) Move value into accumulator (AX, R1 or EAX or RAX or R1 or Reg1) from somewhere in memory.
2) Perform some sort of calulation on it (Add, Subtract, Multiply, Divide, Bit Shift, And, Or, etc.)
3) Store it back to memory
4) Execute a conditional branch instruction which says, as a result of the last mathematical computation, either a) jump to a new address (bypass a section of code), or b) continue with the next instruction.
The Zuse Z3 is probably the simplest Turing-Complete computer that was ever invented (in 1941 no less!); I'd start there:
The Z3 is a floating point machine... I'd wager that it is more complex than the 4004. While the 4004 has a couple more transistors than the Z3 had relays (about 600 in the "CPU"), the telephone relays used by the Z3 had many circuits and thus can perform more complex stuff than a single transistor in a logic circuit.
An ALU (Arithmetic Logic Unit) that does simple addition and subtraction, binary negation, and integer comparisons.[1]
A collection of registers that store binary bit patterns.
A set of data path switches that connect the elements together in various ways - e.g. so you can connect a register to an ALU and do some math on it, or copy the output of one register to another.
There's also an instruction decoder which converts MOV AX, BX into a set of control signals for all the other parts. For example it sets up the data path switches, connects AX and BX, and then triggers a write on BX.
The first instruction decoders were made from hardwired logic. They shipped with the computer, and they were impossible to change. [2]
Then it was realised that the logic could be replaced by a kind of nano-program for each machine instruction which set up all the elements dynamically.
This could be baked into ROM, or it could be loaded on boot. The latter meant instruction sets could be updated to add new features to the CPU. This also meant the same hardware could run two different instruction sets. (A nice trick, but often less useful in practice than it sounds.)
The real advantage was a cut in development time. Instead of having to iterate on board designs with baked-in instruction decoding, the hardware could be (more or less...) finished and the instruction set could evolve after completion. Bugs could be fixed at much lower cost.
It also meant the instruction set could be extended almost indefinitely with no extra hardware cost. (DEC's VAX was the poster child for this, with linked list manipulation and polynomial math available as CPU instructions.)
And it meant that cheaper CPUs in a range could emulate some instructions in compiled software, while more expensive CPUs could run it at full speed in microcoded hardware - all while keeping code compatibility across a CPU family.
The modern situation is complicated. Modern CPUs are fully modelled in software before being taped out and manufactured, so boot-loadable microcode isn't as useful as it once was.
ARM is fully hardwired (so far as I know) but x86 has a complex hybrid architecture with some microcoded elements - although I believe they're fixed on the die, and can't be updated.
[1] More complex CPUs have floating point support, but the principle is the same.
[2] In fact the earliest decoders were diode arrays, which could be swapped out and replaced. So the idea of microsequencing has been around almost since the first CPUs were built.
Intel asm opcodes are translated to processor-specific microcode instructions.
The "microcode updates" actually rewrite the microprograms for each opcode.
If users had access to microcode(not likely anytime soon) very powerful optimizations could be done to create optimal instruction sets for each task.
Today's x86 CPUs usually contain some kind of microcode but it is distinct concept from uOPs (micro operations) that are usually referenced in high level micro architecture descriptions. Incoming instructions are decoded by some combination of hardware and microcode into uOPs that then get executed by RISC-like execution units.
Then there is slight terminological problem with the tendency of both Intel and AMD to label essentially any binary blob they don't feel like documenting as "microcode", ranging from few bytes of configuration data, through actual CPU microcode to complete RTOS images for some embedded CPU.
Wasn't that similar to those Transmeta processors that had most of their instruction set written in software? Seemed like a cool idea, but (as I recall) the Transmeta processors couldn't keep up speed-wise with the existing x86 CPU's.
Eh, the Transmeta Crusoe (first gen) processors had pretty decent performance compared to Pentium M at much lower TDP. The Transmeta Efficeon (second gen) had performance comparable to bigger processors but had some thermal issues that hindered it a fair bit. Efficeon kinda lost Transmeta's original goal of decent performance at lower power consumption, and they went downhill afterwards.
They weren't great but for a small, ambitious company without much chance to iterate they definitely weren't bad.
The technology got incorporated into NVIDIA's Project Denver ARM chips, which were very fast… sometimes. Actually, Denver 2 is shipping in the new Jetson devkit, but I haven't seen much about that or been able to get my hands on one.
That's the general problem with VLIW chips, is that they're amazing on some workloads and pretty bad on others. Itanium, for all its faults, was by far the best general-purpose VLIW CPU.
Thanks for the rare fair comment. People are quick to forget the difference between concept and implementation. The Transmeta concept was clearly viable, but the implementation needed more iterations to before we can fully judge the concept.
Your comment about VLIW is true, but in this case that was a 2nd order effect. Far far worse was The effect of the JIT (CMS): a small kernel running over a long time (e.g., DVD playback) would work absolutely excellently, even on the Crusoe, whereas a large codebase with relatively little reuse (say, Word) would give very uneven performance. This problem was never solved [at Transmeta].
The irony is that today, x86 compability is irrelevant in most places.
Yeah, code-morphing/hardware JIT is extra weird (and probably why Nvidia's Project Denver kinda tanked—turns out, that doesn't work too great for smartphone apps).
One thing I've thought about is having a code-morphing CPU as a sort of accelerator that a single process could be offloaded to (of course, this would require an OS that can marshal processes). Think a database server, a JVM, NodeJS—long-running processes that would benefit from JIT.
Might even be viable with upcoming cache-coherent interconnects like CCIX and GenZ. A more ambitious implementation could offload groups of functions.
Transmeta CPUs used a VLIW architecture with a software layer that decoded x86 instructions into VLIW instructions. The software worked a bit like a JIT where optimizations would be applied to frequently running code.
I would credit them for pushing Intel (and AMD) to optimize for power savings rather than raw speed, because Intel started making significant perf/W improvements.
Transmeta processors were (I believe) the first x86 processors to automatically vary voltage and clock speed multiple times per second. In fact, I wrote a small utility that would display the current clock speed on your taskbar in a graph because it changed so rapidly.
It was a cool idea. That was its point, lower power for acceptable performance. It wasn't trying to be the fastest; their value proposition was being able to play a DVD on a SF NY flight on battery. But Intel pivoted and did that too.
The problem was that back then the platform (chipset, etc) consumed a significant amount of power as well, so even dropping the processor to Atom level TDP couldn't really achieve that much given the rest of the system.
Anyone remember Moblin? Apparently Intel started work on that Linux distro because Microsoft balked regarding an x86 platform without PCI device lookup. And Intel removed the PCI stuff in an effort to cut power drain.
As an aside, running windows on ARM to this day require special SoCs.
The Transmeta Crusoe also included most of the features of the "chipset", it had PCI and memory controller built in at a time when other manufacturers' CPUs didn't.
You still needed to add a display controller but that was true of all the competing CPUs too.
A few years back I re-implemented a microcode assembler that I had used in a silicon valley startup in the 1980s. I used some of the features of Haskell to do it. See metalasm on Sourceforge. It can now do disassembly of horizontal microcode as well.
My first programming job, also.
One Christmas in the late 70s I had three 5120s set up in my living room. I was programming a complete accounts receivable system with reporting and data entry (I was an accounting major, long before small colleges had CS degrees). When all three were running I could turn the heat off, and still have to open a window in the middle of winter. I paid off my college loans with those computers.
One thing not mentioned in any of the discussions was how impossibly slow the systems were. I ran the sieve program from Byte magazine a few years later and the results came out in last place.
I coded in BASIC and the IBM BASIC had a wonderful ISAM built right into the language that made it very easy to handle indexed files. If you have ISAM, you don't need a database.
I took my last 5120 to the the salvage yard 30 years ago. I still have some 8 inch floppies with the code for my very first programs. Unfortunately, I have no way to read them.
The 5100 / 5110 used two emulation layers, one for the S/360 architecture, used to tun APL 360, and a S/3 emulation used to run BASIC. Amazingly, these emulation characteristics weren't disclosed in the manuals.
Don't miss to google "John Titor" in this context ...
Yeah, I poured over the Mick and Brick book. Once place where you can find bit slice processors with microcode is early hard drive controllers. I remember also a SASI floppy controller which used the 8x300.
Modules for these machines come up on eBay for lowish prices. I have enough different retro systems already, but it'd be neat to have just one of those neat looking wire-wrapped cards.
These are chips with a large grid of gates, which they have in common with FPGAs, PLDs, PALs and the like, but you program them by changing the final metalisation layer during manufacture rather than by feeding a bit-stream into them at initialisation.
They were cheaper and faster to make than truly custom chips. A stock of etched and doped silicon wafers could be held by the manufacturer, so they only needed one mask for the final metal layer to be produced for each customer. This also meant that the turnaround from order of a new design to delivery was faster, as only that single mask needed to be prepared.
Is there any information about the microcode, or the hardware architecture? I'd be interested in what caliber of today's guns one would require to emulate this thing.
They apparently existed from 1969 to around late 1970ish or perhaps early 1980ish, during which time they made computers which were open to Microcode programming by the end user -- they even gave the end user a manual on how to do it:
http://bitsavers.trailing-edge.com/pdf/microdata/3200/761020...
This manual should be entitled "How to build a late 70's style Microcode programmable computer". It really gets into the guts.