[Oberon] Oberon on ARM/Pi

[Mike McGaw]

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.
 
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.
 
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).
 
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.
 
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.
 
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.
 
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.
 
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.
 
 
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20121103/f57c23be/attachment.html