[Oberon] Oberon on ARM/Pi

Michal Wallace michal.wallace at gmail.com
Sun Nov 4 13:33:23 CET 2012


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.... :)  )



More information about the Oberon mailing list