New Oberon/2 Compiler 
Author Message
 New Oberon/2 Compiler

Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
prople interested in joining a compiler project, "OPEN SOURCE" to
compile Oberon/2 to an intermediate abstract register machine. This is
to allow multiple targets similar to java but with some neat
twists. If you are interested let me know.

    Thanx,
    Ron



Thu, 09 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
Hallo!

Quote:
>Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
>prople interested in joining a compiler project, "OPEN SOURCE" to
>compile Oberon/2 to an intermediate abstract register machine. This is
>to allow multiple targets similar to java but with some neat
>twists. If you are interested let me know.

Don't do this. We don't need another compiler, we already have enough
good ones. In fact, if you are looking for a free (GPL?) compiler,
with massive optimisation, actively developed, good documentation
etc... and a plattform independant backend, then just use ooc and plug
in another backend instead of the C backend. ooc was designed for just
it. You will get scanner, parser, code tree, optimisations and all
that other heavy work stuff for free.

--
Gru?...
       Tim.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler


Quote:
> Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
> prople interested in joining a compiler project, "OPEN SOURCE" to
> compile Oberon/2 to an intermediate abstract register machine. This is
> to allow multiple targets similar to java but with some neat
> twists. If you are interested let me know.

>     Thanx,
>     Ron

Why not user Coco/R instead of Flex/Bison, that way the development
could actually be done in Oberon itself?

I've been considering starting an open source Oberon compiler project
myself, though my goals are a bit different from yours.  I'm intersted
in writing Oberon-(X, Active, SA, whatever) to Oberon-2 (or 1)
converters.  Also interested in having a platform for being able
to test different extension ideas that people are always throwing
out.

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
Hallo!

Quote:
>Why not user Coco/R instead of Flex/Bison, that way the development
>could actually be done in Oberon itself?

AFAIK Oberon-2 is not LR(1), so you must adjust syntax of Oberon-2 to
use Coco.

Quote:
>I've been considering starting an open source Oberon compiler project
>myself, though my goals are a bit different from yours.  I'm intersted

You could OOC for that, too. Saving a lot of time.

--
Gru?...
       Tim.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler

Quote:

> Hallo!

> >Why not user Coco/R instead of Flex/Bison, that way the development
> >could actually be done in Oberon itself?

> AFAIK Oberon-2 is not LR(1), so you must adjust syntax of Oberon-2 to
> use Coco.

What's not LR(1) about it?

At anyrate an non LR(1) grammar can be "massaged" to LR(1).  Also
as I recall there already exist a Coco/R grammar for Oberon-2.

Quote:
> >I've been considering starting an open source Oberon compiler project
> >myself, though my goals are a bit different from yours.  I'm
intersted

> You could OOC for that, too. Saving a lot of time.

I think that using OOC as a translator would be overkill.
Also the time saved from using what's in OOC would be lost
learning the ins and outs of OOC in my opinion.

All you really need for a source to source translator
is just the parser.

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler

Quote:

> I think that using OOC as a translator would be overkill.
> Also the time saved from using what's in OOC would be lost
> learning the ins and outs of OOC in my opinion.

> All you really need for a source to source translator
> is just the parser.

Then oocn may be of interest to you.  This tools is part of the OOC
distrib and is exclusively geared towards source code manipulation of
Oberon-2 modules.  It includes a parser that gives you the bare bones
syntax tree of a module.  The parser does not depend on the OOC
compiler in any way.

-- Michael van Acken



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler


Quote:

> > I think that using OOC as a translator would be overkill.
> > Also the time saved from using what's in OOC would be lost
> > learning the ins and outs of OOC in my opinion.

> > All you really need for a source to source translator
> > is just the parser.

> Then oocn may be of interest to you.  This tools is part of the OOC
> distrib and is exclusively geared towards source code manipulation of
> Oberon-2 modules.  It includes a parser that gives you the bare bones
> syntax tree of a module.  The parser does not depend on the OOC
> compiler in any way.

> -- Michael van Acken

Well to be honest I'm really more interested in compiler generators
than hand crafted compilers.

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
I tried using the EBNF grammar for Oberon/2 and I can't get it to work.
Would
you like to have a crack at it? I come from a C/C++ background and am
familiar with Flex&Bison so......

    Ron

Quote:



> > Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
> > prople interested in joining a compiler project, "OPEN SOURCE" to
> > compile Oberon/2 to an intermediate abstract register machine. This is
> > to allow multiple targets similar to java but with some neat
> > twists. If you are interested let me know.

> >     Thanx,
> >     Ron

> Why not user Coco/R instead of Flex/Bison, that way the development
> could actually be done in Oberon itself?

> I've been considering starting an open source Oberon compiler project
> myself, though my goals are a bit different from yours.  I'm intersted
> in writing Oberon-(X, Active, SA, whatever) to Oberon-2 (or 1)
> converters.  Also interested in having a platform for being able
> to test different extension ideas that people are always throwing
> out.

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
Also I have create a IDE for COCO under windoz if you are interested.
I am including this on the STRAW HAT OBERON CD.
Quote:



> > Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
> > prople interested in joining a compiler project, "OPEN SOURCE" to
> > compile Oberon/2 to an intermediate abstract register machine. This is
> > to allow multiple targets similar to java but with some neat
> > twists. If you are interested let me know.

> >     Thanx,
> >     Ron

> Why not user Coco/R instead of Flex/Bison, that way the development
> could actually be done in Oberon itself?

> I've been considering starting an open source Oberon compiler project
> myself, though my goals are a bit different from yours.  I'm intersted
> in writing Oberon-(X, Active, SA, whatever) to Oberon-2 (or 1)
> converters.  Also interested in having a platform for being able
> to test different extension ideas that people are always throwing
> out.

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
Tim,
    The reason for this is by doing in C/C++ using Flex & Bison. I am
trying to
get those programmer that may be interested only in compilers to have a
chance
to see the language while they play with it. In doing so it may interest
them enough to
continue in some way with it. By putting the source in Oberon/2 itself
won't
interest these people.

    Ron

Quote:

> Hallo!

> >Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
> >prople interested in joining a compiler project, "OPEN SOURCE" to
> >compile Oberon/2 to an intermediate abstract register machine. This is
> >to allow multiple targets similar to java but with some neat
> >twists. If you are interested let me know.

> Don't do this. We don't need another compiler, we already have enough
> good ones. In fact, if you are looking for a free (GPL?) compiler,
> with massive optimisation, actively developed, good documentation
> etc... and a plattform independant backend, then just use ooc and plug
> in another backend instead of the C backend. ooc was designed for just
> it. You will get scanner, parser, code tree, optimisations and all
> that other heavy work stuff for free.

> --
> Gru?...
>        Tim.



Fri, 10 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
Hallo!

Quote:
>Tim,
>    The reason for this is by doing in C/C++ using Flex & Bison. I am
>trying to
>get those programmer that may be interested only in compilers to have a
>chance
>to see the language while they play with it. In doing so it may interest
>them enough to
>continue in some way with it. By putting the source in Oberon/2 itself
>won't
>interest these people.

I don't think someone will be intersted in an oberon compiler if he is
not interested in the language itself!?

You will develope a while until you compiler will be more intersting
than for example OOC. A lot of time and effort was spend for making
OOC in its current state.

If you are intersted in compiler technologie, writing scanner and
parser is the more dump stuff. Writing optimisations is far more
interesting and OOC will offer you a good infrastructure for that.

Even more time and technology split will hurt the Oberon community
badly. The Oberon System/non Oberon System already did hurt the
community a lot.

--
Gru?...
       Tim.



Sat, 11 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler
As it happens, my compiler OBC uses an LR(1) grammar to parse its
input, but it is a strictly multi-pass compiler, so it does the
parsing without any help from semantic analysis.  I did not find any
places where the context-free grammar of Oberon-2 is not LR(1), except
where the grammar is actually ambiguous.

Here is a list of places where the Abstract Syntax Tree built by the
parser has to be fixed up later:

        Discrimination between selection r.f and module references m.x
        Discrimination of procedure calls p(x) from casts x(t)
        Discrimination of method calls r.m() from selection r.f()
        Promotion of character constants to one-character strings
        Implicit widening of numeric types
        Implicit dereferencing p[i] for p^[i]

I've omitted places where the tree is edited just for constant
propagation.  Of course, ambiguity is a property of grammars, not of
languages, and so the ambiguities I found are partly a product of the
abstract syntax I decided to use.  Certainly, the first three items on
the above list have more right to be called ambiguities than the last
three, which are really there just to make the code generator's task
easier.  All these things could be eliminated by the usual tricks in a
one-pass compiler.

-- Mike



Sat, 11 May 2002 03:00:00 GMT  
 New Oberon/2 Compiler

Quote:

>Just finshed the Flex & Bison grammar for Oberon/2. Looking for 1 or 2
>prople interested in joining a compiler project, "OPEN SOURCE" to
>compile Oberon/2 to an intermediate abstract register machine. This is
>to allow multiple targets similar to java but with some neat
>twists. If you are interested let me know.

> Don't do this.

Why not?

Quote:
> We don't need another compiler, we already have enough
> good ones.

Really?
Most are 32 bit compilers only.
The ooc implementation is full of 32 bit restrictions -- compiler
and library. This has to do with LONGINT -- do you remember?

Most existing compilers are stand-alone, e.g. ooc.
Stand-alone Oberon compilers don't have module load on demand.
Stand-alone compilers miss one of the most important, original
design goal of the Oberon System.

The language Oberon was designed together with the System.
The language alone does not offer much advantage
over its predecessor, except that it is simpler and
more powerful (object-based) and adds pointer safety
(given the implementation initializes all pointer variables,
local, global, and on the heap, and provides GC.

The System adds dynamic linker/loader and up-calls.
Without this functionality, true persistency and
extensible programming is not possible.

Quote:
> In fact, if you are looking for a free (GPL?) compiler,
> with massive optimisation, actively developed, good documentation
> etc... and a plattform independant backend, then just use ooc and plug
> in another backend instead of the C backend. ooc was designed for just
> it. You will get scanner, parser, code tree, optimisations and all
> that other heavy work stuff for free.

Out of curiosity, I browsed the source of Mark Brandis' GSA compiler
and that of ooc recently. If I understood correctly,
much of the GSA work is performed in the back-end for
native code compilers. For ooc there exists only one back-end
which emits C source code. This back-end is very simple, which
is good, but does little in respect to code-optimization.
Native code-generation is the C compiler's task.
I doubt you could avoid the complexity/size of GSA-specific code
in a native-code back-end for ooc. So I guess most of the
work in respect to native code optimization is still to do for ooc.

 g.zel
<><><><>
If you were my daughter... What would you do dady? (quote FZ)
You might want to check out...
http://www.y2knewswire.com/Y2Kengine.htm
but please don't panic.



Sat, 11 May 2002 03:00:00 GMT  
 
 [ 38 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. JOB - new Oberon-2 compiler

2. new Oxford O2 entry in OSCI (Oberon System and Compiler Implementations List)

3. New Oberon compiler goes public

4. New BeOS Oberon-2 Compiler

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

6. Very portable Oberon compiler (Oberon and ANDF)

7. New Books on Oberon (Short summary: Three Questions on Oberon)

8. SOFTWARE: Native XDS-x86 v2.20 (Modula-2/Oberon-2 compiler)

9. Oberon compiler, anyone ?

10. Portable Oberon compiler

11. Oberon compiler

12. Looking for Oberon compiler

 

 
Powered by phpBB® Forum Software