[Oberon] Negative integer literals in Oberon

Jan de Kruyf jan.de.kruyf at gmail.com
Wed Apr 29 15:36:24 CEST 2020


hallo,
>If both Oberon and the OS you run Oberon on have the same strategy,
perfect!

At least one of the Ada compilers has followed this route and stores data
in the GCC "C" way so
 equivalent structures are passed effortlessly (A "thin binding")
But where data structures are not equivalent a "thick binding" has to be
constructed in any case, i.e. an interface module.

In practice a thick binding to a library is easier to work with since the
feel is now like that of a native library.
A thin binding often needs specialist knowledge of the underlying C
interface to be able to work productively
since the 2 language cultures clash here and there.

And in Guy's case I suppose he will have to study the C compiler used in
his target to determine the storage policy.
Hopefully it is GCC.

j.

On Wed, Apr 29, 2020 at 2:51 PM Joerg <joerg.straube at iaeth.ch> wrote:

> Hi
>
> one thing that always has to be deciced: are parameters passed via
> registers or via stack? And if via stack: who decrements/increments the
> stack pointer? the caller or the callee.
>
> If both Oberon and the OS you run Oberon on have the same strategy,
> perfect!
> If Oberon has one method and the OS you run Oberon on has another
> strategy, you need a new Oberon syntax (eg [] or {} in the procedure
> declaration) to mark procedures as „OS APIs“, so the compiler can generate
> the correct code.
>
> br
> Jörg
>
> Am 29.04.2020 um 11:06 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
>
> 
> 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
>>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200429/6621a1a5/attachment.html>


More information about the Oberon mailing list