[Oberon] Oberon on ARM/Pi

[Jörg Straube]

BTW: you can see Wirth"s RISC instruction set as his "VM" ported to an FPGA.

Jörg


On 04.11.2012, at 16:07, Jörg Straube <joerg.straube at iaeth.ch> wrote:

> Absolutely.
> VM make perfect sense the more simple or "dumb" the underlying processor is.
> The original 6502 was rather simple and a program compiled to and interpreted by a VM had no big performance decrease as the VM overhead (VM opcode used as index in a jump table = 1 or 2 6502 instructions) was neglectable compared to the VM instruction code itself (1 VM instruction = 20 up to several 100 6502 instructions).
> 
> Over time the CPUs got more and more intelligent (CISC) with the consequence that 1 VM instruction = 1 CISC instruction. Hence the VM overhead became huge. This made compilers to native CISC code much more attractive than compilers to a VM; your program compiled to native CISC code ran much faster than compiled to a VM.
> 
> But nowadays, HW designers tend to embrace RISC architectures again, and hence a VM approach is the perfect way to complement that HW trend in compiler construction.
> 
> Jörg
> 
> On 04.11.2012, at 13:33, Michal Wallace <michal.wallace at gmail.com> wrote:
> 
>> On Sat, Nov 3, 2012 at 3:32 PM, Mike McGaw <mike at mcgawtech.com> wrote:
>>> 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.
>> 
>> Haven't seen your presentation yet. I'll have to hunt it down. :)
>> 
>>> I can appreciate the Ngaro VM idea; [ ... ] 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.
>> 
>> Sort of. It's true that a big part of the appeal is the many
>> implementations, but one reason there are so many implementations is
>> that it's got a really well-thought-out design.
>> 
>> It was originally designed to host a forth dialect (
>> http://retroforth.org ) ... If you're not familiar, one of the
>> distinguishing features of Forths is that they uses two stacks. So...
>> Instead of having all your local variables mixed in with your
>> call/return stack, you have one stack for data, and another stack for
>> control flow.
>> 
>> Right now, with Ngaro, there are only 30 opcodes ( 31 in the docs, but
>> we just got rid of WAIT ). Which is comparable to Dr Wirth's new RISC
>> machine, when you consider the various arguments/flags you can pass to
>> the instructions. If you use an instruction above #30, what it does is
>> push the current IP onto the return stack, and then performs a jump (
>> which is to say, it calls a procedure ).
>> 
>> In fact, I was planning to just target the RISC machine, until I saw
>> Paul Reed's talk and realized he and Dr Wirth were already doing this.
>> 
>> Rather than compete with them, I wanted to find something that would
>> complement their work, and I decided to take a bottom-up approach to
>> oberon : start with a simple to understand stack machine with few
>> moving parts ( that a student could implement in whatever language
>> they like )... And then build the compiler up from machine code by way
>> of forth. That way, you have a "bottom up" approach to understanding
>> Oberon to complement the top down approach in the project oberon and
>> compiler construction books.
>> 
>>> 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.
>> 
>> My plan is actually to implement ngaro atop risc,  risc atop ngaro,
>> and eventually, ngaro atop an FPGA.
>> 
>>> Keeping the reference VM source implementation elemental will contribute
>>> to confident source translation and target language compilation.
>> 
>> :) Yes! That was one suggestion I had to curb the maintenance issue on
>> all those ngaro implementations: just pick one to be the master and
>> generate the rest.
>> 
>>> 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.
>> 
>> I don't think the translation necessarily needs to be C. Free Pascal
>> is a fantastic compiler, can talk to C code, and targets almost
>> everything already. It's generates very very fast code... I don't have
>> a great benchmark yet, but the ngaro test suite ( which invokes an
>> external ngaro implementation ) consistently takes about 4-5 times as
>> long to run the C version than the pascal version.
>> 
>>> 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.
>> 
>> Yes. I think *one* of the reasons pascal was so popular in its day (
>> aside from just being a great language ) was the UCSD P-machine.
>> 
>> You could just write this tiny virtual machine using whatever tools
>> you had avaliable, and then you'd have the entire pascal system
>> running on your hardware for "free".
>> 
>> Anyway, we hang out in the #retro channel on irc.freenode.net if you
>> want to join us.
>> 
>> ( I keep looking for an #oberon channel somewhere, but so far I
>> haven't found one... I actually kind of thought the whole Oberon
>> community had moved on, until this week.... :)  )
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon