jecel

Here the `int` is being used in place of `char *`, not `char`.

And yes, the PDP-11 did have byte addressing while the PDP-7 on which Unix was originally created was a word addressed machine.

An interesting option is rod logic, which is the mechanical equivalent to a PLA (programmable logic array).

https://www.jamiekawabatarobotics.com/?p=40

The first ATMega, the ATMega603, needed an external device to write to its Flash program memory. The following models removed this restriction.

"No-one would claim that a modern Harvard Architecture computer with its program stored in ROM isn’t a stored-program computer. So does ENIAC take the prize from Baby as the first electronic stored-program computer?"

I do actually claim that a modern Harvard Architecture computers such as the AVR8 or PIC microcontrollers are not stored-program computers. You can't store a program in them and then execute it. To be fair, some MCUs can change their own Flash so the difference can be subtle - in that case the processor is used either normally or as part of the ISP (in-system programming) circuit at different times.

For very simple stored-program machines the ability to modify running code is needed for it to be Turing complete. In a computer like the Baby, how would you add two arrays? It had no index registers. So you would need to increment the instructions that load and store from the arrays every time you go through the loop. I agree that this isn't an issue on a machine with only 32 words of memory in all, but it is a key idea in theory.

Of course, a Harvard computer can simulate a Von Neumann one (see AVR8 simulating an ARM in order to boot Linux where it does indeed store programs and then run them). In fact, a popular way to implement CISC computers was to build a tiny Harvard machine running a single program in its "microcode ROM" emulating the computer you actually wanted to use.

The Apple I had a single 256 byte bipolar PROM for its WozMon debugger. Though the Apple II used ROMs (EPROMS were popular in clones) the expansion cards still were supposed to use tiny PROMs for their drivers (in the case of the disk controller there was even a second PROM for the state machine - Woz did love these devices).

The Altair 680 had sockets for four 256 byte PROMs. One was for the debugger, but a popular option for the other three was the VTL-2 (very tiny language) interpreter. Pretty amazing that they fit a Basic-like language in just 768 bytes, though implementing some language in the 510 byte boot sector has become a popular hobby.

I did a 16 bit processor that is compatible with RISC-V at the assembly language level but has its own binary encoding:

https://github.com/jeceljr/digitalCPUzoo/tree/main/drv16

It is meant as a helper processor in larger FPGA projects. These need less than 64KB of memory. drv16 is about the same size as the tiniest RISC-V (SERV, Glacial) without the huge performance penalties these have.

Just expanding it from 8 to 16 bits makes it practical, if still awkward. I implemented the 2048 game on that, for example.

https://github.com/jeceljr/digitalCPUzoo/tree/main/MCPU

> + 2 others that I honestly have no idea what they do

The original RV32I and RV64I required some control registers for high frequency counters and instruction counters. You also needed the instructions to access these registers. This proved to be too complex for the simplest implementations, so recently (five years ago?) this functionality has been moved to their own extensions.

Including these extensions in G makes the current G have the same functionality as the original G.

Dataflow processors have not been forgotten - there is one inside every high end CPU core. The code in main memory in the form of conventional x86 or ARM machine language gets translated first into "micro ops" in the decoder and then into dataflow machine language in the register rename + reservation stations + completion buffers (collectively implementing "out of order" execution).

But, as the old saying goes, "out of sight is out of mind".

In the late 1990s there was a fun geek webcomic called "After Y2K" that imagined a very different world caused by a huge disaster. I didn't expect anything other than what actually happened, but a lot of people actually believed some of this stuff.

https://www.geekculture.com/geekycomics/Aftery2k/aftery2kmai...

I did an email interview with a major publication in Brazil about the Y2K issue and carefully explained what would and what would not be a problem and how the most serious issues had been fixed at a significant cost. They ignored everything I said and only posted "Mainframe computers will be with us for a long time, says Jecel" in a way that made it sound like a threat. The rest of the article had the typical horror scenarios. They wasted an opportunity to be able to gloat about being right.

Robert Cringely's "Y2K: The Winter of our Disconnect?" was about the only voice of reason in the media back then and he got angry emails saying thing like "the blood of all those who died due to his misinformation would be on his head".

"The terminology of calling computer parts "organs" is gone now, but the "Control" here describes what we now commonly refer to as CPU."

Actually, what was described is currently called the "Control Unit". We divide CPUs into a Datapath (which includes registers, busses, ALU...) and a Control Unit which is either hardwired or microcoded. Decoding instructions is the job of the Control Unit though it might get a little help from the Datapath in some designs.

The block diagram for a modern processor at the end of the article is just the Datapath - the Control Unit is not shown at all which is the most popular current style. It must actually exist in the chip and HDL sources, of course, if the processor is to actually do anything.

It is possible to build single cycle Harvard computers but not von Neumann ones. So a course on computer architecture using, for example, RISC-V as a concrete example might start out showing a Harvard RISC-V with a single cycle implementation. The next step is a multicycle von Neumann version and the third step is a pipelined RISC-V using caches to make a locally Harvard, globally von Neumann implementation.

Herman Goldstine made the decision to distribute the report. Though Eckert and Mauchly liked to think they came up with the idea before von Neumann came along and that he got the idea from them, it is very hard to know if that is true. Kurt Gödel, who von Neumann helped get out of Austria at the start of the war and come work with him at Princeton's Institute of Advanced Study, had already published the idea of using numbers to encode algorithms as part of his famous 1931 proof. And while Turing Machines use the Harvard architecture, the Universal Turing Machine at the end of Alan Turing's 1936 paper is a von Neumann one.

The RISC-V creators were aware of the issues when they designed the C extension with 16 bit instructions to be able to compete with ARM's Thumb. So the bottom two bits of an instruction are enough to distinguish between 16 bit and 32 bit encodings (the standard has a scheme for future longer instructions, but hardware that doesn't implement them can ignore that).

This means that if a RISC-V reads a 16 byte block from instruction memory, it only has to look at 8 pairs of bits. This would require 8 NAND gates plus 8 more NANDs to ignore the top half of any 32 bit instructions. That is 4x(8+8)=64 transistors.

The corresponding circuit for x86 would be huge.

But note that this just separates the instructions. You still have to decode them. Most simple RISC-V implementations have a circuit that transforms each 16 bit instruction into the corresponding 32 bit one, which is all the rest of the processor has to deal with. Here are the sizes of some such circuits:

Hazard 3: 733 NANDs (used in the Raspberry Pi RP2350)

SERV: 532 NANDs (serial RISC-V)

Revive: 506 NANDs (part of FPGAboy)

You would need 8 such circuits to handle the maximum 16 bit instructions in a 16 byte block, and then you would need more circuits to decode the resulting 32 bit instructions. So the 16 NANDs to separate the variable length instructions is not a problem like it is for other ISAs.

The problem with 16 bit instructions for small RISC-V implementations is that now 32 bit instructions will not always be aligned with 32 bit words. Having to fetch an instruction from two separate words adds circuits that can be a large fraction of a small design.

It is better to say RVC is almost never present without the full-size 4 byte instructions since we have one counter example:

https://github.com/gsmecher/minimax

This is an experimental rather than practical design that only directly implements the compressed instructions in hardware and then implements the normal RV32I instructions in "microcode" written using the compressed instructions.

While Trilogy ran into technical problems, Sinclair's Anamartic actually delivered working products:

https://www.computinghistory.org.uk/det/3043/Anamartic-Wafer...

The long term plan was something not that different from what Cerebras does, but in order to not scare possible investors their first product was a battery backed wafer scale static RAM to replace hard disks. This market looked attractive since disks had been stuck at 20MB for a while. But right when Anamartic got ready to sell hard disks started to grow like crazy, first going to 30MB by moving from MFM to RLL then jumping to 40MB, 80MB, 160MB, 250MB and so on. This caused all of Sinclair's investors to pull out.

Note that the country's full name has been "República Federativa do Brasil" only since 1968. Between 1889 and 1967 it was "Estados Unidos do Brasil".

https://pt.wikipedia.org/wiki/Estados_Unidos_do_Brasil

A very nice book is "Designing Video Game Hardware in Verilog" by Steven Hugg and is part of a series of books that is supported by

http://8bitworkshop.com/

I am writing a book somewhat similar to this (currently in Portuguese, but later in English and other languages) using the Digital simulator in Java for the examples as schematics, though they can be exported as Verilog for implementation in FPGA boards.

https://github.com/jeceljr/LivroComputadoresEVideogames

Each chapter represents a video-game console generation, with hardwired Pong and Soccer in the first chapter. I am now working on replacing the game logic in Soccer with a 16 bit version of RISC-V for the second chapter and then improving the video and sound to Colecovision levels. In chapter 3 we will have a 32 bit RISC-V with NES level graphics and sound, with a pipelined RISC-V with something like the Gameduino for chapter 4. The 8 Bit Workshop will let readers program the actual consoles from each era and not just our retro designs.

One additional obstacle for modern audiences is that the TV sets themselves are computers running software. They take a MPEG-2 or MPEG-4 file coming in some network port and send it to some mixed parallel/serial interface to a LCD or similar panel.

If you understood how a 1970s TV worked (specially the simpler black and white ones used in the first video-games) then imagining a circuit that would generate the needed signals was a bit easier.

This reminds me of the "Kansas" environment in the Self programming language. Here is a video about it from Sun in 1995:

https://www.youtube.com/watch?v=Ox5P7QyL774

More interesting search features were added after this video was made.

I am more familiar with the F18A predecessors, such as the F21, than with this design. So it is quite possible that it is a proper asynchronous processor even if the older ones were not.

I am biased by some confusion I observed about the F21. There are two ways to design an ALU: an efficient solution is to combine the inputs and control signals using as little logic as possible to generate the results or to have a separate circuit for each operation and then have the control signals use a multiplexer to select the desired result.

A great example of the first style is the ALU in the ARM1:

http://daveshacks.blogspot.com/2015/12/inside-alu-of-armv1-f...

Many simple educational processors use the second style, as did the F21. In addition, the adder in the F21 was a simple ripple carry adder. In theory, you would have to use a clock slow enough that the + instruction would have enough time to generate the correct result even in the worst case. In the first ALU style that would certainly be true, but with how the F21 was actually designed just executing one or two NOP instructions before the + would work just as well. As soon as the values of the T and N registers were stable the adder would start to ripple and calculate no matter what instructions were being executed. Only when we get to the end of the + instruction does the result need to be ready.

This allowed the amazing demonstrations of some F21 chips, which used 800nm technology, running at 800MHz. This hand scheduling of code to allow frequencies beyond what some instructions could handled was described at the time by several people as being an asynchronous processor design, which is wasn't. That is why I am a bit wary when I see that term used for the descendants of the F21 even if it turns out to be correct.

Another interesting issue with running the F21 at 800MHz was that Chuck Moore's OKAD tools did not originally simulate heat transfer. As a result two transistors were a little smaller than they should have been and could burn out at such high frequencies. Inserting NOPs between instructions allowed these transistors to cool down enough not to be a problem. His next version of OKAD included a neat thermal model in order to avoid that mistake in future designs.

It is far easier to join two asynchronous blocks into a larger system than two synchronous blocks. So place and route would be less critical.

If I understood correctly, the GreenArray chips don't have a clock but each individual core does via a local ring oscillator. So it might run at a different speed than its neighbors and the communication system handles that.

A more famous clockless processor was Amulet, an asynchronous implementation of the ARM. https://en.wikipedia.org/wiki/AMULET_(processor)

The comments show a lot of confusion about what Tesler invented. Other industries did indeed use cut/copy/paste and older editors had ways to do these functions. But the cursor in these editors normally indicated a character. Larry figured out that if instead the cursor indicated the space between characters and he sometimes had a second such cursor to indicate all characters between them then he could do what previous editors needed various commands with a single operation: replace the selection with what has just been typed and move the cursor to right after that. "paste" would the just the equivalent of retyping a previous selection that had been either "cut" or "copied".

If the two cursors were at the same spot (just a blinking vertical bar) then you are inserting text as you type it. If there was some selected text then you are replacing it and then inserting anything more you type. And so on.

Both at Xerox Parc and at Apple he actually tested his ideas on potential users and often found he guessed wrong about what would work and what wouldn't. He would then try something else.

The 74181 has four signals to select the operation (S0 to S3) but also two modifiers. M=1 selects logic functions and M=0 selects math functions (which will be slightly different depending on the value of carry in). So there are 3x16 = 48 possible operations, though they are not all distinct.

https://en.wikipedia.org/wiki/74181

Nearly all current computers address bytes, but in the past we had many computers that addressed words instead as well as processors like the Texas Instruments 34010 that did address bits.

"Computer architecture" is used in several different ways and that can lead to some very confusing conversations. Your proposed stack has some of this confusion. Some alternative terms might help:

"computational model": finite state machine, Turing machine, Petri nets, data-flow, stored program (a.k.a. Von Neumann, or Princeton), dual memory (a.k.a. Harvard), cellular automata, neural networks, quantum computers, analog computers for differential equations

"instruction set architecture": ARM, x86, RISC-V, IBM 360

"instruction set style": CISC, RISC, VLIW, MOVE (a.k.a TTA - Transport Triggered Architecture), Vector

"number of addresses": 0 (stack machine), 1 (accumulator machine), 2 (most CISCs), 3 (most RISCs), 4 (popular with sequential memory machines like Turing's ACE or the Bendix G-15)

"micro-architecture": single cycle, multi-cycle, pipelines, super-pipelined, out-of-order

"system organization": distributed memory, shared memory, non uniform memory, homogeneous, heterogeneous

With these different dimensions for "computer architecture" you will have different answers for which was the weirdest one.

Wouldn't that be the 34010?

One difference between the standard cells in the article and the current ones is that the routing channels have been eliminated thanks to the many metal layers we now have. Back then we couldn't really afford to have metal cross the Vdd and ground lines at the top and bottom of the cells so we just stretched the polysilicon lines to the top and bottom edges. Routing was done by continuing the poly into the channel and then connecting cells with metal. This meant that though the decapped poly lines are just one thing in the photos, in terms of design the parts inside the cells are standard and the parts in the channel are custom.

This scheme works even with just poly and one level of metal, but if you have enough metal layers than you can run them through the cells themselves. You just have to avoid the vias that take the inputs and outputs down to the transistors. You have an additional gain if you flip every other row of cells so that the PMOS of two rows have the Vdd rail overlap and the NMOS of two rows have the ground rail overlap.