
Virtual Processor - peter_d_sherman
https://en.wikipedia.org/wiki/Virtual_Processor
======
peter_d_sherman
Also:

[https://news.ycombinator.com/item?id=9806607](https://news.ycombinator.com/item?id=9806607)

Excerpt:

"The technology was great. I joined just as TAOS was being migrated to intent.
Both worked in the same sort of way; code was written in a custom portable
assembly language, which was then translated into native machine code when it
was loaded into the machine. The TAOS language was VP1, the intent one was
VP2, and the first VP2 systems were hosted on TAOS, so it actually translated
VP2 into VP1 and then into native. Translation was very, very fast; as both VP
were pretty dense it was possible to load and translate VP faster than loading
native code, on certain combinations of platforms.

VP1 had 16 registers and a pretty simple instruction set. The original
incarnation was a assembler macro package. VP2 was way more complicated. It
had five register banks (int32, int64, pointer, float, double) of up to 65535
registers each. It was actually a pretty nice system to program in, especially
when the assembler got strong typing and structured programming support...
yeah, I know what you're thinking.

The OS itself was way ahead of its time: it was an asymmetric multiprocessor
system, where you could have any number of nodes of different CPU types hooked
together via a message-passing system. Code loading was transparent, and
devices and filesystems could be attached to any node on the system. It had a
blisteringly fast compositing GUI, cutting edge audio synthesis, hardware
accelerated OpenGL, and eventually ran on, deep breath: 386 x86 ARM MIPS
PowerPC MCore ColdFire Transputer ShBoom and a V, um, V840? Or something?

Our standard development procedure for new hardware was to have intent running
(inside a Linux process) on a desktop PC; we'd bootstrap a development board
up to the point of having serial support and the VP loader; then we'd hook
them together. Suddenly, we have a two-node system. We could start a terminal
on the desktop and see that node #0 was a Pentium and node #1 was, say, a
ColdFire. You could then spawn a process on node #1 and it would run
transparently on the dev board with full access to the desktop's filesystem
and device drivers, all running, quite slowly, over the serial link."

