Discrete CPU build: logic type, architecture...?

[SiliconWizard]

A serial CPU would indeed be a challenge.
What I imagine being the most difficult for both simulation and debugging is that you somehow have to decode/visualize the entire bitstream (56 bits in case of the HP-35) to find out if it does what it should.

Any decent logic analyzer would make this a breeze. And if you still wanted a more custom view of things for debugging purposes (or you found logic analyzer software not "productive" enough for your purpose), you could always design deserializers just to be able to easily "watch" streams as you debug. Would just take shift registers and a means of displaying the "values".

[szoftveres]

Here's my project: https://hackaday.io/project/11703-microcode-less-ttl-cpu

The CPU control logic boils down to the program counter (4 x 74HC161), two D flip-flops (74HC74) and 1-2 miscellaneous discrete gates. All the rest is just I/O registers and gates, which (by definition of the transport-triggered architecture) serve as the rest of the computer. The cool things about the transport-triggered architecture are absolutely minimal control logic, and modularity (e.g. you extend the inner guts of the cpu as much as you want). The downside is the lack of more sophisticated cpu functions, like stack, subroutines, etc.. but clever software can make those functionalities available (more on the page).

[Martinn]

Here's my project: https://hackaday.io/project/11703-microcode-less-ttl-cpu

Interesting! One might say that the program code IS the microcode...
How do you implement shift operations? Seems tricky with an adder only.

SiliconWizard mentioning of the serial processors (extinct since HP-35) made wonder: What is the optimal processor design in terms of transistors/performance? Of course the "performance" metric is difficult to define.
Serial CPUs are interesting as they utilize few transistors on the data path, while the registers are the same as with parallel architectures (DFF count parallel vs. shift registers is identical) and they are slow.
Another example would be: I could add the parallel multiplier with ~2000 transistors, giving a very fast multiplication, but probably rather inefficient for overall performance (unless you are doing FIR filtering).
Or, in 6502 speak: Does adding X and Y registers together with their indexed adressing functionalities provide enough benefit to increase transistors/performance metric?

[Kleinstein]

A 2nd register definitely helps with the performance. For the 3rd register (e.g. y) the return is usually smaller.  It also makes quite some difference how fast memory access is compared to the operations inside the CPU. With modern highly integrated memory (e.g. SRAM) and discrete logic the memory is quite fast. In the old times with core memory, memory was relatively slow.

More / more powerful  commands for the CPU can make the code shorter and this way save on the transistors needed for the memory and maybe a address line.

Looking for an optimal design, one can likely not just look at individual parts, like register width, mr registers or a HW multiplier or not. Some of the alternatives work well together, or call for other changes. E.g. an efficient hardware stack gets more important the more the stack is used. The rel. modern RISC V design has some new ideas (also in parts left out) that may be worth a look to get off the known old stuff.

Things depend a lot on the programs to write - some code may not need a 2nd register, while others get awfully slow or long without.
For comparing different possible CPU designs it would be about comparing a few real world program parts, like FFT, FIR filter, some sort algirithm, maybe a simple state machine, ... .  Not every design would shine at all tasks.