Oberon language without Oberon System 
Author Message
 Oberon language without Oberon System

An on another topic: why would anyone want the Oberon language without
the Oberon system? IMHO (and that is my private opinion), the Oberon
language by itself is just "a better Modula", probably not worth the
effort of switching over from Modula-2. In order to profit from
extensibility, you need an extensible system. That is, dynamic loading,
and "upward" control flow which places the "main loop" in the operating
system. Where do you have that besides Oberon?

Michael Franz



Tue, 31 Oct 1995 17:25:08 GMT  
 Oberon language without Oberon System

Quote:
>An on another topic: why would anyone want the Oberon language without
>the Oberon system? IMHO (and that is my private opinion), the Oberon
>language by itself is just "a better Modula", probably not worth the
>effort of switching over from Modula-2. In order to profit from
>extensibility, you need an extensible system. That is, dynamic loading,
>and "upward" control flow which places the "main loop" in the operating
>system. Where do you have that besides Oberon?

Again on the Amiga. Here You have a stand alone compiler (there is still
NO system available) and the programs can do dynamical loading.

Sven
--
Internet:                               | Yellow Post:
                                        |     Sven Gohlke                    

                                        |     12169 Berlin



Wed, 01 Nov 1995 02:41:01 GMT  
 Oberon language without Oberon System

Quote:

>An on another topic: why would anyone want the Oberon language without
>the Oberon system? IMHO (and that is my private opinion), the Oberon
>language by itself is just "a better Modula", probably not worth the
>effort of switching over from Modula-2. In order to profit from
>extensibility, you need an extensible system. That is, dynamic loading,
>and "upward" control flow which places the "main loop" in the operating
>system. Where do you have that besides Oberon?

If all you want to do is play, i.e. learn, then you're right. Most industrial
sites, however, will have a large base of existing software that won't run
on Oberon. It's not feasible to re-write it all for the Oberon system.
If, as you say, Oberon the language is better than Modula, then it's only
natural to want to develop new software with the better language. There's
nothing in Oberon the language that requires unusual operating system support.

Another way to look at it is: what's so special about Oberon the language?
Many other languages could be used within the Oberon system instead of Oberon.

This group really should have been named comp.sys.oberon.
--

Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]



Wed, 01 Nov 1995 21:30:05 GMT  
 Oberon language without Oberon System

(Michael Franz) says:

Quote:

>An on another topic: why would anyone want the Oberon language without
>the Oberon system? IMHO (and that is my private opinion), the Oberon

Many people can't always choose their work environment as they like.
They have to use what is available - and often that means machines
that never will support the Oberon system (e.g. pure batch machines,
or IBM mainframes with 3270 terminals). Those people will hesitate
to learn and use a language if they know they have to rewrite all
their programs in another language for such machines.




Fri, 03 Nov 1995 16:17:24 GMT  
 Oberon language without Oberon System

Quote:

>Again on the Amiga. Here You have a stand alone compiler (there is still
>NO system available) and the programs can do dynamical loading.

Since programming Oberon on the Amiga since it is available, I havn't
recogniced the possibility of dynamic loading.

Or do you mean the shared libraries? They have nothing to do with Oberon.
Same the new BOOPSI system, which introduces OOP into the AmigaOs, but
is not very comfortable when used to OOP ala Oberon.

Quote:
>Sven

---
+++hartmut



| Manufactur     | Fido: 2:246/81.1  IRC: Essich   \X/ Oberon  ZOC |



Fri, 03 Nov 1995 19:25:06 GMT  
 Oberon language without Oberon System

Hello Hartmut,

Quote:
>>Again on the Amiga. Here You have a stand alone compiler (there is still
>>NO system available) and the programs can do dynamical loading.
>Since programming Oberon on the Amiga since it is available, I havn't
>recogniced the possibility of dynamic loading.
>Or do you mean the shared libraries? They have nothing to do with Oberon.
>Same the new BOOPSI system, which introduces OOP into the AmigaOs, but
>is not very comfortable when used to OOP ala Oberon.

No, it's new with the update on AmigaOberon V3. Here You can have a global
task which do the dynamical loading.

Sven
--
Internet:                               | Yellow Post:
                                        |     Sven Gohlke                    

                                        |     12169 Berlin



Fri, 03 Nov 1995 23:54:13 GMT  
 Oberon language without Oberon System


|>
|> Hello Hartmut,
|>
|> >>Again on the Amiga. Here You have a stand alone compiler (there is still
|> >>NO system available) and the programs can do dynamical loading.
|>
|> >Since programming Oberon on the Amiga since it is available, I havn't
|> >recogniced the possibility of dynamic loading.
|>
|> >Or do you mean the shared libraries? They have nothing to do with Oberon.
|> >Same the new BOOPSI system, which introduces OOP into the AmigaOs, but
|> >is not very comfortable when used to OOP ala Oberon.
|>
|> No, it's new with the update on AmigaOberon V3. Here You can have a global
|> task which do the dynamical loading.
|>

Bitte? Gibt es denn schon ein neues Update fuer V3.0? Seit wann?

Ciao
   Dieter



Sat, 04 Nov 1995 18:04:39 GMT  
 Oberon language without Oberon System

Quote:



>|>
>|> Hello Hartmut,
>|>
>|> >>Again on the Amiga. Here You have a stand alone compiler (there is still
>|> >>NO system available) and the programs can do dynamical loading.
>|>
>|> >Since programming Oberon on the Amiga since it is available, I havn't
>|> >recogniced the possibility of dynamic loading.
>|>
>|> >Or do you mean the shared libraries? They have nothing to do with Oberon.
>|> >Same the new BOOPSI system, which introduces OOP into the AmigaOs, but
>|> >is not very comfortable when used to OOP ala Oberon.
>|>
>|> No, it's new with the update on AmigaOberon V3. Here You can have a global
>|> task which do the dynamical loading.
>|>

>Bitte? Gibt es denn schon ein neues Update fuer V3.0? Seit wann?

>Ciao
>   Dieter

sumimasen ga doitsu go wakarimasen.

Taylor "Confused" Hutt



Sun, 05 Nov 1995 04:31:25 GMT  
 Oberon language without Oberon System

Quote:

>>Bitte? Gibt es denn schon ein neues Update fuer V3.0? Seit wann?

>sumimasen ga doitsu go wakarimasen.

He asked of the actual Version of AmigaOberon. It's AmigaOberon V3.0
and this version does most (not all) things You have with the System. The
garbage collector do the dynamical allocation as a background task for
every Oberon program. Look in Your handbook section 16.

Sven
--
Internet:                               | Yellow Mail:
                                        |     Sven Gohlke                    

                                        |     12169 Berlin



Mon, 06 Nov 1995 02:52:11 GMT  
 Oberon language without Oberon System

Quote:

>Hello Hartmut,

Hi Sven,

Quote:
>No, it's new with the update on AmigaOberon V3. Here You can have a global
>task which do the dynamical loading.

Huh? I surly got AO 3.0, but there is nothing like dynamic loading.
If you mean the garbace collector: he only manages memory allocation.

If you are sure, that dyn loading is possible, please post some example
or at least tll me the modules to support it. Else I just will not beliefe
it.

Quote:
>Sven

---
+++hartmut



| Manufactur     | Fido: 2:246/81.1  IRC: Essich   \X/ Oberon  ZOC |



Fri, 10 Nov 1995 18:41:48 GMT  
 Oberon language without Oberon System

Hello Hartmut,

Quote:
>>No, it's new with the update on AmigaOberon V3. Here You can have a global
>>task which do the dynamical loading.
>Huh? I surly got AO 3.0, but there is nothing like dynamic loading.
>If you mean the garbace collector: he only manages memory allocation.
>If you are sure, that dyn loading is possible, please post some example
>or at least tll me the modules to support it. Else I just will not beliefe
>it.

I'm sorry about it, no You are right. But i don't think that dynamical
loading is a great advantage of Oberon but the allocation and deallocation
of variables via a garbage collector --- that's great!!

The question was "Who needs Oberon without the system?". To my opinion
everyone who want to write safe and readable programs in a language which
is easy to learn and which is enlargeable without much efford. Most of the
things You are doing in Oberon You can do in other programing languages
(and if You've ever tried it in fortran You'll suddenly like C) and You
can do it readable in Modula2. The last lack of Modula2 are the{*filter*}
references (i hope that's the right word for it, i mean pointer to mem which
You have already deallocated). They are impossible with the garbage collector.

By the way: If i'm right You can tell the operating system of the Amiga only
to load parts of an executable in mem and to load other parts only when needed
but i don't know much about that system depended stuff. And the shared
libraries are the counterpart of the tools in the Oberon system: collections of
'commands' related to a special object and loaded into mem only when needed.

Sven
--
Internet:                               | Yellow Mail:
                                        |     Sven Gohlke                    

                                        |     12169 Berlin



Sat, 11 Nov 1995 02:43:06 GMT  
 Oberon language without Oberon System

Quote:
(Sven Gohlke) writes:
> I'm sorry about it, no You are right. But i don't think that dynamical
> loading is a great advantage of Oberon but the allocation and deallocation
> of variables via a garbage collector --- that's great!!

And slow.

Quote:
> [...] The last lack of Modula2 are the{*filter*}
> references (i hope that's the right word for it, i mean pointer to mem which
> You have already deallocated). They are impossible with the garbage
> collector.

The GC makes other things impossible as well -- including some useful ones...
--



Sun, 12 Nov 1995 02:14:36 GMT  
 Oberon language without Oberon System

Quote:
](Sven Gohlke) writes:

]
]] I'm sorry about it, no You are right. But i don't think that dynamical
]] loading is a great advantage of Oberon but the allocation and deallocation
]] of variables via a garbage collector --- that's great!!
]
]And slow.

Oh, come on! I'm getting so sick and tired of people claiming that GC
is necessarily slow. A few years ago, yes, it was. In Lisp systems
using non-incremental stop-and-copy collectors, yes, it's slow. But in
a good optimization of any of several dozen different incremental
collectors, GC is not slow.

]] [...] The last lack of Modula2 are the{*filter*}
]] references (i hope that's the right word for it, i mean pointer to mem which
]] You have already deallocated). They are impossible with the garbage
]] collector.
]
]The GC makes other things impossible as well -- including some useful ones...

Like what?

In manual memory management, you allocate variables using something
like new or malloc(), and release them using free().

In GC, you allocate variables using something like new or malloc(),
and if you want to explicitly free them, you assign them to nil,
killing the reference.

So, what can you do with manual allocation, that you can't do with GC?

        <MC>
--
|| Mark Craig Carroll: <MC>     ||"Don't try to tell me there's no reason
|| CIS Grad, Univ of Delaware   || for any moment in time, for every memory
|| PGP key available by finger  || of mine. Those years are lines of color on



Sun, 12 Nov 1995 03:50:35 GMT  
 Oberon language without Oberon System

Quote:
(Mark C. Carroll) writes:

Uh-oh, never reply on such a posting! ;-)

Quote:


>](Sven Gohlke) writes:
>]
>]] [...] but the allocation and deallocation of variables via a garbage
>]] collector --- that's great!!
>]
>] And slow.
> Oh, come on! I'm getting so sick and tired of people claiming that GC
> is necessarily slow. A few years ago, yes, it was. In Lisp systems
> using non-incremental stop-and-copy collectors, yes, it's slow. But in
> a good optimization of any of several dozen different incremental
> collectors, GC is not slow.

Ok, the garbage collectors themselves aren't slow, but to keep them
running you need to introduce bookkeeping code for every pointer
operation into your program, and this will slow it down.

Quote:
>]] [...] The last lack of Modula2 are the{*filter*}
>]] references (i hope that's the right word for it, i mean pointer to
>]] mem which You have already deallocated). They are impossible with
>]] the garbage collector.
>]
>] The GC makes other things impossible as well -- including some
>] useful ones...
> Like what?

When working with variable records (very useful when interpreting
typeless languages), the traditional method would be to allocate
enough memory for the biggest of the variants and then just change the
type (interpretation) of that allocation as it is needed.
In Oberon, you have to allocate/deallocate each single record when one
of its other variants is needed -- even if that variant would be of
the same size.

I ran some tests of this setting with Amiga-Oberon and noticed a
slowdown of factor 15..20 for the allocation/deallocation alone. When I
additionally activated the garbage collection, the factor grew to at
least 50 (at which point I became bored and cancelled the GC-runs).

Quote:
> [...]
> So, what can you do with manual allocation, that you can't do with
> GC?

I can't do more when doing it by hand, but I can do it more efficient.

I am not of the opinion that GC is a bad thing in general; but in
combination with the insufficiencies of the Oberon pointer types (and
the fact that you can't escape the GC) I consider it quite harmful.
And that's a pity.

  Lars
--



Mon, 13 Nov 1995 22:25:09 GMT  
 Oberon language without Oberon System

Quote:

> Ok, the garbage collectors themselves aren't slow, but to keep them
> running you need to introduce bookkeeping code for every pointer
> operation into your program, and this will slow it down.

Not true, again! You need bookkeeping if you use AmigaOberon's Garbage
Collector which is a variant of Dijkstra's concurrent garbage
collector. Pointer assignments become *very* costly (8-12 instructions
compared to 1-2). If you're using a more traditional approach (i.e.
mark & sweep) like in the Oberon System, you pay very little for the
great advantage of having GC. Normally, you don't notice the presence
of a GC in the Oberon System. This is due to the fact that Oberon
doesn't allocate that many objects (<< 1000) during normal operation
and that GC is quick.
And please, don't start discussing real-time constraints etc. Those
were not an issue during the design of the Oberon System.

Quote:
> I ran some tests of this setting with Amiga-Oberon and noticed a
> slowdown of factor 15..20 for the allocation/deallocation alone. When I
> additionally activated the garbage collection, the factor grew to at
> least 50 (at which point I became bored and cancelled the GC-runs).

That's not surprising! The memory-system of Amiga Oberon is
pretty bad. It doesn't have to be! If its designer would have chosen a
more traditional approach, he would have saved himself lots of
development time and could have provided us with a faster memory
system. Don't get me wrong: I think that Amiga Oberon is great, we're
using it to port the System to the Amiga; it's just the memory stuff
that needs some remodeling... ;-)

Quote:
> I am not of the opinion that GC is a bad thing in general; but in
> combination with the insufficiencies of the Oberon pointer types (and
> the fact that you can't escape the GC) I consider it quite harmful.

Please don't mingle the concept with its implementation. Use an Oberon
System on any machine and you won't notice the presence of the GC.
Once, you've started to live with not having to think about
deallocation, you "won't leave home without GC!"
BTW: Oberon pointer types aren't very different from M2 or C pointer
types, except that they are safe!


  Institute for Computer Systems
  Swiss Federal Institute of Technology (ETH)
  CH-8092 Zurich, Switzerland



Tue, 14 Nov 1995 00:25:16 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Oberon System 3 / Native Oberon projects

2. inquiry about Visual Oberon/PC Native Oberon System 3

3. Oberon-2 in Native Oberon System 3

4. M2, Oberon, and embedded systems (was Re: m2 / Oberon appendix to 3117)

5. M2, Oberon, and embedded systems (was m2 / Oberon appendix to 3117)

6. Oberon system on native file system

7. Frage Oberon 3 / Question Oberon 3

8. CD-Oberon - Oberon/F

9. CD-Oberon Oberon 3 Printer Problem

10. Native Oberon: Getting DOS based installation out of Oberon-0

11. modula2-to-Oberon, C++-to-Oberon

12. oberon kernel sources (Article 4814 in comp.lang.oberon)

 

 
Powered by phpBB® Forum Software