Oberon/F tutorials 
Author Message
 Oberon/F tutorials

I'm looking for some pointers to a good refrence book on Oberon/F and for a
good book that explains Component Oriented Programming. I'm new to the COP
and OOP world. I've always been a hack it out iteratively programmer, but
the projects I have to work on now just don't lend themselves to that
methodology. I very fluent in Modula-2 and C. Online tutorials would be
appreciated as well.

On a semi-related note anybody out ther using Oberon/F to develop motion
control software?

--
Steve Drees

http://www.*-*-*.com/ ~drees/rockradio   <-- bringing Christian Modern Rock to
the Bay Area



Wed, 24 Nov 1999 03:00:00 GMT  
 Oberon/F tutorials

Quote:

> I'm looking for some pointers to a good refrence book on Oberon/F and for a
> good book that explains Component Oriented Programming. I'm new to the COP
> and OOP world. I've always been a hack it out iteratively programmer, but
> the projects I have to work on now just don't lend themselves to that
> methodology. I very fluent in Modula-2 and C. Online tutorials would be
> appreciated as well.

Here are some useful links:
Oberon microsystems: http://www.oberon.ch/
Several documents regarding COP: http://www.oberon.ch/docu/index.html
Component Pascal: http://www.oberon.ch/docu/language_report.html
Oberon Tribune: http://www.oberon.ch/services/odf/tribune/index.html
Oberon books recommondations and various links to Oberon on-line
resources: http://www.ee.ethz.ch/~psevinc/

Cheers,
Paul



Fri, 26 Nov 1999 03:00:00 GMT  
 Oberon/F tutorials


Quote:

> On a semi-related note anybody out ther using Oberon/F to develop motion
> control software?

considering oberon's lack of preemptive multitasking i doubt that many
programers feel attracted to oberon as a general platform to develop for.

bye bye



Wed, 08 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

Quote:



> > On a semi-related note anybody out ther using Oberon/F to develop motion
> > control software?

> considering oberon's lack of preemptive multitasking i doubt that many
> programers feel attracted to oberon as a general platform to develop for.

> bye bye

Well Clemens considering:

1) premptive multitasking is a system, not a language decision.
   (Oberon System 3 for Windows 95/NT supports preemptive threads)

2) many real time programmers prefer coopertative multitasking because
   it requires less overhead

and

3) there DOES exist an Oberon/F real-time platform that has been used
   to develop robot motion control software

        http://www.oberon.ch/denia/index.html

I'd say your assertion bears re-thinking.



Thu, 09 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials


Quote:

>> considering oberon's lack of preemptive multitasking i doubt that many
>> programers feel attracted to oberon as a general platform to develop for.
> 1) premptive multitasking is a system, not a language decision.
>    (Oberon System 3 for Windows 95/NT supports preemptive threads)

i meant the oberon operating system (environment) but did not say so,
my fault.

using win32 threads using the oberon operating environment on windows
is possible you say, but is it a "good" and simple way of doing things?

at least generally i doubt it because you lose the platform indepedance
of your programs and you have to integrate two different systems, which
may be elegantly done, but still there is the overhead of learning both
systems for the programmer plus the win32 interfaces and programming
may open the program for other possible points of failure which can't be
handled by oberon properly.

but the last is just a thought and not based on any facts of course, but
still this is a point which would have to be taken care for before even
starting to with this idea of incorporating both systems in mind i think.

Quote:
> 2) many real time programmers prefer coopertative multitasking because
>    it requires less overhead

i agree that this is certainly one notion often found, but on the other hand
this usually implies that no third party programs interfere, which may
disturb the cooperative multitasking easily and are likely to remove
a systems determined behaviour as well, at least if the source code is not
available, as it is a black box which could misbehave at any time without
any chance for the using programmer to check this beforehand in the
source code himself.

in a determined system i wouldn't mind using cooperative multitasking as
well myself, especially because of the simplicity compared to most current
preemptive multitasking implementations, but for the above reason (and
windows 3.1x is a good example of how things can go the wrong way
in terms of cooperative multitasking) i wouldn't make it my prefered choice.

Quote:
> 3) there DOES exist an Oberon/F real-time platform that has been used
>    to develop robot motion control software

i never doubted there is one nor did i imply such i think. (-:

especially for determined systems like robot motion control, where
usually only a set of verified and well-behaving modules run, cooperative
multitasking is not generally a problem of course, but i was rather thinking
of more general programs for every day usage, which means "many"
programs running on a machine with as small a possibility to disturb each
other as possible; should have said that as well, my fault again.

bye bye



Sun, 12 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

Quote:



> >> considering oberon's lack of preemptive multitasking i doubt that many
> >> programers feel attracted to oberon as a general platform to develop for.

> > 1) premptive multitasking is a system, not a language decision.
> >    (Oberon System 3 for Windows 95/NT supports preemptive threads)

> i meant the oberon operating system (environment) but did not say so,
> my fault.

> using win32 threads using the oberon operating environment on windows
> is possible you say, but is it a "good" and simple way of doing things?

> at least generally i doubt it because you lose the platform indepedance
> of your programs and you have to integrate two different systems, which
> may be elegantly done, but still there is the overhead of learning both
> systems for the programmer plus the win32 interfaces and programming
> may open the program for other possible points of failure which can't be
> handled by oberon properly.

> but the last is just a thought and not based on any facts of course, but
> still this is a point which would have to be taken care for before even
> starting to with this idea of incorporating both systems in mind i think.

> > 2) many real time programmers prefer coopertative multitasking because
> >    it requires less overhead

> i agree that this is certainly one notion often found, but on the other hand
> this usually implies that no third party programs interfere, which may
> disturb the cooperative multitasking easily and are likely to remove
> a systems determined behaviour as well, at least if the source code is not
> available, as it is a black box which could misbehave at any time without
> any chance for the using programmer to check this beforehand in the
> source code himself.

> in a determined system i wouldn't mind using cooperative multitasking as
> well myself, especially because of the simplicity compared to most current
> preemptive multitasking implementations, but for the above reason (and
> windows 3.1x is a good example of how things can go the wrong way
> in terms of cooperative multitasking) i wouldn't make it my prefered choice.

> > 3) there DOES exist an Oberon/F real-time platform that has been used
> >    to develop robot motion control software

> i never doubted there is one nor did i imply such i think. (-:

> especially for determined systems like robot motion control, where
> usually only a set of verified and well-behaving modules run, cooperative
> multitasking is not generally a problem of course, but i was rather thinking
> of more general programs for every day usage, which means "many"
> programs running on a machine with as small a possibility to disturb each
> other as possible; should have said that as well, my fault again.

> bye bye

No need to appologize.  You brought up some very good and important
points.  Oberon has gone through many changes in the past few years,
but the most prevalant Oberon systems (Oberon/F, System 3 and V4)
has stuck to the "single-process multi-tasking" model.  This could
become an Achilles heel in the future.

For those who are new to Oberon or who haven't yet delved "under the
hood", single process multi-tasking works like this, a task is a
procedure that is put on a task loop to be run over and over again.
It can't be interrupted (normally).  This is in contrast to pre-emptive
multitasking where a task can be suspended by the clock interrupt,
or even normal cooperative multitasking where the task can choose
to give up control in the middle.  Consider a task to check a heat
sensor.

Premptive:

PROCEDURE Sensor;
        LOOP
                ThermoDevices.Read(Sensor);
                IF Sensor > CriticalTemp THEN
                        SoundAlarm();
                END;
        END;
END Sensor;

Cooperative:

PROCEDURE Sensor;
        LOOP
                ThermoDevices.Read(Sensor);
                IF Sensor > CriticalTemp THEN
                        SoundAlarm();
                END
                Threads.Yield();        (* Suspend Task *)
        END;
END Sensor;

Single Process Multitasking

PROCEDURE Sensor;
        ThermoDevices.Read(Sensor);
        IF Sensor > CriticalTemp THEN
                SoundAlarm();
        END;            
END Sensor;

With the last one the loop is not needed.  It will be called over and
over
again by the task loop.  It will always be entered at the top and always
exit at the bottom.  The problem with SPM is when you try to multitask a
more complicated procedure that may have recursion or nested loops.

I had to deal with this in an effort to get around the modeless dialog
issue.  Modeless dialogs give the user the "multi-tasking" feel and
for very simple problems they can be used without multitasking.  However
if you are in the middle of a complex procedure and you need user input
they are a royal pain.  The only way I know around that is to make your
procedure a task.

What I ended up doing was drawing a state diagram for all the branches
in my proceedure.  Then I took out all of the loops and replaced them
with one loop (the task loop) and a giant CASE statement.  After
fiddling
with it for a while it worked.  (I'll eventually get around to posting
my results).

Prof. Wirth did prove that you could do some interesting things with
SPM (he did a networked printer handler and mail handler using only
Oberon and SPM), but maybe a more flexible model would be better.
For one thing most platforms that Oberon runs on currently support
premptive multitasking.  (Win95/NT, UNIX, Amiga, and I'm not sure
about Mac, but if they can run Java Threads there should be a way
to do it in Oberon).  Currently only the Win95/NT version of Oberon
System 3 uses that capability, but why can't that be expanded to
other platforms in uniform way?  Also there are other, possibly
better, co-operative models to consider.  The DOS Oberon compiler
from Edipar implements what I call co-operative threads for lack
of a better term.  There Threads module has the following commands:

        Threads.Fork()          (* Fork new thread *)
        Threads.Yield()         (* Reliquish control to the task loop *)
        Threads.Sleep()         (* Suspend task indefinitely *)
        Threads.Awake()         (* Awaken a suspened task *)
        Threads.Suspend()       (* Kill a task *)

Although not as statisfactory to some as pre-emptive multitasking,
this model at least lets you multi-task complex procedures without
all the head-aches I had to go through.  Basically any procedure
can be multitasked this way as long as a Threads.Yield() is put in
every loop.

Also a while back someone posted a Coroutines modules.  This is
similar to Co-routines in Modula-2.  I've been experimenting with
this to see if I can integrate it into the SPM model, but with
various degress of sucess.  (It works, but my machine kicks me
out of Oberon when I try to run the program multiple times.)

And of course Action Oberon is supposed to introduce a new
Oberon multitasking model.  I'm suspicous of it though.  Apparantly
each module under Action Oberon can have a task loop, but beneath
it all you still have the same SPM, can't stop the procedure in the
middle model.



Tue, 14 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

Dear All,

Just one short comment to this thread. There is a real-time
development environment based around Oberon available,
have a look at:
  http://www.ifr.mavt.ethz.ch/projects/XOberon/cognacxo.html.
Should anybody have any questions please do not hesitate
to contact me.

Kind regards

Sjur J. Vestli
--

-------------------------------------------------------------------------
        Sjur J. Vestli

        Institute of Robotics, CLA H17.1
        Swiss Federal Institute of Technology
        8092 Zurich, Switzerland

        Tel: 01 632 67 95     Fax: 01 632 10 78

-------------------------------------------------------------------------



Wed, 15 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials


Quote:

>Although not as statisfactory to some as pre-emptive multitasking,
>this model at least lets you multi-task complex procedures without
>all the head-aches I had to go through.  Basically any procedure
>can be multitasked this way as long as a Threads.Yield() is put in
>every loop.

I once thought that it would be nice for the compiler to put a Threads.Yield
into every loop, and perhaps also into selected procedure entries.  Has such a
solution been studied?

--
A prudent parent neither ignores nor disturbs suprisingly quiet children.
1-512-374-0144 (d) \0145 (v) / isdn:Guest / BitSurfr
Try to connect, report what happens...



Wed, 15 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

Quote:

> [Edited for space...]
>For one thing most platforms that Oberon runs on currently support
>premptive multitasking.  (Win95/NT, UNIX, Amiga, and I'm not sure
>about Mac, but if they can run Java Threads there should be a way
>to do it in Oberon).  Currently only the Win95/NT version of Oberon
>System 3 uses that capability, but why can't that be expanded to
>other platforms in uniform way?  
> [More editing...]

For the record, not all Java Virtual Machines for Unix have preemptive
multitasking. In fact the canonical implementation (Sun's JVM for Solaris)
uses cooperative multitasking. In my limited understanding of the
specification, this appears to be allowed.

Mark

--

University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--



Fri, 17 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

Quote:


> >Although not as statisfactory to some as pre-emptive multitasking,
> >this model at least lets you multi-task complex procedures without
> >all the head-aches I had to go through.  Basically any procedure
> >can be multitasked this way as long as a Threads.Yield() is put in
> >every loop.

> I once thought that it would be nice for the compiler to put a Threads.Yield
> into every loop, and perhaps also into selected procedure entries.  Has such a
> solution been studied?

I've thought about that some myself.  Having the compiler add the
Threads.Yield code would blur the distinction between pre-emptive
vs co-operative multitasking from the programmers point of view.
One question, would it be better to have the compiler add it to
loops in EVERY procedure or just procedures that were identified
as thread procedures?  Under the first option you would need
someway to turn multitasking off (for performance issues as well
as MUTEX issues).  Under the second there would probably need to
be some change in the Oberon Syntax (i.e. how do you tell the
compiler you have a thread vs a normal procedure?)  Considering
the number of recently proposed changes that is probably no big
deal.  

I have seen some languages that seem to provide "transparent"
co-operative multitasking.  One is OOT (Object Oriented Turing)
which is used quite a bit in Candian CS curriculums.

        http://www.turing.toronto.edu/oot/oot.html

I've messed around with it a bit and multitasking is pretty
easy to do under it.  (Unfortunately they don't currently
have a demo version up, although I occasionally set the clock
back on my PC so I can use the version I downloaded a year
ago).

I would like to see some Win 95/NT Oberon thread examples if
anybody done anything with them.  It would be good to have
a co-operative multitasking model for Oberon that fit it.



Fri, 17 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

.> For the record, not all Java Virtual Machines for Unix have
preemptive
.> multitasking. In fact the canonical implementation (Sun's JVM for
Solaris)
.> uses cooperative multitasking. In my limited understanding of the
.> specification, this appears to be allowed.
.>
.> Mark

Interesting.  Do you know how this is accomplished?  My best guess is
that Yield() instructions are embedded in loops of each thread
procedure.
Is that close?



Fri, 17 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials

Quote:


>.> For the record, not all Java Virtual Machines for Unix have
>.> preemptive multitasking. In fact the canonical implementation
>.> (Sun's JVM for Solaris) uses cooperative multitasking. In my
>.> limited understanding of the specification, this appears to be
>.> allowed.

>Interesting.  Do you know how this is accomplished?  My best guess is
>that Yield() instructions are embedded in loops of each thread
>procedure.
>Is that close?

I expected the Solaris JVM to have preemptive threads. However, I noticed
that each thread ran to completion in succession. That lead me to insert
yield() in the appropriate places to get the behavior I wanted (i.e., to get
multitasking).

Thus to answer your question: you must insert yield() manually; they are not
inserted automatically. (This information is subject to change with each new
release, of course.)

Mark

--

University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--



Sat, 18 Dec 1999 03:00:00 GMT  
 Oberon/F tutorials


Quote:

> I would like to see some Win 95/NT Oberon thread examples if
> anybody done anything with them.  It would be good to have
> a co-operative multitasking model for Oberon that fit it.

There was a concurrent Oberon System project at ETH a few years ago.
The paper is on their server. If I am not mistaken, it later evolved
into Hermes project. A couple of papers related to Hermes appeared
recently, see Guy's references. The name to look for is B.Sanders.

I wonder if Hermes is of any wider interest to the Oberon community.
Could somebody comment? Is Hermes available in source? If yes,
can it become a part of mainstream (=Linz) releases?

Wojtek

--

Nuclear Structure Research Lab, Univ. of Rochester
271 East River Rd, Rochester, NY 14627.
phone (716) 275 2524  fax (716) 473 5384
World Wide Web: http://nuchem.nsrl.rochester.edu/~skulski



Sat, 18 Dec 1999 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Search a good german Oberon Tutorial/Book

2. dr dobbs looking for a tutorial on oberon...

3. Repeat Announcement: Oberon Tutorial at ECOOP'95

4. Oberon System 3 tutorials on the WWW

5. Smalltalk Books/Tutorial - Tutorial for GNU

6. awk Tutorial: Fees Reduced and Tutorial Descriptions for

7. Java Tutorial: Fees Reduced and Tutorial Descriptions for

8. Guile Tutorial: Fees Reduced and Tutorial Descriptions for

9. awk Tutorial: Fees Reduced and Tutorial Descriptions for

10. Guile Tutorial: Fees Reduced and Tutorial Descriptions for

11. Guile Tutorial: Fees Reduced and Tutorial Descriptions for

12. Frage Oberon 3 / Question Oberon 3

 

 
Powered by phpBB® Forum Software