I was going to post this in another thread but it's way off topic, so I'm starting a new one here.
Anywho.... what I'm mostly going to talk about here is what should have happened with UCSD Pascal.
The other thread mention Forth and UCSD Pascal arising at a similar time with a similar idea for a virtual machine.
Both were designed around 1968-69 and the Wiki shows them being released in 1970.
They arose at the same time because someone else designed something similar for another language a couple years earlier.
I think the got the idea from a BASIC produced at the University of Illinois by the same guys that designed the PLATO system, but I'm not 100% sure of that.
UCSD Pascal took the virtual machine a step further than Forth or their predecessor with the portable OS and environment.
I've worked on a P Machine for a different CPU. and if I sat down to seriously work on it for a few days, it would probably be up and running within in a week.
It was a pretty great idea at the time. Most of the work is the P-Machine itself, and then the low level I/O. After that it's just configuring the system which is easy.
There are several things UCSD should have done they didn't, and I think at least one would apply to Forth as well.
1. It should have been made open source... though the concept didn't really exist as we know it at the time. Things were commercial or public domain.
2. They should have included an extensible command shell. Any number of development tools could have extended the system. When combined with #1, support would have exploded.
3. The editor/environment should have been configurable to use different compilers. Apple's Fortran certainly proved the usefulness of the concept.
4. It should have been designed so it could run on top of any native file system that could support longer file names and subdirectories. Basically a level of abstraction in the OS design so it could get away from the proprietary file system where possible.
5. The P-Machine should have been register based and more RISC like to make the P Machine smaller, optimization easier, and translation to native code easier. That way of thinking was several years off though.
I'm not sure if register allocation was even used until the 80s, and I saw compilers as late as the 90s without even peephole optimization.
Native code translation from P Code certainly existed by the late 70s. There was an 8080 translator published in BYTE magazine around 1978... after Tiny Pascal?
The ability to run P-Code modules through a native code translator would have made a huge difference at runtime on speed critical code.
A just in time compiler is what some would call it.
6. The P Machine needs better support for paged or extended memory. This is sort of supported in later versions, but I couldn't find source code and it needs to work hand in hand with the translator. Automatic support for more than 64K along with native code generation makes 8 bits much more competitive with 16 bit machines.
7. The virtual machine (talking the OS/API level here) should have moved away from a strictly terminal interface
I'm not talking about a GUI here, just extend the environment with features similar to Extended BASICs... and then add a few more.
It should have supported some way to detect native hi-res graphics mode. What resolution and pixel depth.
Then it should have APIs for a bunch of related things.
Line, circle, flood fill, DRAW (complex shapes based on strings) and simple blit copies.
Drawing text on the graphics screen like a terminal.
Play sounds, play simple music, play sound samples, and produce speech.
Support for some sort of system timer.
Include a set of Pascal routines to do some of that so it's easy to get up and running, but then they could be ported to native assembly for maximum speed on each machine.
Basically, a lot of the things the PLATO educational system had, but targeted at microcomputers of the early 80s.
All of the technology to do that was available at the time.
Certainly not all systems would have sound, and maybe require a minimum resolution in 2 colors, but it makes portable games, educational software, etc... .not only possible, but easy. Some of it could have been up and running in 1980. Apple Pascal certainly proves that with it's support for some graphics.
Something like Print shop could be ported from one system to another mostly by adding printer drivers.
I've worked a little on pieces of this. It's partially why I wrote the code for printing text on a graphics screen.
It's also why I've been supporting most 6847 based machines, the Atari, the Plus/4 & C64, and I've even done a little work for 9918 based machines (the last three aren't 100% complete). It supports a minimum system it might run on.
Drawing lines, circles, etc... are easy once you have native pixel drawing code.
Sound is awkward beyond simple notes. Sound samples, speech and any sound effects are pretty much native code for each machine.
A new virtual machine like I described, requires a new interpreter, compiler, assembler, peephole optimizer, linker, runtime translator for each CPU, a set of native functions to support native translated code, native sound related libraries... it's a massive undertaking and I've just scratched the surface.
I thought maybe add the graphics, graphics text, sound, and music to the existing system.
Use the graphics text for the editor (full upper and lower case no matter what system it's on).
Then maybe the OS changes so it can sit on top of a native OS.
Maybe sampled sound and speech.
Possibly a peephole optimizer for the existing P Code. I don't even know if stack based code can be optimized that way though.
If it looks promising, then maybe all the new VM stuff. It would be transparent to the Pascal source code.
It might be more important just to get new p machines for each CPU free of copyright issues.
Edited by JamesD, Thu Jun 15, 2017 11:31 AM.