Displaying rasters in Oberon 
Author Message
 Displaying rasters in Oberon

Hi, all...

I've been working on this neural net imaging stuff off and on for
a while, and still have one problem. I have a 2-dimensional array
of bytes (well, characters, really) that holds an image I want to
put on the screen. Asking Oberon to draw it dot-by-dot is of
course very slow. So my question is, where can I find documentation
on the various parts of a pattern structure, or something else
I can put on the screen in a hurry? Anyone have any ideas as to how
to transfer this stuff to the screen *fast*?

On another topic, has anyone else noticed the DOS Oberon compiler
is pretty fragile about how complicated an expression it will handle?
I took a lot of SPARC-Oberon code to the DOS version and got *tons* of
'expression too complicated, out of registers', etc... errors when
using things like arrays of records holding records with arrays in them.
(Well, isn't useful data structuring what Oberon is supposed to be
good at?) Anyway, I had to do some major hacks with temp variables to
get these expressions to work. Any experiences?

Of course, getting *exactly* the same code to work at all on a SPARC
and a PC is just amazing, so I'm pretty happy alll around. Still, it
would be nice to be able to parse a big expression.

Well, best wishes...

-greg
---
Greg DeLozier/Senior Scientific Analyst, Loral/PhD Student, Kent State



Tue, 27 Feb 1996 03:27:09 GMT  
 Displaying rasters in Oberon
Having just posted some "good news" based with my experience with
Oberon-2 on a PC, I must echo DeLozier's experience and dissapointment
with the same system.   From what I can tell, Oberon-2 on a PC cannot
handle expressions with more than a couple of array adds after
a couple of array multiplies, so you have to break up expressions
into lots of multiple assignments in a way that is unneeded in
O2 on a SPARC.  I wince at the fact that I do not have identical
code for some of the same things in my SPARC and PC systems, but I have
assumed (hoped?) it was due to my still being in the middle of a
learning curve.

I also am about to face the question of efficient plotting and
image display with a very large number of data/display elements,
and the graphical editors emphasized by ETHZ are NOT what one needs
for a data-driven system.  I hope this thread leads to lots of good
advice.  Whitney?

---

============================================================================

National Radio Astronomy Observatory  |                             | \/ o\
P.O. Box O                            | Telephone: 505-835-7273     | /\__/
(1003 Lopezville Road - UPS etc. only)|                             |
Socorro, NM  87801-0387  USA          | FAX:       505-835-7027     | AMDG
============================================================================



Tue, 27 Feb 1996 22:10:52 GMT  
 Displaying rasters in Oberon

Quote:

>Having just posted some "good news" based with my experience with
>Oberon-2 on a PC, I must echo DeLozier's experience and dissapointment
>with the same system.   From what I can tell, Oberon-2 on a PC cannot
>handle expressions with more than a couple of array adds after
>a couple of array multiplies, so you have to break up expressions
>into lots of multiple assignments in a way that is unneeded in
>O2 on a SPARC.  I wince at the fact that I do not have identical
>code for some of the same things in my SPARC and PC systems, but I have
>assumed (hoped?) it was due to my still being in the middle of a
>learning curve.

The problem with the DOS version is not with the compiler, but with the
(editorial: braindead) Intel chipset.  The 386 has very few general
purpose registers, and of those, several instructions require specific
registers to be used.  The original compiler was written with a chip that
had 8 general purpose and 8 floating point registers, and that is usually
sufficient (from what I understand).  The 386 has only 4 (truly) general
purpose registers, and 2 index registers.  It does not have any real
floating point registers; instead it implements a floating point stack --
which is not accessible via registers -- and does not support 8 bit values.

Anyway, the method in which registers are allocated causes them to run out
quickly on the 386.  Identifying more places where it is safe to release a
register is a challenge for this compiler.  The author has made some
improvements since the initial release of the compiler, so that is a plus.
 However, I must say that, as it stands now, my compiler does not do
things much differently.

Quote:
>I also am about to face the question of efficient plotting and
>image display with a very large number of data/display elements,
>and the graphical editors emphasized by ETHZ are NOT what one needs
>for a data-driven system.  I hope this thread leads to lots of good
>advice.  Whitney?

Are you specifically wanting to know how to use the CopyBlock and ???Block
routines from Display?  I can provide that information.

Taylor "BitBlt" Hutt
Now you live inside that bottle, the reaper's travlin' at full throttle. Ozzy



Wed, 28 Feb 1996 00:11:40 GMT  
 Displaying rasters in Oberon

[ edited comments on empirical experience with DOS Oberon expression limitations ]

Quote:
> The problem with the DOS version is not with the compiler, but with the
> (editorial: braindead) Intel chipset.  The 386 has very few general
> purpose registers, and of those, several instructions require specific
> registers to be used.  The original compiler was written with a chip that
> had 8 general purpose and 8 floating point registers, and that is usually
> sufficient (from what I understand).  The 386 has only 4 (truly) general
> purpose registers, and 2 index registers.  It does not have any real
> floating point registers; instead it implements a floating point stack --
> which is not accessible via registers -- and does not support 8 bit values.

> Anyway, the method in which registers are allocated causes them to run out
> quickly on the 386.  Identifying more places where it is safe to release a
> register is a challenge for this compiler.  The author has made some
> improvements since the initial release of the compiler, so that is a plus.
>  However, I must say that, as it stands now, my compiler does not do
> things much differently.

I was afraid that what you describe is the situation.  It is another step in
the direction of playing on PCs but doing serious work with workstation
versions.

Quote:
> >I also am about to face the question of efficient plotting and
> >image display with a very large number of data/display elements,
> >and the graphical editors emphasized by ETHZ are NOT what one needs
> >for a data-driven system.  I hope this thread leads to lots of good
> >advice.  Whitney?

> Are you specifically wanting to know how to use the CopyBlock and ???Block
> routines from Display?  I can provide that information.

> Taylor "BitBlt" Hutt

Yes, thank you.  One of my problems is trying to work with Display and Display3 in
System3 (because I want to use Objects, Libraries, ...), and not being able
to trust the applicability of the old books/documentation.  

With the obvious caveat that, yes, if they are parts of the best solution to
fast display of numerical picture information that starts with a large (e.g.
512 X 512 to 1024 X 1024, byte or integer or real) arrays of numbers,
it would be helpful for you to provide that information for those of us (at least
Delozier and I) trying to figure out how to do efficient image handling/display
in Oberon.  Every leg up on a learning curve is appreciated. ;-)

I had hoped that Whitney would chime in with sage advice since he is the only
one I have heard of on this Newsgroup that clearly has done image processing
with large images.

Bob Hjellming

============================================================================

National Radio Astronomy Observatory  |                             | \/ o\
P.O. Box O                            | Telephone: 505-835-7273     | /\__/
(1003 Lopezville Road - UPS etc. only)|                             |
Socorro, NM  87801-0387  USA          | FAX:       505-835-7027     | AMDG
============================================================================



Wed, 28 Feb 1996 04:01:17 GMT  
 Displaying rasters in Oberon

: I also am about to face the question of efficient plotting and
: image display with a very large number of data/display elements,
: and the graphical editors emphasized by ETHZ are NOT what one needs
: for a data-driven system.  I hope this thread leads to lots of good
: advice.  Whitney?

1) Using the Oberon system from the ETH.

Oberon comes with several classes of viewers, including Text and
Graphics viewers. Neither of these classes ( nor even the Picture Viewer
included with some releases ) is well suited to the task of
time-series or image analysis. One needs to write a new viewer
class and designing such a class is specific to the task at hand.
The basic technique of designing a viewer class is Oberon primitives
is covered in Reiser's book, The Oberon System. It helps to read
Gutknecht and Wirth's book Project Oberon as well.

The next question is how to get top performance out of hardware
subsystem such as the display. M. Franz's (?) paper,  
Software : Practice and Experience June (?), 1993. The paper covers
implementing Oberon on the Macintosh and describes the challenges of
implementing/emulating an operating system such as Oberon on top of another
operating system. In particular it addresses the potential performance
bottlenecks due to mismatches between Oberon's subsystems and those
of the host operating system. As an example the Mac displays things
using primitives such as lines, circles, etc whereas Oberon builds
these up in terms of pixels. The paper covers the techniques used
to minimize the impact of these bottlenecks. Most of the work of
using minimizing these bottlenecks seems to be already done in
most of the Oberon ports.

The Oberon implementation running on unix type machines run as an
single process X-application using a single X-Window. Oberon viewers
are drawn within this window. Oberon display primitives are built
upon X display primitives, but it is possible to use the X11 display
functions directly. These functions are found in the module X11.
With little effort it is possible to draw X11 stuff within
an Oberon viewer so that it look like it is apart of the Oberon system.
Some of the X functions allocate and deallocate memory and there is no
garbage collection with X. So, there is a danger of memory leaks. One
of the ways to avoid this problem is to encapuslate X based pointers
with an Oberon pointer.  You then register the Oberon pointer and a
clean up procedure with the garbage collector. The cleanup function
will be called by the garbage collector when there are no more references to
the registered pointer.

Roughly the technique is :

MODULE MyDisplayExtensions;
IMPORT X11;

TYPE
        XImage = POINTER TO RECORD
                        ximage : LONGINT;
        END;

PROCEDURE XDeleteImage( q : SYSTEM.Ptr );
VAR p : XImage;
BEGIN
        ASSERT( x IS XImage );
        p := q(XImage);
        X11.DestroyImage( p.ximage );
END XDeleteImage;

PROCEDURE CreateImage(): XImage;
VAR p : XImage;
BEGIN
        NEW(p);
        p.ximage := X11.CreateImage();
        Register( p, XDeleteImage );
        RETURN p;
END CreateImage;

END MyDisplayExtensions.

The X11 and GC are lowlevel interfaces. It would be wise to
contact the person who implemented your version of Oberon
about implementation details.

It is important to know that X11 is often not the fastest display
system on a unix box. X11 is useful for displaying graphics on
variety of displays and for displaying graphics "over the wire".  
As an example, on the IBM RS6000 the GL interface is much faster ( 7x )
than X for some display routines.  Using X11 instead of GL makes
Oberon more portable. There is a GL/X11 interface from IBM that allows
GL to be run within an X-Window ( and thus within an Oberon viewer ).
There are some stability problems with the GL/X11 interface - but it
is useable.  

2) Using Oberon and the Pascal Family.

We don't use Oberon386 for the PC. We use commercial implementations
of the Pascal family instead. We use Turbo-Pascal from Borland for both
DOS and Windows. We also use Stony-Brook Modula-2 for DOS. The Stony Brook
compiler is an optimizing compiler and interfaces to C. All of these
implementation have their limitations but they are minor in comparison
to the limitations of DOS. We use the similarites between the languages
to our advantage and often port between Pascal, Modula-2 and Oberon.
I estimate that the porting effort between languages to be 5-10 minutes
for a typical 20 line procedure. ( As a test, I translated 10,000 lines of
Pascal code to Oberon. It took a week. I translated from Pascal to
Modula to Oberon. Not all the code worked properly the first time, but it
worked well enough to convince me that the  Pascal family of programming
languages was comparable if not better than using C for working
( as opposed to porting ) across the platforms that we use. This porting
effort may or may not hold if one includes a broader class of machines
then what we use.  On the otherhand the important issue for many is not the
number of different types of machines but rather the number of machines -
the majority being PC's running DOS ). In short, and not surprizingly,
it is possible to prototype on one machine using Pascal on a PC or Oberon
on a unix machine and then quickly port the code to another machine
and language.

We have just started to use an Oberon to C translator for OS/2 but
is to early to tell whether this will be successful. The compile
times are poor, but this is a problem with using PC based C compilers
and not with the Oberon to C translator. It was sad to see that implementor
chosen to implement support for C style printf family but not garbage
collection. Printf's are annoying at best, whereas the lack of a
GC  will undoubtably lead to well known maintenence problems.
The good news is that it implements Oberon-2 and is thus compatible with
the superb POWEROberon implementation which we use for our work.
All in all, I am optimistic about using Oberon on OS/2.

Whitney  



Wed, 28 Feb 1996 05:01:59 GMT  
 Displaying rasters in Oberon

]]Having just posted some "good news" based with my experience with
]]Oberon-2 on a PC, I must echo DeLozier's experience and dissapointment
]]with the same system.   From what I can tell, Oberon-2 on a PC cannot
]]handle expressions with more than a couple of array adds after
]]a couple of array multiplies, so you have to break up expressions
]]into lots of multiple assignments in a way that is unneeded in
]]O2 on a SPARC.  I wince at the fact that I do not have identical
]]code for some of the same things in my SPARC and PC systems, but I have
]]assumed (hoped?) it was due to my still being in the middle of a
]]learning curve.
]
]The problem with the DOS version is not with the compiler, but with the
](editorial: braindead) Intel chipset.  The 386 has very few general
]purpose registers, and of those, several instructions require specific
]registers to be used.  The original compiler was written with a chip that
]had 8 general purpose and 8 floating point registers, and that is usually
]sufficient (from what I understand).  The 386 has only 4 (truly) general
]purpose registers, and 2 index registers.  It does not have any real
]floating point registers; instead it implements a floating point stack --
]which is not accessible via registers -- and does not support 8 bit values.

Sorry, but this is a cop-out. Let's face it: there are dozens of
compilers out there, for languages similar to Oberon, which don't have
this problem. Everything from Turbo Pascal, to Modula-3, to Ada, even
to C++. No other compiler that I've ever used on an MS-DOS machine has
any problem with expressions of arbitrary complexity.

]Anyway, the method in which registers are allocated causes them to run out
]quickly on the 386.  Identifying more places where it is safe to release a
]register is a challenge for this compiler.  The author has made some
]improvements since the initial release of the compiler, so that is a plus.
] However, I must say that, as it stands now, my compiler does not do
]things much differently.

From the viewpoint of writing a compiler, I can't figure out why this
is such a big deal: it's *not* such a hard problem to solve: when an
expression gets too hairy to work on using only registers, dump to the
stack when you run out. Then when you've performed enough of the
expression that it's simplified, pop terms off the stack.  Figuring
out the order to push in is simple, based on the expression and
operator precendences.

        <MC>

--
|| Mark Craig Carroll: <MC>     ||"I prize the cloudy, tearing sky,
|| Univ of Delaware, Dept of CIS|| for the thoughts that flap and fly.
|| PGP public key available     || For staying in and reading by.



Fri, 01 Mar 1996 03:47:32 GMT  
 Displaying rasters in Oberon


: ]The problem with the DOS version is not with the compiler, but with the
: ](editorial: braindead) Intel chipset.  The 386 has very few general
: ]purpose registers,

: Sorry, but this is a cop-out. Let's face it: there are dozens of
: compilers out there, for languages similar to Oberon, which don't have
: this problem. Everything from Turbo Pascal, to Modula-3, to Ada, even
: to C++. No other compiler that I've ever used on an MS-DOS machine has
: any problem with expressions of arbitrary complexity.

Doubt the ETH should spend its research efforts trying to get
the most out of the wierd designs of yesteryear. Oberon386 is
part of research project that people out side of the ETH get to
play with. ETH research efforts go into RISC based machines,
parallel machines, etc. Stuff that may hit mass production in
a few years. The PC stuff is the domain of commercial guys trying
to capitalize on the 100,000,000 Intel based PC's out there running
without an operating system.

Whitney



Fri, 01 Mar 1996 06:58:34 GMT  
 Displaying rasters in Oberon

Quote:


>: Sorry, but this is a cop-out. Let's face it: there are dozens of
>: compilers out there, for languages similar to Oberon, which don't have
>: this problem. Everything from Turbo Pascal, to Modula-3, to Ada, even
>: to C++. No other compiler that I've ever used on an MS-DOS machine has
>: any problem with expressions of arbitrary complexity.

>Doubt the ETH should spend its research efforts trying to get
>the most out of the wierd designs of yesteryear. Oberon386 is
>part of research project that people out side of the ETH get to
>play with. ETH research efforts go into RISC based machines,
>parallel machines, etc. Stuff that may hit mass production in
>a few years. The PC stuff is the domain of commercial guys trying
>to capitalize on the 100,000,000 Intel based PC's out there running
>without an operating system.

Let's face it: DOS version is underdone. Not only expression evaluation.
In current DOS386 System-2 version there are bugs, for example one that
reboots the computer when too much dynamic memory is requested. (This
has been discussed here already.) The situation is perfectly well known
to ETH DOS developer, yet he did nothing to correct the bug. I believe
it is not due to "weird [processor] design".

I do not understand Whitney's argument about PCs. If PC version was as
good as others, then PC would be as good a developement platform as others,
why not ? The code could then be moved to other platforms. As it is now,
PC is crippled by inferior DOS Oberon version. Do not blame it on Intel,
though.

Wojtek

Wojtek Skulski, Lawrence Berkeley Laboratory, 1 Cyclotron Rd, MS 71-259



Fri, 01 Mar 1996 01:18:00 GMT  
 Displaying rasters in Oberon




: >
: Let's face it: DOS version is underdone. Not only expression evaluation.
: In current DOS386 System-2 version there are bugs,

: I do not understand Whitney's argument about PCs. If PC version was as
: good as others, then PC would be as good a developement platform as others,
: why not ? The code could then be moved to other platforms. As it is now,
: PC is crippled by inferior DOS Oberon version. Do not blame it on Intel,
: though.

Agreed. The PC version is underdone. Like many places we have more
PC's then Macs or unix boxes. It would be great if we could port
the code we have written on the RS6000 to the PC or even the other
way around. But who is going to do make these improvements and
why would they do it. Many of the Oberon ports have been done as
research projects by graduate students. The challenges of writing a
compiler for super-scalar RISC architectures such as the RS6000 makes
for a good research topic. Writing for a register starved 386 probably
does not. If there isn't a research topic in it there is little
motivation for an implementation regardless how much others could
use it.  On the otherhand, I think that a great implementation for
the 386 would do wonders for the general acceptance of Oberon.
This may or may not help promote their other research.  

If you want to use Oberon for your work, maybe the question to ask
is what is the most cost effective Oberon machine. For our work
it is no longer the IBM-PC clone ( its limitations outweigh its
price advantage for some tasks ) but rather the soon to be released
IBM PowerPC. IBM, Motorola, etc claim that this machine will run the
RS6000 binaries - and thus POWEROberon. There are machines to consider
as well.

Whitney



Fri, 01 Mar 1996 11:24:46 GMT  
 Displaying rasters in Oberon
Wow. I post a note about getting rasters to the screen, go away for
a few days, and get back to find people arguing about Intel processors
and ETH research priorities! Aren't we lively? :-)

First, one last comment about expression evaluation. I agree that there
are lots of compilers for 386's that handle quite complicated expressions,
but I guess if you start out to write a portable compiler that assumes
sufficient registers are around for any expression, then when you get to
the 386 you've got a problem. That's too bad, but I can sure see how it
could happen. I like the 386 version anyway, and use it at home a lot.

Here's how the ETH could get a lot more work done on the 386 version
at minimal cost: release the sources. I'd love to try and fix that compiler.
Or do a half dozen other things. As it is, I spend a lot of time trying to
figure out things that seem hidden from me for no apparent reason.

Oh, well. I like it anyway.

Anyway, I'm still trying to get images onto the screen in a fairly quick
way.  I got a note from ETH (thanks!) suggesting I use the Pictures
module, which I took a look at. True enough, one can copy a picture to
the screen like greased lightning. Just great.

Trouble is, using the Pictures.Dot command, it takes about a minute
for my Sparc IPX to fill and 800x800 Picture using something like:

        FOR i := 0 to 799 DO
            FOR j := 0 to 799 DO
                Pictures.Dot(MyPic,(i+j)MOD 256,i,j,Display.replace);
            END;
        END;

Now, I have these wild imaginings that I could manipulate the image
data in an array somewhere and put it into the picture much faster if
I knew where the data were stored. All I can see in the .Def are
fields for the height, width, & depth, though I assume a pointer to
the data exists somewhere...

Any further suggestions?

Best wishes,

-greg
---
Greg DeLozier/Senior Scientific Analyst/L{*filter*}Defense Systems



Sat, 02 Mar 1996 02:14:01 GMT  
 Displaying rasters in Oberon

Quote:

>If you want to use Oberon for your work, maybe the question to ask
>is what is the most cost effective Oberon machine. For our work
>it is no longer the IBM-PC clone ( its limitations outweigh its
>price advantage for some tasks ) but rather the soon to be released
>IBM PowerPC. IBM, Motorola, etc claim that this machine will run the
>RS6000 binaries - and thus POWEROberon. There are machines to consider
>as well.

Sounds great to me. Do you have any idea, when PowerPC will be released and
what will be the price ? Is it going to run DOS programs as well ?

Wojtek

Wojtek Skulski, Lawrence Berkeley Laboratory, 1 Cyclotron Rd, MS 71-259



Fri, 01 Mar 1996 19:48:00 GMT  
 Displaying rasters in Oberon

: Trouble is, using the Pictures.Dot command, it takes about a minute
: for my Sparc IPX to fill and 800x800 Picture using something like:

: Now, I have these wild imaginings that I could manipulate the image
: data in an array somewhere and put it into the picture much faster if
: I knew where the data were stored. All I can see in the .Def are
: fields for the height, width, & depth, though I assume a pointer to
: the data exists somewhere...

: Any further suggestions?

I use : X11.CreateImage, X11.PutImage and X11.DestroyImage on
on the RS6000. It should work on the other unix boxes including
the Sparc.

Whitney



Sat, 02 Mar 1996 03:54:13 GMT  
 Displaying rasters in Oberon

: I use : X11.CreateImage, X11.PutImage and X11.DestroyImage on
: on the RS6000. It should work on the other unix boxes including
: the Sparc.

I put some example code on how to use this on
   oberon.Meakins.McGill.CA:/pub/Oberon/X11/Images0.Mod

( 132.206.169.3 )

I have disable the ObjectCloser part - the interface to the
garbage collector. I think the version I have is specific to
the RS6000. You should get a Sparc version of ObjectCloser
other wise you will have storage leak problems from uncollected
C pointers created with X11.CreateImage.

Whitney



Sat, 02 Mar 1996 04:33:11 GMT  
 
 [ 30 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. TK: Display Raster Image?

2. Oberon OS\2 display colors washed out

3. Format of Display.Pattern in Linux (and various) Oberons

4. GIF87/89 raster data LZW routines in awk?

5. RASTER PRINTER

6. Observing a raster pattern with Intensity Graph

7. Maping of the data in the binary format as a raster graphics

8. Raster files to VRML online

9. Geometry/raster engine in VHDL

10. Raster Refresh on PC compatibles

11. SEARCHING : a library to read/write raster images with Fortran 90 on Windows NT

12. Polar Array - Raster Grid

 

 
Powered by phpBB® Forum Software