[Oberon] Negative integer literals in Oberon

[Jan de Kruyf]

Guy, I am a bit out of the running. My life took a different turn.
But I would say that you might want to investigate how the Ada people do it.
Basically you design an interface module to translate the C peculiarities
to Oberon in any language you like
(assembler comes to mind in specific cases) and then publish the Oberon
interface for the Oberon programmer.
This is a much cleaner solution than trying to massage Oberon to speak C,
that is a bit of a dead end.
And an added advantage is that one can do type and range checking on
whatever C is going to spit out.

j.


On Wed, Apr 29, 2020 at 1:29 AM Guy T. <turgu666 at gmail.com> wrote:

> I’m following this thread with great interest.
>
> As I’m building a compiler for the ESP32 IOT chip, I’m facing issues as
> I’m transforming the compiler to allow relatively easy integration with C
> functions present in the ESP-IDF framework (This is *the* framework needed
> to access some hidden part of the chip). For that, I’ve defined new forms
> for arrays, records, procedures and pointers to be compatible with the C
> language syntax and semantic. I also need to add 16bits unsigned and 64bits
> signed integers. I may have to add unsigned integer depending on the needs.
> I already added bit-wise AND, OR and XOR standard functions that I may get
> rid of depending on the suitability of SETs to get good code readability. I
> miss a lot enumeration as the C enum is in used everywhere in the ESP-IDF
> framework (but I’m not for now implementing it in Oberon). I’m also
> considering variable number of parameter for C procedure calls…
>
> I try to find ways to get the interaction with the ESP-IDF framework as
> easy as possible for the Oberon programmer (in occurence, me…) without
> loosing the sense of the language.
>
> What I wanted to show is the context of added functionalities required to
> get Oberon inter-operate with an existing framework. The most important
> aspect for me is the readability for the developer (and long term support
> readability) without loosing too much of the simplicity of the language.
>
> Guy
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200429/ea83ef16/attachment.html>