I wrote a p-machine in UCSD pascal itself that ran on a Terak graphics computer. It had 8" floppies. I did it just to see if I could.<div><br></div><div>I was at the Stride Faire when people in the audience were holding money in the air to buy the newest p machine implementation and the SoftTech people declined to sell it.</div>
<div><br></div><div>I hand de-compiled much of the SEK module (a pun, Sven Eric Knudson or Sequential Executive Kernel) in the Modula-2 system that ran on the M2 machine. I also de-assembled the M machine interpreter that was shipped from Provo, and became convinced that it had been written in Ada and compiled.<br>
<div><br></div><div>I always go through the same phases. I really dislike whatever new thing Wirth has done. Then I putter with it a bit. Then I think, again, that he is the best.</div><div><br></div><div>What I understood from his new video was that he used a high level description language to describe the hardware. There were some projects such as that that compiled hardware descriptions in a clearly Wirthian language into Xilinx images, sometime in the 90s. These ran on the ETH S3 system. I couldn't afford the prototype board then, but I did compile several hardware projects with that compiler.</div>
<div><br></div><div>I would love to have his high level source for his CPU. I would almost certainly grumble at many of his design choices, before I saw their wisdom. It would be interesting to port all the existing compilers to this CPU, just as a matter of polishing our group expertise.</div>
<div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Sat, Nov 3, 2012 at 3:32 PM, Mike McGaw <span dir="ltr"><<a href="mailto:mike@mcgawtech.com" target="_blank">mike@mcgawtech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:arial,helvetica,sans-serif"><div><span>This thread struck a nerve for me, as I have been an advocate 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="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<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.
I 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="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<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 sizes for code that will run ON the VM will rule here, I would guess, as to overall execution speed, as the VM goes).</span></div>
<div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<span>However, Wirth has been at work, along with Reed, in the development of a clean RISC-style implementation directed at a XILINX FPGA. 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="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<span>What is desperately needed, though, is a VM for the compiler that is set up for at
least one (easily implemented) commonly available target. Toward that end, I would argue for a VM that is implemented very cleanly and in an elemental manner. This means a VM 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. Keeping the reference VM source implementation elemental will contribute to confident source translation and target language compilation.</span></div>
<div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<span>In this way, for example, on the Pi, one can (with a C translation of the VM) 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. The libs are linked with a machine translated VM, for which suitable hooks are made to enable the calling of these libraries. 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="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<span>I do this type of thing, right now, with the Lilith M2 VM. It is relatively easy and straight forward to move this wherever I wish.
Quickly. And with reliable results.</span></div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<span>This is what is needed for Oberon, in order to sustain this language and system's viability. From that basis, most of us would be able to take this remarkable language and system wherever we wish, to almost any end we desire.</span></div>
<span class="HOEnZb"><font color="#888888"><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif">
<span></span> </div><div style="font-style:normal;font-size:16px;background-color:transparent;font-family:arial,helvetica,sans-serif"><span>-Mike</span></div><div><span></span></div><div></div><div> </div><div> </div></font></span></div>
</div><br>--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="'times new roman', serif">Aubrey McIntosh, Ph.D.<br>211 E. 5th St.<br>Morris MN 56267</font><div><div><span style="line-height:20px;background-color:rgb(255,255,255)"><font face="'times new roman', serif">(512)-348-7401</font></span></div>
</div><div><div><br></div></div><br>
</div></div>