[Oberon] Oberon compiler futures

[Douglas G. Danforth]

If the C library resides in a DLL then yes it is possible.
-Doug Danforth

On 12/22/2012 10:57 PM, Srinivas Nayak wrote:
> 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
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>