> A small LOOP with a single EXIT is relatively painless to fix. It is when > you get nested LOOPs spanning many lines with multiple EXITs (and possibly > RETURNs) in each that life becomes interesting. > > This is where evolution kicks in. The lifetime of such code is limited by > the number of people who are able and prepared to maintain it. One possible approach could be: Add the small number of “Original Oberon-2” features such as LOOP, EXIT and RETURN to the compiler just to *initially* speed up the porting effort of V4. But *eventually* eliminate those constructs *on* the then-ported system. The advantage would be that one would not need to also deal with porting complex, nested LOOP statements initially, thereby reducing risk of errors..
Andreas:
Add the small number of “Original Oberon-2” features such as LOOP, EXIT and RETURN to the compiler just to *initially* speed up the porting effort of V4. But *eventually* eliminate those constructs *on* the then-ported system. The advantage would be that one would not need to also deal with porting complex, nested LOOP statements initially, thereby reducing risk of errors..
Sounds like a plan. A dream would be to have a V4 successor named V6 (because V5 is taken) replacing V4 under Windows and Linux, and also running on the FPGA. This is a dream inspired by the fact that once upon a time it was true. Oberon System was running on all these *nix and Windows machines, and also on Ceres. It must be then possible to repeat the same trick, with the FPGA serving as Ceres. Both physical RISC5 in the FPGA and emulated RISC5. It must be possible, but it may require bright grad students.... like the originals used to be. W
participants (2)
-
Andreas Pirklbauer -
Skulski, Wojciech