[Oberon] Oberon-1 or Oberon-2?

[Jörg]

Hi

As we see in this discussion: There are HW guys where building and soldering
a board is a piece of cake and there are the softies where writing code is
rather like eating or breathing :-)

The whole idea of the RISC5 project was to dismiss this HW/SW discussion and
demonstrate how a complete computer system works from A to Z: It needs a
programming language, it needs a compiler, it needs an operating system with
its HW drivers and it needs HW.

If you take existing programming languages, existing OSes, existing
compilers and existing CPUs you cannot teach the students the basic concepts
of these computer parts as you are distracted by too many details.
Try writing a compiler for the latest Intel processor: you get nuts to
really take benefits of all bells and whistles these powerful CPUs deliver.
If you start writing a compiler for C or C++ language you get nuts by the
thousands of exceptions you would have to handle.
All can be done and actually has been done but this is not something you
want to teach at university.

Professor Wirth wanted always to make things as simple as possible to teach
the basic concepts of computer science. So, he invented his own minimal OO
language, built his own compiler for it generating his instruction set, and
the built an OS around it. What was missing was a HW that really executed
his instruction set. Having experimented with quiet a few existing CPUs, he
always found the compiler gets too complex to teach how a compiler works.
Finally, with the help of FPGA he was able to build his own CPU HW without
going through an expensive ASIC production.

Adapting an existing compiler to generate RISC5 code could be a nice
semester work or so. But I fear that ETH is not interested in doing it as
the current professors have other topics of interest.

But I'm with Chris: Project Oberon is a great achievement for education. I
would wish there is an active community taking care of this project and
adding things to it (like Chris mentioned eg. Ethernet). In its current
state it's too simplistic and I guess will not find a lot of friends :-(

br
Jörg

-----Original Message-----
From: skulski at pas.rochester.edu [mailto:skulski at pas.rochester.edu] 
Sent: Mittwoch, 29. Oktober 2014 16:38
To: oberon at lists.inf.ethz.ch
Cc: skulski at pas.rochester.edu
Subject: Re: [Oberon] Oberon-1 or Oberon-2?

> Date: Wed, 29 Oct 2014 08:07:36 +1030
> From: "Chris Burrows" <chris at cfbsoftware.com>

> If you are considering porting Oberon / Oberon-2
> or Component Pascal to a new platform,
> investigate which languages are currently being used
> to develop the sort of applications that you want
> to implement, and the libraries that you want
> to use on that platform. If they are predominantly
> written in C then Oberon might well be adequate.
> If they are written in C++ and extensively using
> the O-O features of C++ then Oberon-2 would likely be
> more suitable. If they are written in C# then
> you will find that Component Pascal for .NET
> is the most compatible.

Chris:

  this is a very good comment. I know where it is coming from: you are
looking from the software perspective. If I was planning to work with
Rpi, Arduino, Netduino, or one of your ARM development boards, then your
proposition would make perfect sense. My plans are different, though. I
want to focus on the FPGA, using the Oberon System 2013 as the starting
point. Here I can see that The System was deliberately chopped down. I
can see Professor's Wirth point in doing so for the purpose of updating
his book. He was documenting the state of affairs in a given point in
time, which predated V4, System-3, and all the subsequent work. This is
fine. But from my perspective it would be more practical to start from
the later point in time. Just compare the Linz V4 with the original
Oberon System and you will see how much useful software went into the V4
distribution. Ditto with System-3.

So from purely practical perspective I prefer to start from the more
mature point in the Oberon System history. In order for this to happen the
more recent version of the compiler needs to emit the RISC5 code. This is
my current question to the community. Is there any chance that OP2 is
updated to RISC5, or perhaps the Wirth compiler, whichever is more
practical. Another option would be to ditch the RICS5 and use some other
processor core which is served by one of existing OP2 back ends. I am not
sure if this is a practical option.

FYI, designing the appropriate FPGA board is a piece of cake compared with
porting the compiler. I can do the former, but not necessarily the latter.
And frankly, why should I try to perform the task which others in this
community can do much better than I can?

Regards,
Wojtek


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6097 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20141029/c201f193/attachment.bin