Everyday Oberon + real-time apps. 
Author Message
 Everyday Oberon + real-time apps.

Oberon-2 is such a nice language that I would dearly like
to be able to program in it in a standard environment,
such as DOS or Unix, ie. not within the Oberon-OS - nothing
against Oberon-OS, but it's hard to use it for doing
everyday work with, such as manipulating standard DOS/Unix
files as opposed to Oberon files. And because of this, it's
difficult to convince others that they should try it too.

Further, because I would also like to use Oberon-2 for
real-time embedded programming, is there any talk of
introducing embedded programming features to Oberon,
such as interrupt handling, I/O port handling, register
handling and absolute addressing for reading and writing
to hardware chips? I also see another problem with the
garbage collector because in real-time applications one
can't afford to let the GC loose and block other processes.
Feedback on this subject would be most appreciated.

I've also been thinking of trying to construct my own,
be it a reduced, version of Oberon-2 compiler. However,
I am stuck on several points, eg., I don't have a
floating-point arithmetic library, I don't know how to
link object files to make an executable file in an MS-DOS
environment, and thirdly, I don't know how the garbage
collector works (for real-time apps, I would turn it off
and use standard 'alloc' and 'free' - unless anyone else
has a better idea). I mean, in "Project Oberon" it talks
about "traversing the tree" to perform Garbage collection
- my question is, how does one construct the tree in the
first place? Any help in any of these areas will, again,
be most appreciated.

As I said, it's such a nice language that I'm itching to
make it my everyday programming language - and I'm pretty
sure there are lots of people out there just like me.

Ray Cheung.



Wed, 23 Apr 1997 19:05:46 GMT  
 Everyday Oberon + real-time apps.

Quote:

>Oberon-2 is such a nice language that I would dearly like
>to be able to program in it in a standard environment,
>such as DOS or Unix, ie. not within the Oberon-OS - nothing
>against Oberon-OS, but it's hard to use it for doing
>everyday work with, such as manipulating standard DOS/Unix
>files as opposed to Oberon files. And because of this, it's
>difficult to convince others that they should try it too.

You need to talk to Guenter Dotzel of ModulaWare.  He has a standalone
compiler for DOS, one for the DEC Alpha and some for that obsolete
behemoth known as VMS.  RTA in the UK also has a standalone compiler, but
they seemed to have completely disappeared from this newsgroup.

Quote:

>Further, because I would also like to use Oberon-2 for
>real-time embedded programming, is there any talk of
>introducing embedded programming features to Oberon,
>such as interrupt handling, I/O port handling, register
>handling and absolute addressing for reading and writing
>to hardware chips?

Not really, but all the DOS versions of Oberon do provide access to the
things you desire; it's just that they are (fairly) undocumented on all
but my system.  Of course, it would be hard to ROMify Oberon code that
needs the Oberon OS...

Quote:

>I've also been thinking of trying to construct my own,
>be it a reduced, version of Oberon-2 compiler. However,
>I am stuck on several points, eg., I don't have a
>floating-point arithmetic library, I don't know how to
>link object files to make an executable file in an MS-DOS
>environment, and thirdly, I don't know how the garbage
>collector works (for real-time apps, I would turn it off
>and use standard 'alloc' and 'free' - unless anyone else
>has a better idea). I mean, in "Project Oberon" it talks
>about "traversing the tree" to perform Garbage collection
>- my question is, how does one construct the tree in the
>first place? Any help in any of these areas will, again,
>be most appreciated.

Regarding the floating point library.  Make a design decision: require a
floating point coprocessor if they want to do floating point math.  
That's ends that problem.  To learn how the GC works, you need to get
Yellow Book 156 (which is at: ftp.inf.ethz.ch:/docs/tech-reports in
postscript form).  This has a great explanation of the GC and heap allocator.

As someone who has done what you want to do, I just want to say that I
hope you have a lot of free time!  It's a small system, but all the
information you need to reproduce it is not in one central repository.  
Even when you get all the information you can, you will have to do some
synthesis and fill in the blanks.  It'll be a lot easier to use one of
the systems that already exist.  ETH's versions are quite good for MS-DOS
and Windows.  I have a version that comes with most of the source code
(no, I didn't release the GC in source form yet).  If you want more
information about either of these, email me.

Taylor Hutt, 44 heart rate, 100/60 bp
Save a life: donate {*filter*} (and you get free food afterwords, too!).



Thu, 24 Apr 1997 09:53:57 GMT  
 Everyday Oberon + real-time apps.

Quote:
> Oberon-2 is such a nice language that I would dearly like
> to be able to program in it in a standard environment,
> such as DOS or Unix, ie. not within the Oberon-OS - nothing
> against Oberon-OS, but it's hard to use it for doing
> everyday work with, such as manipulating standard DOS/Unix
> files as opposed to Oberon files. And because of this, it's
> difficult to convince others that they should try it too.
> As I said, it's such a nice language that I'm itching to
> make it my everyday programming language - and I'm pretty
> sure there are lots of people out there just like me.

Yes!

I have your same point of view.

In fact I think that the Oberon Language is a language worth using and
developping for, but using the Oberon Sys is a real pain: you can't ask a user
to use it for creating some project, too difficult and unfriendly.

In fact there are Oberon Sys independant versions of Oberon under Amiga and
other platforms, some of wich are also public domain.
I use them and I think they are great for developping smth modular and Obj
Oriented.

Bye!



Sat, 26 Apr 1997 19:37:00 GMT  
 Everyday Oberon + real-time apps.

Quote:
> Oberon-2 is such a nice language that I would dearly like
> to be able to program in it in a standard environment,
> such as DOS or Unix, ie. not within the Oberon-OS - nothing
> against Oberon-OS, but it's hard to use it for doing
> everyday work with, such as manipulating standard DOS/Unix
> files as opposed to Oberon files. And because of this, it's
> difficult to convince others that they should try it too.

> Further, because I would also like to use Oberon-2 for
> real-time embedded programming, is there any talk of
> introducing embedded programming features to Oberon,
> such as interrupt handling, I/O port handling, register
> handling and absolute addressing for reading and writing
> to hardware chips? I also see another problem with the
> garbage collector because in real-time applications one
> can't afford to let the GC loose and block other processes.
> Feedback on this subject would be most appreciated.

I, too, am in the same position: I like Oberon and want to program
using it in my everyday environment.  It is also a real pain to have to
distribute a couple of megs of environment files in order to sell an
application to an end user (I know Windows already forces one to do
this ;-) ).  Fortunately, I am programming on an Amiga and have
available Amiga Oberon -- an excellent Oberon-2 implementation which
deals with many of the issues you raise regarding garbage collection
disabling, interrupt handling (uses the resident OS's interrupt
mechanism), and has extensions? for accessing hardware directly (not
recommended on the Amiga).

I understand that there is a Windows-based Oberon-2 compiler called "Pow!"
which doesn't depend on the Oberon System.  It works within the Windows
environment and produces Windows applications.  An evaluation copy is
available at ftp.fim.uni-linz.ac.at/pub/soft/pow-oberon2.

Quote:
> I've also been thinking of trying to construct my own,
> be it a reduced, version of Oberon-2 compiler. However,
> I am stuck on several points, eg., I don't have a
> floating-point arithmetic library, I don't know how to
> link object files to make an executable file in an MS-DOS
> environment, and thirdly, I don't know how the garbage
> collector works (for real-time apps, I would turn it off
> and use standard 'alloc' and 'free' - unless anyone else
> has a better idea).

I can help on the first item on your list, I've implemented a floating-point
arithmetic library here at work using Ada.  Copyright restrictions prevent
me from giving you the source but I can rehash the algorithms in Oberon-2,
on my own time -- when I have time.  On the second item, I would recommend
producing object files which a standard MSDOS linker can handle.  For the
garbage collector, you'll find a lot of information at ftp.inf.ethz.ch in
pub/Oberon/Docs about Oberon-2, etc.  BTW, in most real-time environments,
garbage collection is really not necessary.  Data structures are typically
static and allocated only once during power-on.  They then remain until
power is shut off.  Thus, you would use Oberon-2's NEW procedure to allocate
the data and then never deallocate it.  As a matter of fact, in a safe
real-time system, you should know exactly how much memory you will need
and where it is going to be used so you could declare all variables
statically.

I too have been attempting an Oberon-2 compiler project but have had to put it
aside (i.e., there's no money in Oberon-2 compilers) so I can earn some money
with my business.  If you are interested in collaborating, send me email.


Computer Inspirations



Sat, 26 Apr 1997 19:51:31 GMT  
 Everyday Oberon + real-time apps.

Quote:

>You need to talk to Guenter Dotzel of ModulaWare.  He has a standalone
>compiler for DOS, one for the DEC Alpha and some for that obsolete
>behemoth known as VMS.  RTA in the UK also has a standalone compiler, but
>they seemed to have completely disappeared from this newsgroup.

RTA is alive, kicking, well, here, and supplying Oberon-2 to the
world and its mother. There was a hiatus after Ian Marshall left
RTA, but I monitor the newsgroup. I just don't post unless I have
something to say. For example, I didn't say anything about the
lengthy discussion of re-introducing enumerated types into Oberon-2
because it was totally ruled out at Oakwood, so it is very very
unlikely to happen in commercial compilers.

--
-- Jim Hawkins



Sat, 26 Apr 1997 23:35:55 GMT  
 Everyday Oberon + real-time apps.

Quote:

>> Oberon-2 is such a nice language that I would dearly like
>> to be able to program in it in a standard environment,
>> such as DOS or Unix, ie. not within the Oberon-OS - nothing
>> against Oberon-OS, but it's hard to use it for doing
>> everyday work with, such as manipulating standard DOS/Unix
>> files as opposed to Oberon files. And because of this, it's
>> difficult to convince others that they should try it too.

>> As I said, it's such a nice language that I'm itching to
>> make it my everyday programming language - and I'm pretty
>> sure there are lots of people out there just like me.

>Yes!

>I have your same point of view.

... snip ...
  This issue is one of communication between Oberon and non Oberon
environments.  It occurs to me that "messaging" is a possible solution
for those environments (Windows, Solaris/X, etc.) that support messages.
I have not yet, but am in the process of writing a Link module in Oberon
and its dual in C++ that talk to each other in Windows via Windows messages.
Integers, characters, reals, etc. can be sent via a message (lParam) which
can be understood on both sides.  Once this primative is established than
a function call under C, f(a,b,c), becomes serialized and reconstructed
within Oberon as a function.  One might think this is slow but then don't
forget that every keystroke in windows is sent as a message and also that
the tight loops and dense code occur within a module and not at the
module boundary.
  If this works in Windows I will implement it in X for Solaris(SUN).
Anyone else try anything like this?
-Doug Danforth

--
UME Voice, The speech recognition standard for Wall Street.



Tue, 29 Apr 1997 04:58:07 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Time to REAL & REAL to time

2. re Oberon / Real time control :-(

3. Oberon / real time control :-(

4. Oberon for Real-Time Course?

5. IMAQ for real time app?

6. ANNOUNCE: GroupKit 3.2 (real-time groupware toolkit + apps)

7. TCL for real-time control app?

8. Lisp in real-time apps?

9. real time dispaly of time.

10. Help!: problem with fast timing for real-time application on PC

11. Help!: problem with fast timing for real-time application on PC

12. DOS compressed date/time into real date/time

 

 
Powered by phpBB® Forum Software