What tweeks you would add for low level programing

Thinking about Forth and LISP, what features would one like added to the
instruction set of a average retro cpu for exotic programing.
I am looking for tweeks that I can add to my mostly finished FPGA cpu design.
Is a 0branch in Forth better done in hardware? For list processing how is the best
way to have a pointer with flags. Is a case statement loop better in hardware?
Ben.

Well, the “minor” tweak I suggest is redesigning everything from scratch around balanced ternary.

No, no, I’m not being serious. I like the idea of balanced ternary computing, but it hurts my brain even beginning to ponder everything that needs to be rethought from the ground up.

But the front panel would be cool, Red -1, blank/white for 0, Green for 1 for the blinking
lights, 3 way toggle switches.
Ben.
PS: Real soon
AbeBooks:
An experimental study of the uses of ternary logic in digital computers. (1964) [Leatherbound] re-print
Friichtenicht, Richard D.
The book has been shipped to you.
Price: US$ 20.36
Estimated Delivery:
on or before MAY 2,2023

My favorite “lost” feature is general indirection for any instructions involving memory access. It should be also rather simple to implement: on a given bit (as an extension to the general instruction code) perform an extra lookup on the value currently in the memory buffer register.
What it does: it transcends / blurs the lines separating storage and operations, with code that is self-modifying but still well controlled. (E.g., you want to add a variable factor to something else. We’ll just directly interact with the code in the value part of this addition in order to set it up in-place. Or, this makes it quite easy to have low-level object oriented code.)

Caveat: Nothing saves you from accidentally having infinite levels of indirection. (You probably don’t want to have more than two, and even this should be an exceptionally rare occurrence. This is also what is found as a rule in vintage operations manuals: Never have more than two levels of indirection.)

Somewhat related: remote execution. I.e. execute a single instruction provided in the given memory location. Again, we perform an indirection, but this time, we replace the contents of the instruction register (and, if this is a multi-byte instruction set, the operand that goes with this.)
What it does: it allows us to paramterize more than just operands. (E.g., if it’s a jump instruction in a configuration table, we may divert into entirely different branches of code, like switching input routines, etc.)

I don’t know.

But I do know that the BCPL compiler expects the underlying bytecode interpreter to do a lot of the hard work to execute a switch/case construct…

However it will help you. There are 2 switch opcodes and the compiler will pick the best to use…

The first is a simple list of values, so the compiler builds up a table that contains the value to test, the ‘default’ address then a list of pairs of value to test against and a destination address to jump to.

So one opcode and a list of numbers/tests and addresses…

The 2nd is similar, but rather than a simple list, it’s a balanced binary tree of values to test against. Used with larger lists of case statements or a more widely spread set of cases.

I feel that’s a lot to ask native hardware (microcode) to do but there you are…

-Gordon