discussion

mpound types, and classic cell-oriented Forth kind of sucks at even mildly complex datastructures—they are certainly possible, but being unable to manipulate them as values on the stack makes things quite unnatural. (And that’s where I draw the line between Forths proper and “postfix Lisps” like PostScript, Joy, and Factor, as such manipulation doesn’t seem feasible without some sort of automatic memory management.) [1] https://github.com/ForthHub/discussion/issues/79#issuecommen... [2] https://github.com/ActorForth/ActorForth

ive-code compilers though, [2] and I expect they always will. More on how Forth collides with low-level CPU matters: [3][4][5] [0] https://www.complang.tuwien.ac.at/forth/threading/ [1] https://www.complang.tuwien.ac.at/forth/threaded-code.html [2] https://github.com/ForthHub/discussion/issues/88#issuecommen... [3] The Behavior of Efficient Virtual Machine Interpreters on Modern Architectures - https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12... [4] Branch Prediction and the Performance of Interpreters - Don't Trust Folklore https://hal.inria.fr/hal-01100647/document [5] Optimizing Indirect Branch Prediction Accuracy in Virtual Machine Interpreters - https://www.scss.tcd.ie/David.Gregg/papers/toplas05.pdf

ications at a time. All an operating system does is separate hostile C code applications from each other. C is probably not the best starting point to reboot society using 8-bit systems. Forth, or some derivative might be better. Charles Moore's original 1968 listings for Forth on an IBM 1130 are available from here: https://github.com/ForthHub/discussion/issues/63 Remember also that every mid-1970s microprocessor generally relied on a minicomputer (built from TTL) for its software and logic design. If you go back 10 years (1965) to the PDP-8 minicomputer, these were built from diode-transistor logic or DTL - made from discrete diodes, transistors, resistors and capacitors. This sort of technology could possibly be re-booted more easily for post-apocalypse society. The original 12 bit PDP-8 contained 10,148 diodes, 1409 transistors, 5615 resistors, and 1674 capacitors. See- https://www.pdp8.net/straight8/functional_restore.shtml Scale these figures by 1.33 and you have the approximate requirements for a 16-bit architecture. Whilst over 50 years old, the PDP-8 could run BASIC at speeds not too dissimilar to the early 8-bit micros that appeared in 1976 - about 10 years later. It used a modular construction - and if you did find yourself with an excess of diodes and transistors, the best approach might be to build a series of logic modules - loosely based on the 7400 series, but using DTL for simplicity. If you were to standardise on a footprint similar to a 40 pin DIP, you could probably recreate about 8 NAND gates in such a device. Some years ago I looked at the NAND to Tetris cpu, and worked out a bitslice design based entirely on 2-input NANDs. Each bitslice needed 80 NANDs, so a 16-bit machine would need 1280 gates. Memory would be difficult, but something could be implemented using shift registers. You could of course revert back to storing charge on a CRT screen - which formed the basis of the 1K words of memory on the Manchester Baby machine of 1949 (Williams Tube). Finally - never underestimate audio frequency generation, and storing signals as audio tones - something that cpus are good at. Possibly use a rotating magnetic drum for storage. In the summer of 1984 - a friend and I, who both owned Sinclair ZX81s set up a 1-way data link between one machine and the other across our college dorms - using a FM transmitter bug and an FM radio receiver - over a distance of 300 feet.