[Oberon] Concurrency support in Oberon

[Jörg]

Hi

Using the module SYSTEM is not dangerous per se.
It is rather thought to flag a module as "non portable".

Functionality provided by module SYSTEM are either HW related, endianness
related or low-level CPU register related. The functionality of SYSTEM is
implemented by the compiler itself, so you can compare it to kind of
compiler flags in C.
Programs using MODULE are most probably not easily portable to other HW,
CPUs or register usage schemes.

Writing OSes (and compilers) tend to be very close to HW/CPU.

br
Jörg

-----Original Message-----
From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Lars
Sent: Donnerstag, 24. November 2016 12:20
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Concurrency support in Oberon

On Tue, November 22, 2016 11:15 pm, Srinivas Nayak wrote:
> 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...

Well there is BSD..and minix.. so why not?

As much as I hate forks, or clones, or duplications of efforts, I'm all in
favor of academic projects that go against the grind... BSD tends to be
simpler without as many nobs as linux, while minix tends to try to solve
the crashing issues and danger issues to try and make the system more safe
and reliable. Different approaches, all still useful research projects.

>  When our world is full of OSs... why shall I create one more?

Because all operating systems are garbage and suck.

"Sucks less" is the goal...

Same goes with programming languages. Why have one more? Because most of
them are pathetic...

Oh no, a pessimist in the room!


> 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 only allow this if SYSTEM keyword used? That was my point in another
email...

i.e. if oberon doesn't have something that C has, why not implement it in
SYSTEM? If SYSTEM ability is lacking, it must be improved


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

And GoLang has a runtime similar to, maybe visual basic 6.0 where the
runtime is shipped inside the executable. Well not so similar to visual
basic 6 if it was a DLL.

So, you ship runtime as part of exe, or part of something else.. like JVM,
or ld-linux.so.....

What is disadvantage of shipping it with Exe/Elf? makes exe bigger... you
don't like that?  Making something like ld-linux reduces need for runtime
to be cloned into each exe, wasting space?  Shipping runtime as DLL/SO
causes "DLL hell"? .... like when you got that visual basic error "run
time missing" or "Visual c++ library missing"...

So you mean putting run time closer to the kernel? instead of a JVM that
sits on the system as a service running...

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

Then for another dream, create apache module that causes web servers to
have access to oberon system...  Not sure if this would be of any use.

> Now, I am sure, every body will kill me...
> They will call me mad...
> But it was just a dream...
>

You may have reached Arthur Schopenhauer...
https://www.brainyquote.com/quotes/quotes/a/arthurscho103608.html
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon