Are we going back to programming in Forth now?

Once or twice a month Forth and Lisp posts get repeated...

So going back to Forth is probably not a good idea, but consider this....

1. Modern CPU microarchitectures issue multiple instructions/micro-instructions per clock.

2. Modern CPU microarchitectures rely heavily on register renaming in order to avoid bottlenecking on register allocation.

3. High code density is a huge win because: a) highly dense code reduces the cache footprint for a given amount of expressed functionality, which in turn reduces the amount of die area that need be dedicated to instruction cache in a well-balanced processor. b) highly dense code reduces the amount of bus traffic filling the instruction cache from main memory, thus reducing the overall memory bandwidth required to execute a given amount of functionality. Taking a & b together, they explain, in part, why X86 is still king of the hill, and it certainly explains why X86 won over Itanium. X86 code, for all its accumulated cruft, is very dense.

4. Stack machine code is also very dense, because exactly zero bits are dedicated to register names in every instruction.

So... given that the register numbers in typical 2-address or 3-address machines are getting renamed away anyway, why have them at all? Let the compiler generate 0-address code for a stack machine, and let the instruction decoder parse a long string of tokens during a single clock, using standard register renaming techniques to assign virtual stack locations from a large buffer pool. It could issue multiple stack ops per clock, but unwound into simple 3-address micro-ops for the CPU back end. It's really just the final step in moving the register allocator from the compiler to the CPU.

These are all solved problems for the X86 instruction set. Given that existence proof, it is difficult to argue that it would be hard to do for a clean stack-machine ISA.

This is the premise of the Mill architecture; though I haven't heard from them for a while now.

Really? The stuff I've seen about Mill is that they are doing a VLIW machine, which is a very different concept.

I don't know why the mill architecture has not gone into production yet. That technology has been in development for 13 years. It brings forth some interesting ideas. What is holding them back?

Isn't is a volunteer effort?

It is a startup though the degree of funding is not clear.

Haven't followed CPU arch in a very long time so my memory may fail, but the B7700 (1977) based on B5000 (1961) architecture demonstrated what you say on an industrial scale. The machine read in a long 48 bit string of opcodes, mapping them directly to hardware (adders, barrel shifters, inc/dec logic, branch prediction), maximizing throughput by anticipating needs for the next few clocks like setting up and (where possible) execute in different parts of the CPU. Since many operations were already present in pipeline and a cache miss or instruction branch could maybe predicted sooner you could see a long way into the future in some cases. This would leave the memory bus more free for data. And if I remember correctly, it would issue multiple (abstract?) cached stack operations to memory if possible, as the interface was quite sophisticated. And other CPUs could service the stack, SMP, if necessary. I had to troubleshoot these opcodes to the bit level back then, in 1981.

Did you keep any material about your time with the B7700? photos, printer listings, tapes, manuals? We're trying to build an emulator for the Burroughs B6700 (and by extension the B7700) so every scrap of information helps.

Very interesting! (I say this as someone interested in emulation in general, I sadly am not familiar with Burroughs equipment, although I know the name is synonymous with early cutting edge design.)

Does this project have any sort of publicly accessible online home yet?

nothing yet, we need to find a complete release of MCP for the Burroughs B6700 before we plan out the project.

Afaik, the Java virtual machine is also heavily stack-based.

Is that relevant to the hardware implementation though?

Most compilers use AST for internal intermediate code. TempleOS uses a stack machine intermediate code. At the end, it converts from intermediate code to x86_64 machine code.