[Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)

[Guy T.]

I’m following this thread with great interest… I was not expecting this but it is a very interesting discussion.

For me, the fundamental question is: What is the community trying to achieve?

Some partial answers:

- Attract other peoples in the realm of Project Oberon and/or the Oberon language.
- Continue the development of Project Oberon in a niche RISC5/fpga based environment.
- Extend the Project Oberon to get it run on many different hardware platforms.
- Extend the Project Oberon to supply other useful tools to the end user.
- Other aspects (like convergence of Oberon dialects, etc.)
- All of the above

My current personal requirement is to use the Oberon language as a mean to develop IOT applications on a chip that was not looked at by the community up to now. At first, I expected to use it in a “bare metal” manner, but I found impossible to do without taking into account the complexity/lack of openness of some hardware related aspects of the targeted chip (ESP32) and the need to interface the de-facto framework. That framework (ESP-IDF) can be seen as an abstraction layer to the hardware.

I would like to see the Oberon OS available on other platforms than the RISC5, not because it’s not a nice idea, but it limits the availability of a functioning platform as the hardware is rather limited in availability. For sure, there is the RISC5 emulator that can be used on many platforms, but I would prefer to see it runs as a main alternative to Windows/Linux/Whatever. Getting it run on a very cheap platform like the Raspberry Pi would be a bonus. It can help attract peoples to the community.

To limit the effort of porting the Oberon Project to other platforms, abstracting the hardware is a key aspect, both for the OS and for the compiler. Both aspects need to be resolved. Building an abstraction layer from scratch would be an important challenge. Think about USB, Ethernet, WiFi, Disks Format, etc. The compiler is the easiest portion of porting the project, as long as the community converge to a solution.

A first step toward abstracting the hardware could be to use the Linux kernel. Just the kernel, and then build on top of it. You then gain all the drivers for almost every piece of kit available, transforming the OS only once. For the compiler, depending on the choice taken, GCC and its dependencies would be also required.

But first, there is a need to converge toward a vision to where, as a community, you/we see the future of this project.

Cheers!

Guy