<html><head></head><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:13px"> <div id="yui_3_16_0_ym19_1_1501679400568_10821" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10822">On the matter of OP2 vs. single-pass Wirth compiler:</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10823" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10824"><br id="yui_3_16_0_ym19_1_1501679400568_10825" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10826" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10827">1. There are far more CPUs supported by OP2 than this single pass.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10828" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10829">2. The code generation can be cleanly separated in OP2, and not as easily in the single pass</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10830" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10831">3. *** OP2 supports the Oberon and Oberon-2 syntax *** No source changes to S3 or V4 code must be made to use it. Single Pass (RISC5) demands many changes, potentially.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10832" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10833">4. OP2 is well sorted, and stable. Predictable in its behavior.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10834" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10835">5. OP2, because it uses an AST, enables many interesting things to be done: a) an AST-traversing interpreter; b) debugger support; c) code slicing support. Many theses and dissertations from Linz shows this.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10836" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10837">6. It is not very difficult to make a version of OP2 that supports multiple CPU targets via switches.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10838" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10839">7. One of the targets could be the C source output backend for Ofront.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10840" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10841"><br id="yui_3_16_0_ym19_1_1501679400568_10842" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10843" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10844"><br id="yui_3_16_0_ym19_1_1501679400568_10845" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10846" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10847">What is needed, with regard to OP2, IMHO:</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10848" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10849"><br id="yui_3_16_0_ym19_1_1501679400568_10850" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10851" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10852">1. It would be VERY useful to have a back end for OP2 that targeted a purpose-built interpreter (processing something like byte code from a linear file, not a tree-traversing interpreter). Here, it would be very helpful to have it support an instruction set for which a clean and simple interpreter exists or can be built. I am thinking specifically of an instruction set not far from the Lilith-inspired KRONOS 32-bit CPU. This would permit a very portable interpreter that could be retargeted with ease (use Ofront, for example, to machine generate a C version). Once this is accomplished, the systems, their compiler (and target generators) and nearly all of the code base would live on indefinitely.</span></div><span id="yui_3_16_0_ym19_1_1501679400568_10853"></span><div id="yui_3_16_0_ym19_1_1501679400568_10854" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10855"><br id="yui_3_16_0_ym19_1_1501679400568_10856" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10857" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10858">2. It would be nice to support RISC5's CPU and system architecture</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10859" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10860"><br id="yui_3_16_0_ym19_1_1501679400568_10861" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10862" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10863">Both compilers have their purpose: OP2 is regarded by some as being somewhat 'inscrutable', and most of the published (e.g., available source implementations) progress with OP2 has been accomplished by those who were trained at ETH, and have had direct experience with it. But it remains a bit of a climb for the uninitiated. The single pass design is lauded by others for its simplicity. Both compilers show how it is possible to radically reduce the source expression of a real and useful language design, provided that this language design is done intelligently, achieving a source expression that is 10x or more reduced in size over something like C. The single pass version lends itself to the task of teaching compiler design, and is without peer in this regard. OP2 supports a much larger code base that many users find helpful.</span></div><div id="yui_3_16_0_ym19_1_1501679400568_10864" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10865"><br id="yui_3_16_0_ym19_1_1501679400568_10866" clear="none"></span></div><div id="yui_3_16_0_ym19_1_1501679400568_10198" dir="ltr"><span id="yui_3_16_0_ym19_1_1501679400568_10868">One person's opinion.</span></div></div></body></html>