<div dir="ltr">Jörg,<br><div><br></div><div>The difference is about 9 machine instructions between bit addressing and read modify write on AVR.</div><div>depending on the context. Obviously in the middle of a routine it is less, in an ISR it can be dramatic </div><div>since registers must be saved.</div><div><br></div><div>ARM on stm32 has the same bit address facility.</div><div><br></div><div>And readability of the Oberon way is not good. It was my motivation at the time to change Oberon-0.</div><div><br></div><div>But I would much rather you helped with a bit of C++ decoding in the GCC compiler. . . 🙄</div><div>I feel that is more important.</div><div><br></div><div>j.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 16, 2018 at 12:34 PM, Jörg <span dir="ltr"><<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DE-CH" link="blue" vlink="purple"><div class="m_-8372284466456157510WordSection1"><p class="MsoNormal"><span lang="EN-US">J.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">I know it’s not perfect but:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">1 and 2 can somewhat (not totally perhaps kind of) be covered with Oberon SETs.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">3 I do with MODs and DIVs (the compiler converts those in simple shifts)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">4 ARRAY OF SETs<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">5 is called “ofront”<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Under the assumption that the underlying instruction set (assembler code) does not allow to access those single or multi-bit entities (e.g. only access BYTEs), the whole bit variables you request is “syntactical sugar”. The compiler would have to translate it in ANDs, ORs, RORs, Shifts and so. <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">br<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Jörg<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">Von: </span></b><span style="font-size:12.0pt;color:black">Oberon <<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank">oberon-bounces@lists.inf.<wbr>ethz.ch</a>> im Auftrag von Jan de Kruyf <<a href="mailto:jan.de.kruyf@gmail.com" target="_blank">jan.de.kruyf@gmail.com</a>><br><b>Antworten an: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Datum: </b>Donnerstag, 16. August 2018 um 11:53<br><b>An: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Betreff: </b>Re: [Oberon] FPGA - Simple OOP example<u></u><u></u></span></p></div><div><div class="h5"><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So let me be the devil's advocate:<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I program embedded stuff. And for lack of integration of Oberon into main line engineering <u></u><u></u></p></div><div><p class="MsoNormal">I am forced to use another language. I chose Ada because it is relatively easy to understand <u></u><u></u></p></div><div><p class="MsoNormal">the syntax when you first start out.<u></u><u></u></p></div><div><p class="MsoNormal">At the same time it is bulky and slow in use. The paranoid security of it hampers the readbility and does<u></u><u></u></p></div><div><p class="MsoNormal">not really improve the bug situation.  The code is as efficient as GCC can make it. <u></u><u></u></p></div><div><p class="MsoNormal">Which is pretty good, but at a price.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">For Oberon to be a real alternative I would minimally need:<u></u><u></u></p></div><div><p class="MsoNormal">1. single bit variables.<u></u><u></u></p></div><div><p class="MsoNormal">2. packed arrays of those.<u></u><u></u></p></div><div><p class="MsoNormal">3. if at all possible multi bit variables (2, 3, 4, 5 etc.)<u></u><u></u></p></div><div><p class="MsoNormal">4. packed records of single and multi bit variables.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The single bit stuff I did many years ago in Oberon-0 for AVR and it was not difficult.<u></u><u></u></p></div><div><p class="MsoNormal">All the OOP stuff as in C++ and Ada only confuse me further so I have no use for them. <u></u><u></u></p></div><div><p class="MsoNormal">There are other ways of sane thinking that give the same benefits. I am very<u></u><u></u></p></div><div><p class="MsoNormal">much in agreement with NW on that.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In any case: then there is item 5:<u></u><u></u></p></div><div><p class="MsoNormal">  An Oberon front end for GCC. so we have a proper Application Binary Interface and<u></u><u></u></p></div><div><p class="MsoNormal">can hang some libc onto it. And have an interface to other languages. AND use any <u></u><u></u></p></div><div><p class="MsoNormal">controller for which GCC has a back end. And have industry standard load files that can <u></u><u></u></p></div><div><p class="MsoNormal">used where ever.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">To think that we must forever and in eternity use hand-crafted compilers that become, <u></u><u></u></p></div><div><p class="MsoNormal">after time, most difficult to maintain is to me plain religious lunacy.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So I am open to suggestions from the group. The GCC stuff must be done first. <u></u><u></u></p></div><div><p class="MsoNormal">The rest can be discussed over time.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Enjoy the summer holidays all.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">j.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Aug 16, 2018 at 10:02 AM, Diego Sardina <<a href="mailto:dsar@eml.cc" target="_blank">dsar@eml.cc</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">On Thu, Aug 16, 2018, at 9:23 AM, Tomas Kral wrote:<br>> On Thu, 16 Aug 2018 08:38:04 +0200<br>> Jan de Kruyf <<a href="mailto:jan.de.kruyf@gmail.com" target="_blank">jan.de.kruyf@gmail.com</a>> wrote:<br>> <br>> > The spirit of Edsger Dijkstra is still haunting us. <span style="font-family:"Apple Color Emoji"">😠</span> Rational<br>> > western man or not.<br>> <br>> Modern trends usually are very complex, the spirit of Oberon is quite<br>> the opposite, keep it simple minimal, and leave out the fancy.<br>> <br><br>Just some days ago I (casually) found in my old hard disk an interesting<br>paper by Hoare about language design, it's still available on the web:<br><br><a href="http://web.eecs.umich.edu/~bchandra/courses/papers/Hoare_Hints.pdf" target="_blank">http://web.eecs.umich.edu/~<wbr>bchandra/courses/papers/Hoare_<wbr>Hints.pdf</a><br><br>Briefly, Oberon fullfills all of Hoare's requirements:<br><br>"A good language design may be summarized in five catch phrases: simplicity, security, fast translation, efficient object code, and readability."<br><br>--<br>Diego Sardina<u></u><u></u></p><div><div><p class="MsoNormal">--<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" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><u></u><u></u></p></div></div></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a> <u></u><u></u></p></div></div></div></div>
<br>--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">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/<wbr>mailman/listinfo/oberon</a><br>
<br></blockquote></div><br></div>