<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>This thread struck a nerve for me, as I have been an advocate&nbsp;of a virtual machine implementation for the Oberon compiler (see the end of the presentation I made at the last Oberon Day) for some time, now.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>I can appreciate the Ngaro VM idea; I have spent considerable time with the Lilith M2 interpreter and the KRONOS 32-bit version of this architecture, and I can appreciate the benefits of a stack-machine-based interpreter, so when I took a look at the Ngaro link, I smiled a bit.&nbsp;
 I&nbsp;suspect the point of this link in the previous post was not the architecture per se (although stack machines make certain aspects of code generation a bit easier), but rather its implementation in several target languages that are in broad use today.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>And, the point may be made that a stack architecture based VM, with suitable instruction choice can be implemented more efficiently as a VM than say, a RISC architecture (generated&nbsp;sizes for code&nbsp;that will run&nbsp;ON the VM&nbsp;will rule here, I would guess, as to overall execution speed, as&nbsp;the VM goes).</span></div><div style="color: rgb(0, 0, 0);
 font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>However, Wirth has been at work, along with Reed, in the development of a clean RISC-style implementation directed at a XILINX FPGA.&nbsp; This, I am hoping, will be featured in a re-release of the now classic Project Oberon book in the not too distant future.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>What is desperately needed, though, is a VM for the compiler that is set up for at
 least one (easily implemented) commonly available&nbsp;target.&nbsp; Toward that end, I would argue for a VM that is implemented very cleanly and in an elemental manner.&nbsp; This means&nbsp;a VM&nbsp;source implementation (in Oberon) that can be directly and easily machine translated into most any target language to enable easy and direct porting of the core VM.&nbsp; Keeping the reference VM source implementation elemental will contribute to confident source translation and target language compilation.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>In this way, for example, on the Pi, one can (with a C translation of the VM)&nbsp;directly link the C source that manages
 the niggling driver libraries that take so much time to develop, and yet are key to rapid deployment of Oberon on a new architecture or implementation.&nbsp; The libs are linked with a machine translated VM, for which suitable hooks are made to enable the calling of these libraries.&nbsp; Some may argue about performance, but I would submit that performance matters are probably not as much of a concern as most might suggest, depending on what the target application may be.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>I do this&nbsp;type of&nbsp;thing, right now, with the Lilith M2 VM.&nbsp; It is relatively easy and straight forward to move this wherever I wish.&nbsp;
 Quickly.&nbsp; And with reliable results.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>This is what is needed for Oberon, in order to sustain this language and system's viability.&nbsp; From that basis, most of us&nbsp;would be&nbsp;able to take this remarkable language and system&nbsp;wherever we wish, to almost any end we desire.</span></div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color:
 transparent;"><span></span>&nbsp;</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; background-color: transparent;"><span>-Mike</span></div><div><span></span></div><div></div><div>&nbsp;</div><div>&nbsp;</div></div></body></html>