[Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)

[Guy T.]

My understanding is that the ESP32 Oberon compiler, as I’ve designed and implemented it, supports the “thick” binding. Those thick bindings are created using the “MODULE [CDECL] ModuleName;” declaration (please look at my previous message under the same subject). It is also allowing for declarations of C elements inside an Oberon module to permit building handlers in the Oberon language.

Yes, the ESP-IDF framework is using GCC. The Oberon compiler is also using GCC as the generated code is in assembly language and is automatically compiled to object code by calling the GCC assembly language tool. There is not that many differences between the underneath storage policies of both C and Oberon, as they are based on the defined Tensilica Xtensa architecture  (http://0x04.net/~mwk/doc/xtensa.pdf).

Guy

>I fully support your recommendation to use thick binding.
>However, the author of the „thick“ interface module needs some compiler help.
>
>Gruss
>Jörg
>
>> Am 29.04.2020 um 15:37 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
>> 
>> 
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200429/fa93d03b/attachment.html>