Re: Some OOC issues (was: Re: Target audience)

[acken@informatik.uni-kl.de]

Peter Froehlich <pfroehli@nospam.ics.uci.edu> wrote:
> In article <6h86cu$gi7$1@news02.btx.dtag.de>, mvacken@t-online.de (Michael
> van Acken) wrote:
>
> >OOC, and its current compiler incarnation oo2c, can interface with any
> >kind of C code.  Interfaces to (well defined) portable packages can be
> >defined in a special INTERFACE module, which is subsequently used like
> >a standard Oberon-2 module.  An example for this is the interface to
> >the X11 library and how it is used by VO.
>
>    Am I correct that this also opens up interoperability with FORTRAN,
> Pascal, or whatever other language not relying on a complicated run-time
> model?

Yes.  As long as the object code from "whatever other language" can be
linked in, with variable and function names known on the linker level,
interfacing is simple.

>    There are of course two different issues here: One is the
> fundamental problem to map things like multiple inheritance,
> templates or overloading to Oberon-2. The other is that each and
> every C++ compiler potentially uses a slightly different run-time
> model, so even when we map "simple C++" to Oberon, we would have to
> do so (potentially) for each C++ compiler.

You identified the two problems of interfacing to C++ correctly.

> Or is the oo2c <-> GCC relation so "fixed" that other C/C++
> compilers don't work anyway?

oo2c translates to ANSI-C.  It does not need gcc.

> >Note that certain things are very close to the compiler
> >implementation, even if the language itself isn't touched.  Anything
> >interacting with a compiler's run-time system tends to be
> >non-portable: meta-programming facilities, exceptions, dynamic loading,
> >to name a few.
>
>    There should nevertheless be a safe way to write object I/O stuff. I
> don't know OOC well enough: does it have a Types.Mod?

Yes, a Types module is provided.

>    This brings up another thing I don't understand: Why are there no
> native backends (none at all!) for OOC? What happend to Frank
> Copeland for instance?

No one knows.

> Why can't existing backends (e.g. for PowerPC) not be plugged-in
> with relatively small cost?

A back-end has to close the gap between the compiler's internal code
representation and the target architecture.  Obviously a back-end can
only be written for one particular intermediate code representation.
Several parts of this task can be shared between back-ends, as long as
their implementation is configurable to a certain degree.  For example, a
instruction scheduler exists, and the back-end writer only needs to provide
his own scheduling policy.

>    A last point: Obviously this post should rather go to the OOC mailing
> list, but since I didn't get a reply on my last mail to that list, I
> assume it is in some "unstable" state. Is that true? There have also been
> no new archives for some months...

Mh, that's strange.  I assume you are referring to your post about a
ADT Container.  There were several replies.  You should contact
jnzimmer@informatik.uni-kl.de about this.  He is the list maintainer,
and he should have an archive of the posts.  If he doesn't have them,
drop me a note and I'll dig them out for you.

-- Michael van Acken

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading