[cctalk] Re: Forth on the HP 3000: Alternate History

On Tue, Jan 16, 2024 at 5:53 AM Rodney Brown via cctalk <cctalk(a)classiccmp.org> wrote: In related news, we're not too many days away from Dave releasing update 13 of the HP 3000 SIMH, which can simulate an IMB / HP-IB I/O based HP 3000 Series 58 and that means we can now run all versions of MPE V/E up to and including Release 40, the very last release of Classic MPE which is even Y2K compliant (cough, for the next four years, cough). MPE fans can expect a complete MPE V/E Release 40 turnkey version in the very near future. I wouldn't call the classic 3000 a Harvard architecture. It's just that its designers probably knew the issues surrounding self-modifying code and decided that all executable code was going to be reentrant and shareable which means it never has to be swapped "out", does not require separate VM backing store (it's swapped in directly out of the program file or SL library file), etc. so it has to be "read only" under execution. The ideas of dynamically generated code, JITs, etc. just hadn't caught on yet. Besides FORTH etc., this caused issues for things like APL\3000 which was developed at HP Labs in the mid 70s. They made it the world's first dynamically compiled APL, but ran into the read-only-code limitations and so they decided to target a virtual "eMachine" rather than native code and then interpret that intermediate code at runtime. They even included a couple new CPU instructions in the APL microcode to accelerate the dispatch of the virtual machine instructions. Unfortunately APL\3000 suffered from performance issues which pretty much doomed it (which is sad because it would really have shined as later machines got faster and wider). But now in retrospect I wonder why they (and others) didn't just say "Ok guys, we need to dynamically emit and modify code now please." and solve the problem properly. It seems like it would be a relatively small amount of code to implement effective workarounds, even in the extant MPE software and hardware environment. One thought would be to provide a big SL library file full of code segments that are nothing but NOOPs, and then have the application choose one of them and just write the code directly into the segment in the SL file and then dynamically load it. A few more lines of code to update the code segment in memory if it's already present. "ZOMG! Hax! Privileged Mode!" you may cry, but geez, all this stuff that looked scary at the time sure looks really trivial compared to what we have to deal with now. The Classic 3000 is a neat architecture and back in the day we always figured out a way to do whatever we needed to. Gavin