[Oberon] Oberon on ARM/Pi

[Jörg Straube]

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