J. My point is still valid. Selecting a kernel like the Linux one would be a good starting point to get all compatible linux hardware readily available for the Oberon OS. The linux kernel interface can then be used as the hardware abstraction for other integrations like specific chips. You then create the specific limited “kernel” in line with the specifications of the chip manufacturer. Guy

August: Gcc is a big beast and full of deceit, but there are an awful lot of people working on it. As a result Gcc generally knows about the latest hardware available. Also crosscompiler tool chain building is pretty well standarized. So provided it has the input language you want to use, you generally can rig up a tool chain almost semi automatically. It just takes some time recompiling the beast and the utilities.

Guy: Linux on a fast Arm chip works reasonably well, but for slow Arm controllers and small fry a bare metal solution works much much better. For hi level peripherals one can use the manufacturer provided libraries via a binding if needed. Just as you are trying to do, except that in your case the library is proprietary.

J.

On Thu, 30 Apr 2020, 23:29 Guy T., <turgu666 at gmail.com> wrote:

...

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