<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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 (<span style="text-decoration: underline; color: rgb(212, 212, 212); font-family: Menlo, Monaco, "Courier New", monospace; white-space: pre; background-color: rgb(30, 30, 30);" class=""><a href="http://0x04.net/~mwk/doc/xtensa.pdf" class="">http://0x04.net/~mwk/doc/xtensa.pdf</a></span>).</div><div class=""><br class=""></div><div class="">Guy</div><div class=""><br class=""></div><div class="">>I fully support your recommendation to use thick binding.</div><div class="">>However, the author of the „thick“ interface module needs some compiler help.</div><div class="">></div><div class="">>Gruss</div><div class="">>Jörg</div><div class="">></div><div class="">>> Am 29.04.2020 um 15:37 schrieb Jan de Kruyf <jan.de.kruyf at <a href="http://gmail.com" class="">gmail.com</a>>:</div><div class="">>> </div><div class="">>> </div><div class="">>> hallo,</div><div class="">>> >If both Oberon and the OS you run Oberon on have the same strategy, perfect!</div><div class="">>> </div><div class="">>> At least one of the Ada compilers has followed this route and stores data in the GCC "C" way so</div><div class="">>> equivalent structures are passed effortlessly (A "thin binding")</div><div class="">>> But where data structures are not equivalent a "thick binding" has to be constructed in any case, i.e. an interface module.</div><div class="">>> </div><div class="">>> In practice a thick binding to a library is easier to work with since the feel is now like that of a native library.</div><div class="">>> A thin binding often needs specialist knowledge of the underlying C interface to be able to work productively</div><div class="">>> since the 2 language cultures clash here and there.</div><div class="">>> </div><div class="">>> And in Guy's case I suppose he will have to study the C compiler used in his target to determine the storage policy.</div><div class="">>> Hopefully it is GCC.</div><div class="">>> </div><div class="">>> j.</div><div class="">>> </div><div class="">>> On Wed, Apr 29, 2020 at 2:51 PM Joerg <joerg.straube at <a href="http://iaeth.ch" class="">iaeth.ch</a>> wrote:</div><div class="">>>> Hi</div><div class="">>>> </div><div class="">>>> 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.</div><div class="">>>> </div><div class="">>>> If both Oberon and the OS you run Oberon on have the same strategy, perfect!</div><div class="">>>> 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.</div><div class="">>>> </div><div class="">>>> br</div><div class="">>>> Jörg</div><div class="">>>> </div><div class="">>>>> Am 29.04.2020 um 11:06 schrieb Jan de Kruyf <jan.de.kruyf at <a href="http://gmail.com" class="">gmail.com</a>>:</div><div class="">>>>> </div><div class="">>>>> </div><div class="">>>>> Guy, I am a bit out of the running. My life took a different turn.</div><div class="">>>>> But I would say that you might want to investigate how the Ada people do it.</div><div class="">>>>> Basically you design an interface module to translate the C peculiarities to Oberon in any language you like</div><div class="">>>>> (assembler comes to mind in specific cases) and then publish the Oberon interface for the Oberon programmer.</div><div class="">>>>> This is a much cleaner solution than trying to massage Oberon to speak C, that is a bit of a dead end.</div><div class="">>>>> And an added advantage is that one can do type and range checking on whatever C is going to spit out.</div><div class="">>>>> </div><div class="">>>>> j.</div><div class="">>>>> </div><div class="">>>>> </div><div class="">>>>> On Wed, Apr 29, 2020 at 1:29 AM Guy T. <turgu666 at <a href="http://gmail.com" class="">gmail.com</a>> wrote:</div><div class="">>>>>> I’m following this thread with great interest. </div><div class="">>>>>> </div><div class="">>>>>> 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… </div><div class="">>>>>> </div><div class="">>>>>> 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. </div><div class="">>>>>> </div><div class="">>>>>> 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.</div><div class="">>>>>> </div><div class="">>>>>> Guy</div><div class=""><br class=""></div></body></html>