[Oberon] Oberon on ARM/Pi

[Aubrey.McIntosh at Alumni.UTexas.Net]

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.

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.

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.

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.

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.

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.




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.
>
> 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
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>


-- 
Aubrey McIntosh, Ph.D.
211 E. 5th St.
Morris MN 56267
(512)-348-7401
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20121104/051577d3/attachment.html