
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi<div><br></div><div>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><br></div><div><div>If both Oberon and the OS you run Oberon on have the same strategy, perfect!</div><div>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><br></div><div><div dir="ltr">br<br><div>Jörg</div></div><div dir="ltr"><br><blockquote type="cite">Am 29.04.2020 um 11:06 schrieb Jan de Kruyf <jan.de.kruyf@gmail.com>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Guy, I am a bit out of the running. My life took a different turn.<div>But I would say that you might want to investigate how the Ada people do it.</div><div>Basically you design an interface module to translate the C peculiarities to Oberon in any language you like</div><div>(assembler comes to mind in specific cases) and then publish the Oberon interface for the Oberon programmer.</div><div>This is a much cleaner solution than trying to massage Oberon to speak C, that is a bit of a dead end.</div><div>And an added advantage is that one can do type and range checking on whatever C is going to spit out.</div><div><br></div><div>j.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 1:29 AM Guy T. <<a href="mailto:turgu666@gmail.com">turgu666@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I’m following this thread with great interest. <br>

<br>

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… <br>

<br>

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. <br>

<br>

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.<br>

<br>

Guy<br>

<br>

--<br>

<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>

<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>

</blockquote></div>

<span>--</span><br><span>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</span><br><span>https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br></div></blockquote></div></div></body></html>