[Oberon] Ofront+

[Stewart Greenhill]

It is worth mentioning a few nice features of Oleg's system.

Ofront+ is based on ofront (by Josef Templ) and uses "C" as an intermediate
language for code generation.

1) Portability. Using a C compiler as the back-end allows code to be
compiled for a huge range of CPU architectures. Obviously Oberon easily
works on modern 32/64 bit machines such as x86 or ARM. Ofront+ also
supports 8-bit architectures (eg. Z80, 6502) found in vintage computers and
embedded systems. This design also makes it easy to cross-compile from one
architecture to another.

2) Optimisation. The C compiler back-end automatically gives you a huge
range of standard optimisations - efficient register allocation, constant
folding, code hoisting, common subexpression elimination, loop unrolling,
function inlining. If you need your Oberon code to be fast, there is no
better solution.

3) Foreign Code Interface. Most Oberon "Systems" tend to be self-contained,
but if you are interested in writing stand-alone programs for conventional
operating systems it is important to be able to use external software
libraries. To call code written C or some other language, you need a way to
declare foreign functions and data structures. In particular, the run-time
needs to know which pointers are to be traced and managed by the garbage
collector, and which pointers are unmanaged. This is done using system
flags which apply to records, pointers, and arrays. For function
declaration, Ofront+ includes the "code procedure" method from the original
ofront implementation, but also adds a more general "external procedure"
method, as found in Blackbox/Component Pascal.

To be honest, I was skeptical of the "code procedure" idea, which
essentially declares a typed macro that is expanded when the call is
compiled. These can be cumbersome to write, and in some cases must include
explicit type casts. Then I realised that this allows *blazingly fast*
maths operations using math.h/libm. In Ofront+ you can write the following,
which causes the math.h sin() function to be called when Math.sin is
invoked.

MODULE Math;    (* OMAKE LINK "m" *)
IMPORT C;
PROCEDURE -includeMath* "#include <math.h>";
PROCEDURE -sin*(x : C.double) : C.double "sin(x)";
PROCEDURE -cos*(x : C.double) : C.double "cos(x)";
..etc

There are rare cases where Math.sin might generate an external function
call, but usually this call is aggressively optimised by the back end, even
reducing to a single FSIN instruction. This is because the C compiler has
deep knowledge about "builtin" functions declared in math.h. For example,
if you need both Math.sin(x) and Math.cos(x) it will use the FSINCOS
instruction to compute them both simultaneously.

4) Multi Language. In the past I used both Oberon-2 and Component Pascal.
Returning to the Oberon world after some time, I was somewhat dismayed to
find yet more incompatible dialects have arisen. While I accept that there
are valid reasons for changing the language design, this is actually
terrible for the community. It fragments users and their software into
islands that cannot easily share code and experience, a modern Tower of
Babel. Ofront+ partially solves this problem by allowing a single project
to mix code from different Oberon dialects. This helps with code re-use,
but also takes some of the risk out of choosing a particular dialect.

Cheers,
  Stewart



On Fri, 30 Oct 2020 at 11:36, Oleg N. Cher <allot at bk.ru> wrote:

> Dear Oberoners,
>
> I'm really surprised that many people here are hearing about Online
> Oberon for the first time. I've known about it for a long time.
>
> In order to inform the public, I want to tell you about my own fork of
> Josef Templ's project Ofront: https://github.com/jtempl/ofront/
>
> Ofront+ is a direct continuation of the ideas embedded in the Ofront
> project. But it expands number of supported Oberon dialects:
>
>    Oberon/Oberon-2
>
>    Oberon-07/16 (support is still in-work,
>                  but users need to encourage this direction)
>
>    Component Pascal (almost everything is supported
>                      except 2-byte CHAR type, even some GPCP extensions)
>
>    Oberon-3 (experimental dialect with constant arrays and "proper FOR")
>
> We can also use multiple dialects in a single project.
>
> Ofront+ also increases the number of available target architectures:
>
>    BlackBox Component Builder
>    FreeBSD amd64
>    Linux amd64
>    Linux armv7
>    Linux i386
>    OpenBSD amd64
>    OpenBSD armv7
>    OpenBSD i386
>    macOS X
>    MS Windows 32 bits
>    MS Windows 64 bits
>
> Ofront+ was tested and used with C compilers:
>
>    GCC/MinGW, 32/64 bits
>    Clang
>    SDCC (Small Device C Compiler)
>    Tiny C (tcc)
>    cc65 (for CPU 6502)
>
> The latest build of Ofront+ you can get here:
>
>    https://github.com/Oleg-N-Cher/OfrontPlus
>
> I have been working on this for many years and try to keep the project
> afloat all the time. It's not very documented and it's not covered by a
> huge set of tests, but I do what I can based on my modest strength.
>
> I didn't plan to go that far, I just needed to make a few changes. Then
> I wanted to make support for Windows. Now we have the result of this
> work. I still want to do a lot before the release of version 1.0, but
> this is already quite stable.
>
> I won't tell you very much about the differences, but users say that I
> went too far. ;-)
>
> Ofront+ comes as a subsystem for BlackBox and as command line tool
> (Oberon-like GUI not implemented).
>
> So welcome, please use, write reviews and suggestions. Also I provide
> support for free.
>
> I want to thank Josef Templ, who actively supported me and helped me
> solve many problems.
>
> I also want to thank Stewart Greenhill, who made useful improvements and
> helped fix problems, and developed his own tools for Ofront+.
>
> List of differences and improvements:
>
>    https://github.com/Oleg-N-Cher/OfrontPlus/blob/master/Readme.txt
>
> --
>   Oleg N. Cher
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201126/18e56b7d/attachment.html>