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

[Guy T.]

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