The nesting gets weird on this site. So, I'm replying to those all at once.

re Burroughs. Yeah, I guess there was some OOP principles in its combo of descriptors and modules. Didn't think about that. Many CPU's I knew about. Another thing was how you could pause processes on exception to correct or properly terminate them. Something LISP machines would brag about later on. Something I still want today in such a clean form.

re Hamilton. Appreciate confirmation on her skill. Yeah, AGC was some serious constraints. She didn't just do all that stuff in Wikipedia. Her follow-up was essentially inventing or commercializing correct-by-construction with HOL and 001 Toolkit work. Despite the usability & performance drawbacks, it was essentially model-driven development with mathematical notation plus semi-automated design plus automated code, test, and trace generation. Reminiscient of CASE tools but more rigorous & enforced resource use (eg real-time). Showed up in mid-70's. Dijkstra and Hoare's methods are what high-assurance designs used a bit after Hamilton's time in 80's-90's. Methods like Hamilton's are what high-assurance is developing now under DARPA and Euro contracts with subsets like Esterel SCADE in production. So, given inventing most key practices from scratch, I've been calling her the effective founder of software engineering and pioneer in high-assurance that was 10-30 years ahead depending on capability. Deserves way more credit than IT field gives her. NASA at least gave her official recognition plus largest, financial award per 2003 report.

re Flex. Thanks for the clarification. Yeah, the big Flex does seem to have made mistake Intel i432 did. Might be a limit to how much of a system can go into hardware with cost & performance efficiency. Still open problem.

re microcode. Never knew they mainly were trying to beat the RAM speeds. Gonna have to think on that as fighting memory speeds is a current worry in exascale presentations. The emulator advantage might be long-term esp for backward compatibility for existing or future systems. Worked wonders for AS/400's evolution.

re BEE3. Thanks for the tip! On concept level, I was working on an idea for something like this for virtual silicon to reduce number of prototyping runs, esp at lowest nodes. I was going to use instrumented FPGA's or something similar that also capture process-specific stuff. This might have valuable lessons.

re design for future. This one I have a hard time getting. For specific tech rather than concepts which make plenty sense. Reason being, it sounds like great advice for about the whole ride through Moore's law. Except most think that's over. So, we may have to modify your recommendation. Right now, they're casting a wide net with proposals + prototypes ranging from 2.5D-3D dies, massive multicore, low multicore + many HW accelerators, expanded GPU's, hybrid CPU/FPGA's, mixed signal (i.e. more analog), and so on. Landscape was homogenous for software where serial or somewhat parallel stuff just gets faster and cheaper. Now, it's so heterogenous that committing to one requires design that might kill success on many others with no clear winner in sight. Just a few likely survivors like Intel, GPU, offload, and FPGA approaches.

So, that poses a huge problem when I try to bet on the future for specific, HW tech. Here's some heuristics I have. It seems clear we keep things modular & interface in case HW accelerators show up for any function. Minimizing state or tight coupling is good as concurrency or caching issues will likely stay. Need to map design to coarse- and fine-grained parallelism, configurable or synthesizable, if possible since victor isn't decided. Design for scaling. Minimize effect of failures of individual components as higher transistors & cores = higher failures. Seemless detection and recovery. Protection mechanisms or about anything else still needs to be small and/or parallelizable to get high, clock speed. Much more research on cache design & optimization since it stays an issue. Continue focus on high-level languages that auto-generate to efficient, low-level implementations with extra focus on parallel/concurrent/hardware-friendly synthesis.

Those are off top of my head. I'm sure you've noticed the diversity and fragmentation of various HW and computing approaches happening. Have you thought about what to focus on or how to map the software to many emerging tech at once to minimize risk? I'm always up for opinions on it given we're years into exascale & post-Moore research with still no consensus far as I can tell as an outsider to HPC research.