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

[Liam Proven]

On Thu, 30 Apr 2020 at 23:29, Guy T. <turgu666 at gmail.com> wrote:
>
> For me, the fundamental question is: What is the community trying to achieve?

A fair point.

> Some partial answers:
>
> - Attract other peoples in the realm of Project Oberon and/or the Oberon language.

Yes.

> - Continue the development of Project Oberon in a niche RISC5/fpga based environment.

Not of particular interest to me, personally.

> - Extend the Project Oberon to get it run on many different hardware platforms.

Would be lovely to see.

> - Extend the Project Oberon to supply other useful tools to the end user.

Also good.

> - Other aspects (like convergence of Oberon dialects, etc.)

Indeed a serious problem that is rarely discussed.


> 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.

Valid point.

AFAIK, there are several Oberon compilers that can target ARM. That
part is done.

The RasPi is a very odd machine, in that the ARM is _not_ the central
processor. The main processor is the GPU and it is the GPU that boots
the machine. Once it has initialised the hardware and so on, it reads
a file called KERNEL.IMG on a FAT partition on the SD card, puts it in
RAM, and tells the ARM to start executing.

So you don't need a bootloader or anything.

There are of course many other cheap ARM boards out there, from the
Orange Pie to the Pine64. Most are a lot more standard. But all put
together, their sales are a fraction of the sales of the RasPi.

I would suggest _starting_ with the RasPi and if the interest emerges
it would serve as a bootstrap for other more-standard hardware: a
working ARM kernel, a working USB stack, etc.

I mean most of the parts are already there.

> 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.

This is what AROS is doing to target the RasPi. Something similar
applies to Haiku, the Aranym/AFROS project and others. I think it is a
_very_ bad idea.

In Oberon's case it would mean using a multi-megabyte inefficient blob
of millions of lines of code to support a tiny efficient kernel less
than 0.1% of the size.

So, you lose the efficiency, you lose the small size and simplicity,
and you end up with something nearly as bloated as Linux -- but it's a
very poor Linux that's not very compatible.

Better to start with, say, Ultibo:

https://ultibo.org/

Component Pascal on the bare metal of the Pi. Supplies all the drivers
etc. ready to go.

There is already an Oberon hardware emulator hosted on Ultibo, but
it's not a native OS.

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

Very true. Although FOSS projects do not need to have a single goal.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053