[Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)
Jan de Kruyf
jan.de.kruyf at gmail.com
Thu Apr 30 21:47:40 CEST 2020
You talk so well, much better than I ever could, you will be the
Oh and the technical writer that delivers 1st class doku, no matter what 💥.
And System 3 with Gadgets ran very well in Virtual box last time I
installed it. Just make some image files of the disks and mount them on a
I downloaded Vishap this afternoon, which is based on Ofront. It is very
x86 centric, and I am not sure about the amount of work to break that out
and change it to any architecture, but I fear not little.
While I do have a very good idea of how to set up a bare metal Ada runtime
with library both for small Avr 8 bitters and stm32 on a virgin gcc.
Basically the runtime splits in 3. The clib, the controller specific
hardware layer and the (Oberon) OS to whatever extend it is needed.
For me the unknown is the front end. Maybe study that Modula2 compiler for
a bit as well.
On Thu, 30 Apr 2020, 20:57 Liam Proven, <lproven at gmail.com> wrote:
> On Thu, 30 Apr 2020 at 06:17, Joerg <joerg.straube at iaeth.ch> wrote:
> > If I think of it, what I personally really like is actually not the
> Oberon language but the Oberon OS.
> Me too.
> The problem I have found talking about and trying to tell people
> about Oberon (language or OS) is that today, for most people, there
> are only 2 OSes: Windows NT and Linux. Everything else is niche or an
> end-user tool of little interest to anyone except professional
> programmers (macOS & iOS).
> People have genuinely, seriously said to me that there's no point in
> investigating other languages or OSes, because ultimately they are all
> implemented in C anyway.
> If all you know is NT and *nix, this is _obviously_ true: everything,
> at the bottom, is written in C. Because everything that is _not_
> implemented in C is so obscure most people have never heard of it.
> They don't know it even exists.
> This is the "black swan problem":
> For millennia, it was a given that all swans are white, because in
> Europe and Asia and Africa, nobody ever saw a black swan. There are
> lots of different species of swans but they are all white. Therefore,
> all swans are white, QED.
> Then Europeans got to Australia and found that Australian swans are black.
> Nobody ever questioned that swans are white, because nobody ever even
> imagined that they could be any other colour. It was obvious that all
> swans are white because they all are.
> In programming languages today, from Perl to Python, to Lisp (on x86
> etc), to Pascal (Delphi etc.), .NET, Java, C++, D, C#, Clojure,
> whatever: either it's written in C or it's written in something that
> was implemented in C. It does not matter where you start, on and Unix
> or on any Windows, if you go down enough layers, you will get to C.
> Therefore, everything is implemented in C.
> Even things like Genode (Rust) or HelenOS... still C underneath.
> The modern alternatives to C, e.g. Rust or Go, were implemented in C.
> Apart from a few crazy or ancient systems that were hand-crafted in
> assembly, or at least parts of them: AmigaOS, MenuetOS, VisOpSys. They
> don't really matter.
> Thus, it is obvious that all swans are white, and all languages are
> written in C.
> So to get people interested in the idea that there is a whole other
> way to write OSes, and a whole other family of languages alive and
> well that _don't_ stem from C or from the Unix/Mac/DOS lineage, it is
> necessary to demonstrate to them that this language is real, it
> exists, it's not proprietary or commercial, and it doesn't just run on
> its own weird OS they've never heard of... it runs on the OSes they
> know and they can use it and explore it, and _then_ try the OS.
> > But indeed the crux of the Oberon OS is the not existing driver eco
> system for HW!
> It would seem to me that there are 2 ways to look at this.
> I regularly see people asking if they can run Classic MacOS, or RISC
> OS, or AmigaOS, under VirtualBox, or VMware, or $(insert hypervisor).
> They are not really aware that there are other architectures than x86.
> x86 is a given; all personal computers have x86. PC, Mac, Linux, even
> weird things like FreeBSD or AROS... all run on x86. So if people
> experiment with weird OSes, they run them on a hypervisor.
> The idea that there are OSes that they _can't_ run on a hypervisor is
> shocking and new.
> What this means is that perhaps what we need to focus on for Native
> Oberon is just making sure that it runs well on the main hypervisors.
> * VirtualBox is the main freeware one and runs on Windows, macOS and Linux
> * KVM and Xen are the main Linux ones (including KVM behind GNOME Boxes)
> * VMware and (very distant 2nd) Microsoft Hyper-V are the main
> commercial ones. Hyper-V comes free with modern Windows, though.
> The most important drivers for Native Oberon, then, IMHO, are to make
> sure that it works well on hypervisors -- mainly VirtualBox and
> VMware, followed by KVM. If it installs easily and runs well, then
> we're good.
> The second thing to consider, IMHO, is that it might be "better to be
> a big fish in a small pond, than a small fish in a big pond."
> If you're a small fish in the sea, you are in constant danger of being
> eaten. If you're a big fish in a little pond, you are safer and being
> noticed becomes a good thing.
> So I suggest that it would be better for Oberon if it supported some
> more narrow non-x86 hardware, where the number of necessary drivers
> would be tiny.
> This means ARM, realistically.
> And the best-selling end-user ARM computer in the world is the
> Raspberry Pi, with over 30 million units sold as of the end of last
> year: https://www.zdnet.com/article/raspberry-pi-now-weve-sold-30-million/
> There are only a handful of models and fewer if you only look at those
> still on sale. The Raspi 2, 3 and 3+ are inter-compatible. The Raspi 1
> is discontinued. The Compute Module is not really relevant (and is
> compatible anyway.)
> The Raspi Zero and Zero W (with wireless) are only about £5/$5 and are
> compatible with the 2/3/3+, but single-core.
> I would say:
> - don't worry about driver support on x86; assume basically nobody
> will run it on bare metal. Make sure it works in 2 (maybe 3)
> hypervisors, and don't worry.
> - get it running on the Raspi 2/3/zero
> - the 4 is newer and optional, for now.
> Linux is very limited on the Raspi 2/3/zero: it's very slow and barely
> fits. This would be a _major_ chance for Oberon to shine.
> 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
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon