It's from the 80s and has a fair amount of Forth content as well. I'm not sure where I got this link, but I'm finding it worth reading.

https://users.ece.cmu.edu/~koopman/stac ... index.html

It's my understanding that contemporary CPU designers see stack machines as a dead end, because they are not compatible with pipelines, speculative execution, and other optimizations. That's why many RISC designs don't use CPU flags with registers used for nearly all CPU state. Still it's interesting to see an alternative path.

Update: I just remember that I got the link from a page describing a stack machine someone built. It's here: http://www.mtmscientific.com/stack.html

Yeah, it's an interesting subject; I'm in the process of designing one myself. It's definitely understandable why they never caught on (it's not totally impossible to implement some optimizations, but it's definitely trickier than with more conventional designs,) but it's a fun little notion to play around with

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

@commodorejohn, thanks for the pointer to your stack machine ideas. I likewise have crazy ideas about building one. BTW have you seem the Mark 1 Forth computer?
http://www.aholme.co.uk/Mk1/Architecture.htm

@garth, thank for the links. I see a link to my link already there.

Yeah, I ran across that back when I first started looking into a stack-based design. Definitely a nice simple project, but I really wanted to do a 16-bit design* and got inspired by the PDP-8/DG Nova approach of exposing the simpler micro-operations to the programmer directly

* (Of course, since I can never have just one project, I've already started sketching out a 32-bit extension to the architecture...but that'll have to wait until I've even successfully implemented the first version...!)

By 16 bit I assume you mean a 16 bit ALU, as the programming model on the Mark 1 is 16 bit in two 8 bit cycles.

I really need to learn more about the PDP-8 and DG Nova. The first DEC hardware I worked on was the PDP-11 and then VAX. As CISC machines they probably had a very different feel to the programmer. The modern RISC CPU's I've worked with have such high transistor counts that they don't feel that different from old school CISC machines.

Yeah, the -11 (along with System/360) definitely kicked off the "large register file and comfortably orthogonal instruction set" model that most later 16/32-bit CPUs (8086 excepted) would take their cues from. The -8 is much more in line with the 6502 approach of having just enough functionality to get by on and building everything more complex out of the available operations. de Castro got a bit more elaborate with the Nova, but only so much.

I just finished reading a PDP-8 assembly language primmer. My head hurts because it's so primitive. There's no load instruction! Instead you have to clear the accumulator and add memory to it. There's no software stack at all, so it makes the 6502's tiny stack seem luxurious.

To bring it back to the 6502. The PDP-8 used memory pages and a page zero direct and indirect addressing mode that's vaguely similar to the 6502. Also, using page zero as essentially additional registers seems similar too. I now wonder just who came up with the concept.

Yup - it was intentionally designed as a minimalist architecture, and boy does it show ;D (Note, also, that there's no subtract instruction, 'cause you already have instructions to ones-complement and increment the accumulator - negating it - and add! No OR or XOR operations in the base instruction set, either, because these too can be synthesized from what's available.) Still, it's kinda fun, once you've wrapped your head around it; assembly-language programming is already about breaking down complex operations into sequences of simpler ones, it's just that the PDP-8 makes you do that to get to where most CPUs start from

The question of influence on the 6502 is a good one. DEC's accumulator-based machines weren't the only ones with a paged addressing model, and the 6502 more likely got zero-page directly from the 6800, but the 6800 doesn't have the memory-indirect addressing feature that the 6502 shares with the PDP-8. The 6509 even borrows the -8's extended addressing convention wherein direct addressing maps to the "near" bank and indirect addressing maps to the "far" bank. You gotta wonder...

I went further down the rabbit hole and found this web page:
https://homepage.cs.uiowa.edu/~jones/pdp8/faqs/

Which claims that:

I also did a deep dive on DG Nova programming. It looks much easier than PDP-8 programming, almost normal in fact. I also like the assembler syntax as well.

Yeah, that makes sense; the 160's influence reaches far.

And yes, the Nova is quite a nice little architecture. The combination of conditional-save and conditional-skip bits right in the opcode is particularly nice (and fairly ahead of its time.)

I've read this thread with interest. The meanderings taken here match those that I've also taken. I really like Doug Jones' pages on the PDP-8, and many of his other pages on computers.

The I/O processors for the CDC 6600 have been a real inspiration. They were significantly ahead of their time. The use of a single 10 MHz ALU plus 10 independent 1 microsecond core memory arrays are a really effective example of economy. The same 12-bit memory modules used for each on the I/O processors were used in the implement 60-bit core memories of the main processor. A great example of the use of modularity in the design of a real system.

On the stack machines front, I have a copy of Dr. Koopman's book linked to above. I used some of the data he provides on the instruction frequency of important Forth primitives (Table 6.1) to help me decide which Forth primitives to implement as dedicated instructions in the Forth Virtual Machine function block built into my M65C02A extension of the 6502/65C02 family architecture. I've used the descriptions of stack machines in Dr. Koopman's book, Dr. Brad Rodriguez's Moving Forth articles, and the Inmos transputers as models for several stack machines that I've implemented in FPGAs. The Burroughs B5000/B6500 family of processors are also good to review when stack machines are being considered.

_________________
Michael A.

Another stack computer https://users.ece.cmu.edu/~koopman/stac ... ec5_2.html

This one is supposed to be targeted to Forth.