[Oberon] Oberon compiler futures

[Srinivas Nayak]

Dear All,

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,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/


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