[Oberon] Oberon compiler futures
sinu.nayak2001 at gmail.com
Sun Dec 23 07:57:53 CET 2012
Is it not possible to call C APIs from Oberon?
I mean, somehow interfacing to C libraries?
I have no knowledge if it is doable or not, just got an idea!
With thanks and best regards,
Mike McGaw wrote:
> Regarding the suggestions to create an Oberon compiler that somehow
> connects to GCC, but at one of the intermediate code levels: I would
> argue that we should be careful of such an exercise for many reasons,
> not the least of which is the fact that GCC and the underlying
> structures are huge and as others have pointed out, are a moving target.
> We have already options for Oberon compilers that generate C. I have
> never liked that approach; it is rather like taking a bath with your
> socks on. But, it can (and has already) been done.
> I would argue that we should instead concentrate on a very clean, very
> straight forward VM, and then write a back end accordingly. I am not
> in favor of the Java VM, or other such VMs- they are too big, too
> complex and too much of a moving target. Rather, I think a clear,
> concise, clean design is needed here. If the VM is well conceived, we
> should be able to 'kill all the birds (with one stone)' that have been
> discussed, whether your need is embedded, to be able to run Oberon
> TUI, etc., etc. If the VM is well conceived, for example, written in a
> subset of Oberon that could be compiled also, let us say, by M2, then,
> this VM source can be easily machine translated to the language of
> your choice (including C). But here, because (if the VM is cleanly
> conceived) the source Oberon/M2 implementation is elemental, the
> resulting target language translation should be readily digestible not
> only to the reader of the translated source, but this should also be
> reliably compiled by almost any (C) compiler you wish to use. A major
> plus is that the plethora of (C-based, or at least C-callable) device
> drivers become available in a direct way to this (translated-to-C) VM.
> And we could finally, once and for all, lock in on a target backend
> architecture, which would also, once and for all, fix the object
> format so that the module loader, once and for all, could be fixed.
> THAT would make the system portable, and provide a future lifetime
> comparable to the venerable P-system based Pascal, and far more useful.
> If you really, really, really had to have native code, then, it would
> be a much simpler exercise to design translators that map the VM op
> codes and so on to the new target native op codes and so on. How easy
> this is to do will depend alot on the VM design, and the target native
> architecture of course, but, the RISC VM and compiler that Wirth is
> working on should enable a reasonably straight-forward means of doing
> such a translation to another RISC target (since most of what we are
> seeing today are RISC machines of one sort or another).
> The benefits of this are immediately recognizable. Getting an Oberon
> system up on the Raspberry Pi would be a walk in the park, if we had
> such a compiler and associated VM.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon