<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><span><div>Regarding the suggestions to create an Oberon compiler that somehow connects to GCC, but at one of the intermediate code levels: I would argue that we should be careful of such an exercise for many reasons, not the least of which is the fact that GCC and the underlying structures are huge and as others have pointed out, are a moving target.</div><div> </div><div>We have already options for Oberon compilers that generate C. I have never liked that approach; it is rather like taking a bath with your socks on. But, it can (and has already) been done.</div><div> </div><div>I would argue that we should instead concentrate on a very clean, very straight forward VM, and then write a back end accordingly. I am not in favor of the Java VM, or other such VMs- they are too big, too complex and too much of a moving target. Rather, I
think a clear, concise, clean design is needed here. If the VM is well conceived, we should be able to 'kill all the birds (with one stone)' that have been discussed, whether your need is embedded, to be able to run Oberon TUI, etc., etc. If the VM is well conceived, for example, written in a subset of Oberon that could be compiled also, let us say, by M2, then, this VM source can be easily machine translated to the language of your choice (including C). But here, because (if the VM is cleanly conceived) the source Oberon/M2 implementation is elemental, the resulting target language translation should be readily digestible not only to the reader of the translated source, but this should also be reliably compiled by almost any (C) compiler you wish to use. A major plus is that the plethora of (C-based, or at least C-callable) device drivers become available in a direct way to this (translated-to-C) VM. And we could finally, once and for all, lock in
on a target backend architecture, which would also, once and for all, fix the object format so that the module loader, once and for all, could be fixed. THAT would make the system portable, and provide a future lifetime comparable to the venerable P-system based Pascal, and far more useful.</div><div> </div><div>If you really, really, really had to have native code, then, it would be a much simpler exercise to design translators that map the VM op codes and so on to the new target native op codes and so on. How easy this is to do will depend alot on the VM design, and the target native architecture of course, but, the RISC VM and compiler that Wirth is working on should enable a reasonably straight-forward means of doing such a translation to another RISC target (since most of what we are seeing today are RISC machines of one sort or another).</div><div> </div><div>The benefits of this are immediately recognizable. Getting an Oberon system
up on the Raspberry Pi would be a walk in the park, if we had such a compiler and associated VM. </div><div> </div><div>-M</span></div><div> </div></div></body></html>