[Oberon] Concurrency support in Oberon

Wed Nov 23 09:06:15 CET 2016

Srinivas

The goal of the Oberon language was to show two things
- it shall be a high level language simple to learn with as few reserved words as necessary.
- it shall offer high level functions but also low layer functions being able to use it to program an OS.

The proof of the first point is: the report describing Oberon-07 (syntax and semantics) is only 17 pages.
The proof of the second point is: ProjectOberon is an OS completely written in Oberon.

Concurrency can be non-preemptive or preemptive. Non-preemptive concurrency is easier to implement in your OS. You have to study mechanisms like semaphores, mutex and coroutines.

In essence it boils down to how your underlaying CPU is handling procedure calls. Knowing the exact details of this mechanisms (what registers are used, does the CPU store/restore registers automatically, what happens to the stack…) is paramount when you want to implement e.g. coroutines. Coroutines can be provided on top of ProjectOberon in Oberon-07 as normal module. You will need SYSTEM.REG and SYSTEM.LDREG to do it.

Pre-emptive concurrency (aka interrupts) are harder and need some compiler support to handle the interrupt concept of the underlying CPU correctly.

br
Jörg

> Am 23.11.2016 um 07:15 schrieb Srinivas Nayak <sinu.nayak2001 at gmail.com>:
> 
> Nice coincidence, received Skulski's post while I was posting mine, just two seconds after.
> 
>> First, why write another Linux if you have the original? What would you gain?
> 
> You are correct. A big No... I never intended to create one more Linux...
> When our world is full of OSs... why shall I create one more?
> It was just thrown as an example to stretch thinking of friends,
> to answer, how concurrency can be achieved using Oberon language...
> 
> Intention behind Linux example was:
> Say tomorrow I will set out to write a new OS using Oberon...say a Unix like OS...
> Oberon is a system programming language. Everybody agree on this.
> So, can I succeed choosing Oberon as my language of this OS implementation?
> I was thinking, is there any language level primitive for atomic action?
> 
> This was the thought that time...
> 
> Later I saw Active Oberon is having something called Await and Signal. :-)
> No doubt, even if Oberon doesn't have any such primitive, like C,
> we can create small low level functions which directly calls
> machine instruction like XCHG (for x86) and provide atomicity.
> And then on wards one can build up slowly the rest of the Unix world.
> But having a language feature is even better...like Await and Signal.
> Otherwise, such two SYSTEM functions also will do the job.
> 
> And this was the after thought... :-)
> 
> ============
> 
> Ok, now about Oberon programming on Linux...
> 
>> I am not sure if there is such a thing as a Linux linker and loader. I thought that the Linux toolchain was named GCC. With that perspective, the work has already been done.
> 
> To my knowledge, Linux's linker is "ld" and loader is "ld-Linux.so"
> When you compile a program with GCC, ld is called inside GCC it to create the executable.
> Inside the executable, loader name "ld-Linux.so" is hiddenly kept written.
> When shell starts to execute the executable, this loader gets activated.
> Then all needed librararies are loaded and your program starts...
> 
>> Linux kernel can load and unload "kernel modules" on demand with commands such as insmod and modprobe.
> Correct, but I was talking about Oberon modules.
>> Furthermore, internally the Linux kernel is a cooperative multitasking environment without memory protection. Sounds familiar?
> Yes. correct.
> 
>> en.wikipedia.org/wiki/Oberon-2#Implementations says: The Optimizing Oberon-2 Compiler compiles to C, using the GCC toolchain for program generation. [...] XDS Modula2/Oberon2 [...] contains an optimizing compiler for Intel Pentium, or "via-C" translator for cross-platform development. Available for Windows and Linux.
> 
> Correct. OO2C is good. Also there is voc, which is good too.
> My intention was not about optimized output and portability.
> I was interested to know how things work...
> So there, I was thinking, if Oberon is a small language,
> and can create native code, why not it can emit x86 code directly?
> Now you will say, why not take OP2 compiler that comes with Native Oberon?
> But I was thinking, if NW's Oberon 7 compiler is just 4 files
> and all machine code can be put into 1 file OSG.Mod,
> why take pain of many files of OP2. Again portability is not the need.
> Now, if we agree to this, we can have a small Oberon 7 compiler
> that directly emits x86 code...
> 
> After this, time to run the code...
> No doubt, output of OO2C and voc also runs.
> But they take help of Linux loader.
> Which is simply inadiquate to provide beauties of Oberon philosophy.
> Like command activation, dynamically (un)loading imported modules...etc.
> Towards that end, you will suggest 1. installing Oberon OS on Linux to get those benefits.
> or 2. installing Blackbox on Linux.
> 
> 1. I think, why we need a whole OS to load?
> Can't we create a minimal runtime environment for our Oberon program?
> Like Java has its own, ld-Linux.so is C's runtime environment...
> Similarly, if we can create our own loader, it can be activated from executable,
> it can provide us SYSTEM, it can provide us rest runtime necessities of our program,
> it can provide garbage collection, etc etc... just a dream :-D
> 
> 2. I am happy about this...
> But the way ld-Linux.so works invisibly, if blackbox could work similarly...
> And yes, I was thinking about Oberon 7, not component pascal and component oriented stuff...
> Just small part of blackbox which allows Oberon 7 features only...
> to help me create CLI (and GUI) apps in Oberon in an small environment like guided in Owkwood guideline...
> 
> Now, I am sure, every body will kill me...
> They will call me mad...
> But it was just a dream...
> 
> 
> 
> With thanks and best regards,
> 
> Yours sincerely,
> Srinivas Nayak
> 
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
> 
> On 11/23/2016 10:12 AM, Skulski, Wojciech wrote:
>> Srinivas:
>> 
>>> But how to make a Oberon program run on bare Linux, i.e.
>>> how to create runtime environment for an Oberon program
>>> using Linux linker and loader, that is now on my head...
>> 
>> I am not sure if there is such a thing as a Linux linker and loader. I thought that the Linux toolchain was named gcc. With that perspective, the work has already been done.
>> 
>> en.wikipedia.org/wiki/Oberon-2#Implementations says:
>> The Optimizing Oberon-2 Compiler compiles to C, using the gcc toolchain for program generation. [...] XDS Modula2/Oberon2 [...] contains an optimizing compiler for Intel Pentium, or "via-C" translator for cross-platform development. Available for Windows and Linux.
>> 
>> Also do not forget Ofront.
>> 
>>> On import, we have to load modules on the fly...
>>> We should be able to unload modules and re-load...
>> 
>> Linux kernel can load and unload "kernel modules" on demand with commands such as insmod and modprobe.  Furthermore, internally the Linux kernel is a cooperative multitasking environment without memory protection. Sounds familiar? I found this information in Linux kernel programming books. These books also say that "kernel modules" are a form of OOP.  If I look at Linux kernel, then Il recognize the most important Oberon System features in disguise.
>> 
>> I have not seen any reference to Project Oberon in Linux literature despite some Linux kernel architects being prominent figures in academic computer science. Oberon System predated Linux "kernel modules", if I am not mistaken. Linux creators seem not to know the history of their own field.
>> 
>>> I feel, writing a Linux like OS using Oberon is possible...
>>> Forgetting for the time being Garbage collection and command activation...
>>> And providing certain run-time data structures...
>> 
>> First, why write another Linux if you have the original? What would you gain?
>> 
>> Second, it is not a stretch to say that Oberon System is an OS kernel by itself. Just the way it is now, it is quite analogous to the Linux kernel. If you agree with that, then you "only" need to add the notion of tasks running in the user memory space, while the Oberon System now assumes the role of the Linux kernel. You "only" need to add virtual memory for the user space, as well as "system calls" to break through the user/kernel barrier. The system calls can be executed by user programs written in some other language other than Oberon.
>> 
>> After doing this you will have an analogon of the Linux architecture. I am not sure what would be a benefit of developing such a copy.
>> 
>> W.
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon