[Oberon] Oberon 2 on RISC5
Mike McGaw
mike at mcgawtech.com
Wed Nov 7 13:23:05 CET 2018
I have read with more than passing interest regarding comments on implementing Oberon 2 for RISC5 targets.
I think this is an excellent idea.
While I certainly can understand that the OP2 compiler would struggle with RISC5 on FPGA due to memory limitations in the hardware, I think we may be missing an important segment of
application if we focus on an OP2 compiler that is _intended_ to run on a RISC5 FPGA hardware target.
It would be very useful to simply have an OP2 backend for RISC5, so that this could be used as a crosscompiler, but on a classical Oberon system (with more resources to support this, and also provide better support of hosting environment resources, file systems, network, etc., etc.). Most uses that are of a practical nature for RISC5 are not of the full system nature (e.g., running a display, keyboard and mouse, etc.), although such a system has pedagogical value. Instead, they are headless, embedded. If you want a full system, there are certainly much cheaper and much better (color depth, display sizes, etc., etc.) ways of doing this, and these can more or less easily host a classical Oberon system (see Matthias' excellent OLR work, for example, or the seemingly timeless V4 systems of Linz).
It would be a useful exercise to have an Oberon 2 compiler for RISC5, but I might suggest that focusing on a back end for OP2 might be preferred, as it would make use of an already well sorted, well pedigreed OP2 scanner/parser/AST capability, so that users would not have to learn a new compiler's idiosyncracies. Tools that behave in a predictable manner, fitting within an established, well understood experience base are rather valuable. And I have not touched on how SYSTEM might be done in a new Oberon 2 implementation on RISC5, vs an OP2-based approach...
As a cross-compiler, one could use the interpreted RISC5 systems (suitably expanded in memory), or one of the myriad of classical Oberon systems to host the OP2 compiler.
A worthy longer term goal might be a VM-based RISC5 implementation that supports the display and memory needs/characteristics of the classic V4 and S3 systems, equipped with an (OP2-based) Oberon 2 capable compiler. Then, the user/developer could choose any way they wished to proceed: embedded RISC5, or an immensely portable development/host environment. And, more to the point, the entire system would be lifted away from a hosting environment in a manner that would render it timeless.
-Mike
--------------------------------------------
On Wed, 11/7/18, <oberon-request at lists.inf.ethz.ch> wrote:
Subject: Oberon Digest, Vol 174, Issue 8
To: oberon at lists.inf.ethz.ch
Date: Wednesday, November 7, 2018, 6:00 AM
Send Oberon mailing list submissions to
oberon at lists.inf.ethz.ch
To subscribe or unsubscribe via the
World Wide Web, visit
https://lists.inf.ethz.ch/mailman/listinfo/oberon
or, via email, send a message with
subject or body 'help' to
oberon-request at lists.inf.ethz.ch
You can reach the person managing the
list at
oberon-owner at lists.inf.ethz.ch
When replying, please edit your Subject
line so it is more specific
than "Re: Contents of Oberon
digest..."
Today's Topics:
1. Re: LED in FPGA Oberon
(Walter Gallegos)
2. Re: a module a page (keeps
the mind sane)? (Frans-Pieter Vonck)
3. Startup script for
Oberon V4 for Linux (Treutwein Bernhard)
4. Re: a module a page (keeps
the mind sane)? (Charles Perkins)
5. Re: a module a page (keeps
the mind sane)? (Frans-Pieter Vonck)
----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Nov 2018 08:23:47 -0300
From: Walter Gallegos <walter at waltergallegos.com>
To: oberon at lists.inf.ethz.ch
Subject: Re: [Oberon] LED in FPGA
Oberon
Message-ID: <25df86bf-11c4-e9c2-e4ca-1e710a294046 at waltergallegos.com>
Content-Type: text/plain;
charset=utf-8; format=flowed
Hi Wojtek,
LED even practical into PO ecosystem is
hardware specific. In my
RiscCore there are not LEDs connected
to processor core. This
functionality is relayed to the custom
project. The final user implement
your own status indicators in hardware
and the correspondent software
module; so, LED related lines are
commented in my compiler files set to
avoid mistakes.
Regards.
El 5/11/18 a las 23:36, Skulski,
Wojciech escribi?:
> Hello:
>
> There is this "proper procedure"
named LED on page 15 in the Oberon-07 Report dated Revision
1.10.2013 / 3.5.2016, which is the newest version of the
language.
>
> Proper procedures:
> Name Argument types Function
> LED(n) INTEGER display n on LEDs
>
> It is a very convenient procedure
indeed. It is provided in both the Oberon System proper, as
well as Astrobe. It is used in the core bootloader to track
the progression of the code.
>
> However... Is it not strange that
the little debugging utility geared towards just the FPGA
applications has been carved into the Language Report? I
would rather see it as a SYSTEM feature SYSTEM.LED(n), or as
an "undocumented feature" of a particular implementation.
Ideally, it would have been a separate MODULE. But I do
understand that it was needed for the bootloader which is
executed prior to loading the system kernel. In this
situation, SYSTEM.LED would be the most appropriate, IMHO.
>
> In my RiskFive we are not
providing the FPGA pins to drive LEDS due to shortage of
pins in the Artix-7 in the CSG324 package. I am rather
providing an I2C pin expander with eight LEDs. We will
provide for eight LEDs driven with outputting an INTEGER to
a particular address, where the I2C firmware will take care
of sequencing the signals. So I am not ditching the LEDs.
But I do not like including such a specialized facility
directly in the Language Report.
>
> Wojtek
> --
> Oberon at lists.inf.ethz.ch
mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
------------------------------
Message: 2
Date: Tue, 06 Nov 2018 14:00:11 +0100
From: Frans-Pieter Vonck <fp at vonck.nl>
To: chris at cfbsoftware.com,
ETH Oberon and related systems
<oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] a module a page
(keeps the mind sane)?
Message-ID: <02bc95390a406ed158c1aa427bf12b0c at vonck.nl>
Content-Type: text/plain;
charset=UTF-8; format=flowed
Hi Chris,
do you have by any chance a link for
the article "Tasks versus Threads
[..]"
I cannot find it on the net.
From Wirth: "Embedded Systems and
Real-Time Programming"
" The next decision was to eliminate
the RT-OS, as it seemed possible
to do essentially
without concurrent processes in
the form of
threads. The third
decision was to program the entire
software in Oberon [2], which is very
suitable for
programming close to the hardware."
So he probably used Tasks vs Threads
concept for the helicopter.
> "Tasks, called commands, are a
conceptual pillar of the Oberon
> operating environment. Making them
interruptible adds significant
> power to the concept
In the oberon loop the commands are
already interrupted by input events:
keyboard, mouse, network communication.
Does he mean, tat a task can
interrupt another task?
Explanation must be found in his
article.
Greets,
F.P.
Chris Burrows schreef op 2018-11-06
11:48:
> I recommend that you read Wirth's
1996 paper titled "Tasks versus
> Threads: An Alternative
Multiprocessing Paradigm". The relative merits
> of tasks, processes, coroutines
and threads are discussed.
>
> "An alternative to threads is
presented as a paradigm for
> single-processor multi-tasking
systems. It avoids complex and hidden
> mechanisms for process scheduling,
and is therefore particularly
> suitable for realtime systems
requiring fast response times, and for
> small systems in general."
>
> "Tasks, called commands, are a
conceptual pillar of the Oberon
> operating environment. Making them
interruptible adds significant
> power to the concept and is shown
to require surprisingly few changes
> and additions to the existing
system, hence retaining its basic
> compactness and efficiency."
>
> An implementation of these ideas
(called System7) on Native Oberon can
> be downloaded from the ETH Oberon
site:
>
> ftp://ftp.ethoberon.ethz.ch
>
> by following the path:
>
> ETHOberon/Contrib/System7/
>
> Now that interrupts are working on
Project Oberon 2013 it would be an
> interesting exercise to try out
these concepts there as well,
>
> Regards,
> Chris
>
> Chris Burrows
> CFB Software
> http://www.astrobe.com/RISC5
>
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch]
On Behalf Of
>> Frans-Pieter Vonck
>> Sent: Tuesday, 6 November 2018
6:39 PM
>> To: J?rg Straube
>> Cc: ETH Oberon and related
systems; paulreed at paddedcell.com
>> Subject: Re: [Oberon] a module
a page (keeps the mind sane)?
>>
>> Hi J rg,
>>
>> I saw the coroutine module is
not yet written for project oberon.
>> But that does not keep me from
trying out the concept of cooperatieve
>> multitasking.
>> I will look into that,
>>
>> Thanks.
>> F.P.
>>
>> J rg Straube schreef op
2018-11-05 23:22:
>> > F.P.
>> >
>> > Installing tasks in the
Oberon loop is THE way to enable multi
>> tasking
>> > in Oberon.
>> >
>> > T :=
Oberon.NewTask(myHandler, 1000);
>> > Oberon.Install(T);
>> >
>> > Every 1000 ms the
procedure myHandler will be called.
>> >
>> > Another way to have
cooperative multitasking is to implement module
>> > Coroutines .
>> >
>> > br
>> > J rg
>> >
>
>
> --
> Oberon at lists.inf.ethz.ch
mailing list for ETH Oberon and related
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
------------------------------
Message: 3
Date: Tue, 6 Nov 2018 14:36:32 +0000
From: Treutwein Bernhard
<Bernhard.Treutwein at Verwaltung.Uni-Muenchen.DE>
To: "'oberon at lists.inf.ethz.ch'"
<oberon at lists.inf.ethz.ch>
Subject: [Oberon] Startup script
for Oberon V4 for Linux
Message-ID:
<78A8BD6765DCF048A628A51C3FBD1D7659BA7F25 at MXS2.zuv.uni-muenchen.de>
Content-Type: text/plain;
charset="us-ascii"
I finally succeeded with the following
slightly modified startup script:
I trried it successfully with TinCore
9.2 (you have to install the bash extension),
Q4OS 32bit and 64bit.
-------------------------------------------- cut
here -----------------
#!/bin/bash
# change the line below if you have
installed oberon to a different
# directory
export OBROOT=/usr/local/oberon
for f in `find $OBROOT/ -maxdepth 1
-mindepth 1 -type d`; do
rm `basename $f`
if ! test -e `basename $f` ;
then
ln -s $f
`basename $f` 2> /dev/null
fi
done
rm root
ln -s $OBROOT root 2> /dev/null
OBERON="./:`find $OBROOT/ -type d | tr
"\12" :`"
export OBERON
xset +fp $OBROOT/xfonts
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OBROOT
$OBROOT/oberon $1 $2 $3 $4 $5
-------------------------------------------- cut
here -----------------
The differences to the original version
of Robert are the following:
1. move -type d behind -mindepth 1
2. append / to $OBROOT in the two find
statements
(diff -uw sob sob.org):
----------------------------------------
---
/usr/local/oberon/sob 2018-11-06
15:07:13.253525925 +0100
+++
/usr/local/oberon/sob.org 2004-11-05
19:47:16.000000000 +0100
@@ -2,9 +2,9 @@
# directory
export OBROOT=/usr/local/oberon
-for f in `find $OBROOT/ -maxdepth 1
-mindepth 1 -type d`; do
+for f in `find $OBROOT -type d
-maxdepth 1 -mindepth 1`; do
rm `basename $f`
if ! test -e `basename $f` ;
then
ln -s $f
`basename $f` 2> /dev/null
@@ -12,7 +12,7 @@
done
rm root
ln -s $OBROOT root 2> /dev/null
-OBERON="./:`find $OBROOT/ -type d | tr
"\12" :`"
+OBERON="./:`find $OBROOT -type d | tr
"\12" :`"
export OBERON
xset +fp $OBROOT/xfonts
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OBROOT
----------------------------------------
Bernhard
>-----Original Message-----
>From: Tomas Kral [mailto:thomas.kral at email.cz]
>Sent: Friday, November 02, 2018
1:26 PM
>To: oberon at lists.inf.ethz.ch
>Subject: Re: [Oberon] addition:
Oberon V4 for Linux
>
>On Fri, 2 Nov 2018 12:07:00 +0000
>Treutwein Bernhard <Bernhard.Treutwein at Verwaltung.Uni-Muenchen.DE>
>wrote:
>
>> only a "-- failed" entry in
the System.log
>
>I recoded to this and now it
works.
>
>#!/bin/sh
># oberon start up script
>
>export OBERON=="./:`find $PWD -type
d | tr "\12" :`"
>echo $OBERON
>#xset -display $DISPLAY +fp
$PWD/Fonts
>export LD_LIBRARY_PATH=$PWD
>./oberon
># eof
>
>I needed to install and load fonts
on local machine `RPI', as I connect
>to x86 server using `ssh -x', wheer
Linz Oberon V4 is installed. So I
>need to run this command on local
`xset -display $DISPLAY +fp
>$PWD/Fonts'
>
>Is there a better way?
>
>--
>Tomas Kral <thomas.kral at email.cz>
------------------------------
Message: 4
Date: Tue, 6 Nov 2018 07:05:35 -0800
From: Charles Perkins <chuck at kuracali.com>
To: fp at vonck.nl, oberon at lists.inf.ethz.ch
Subject: Re: [Oberon] a module a page
(keeps the mind sane)?
Message-ID:
<CABE0DMv1vgcQzp7oK0v9bQyyKQ0Gc=7Jc3LE1SaGnat7OFPgjA at mail.gmail.com>
Content-Type: text/plain;
charset="utf-8"
I have found a copy here:
http://norayr.am/papers/WirthTasksVersusThreads.pdf
On Tue, Nov 6, 2018 at 5:00 AM
Frans-Pieter Vonck <fp at vonck.nl>
wrote:
> Hi Chris,
>
> do you have by any chance a link
for the article "Tasks versus Threads
> [..]"
> I cannot find it on the net.
>
> From Wirth: "Embedded
Systems and Real-Time Programming"
>
> " The next decision was to
eliminate the RT-OS, as it seemed possible
> to do
essentially without concurrent
processes in the form of
> threads. The third
> decision was to program the entire
software in Oberon [2], which is very
> suitable for
> programming close to the
hardware."
> So he probably used Tasks vs
Threads concept for the helicopter.
>
> > "Tasks, called commands, are
a conceptual pillar of the Oberon
> > operating environment. Making
them interruptible adds significant
> > power to the concept
> In the oberon loop the commands
are already interrupted by input events:
> keyboard, mouse, network
communication. Does he mean, tat a task can
> interrupt another task?
> Explanation must be found in his
article.
>
> Greets,
> F.P.
>
>
>
> Chris Burrows schreef op
2018-11-06 11:48:
> > I recommend that you read
Wirth's 1996 paper titled "Tasks versus
> > Threads: An Alternative
Multiprocessing Paradigm". The relative merits
> > of tasks, processes,
coroutines and threads are discussed.
> >
> > "An alternative to threads is
presented as a paradigm for
> > single-processor
multi-tasking systems. It avoids complex and hidden
> > mechanisms for process
scheduling, and is therefore particularly
> > suitable for realtime systems
requiring fast response times, and for
> > small systems in general."
> >
> > "Tasks, called commands, are
a conceptual pillar of the Oberon
> > operating environment. Making
them interruptible adds significant
> > power to the concept and is
shown to require surprisingly few changes
> > and additions to the existing
system, hence retaining its basic
> > compactness and efficiency."
> >
> > An implementation of these
ideas (called System7) on Native Oberon can
> > be downloaded from the ETH
Oberon site:
> >
> > ftp://ftp.ethoberon.ethz.ch
> >
> > by following the path:
> >
> > ETHOberon/Contrib/System7/
> >
> > Now that interrupts are
working on Project Oberon 2013 it would be an
> > interesting exercise to try
out these concepts there as well,
> >
> > Regards,
> > Chris
> >
> > Chris Burrows
> > CFB Software
> > http://www.astrobe.com/RISC5
> >
> >> -----Original
Message-----
> >> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch]
On Behalf Of
> >> Frans-Pieter Vonck
> >> Sent: Tuesday, 6 November
2018 6:39 PM
> >> To: J?rg Straube
> >> Cc: ETH Oberon and
related systems; paulreed at paddedcell.com
> >> Subject: Re: [Oberon] a
module a page (keeps the mind sane)?
> >>
> >> Hi J rg,
> >>
> >> I saw the coroutine
module is not yet written for project oberon.
> >> But that does not keep me
from trying out the concept of cooperatieve
> >> multitasking.
> >> I will look into that,
> >>
> >> Thanks.
> >> F.P.
> >>
> >> J rg Straube schreef op
2018-11-05 23:22:
> >> > F.P.
> >> >
> >> > Installing tasks in
the Oberon loop is THE way to enable multi
> >> tasking
> >> > in Oberon.
> >> >
> >> > T :=
Oberon.NewTask(myHandler, 1000);
> >> > Oberon.Install(T);
> >> >
> >> > Every 1000 ms the
procedure myHandler will be called.
> >> >
> >> > Another way to have
cooperative multitasking is to implement module
> >> > Coroutines .
> >> >
> >> > br
> >> > J rg
> >> >
> >
> >
> > --
> > 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
>
-------------- next part
--------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20181106/b7fea40e/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 06 Nov 2018 17:45:42 +0100
From: Frans-Pieter Vonck <fp at vonck.nl>
To: Charles Perkins <chuck at kuracali.com>
Cc: oberon at lists.inf.ethz.ch
Subject: Re: [Oberon] a module a page
(keeps the mind sane)?
Message-ID: <a620d10d3cce1c78e8c433a6a539d631 at vonck.nl>
Content-Type: text/plain;
charset=UTF-8; format=flowed
Thanks,
F.P.
Charles Perkins schreef op 2018-11-06
16:05:
> I have found a copy here:
> http://norayr.am/papers/WirthTasksVersusThreads.pdf
>
> On Tue, Nov 6, 2018 at 5:00 AM
Frans-Pieter Vonck <fp at vonck.nl>
wrote:
>
>> Hi Chris,
>>
>> do you have by any chance a
link for the article "Tasks versus
>> Threads
>> [..]"
>> I cannot find it on the net.
>>
>> From Wirth: "Embedded Systems
and Real-Time Programming"
>>
>> " The next decision was to
eliminate the RT-OS, as it seemed
>> possible
>> to do
essentially without concurrent
processes in the form
>> of
>> threads. The
third
>> decision was to program the
entire software in Oberon [2], which is
>> very
>> suitable for
>> programming close to the
hardware."
>> So he probably used Tasks vs
Threads concept for the helicopter.
>>
>>> "Tasks, called commands,
are a conceptual pillar of the Oberon
>>> operating environment.
Making them interruptible adds significant
>>> power to the concept
>> In the oberon loop the
commands are already interrupted by input
>> events:
>> keyboard, mouse, network
communication. Does he mean, tat a task can
>>
>> interrupt another task?
>> Explanation must be found in
his article.
>>
>> Greets,
>> F.P.
>>
>> Chris Burrows schreef op
2018-11-06 11:48:
>>> I recommend that you read
Wirth's 1996 paper titled "Tasks versus
>>> Threads: An Alternative
Multiprocessing Paradigm". The relative
>> merits
>>> of tasks, processes,
coroutines and threads are discussed.
>>>
>>> "An alternative to threads
is presented as a paradigm for
>>> single-processor
multi-tasking systems. It avoids complex and
>> hidden
>>> mechanisms for process
scheduling, and is therefore particularly
>>> suitable for realtime
systems requiring fast response times, and
>> for
>>> small systems in
general."
>>>
>>> "Tasks, called commands,
are a conceptual pillar of the Oberon
>>> operating environment.
Making them interruptible adds significant
>>> power to the concept and
is shown to require surprisingly few
>> changes
>>> and additions to the
existing system, hence retaining its basic
>>> compactness and
efficiency."
>>>
>>> An implementation of these
ideas (called System7) on Native Oberon
>> can
>>> be downloaded from the ETH
Oberon site:
>>>
>>> ftp://ftp.ethoberon.ethz.ch
>>>
>>> by following the path:
>>>
>>>
ETHOberon/Contrib/System7/
>>>
>>> Now that interrupts are
working on Project Oberon 2013 it would be
>> an
>>> interesting exercise to
try out these concepts there as well,
>>>
>>> Regards,
>>> Chris
>>>
>>> Chris Burrows
>>> CFB Software
>>> http://www.astrobe.com/RISC5
>>>
>>>> -----Original
Message-----
>>>> From: Oberon
[mailto:oberon-bounces at lists.inf.ethz.ch]
On Behalf
>> Of
>>>> Frans-Pieter Vonck
>>>> Sent: Tuesday, 6
November 2018 6:39 PM
>>>> To: J?rg Straube
>>>> Cc: ETH Oberon and
related systems; paulreed at paddedcell.com
>>>> Subject: Re: [Oberon]
a module a page (keeps the mind sane)?
>>>>
>>>> Hi J rg,
>>>>
>>>> I saw the coroutine
module is not yet written for project oberon.
>>>> But that does not keep
me from trying out the concept of
>> cooperatieve
>>>> multitasking.
>>>> I will look into
that,
>>>>
>>>> Thanks.
>>>> F.P.
>>>>
>>>> J rg Straube schreef
op 2018-11-05 23:22:
>>>>> F.P.
>>>>>
>>>>> Installing tasks
in the Oberon loop is THE way to enable multi
>>>> tasking
>>>>> in Oberon.
>>>>>
>>>>> T :=
Oberon.NewTask(myHandler, 1000);
>>>>>
Oberon.Install(T);
>>>>>
>>>>> Every 1000 ms the
procedure myHandler will be called.
>>>>>
>>>>> Another way to
have cooperative multitasking is to implement
>> module
>>>>> Coroutines
.
>>>>>
>>>>> br
>>>>> J rg
>>>>>
>>>
>>>
>>> --
>>> 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
------------------------------
Subject: Digest Footer
--
Oberon at lists.inf.ethz.ch
mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
------------------------------
End of Oberon Digest, Vol 174, Issue 8
**************************************
More information about the Oberon
mailing list