Very portable Oberon compiler (Oberon and ANDF) 
Author Message
 Very portable Oberon compiler (Oberon and ANDF)

Hi,

What with all the talk about the ANDF (Architecture Neutral
Distribution Format) standard, which effectively provides a
universal assembly language without any of the disadvantages
of p-code, I want to ask the following question:

* How feasible would it be to use ANDF to create a portable
oberon compiler?  Presumably this would enable the Oberon
system to be ported to all computers that support ANDF.

To my way of thinking, the portability of the Oberon operating
system, and the elegance of the Oberon language make for a
potent mix.  Combine this with an ANDF compiler, and you get
an almost totally portable environment.  Maybe?

Cheers,
Andrew McVeigh

--
"Love your neighbour as yourself"  |   Andrew McVeigh      
        Jesus Christ               +-----------------



Fri, 31 May 1996 19:03:34 GMT  
 Very portable Oberon compiler (Oberon and ANDF)

Quote:

>Hi,

>What with all the talk about the ANDF (Architecture Neutral
>Distribution Format) standard, which effectively provides a
>universal assembly language without any of the disadvantages
>of p-code, I want to ask the following question:

I'm glad you didn't give any opinions about ANDF. I've been following those
comp.lang.misc threads and for a while I thought it was going to break
out into full blown war.

Quote:
>* How feasible would it be to use ANDF to create a portable
>oberon compiler?  Presumably this would enable the Oberon
>system to be ported to all computers that support ANDF.

Actually, its easier than that with Oberon compilers because you can make
more assumptions about your environment. For example, you know that you
have at least some of the Oberon (operating) system around you. Moreover,
you're talking about a portable image generated from one language, not the
multitude that ANDF tried to support.

I remember (and have just looked up) a paper given in the second
international Modula-2 conference, Loughborough 1991 which had me quite
interested at the time. I dont know where you'll find this, but its as
follows :

Title    : Portability Redefined

Authors  : Michael Franz (Institut fur computersyteme, ETH Zurich)
           Stefan Ludwig (Abteilung fur Informatik, ETH Zurich)

Abstract : This paper describes a system that provides object-level
           compatibility between different computer architectures. Compiled
           programs are represented by a symbol table plus an abstract
           syntax tree. Our prototype implementation features dynamic module
           loading and incorporates a code generating loader.

The principle was quite smart, but I think only applicable to a dynamic
load environment such as Oberon. The idea is that when a call is made to
either a library or command procedure, the system did the Oberon style
check of loaded modules, then check of available loadable modules. If
neither was available it would look for one of these portable objects
and load it via a native code generator.

Like ANDF this process gives a reduced performance, but unlike ANDF it
only does so for the first load (after which the native version is
available for reuse). By all accounts, for a typical size module even
the performance difference on first load was hardly noticeable.

Quote:
>To my way of thinking, the portability of the Oberon operating
>system, and the elegance of the Oberon language make for a
>potent mix.  Combine this with an ANDF compiler, and you get
>an almost totally portable environment.  Maybe?

Actually, provided that you keep as much code in Oberon as possible,
it means only having to re-write the loader, the code generator and
possibly one or two other hardware/OS dependant modules. Then you
can just bootstrap the rest through the loader (or at least thats the
theory!!).

I think like ANDF, however, that you wind up with similar problems with
version maintenance. You have to depend, for example, on the user of
your portable module having versions of the libraries it imports of same
age or older.

--
---------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401

UK                                 Compuserve : 71333,2456
---------------------------------------------------------------------------



Mon, 03 Jun 1996 19:10:10 GMT  
 Very portable Oberon compiler (Oberon and ANDF)

Quote:


>>Hi,

>>What with all the talk about the ANDF (Architecture Neutral
>>Distribution Format) standard, which effectively provides a
>>universal assembly language without any of the disadvantages
>>of p-code, I want to ask the following question:

>I'm glad you didn't give any opinions about ANDF. I've been following those
>comp.lang.misc threads and for a while I thought it was going to break
>out into full blown war.

>>* How feasible would it be to use ANDF to create a portable
>>oberon compiler?  Presumably this would enable the Oberon
>>system to be ported to all computers that support ANDF.

>Actually, its easier than that with Oberon compilers because you can make
>more assumptions about your environment. For example, you know that you
>have at least some of the Oberon (operating) system around you. Moreover,
>you're talking about a portable image generated from one language, not the
>multitude that ANDF tried to support.

>I remember (and have just looked up) a paper given in the second
>international Modula-2 conference, Loughborough 1991 which had me quite
>interested at the time. I dont know where you'll find this, but its as
>follows :

>Title    : Portability Redefined

>Authors  : Michael Franz (Institut fur computersyteme, ETH Zurich)
>           Stefan Ludwig (Abteilung fur Informatik, ETH Zurich)

>Abstract : This paper describes a system that provides object-level
>           compatibility between different computer architectures. Compiled
>           programs are represented by a symbol table plus an abstract
>           syntax tree. Our prototype implementation features dynamic module
>           loading and incorporates a code generating loader.

>The principle was quite smart, but I think only applicable to a dynamic
>load environment such as Oberon. The idea is that when a call is made to
>either a library or command procedure, the system did the Oberon style
>check of loaded modules, then check of available loadable modules. If
>neither was available it would look for one of these portable objects
>and load it via a native code generator.

>Like ANDF this process gives a reduced performance, but unlike ANDF it
>only does so for the first load (after which the native version is
>available for reuse). By all accounts, for a typical size module even
>the performance difference on first load was hardly noticeable.

I'm not an ANDF fan, but I feel I should point out that actually, this
whole statement isn't true.

ANDF does *not* give reduced performance, on the first run or on ANY
run.

ANDF is a portable intermediate language - much like the tree form
internal to the GCC compiler family. The point of ANDF is to compile
to this common intermediate language.

An ANDF compiler compiles down to intermediate code, performing all of
the high-level optimizations that it can, and then stopping before it
translates it to real object code.

Then, when someone goes to install an ANDF application, the installer
is basically a compiler back-end, which reads the intermediate code,
and translates it into true object code, performing all of the
low-level optimizations.

It's basically the result of taking a compiler like GCC, and breaking
it into two seperate pieces - the front end and the back end, and
letting users run the back end on the generated intermediate code when
they go to install it.

So there really isn't any performance hit - except that it takes
longer to install a new piece of software when it's distributed as
ANDF.

Of course, whether doing this is a good idea or not is a seperate
issue.

Quote:
>>To my way of thinking, the portability of the Oberon operating
>>system, and the elegance of the Oberon language make for a
>>potent mix.  Combine this with an ANDF compiler, and you get
>>an almost totally portable environment.  Maybe?

>Actually, provided that you keep as much code in Oberon as possible,
>it means only having to re-write the loader, the code generator and
>possibly one or two other hardware/OS dependant modules. Then you
>can just bootstrap the rest through the loader (or at least thats the
>theory!!).

Actually, it wouldn't work quite so well. ANDF assumes monolithic
programs. Oberon could use an ANDF like intermediate code (much the
way Smalltalk does), but it wouldn't be compatible with the rest of
the ANDF stuff.

Quote:
>I think like ANDF, however, that you wind up with similar problems with
>version maintenance. You have to depend, for example, on the user of
>your portable module having versions of the libraries it imports of same
>age or older.

I believe that that kind of problem is addressed by ANDF. The real
problems of ANDF are of a rather different nature, but they've been
beaten to death recently, so I won't rehash that mess.

        <MC>

--
|| Mark Craig Carroll: <MC>     || "Humanity isn't a physical description,
|| CIS Grad, U of Delaware      || it's a spiritual goal. It's not something
|| PGP Key Available, by finger || you're given, it's something you earn."



Wed, 05 Jun 1996 00:09:44 GMT  
 Very portable Oberon compiler (Oberon and ANDF)

Hi all,

Quote:

>  >* How feasible would it be to use ANDF to create a portable
>  >oberon compiler?  Presumably this would enable the Oberon
>  >system to be ported to all computers that support ANDF.

>  Actually, its easier than that with Oberon compilers because you can make
>  more assumptions about your environment. For example, you know that you
>  have at least some of the Oberon (operating) system around you. Moreover,
>  you're talking about a portable image generated from one language, not the
>  multitude that ANDF tried to support.

Actually, I wanted to know if it was possible to use ANDF to write a
portable code generator!  I realise that any compiler written in Oberon
is going to be portable, however the code it generates will be tied to
a particular instruction set.

Quote:
>  >To my way of thinking, the portability of the Oberon operating
>  >system, and the elegance of the Oberon language make for a
>  >potent mix.  Combine this with an ANDF compiler, and you get
>  >an almost totally portable environment.  Maybe?

>  Actually, provided that you keep as much code in Oberon as possible,
>  it means only having to re-write the loader, the code generator and
>  possibly one or two other hardware/OS dependant modules. Then you
>  can just bootstrap the rest through the loader (or at least thats the
>  theory!!).

Well, rewriting the code generator is something that would be nice to
avoid!  I don't know that much about ANDF (except that it seems to make
a lot of people very mad!! ;-), but I presume that you could get the
code generator interfacing somehow to the ANDF installer to create a
machine-independent code-generator...

Cheers,

Andrew McVeigh

p.s. I have sent away for the ANDF papers, but haven't received them
yet.  Does anyone know an ftp site, or an alternative source?

--
"Love your neighbour as yourself"  |   Andrew McVeigh      
        Jesus Christ               +-----------------



Tue, 04 Jun 1996 22:36:52 GMT  
 Very portable Oberon compiler (Oberon and ANDF)

Quote:

>>Like ANDF this process gives a reduced performance, but unlike ANDF it
>>only does so for the first load (after which the native version is
>>available for reuse). By all accounts, for a typical size module even
>>the performance difference on first load was hardly noticeable.
>ANDF is a portable intermediate language - much like the tree form
>internal to the GCC compiler family. The point of ANDF is to compile
>to this common intermediate language.

Actually, this is what happens when you skip read usenet postings. I'd
missed the fact it was a code generator. The arguments that were going on
seemed to imply it worked as an emulator for an abstract ANDF machine.
It makes a few other comments I saw make more sense.

Quote:
>>Actually, provided that you keep as much code in Oberon as possible,
>>it means only having to re-write the loader, the code generator and
>>possibly one or two other hardware/OS dependant modules. Then you
>>can just bootstrap the rest through the loader (or at least thats the
>>theory!!).

>Actually, it wouldn't work quite so well. ANDF assumes monolithic
>programs. Oberon could use an ANDF like intermediate code (much the
>way Smalltalk does), but it wouldn't be compatible with the rest of
>the ANDF stuff.

I wasn't talking about ANDF, I was talking about the portable oberon
object format. This must be my mistake as the next follow thought I
was talking about ANDF as well.

---------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401

UK                                 Compuserve : 71333,2456
---------------------------------------------------------------------------



Sun, 09 Jun 1996 04:08:21 GMT  
 Very portable Oberon compiler (Oberon and ANDF)

Quote:

>>  Actually, its easier than that with Oberon compilers because you can make
>>  more assumptions about your environment. For example, you know that you
>>  have at least some of the Oberon (operating) system around you. Moreover,
>>  you're talking about a portable image generated from one language, not the
>>  multitude that ANDF tried to support.

>Actually, I wanted to know if it was possible to use ANDF to write a
>portable code generator!  I realise that any compiler written in Oberon
>is going to be portable, however the code it generates will be tied to
>a particular instruction set.

No, I was talking about the portable Oberon format, not ANDF. This is what
I meant - any code generated by the Oberon compiler is then portable
to any platform with the portable format loader. Which, as pointed out
by the other guys follow to my posting, is exactly what ANDF does.

Quote:
>Well, rewriting the code generator is something that would be nice to
>avoid!  I don't know that much about ANDF (except that it seems to make
>a lot of people very mad!! ;-), but I presume that you could get the
>code generator interfacing somehow to the ANDF installer to create a
>machine-independent code-generator...

A machine independant code generator ?
Are you just asking if someone is going to output ANDF from their
Oberon compiler ?

--
---------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401

UK                                 Compuserve : 71333,2456
---------------------------------------------------------------------------



Sun, 09 Jun 1996 04:13:25 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. A portable Oberon compiler

2. Oberon/Modula portable compiler

3. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

4. SMALL PORTABLE Oberon compiler?

5. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

6. Portable Free Oberon-2 standalone compilers?

7. Portable Free Oberon-2 standalone compilers?

8. Portable Oberon compiler

9. Announce: Oberon 960, an Oberon-2 compiler generating 80960 code

10. Is Oberon data format portable ??

11. Oberon and Portables

12. Frage Oberon 3 / Question Oberon 3

 

 
Powered by phpBB® Forum Software