Pascal to Oberon Translator

[Chris Burrows]

Is anybody interested in using a Pascal to Oberon translator? I have a
prototype written in Component Pascal which is working and seems to handle
J&W / Standard Pascal programs reasonably well. However, it would need
significant additional work to handle other Pascal dialects (e.g. UCSD,
Turbo, Delphi). I'm trying to decide whether to proceed any further or start
a new project altogether.

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[noch]

In fact I need oberon to pascal translator more than pascal to oberon.
Anyway it is cool to automate translations, may be I can translate my
pascal projects to oberon easy ;)
If you will publish it please write here ;)

[Chris Burrows]

Post by noch
In fact I need oberon to pascal translator more than pascal to oberon.

Why would you want to go backwards? ;-)

Post by noch
Anyway it is cool to automate translations, may be I can translate my
pascal projects to oberon easy ;)
If you will publish it please write here ;)

The BlackBox Component Pascal version of the translator for Win32 is now
available from Helmut Zinn's excellent Component Pascal collection at:

http://www.zinnamturm.de/

If initial feedback shows no problems, I'll upload the Gardens Point
Component Pascal version for Microsoft .NET to my website in a week or so,

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[noch]

You asking why I need to go backwards? I do not going backwords!
There are no suitable for me oberon-2 compiler for linux yet.
I am waiting for blackbox release impatiently.

There are only two compilers which produce native code:
xds, oo2c.
xds doesn't do garbage collection for swapped data.
oo2c is mot useful, but it is not real compiler, just translator.
I like very much Ulm's oberon system but it is oberon compiler not
oberon-2 and there are no open arrays.
Anyway developers planning to implement open arrays when have a time.
Besides, I can't run it on my 120mhz 32mb ram laptop.
It fall in thrashing when compiling and can't compile simple hello
world program even in one hour.
So, I tell you I need oberon to pascal compiler more than pascal to
oberon because if I have no suitable compiler for programming, and I am
forced to use the best available: oo2c, that just making translation
from oberon to c code. So it will be a good solution write oberon
program, translate to pascal and compile it with kylix or better
freepascal compiler.
BTW... some tasks allow me not to concentrate on the produced code,
will it be native or IL. And for some of them I can try to use .net
code compiler, but... ETHZ compiler does not work under linux...
and when using gpcp compiler I am forced to do just .net programming
with oberon syntax. That code can be compiled only with gpcp compiler,
because in standard oberon/component pascal there are no Console module
for instance, there are In, Out, Files... and so on.

Thanks


Norayr Chilingaryan

---
http://www.geocities.com/asprayama/if-so

[noch]

I mean sure ETHZ .net compiler doesn't work under linux

[Stewart Greenhill]

Post by noch
There are no suitable for me oberon-2 compiler for linux yet.

[...]

Post by noch
xds, oo2c.
xds doesn't do garbage collection for swapped data.
oo2c is mot useful, but it is not real compiler, just translator.

[...]

Post by noch
So, I tell you I need oberon to pascal compiler more than pascal to
oberon because if I have no suitable compiler for programming, and I am
forced to use the best available: oo2c, that just making translation
from oberon to c code. So it will be a good solution write oberon
program, translate to pascal and compile it with kylix or better
freepascal compiler.

I hope that you can see the irony in what you are suggesting. You don't
like oo2c because its "just a translator", yet you consider and oberon
to pascal translator a "good solution".

Ultimately, all compilers are just translators. They take a source
language and produce object code. Often there are many intermediate
stages; sometimes there are none.

oo2c has a higly modular internal structure, consisting of multiple
intermediate stages. The parser builds an abstract syntax tree ("AST"),
which is then converted into a SSA intermediate representation ("IR").
OOC does extensive optimisation and transformation on the IR code. This
includes data-flow analysis which allows it to pick up problems like
uninitialised objects, and unused objects at compile time. It also
allows certain "run-time" checks to be factored out at compile time,
which is important for achieving best performance for complex array and
record manipulations. The IR code is then translated to assembley
language. For portability OOC uses "C" as its assembley language, and
"gcc" as its assembler.

Alternatively, you could write your own native back-end to generate
other kinds of output from the IR code. That would cost you a large
amount of your time, and would not likely produce any benefit except
perhaps some philosophical satisfaction. Indeed, OOC includes an
experimental x86 back-end which I suspect was developed for that very
reason. If you can write a better optimizer than OOC + gcc combined then
you might gain something in terms of performance. If you have a large
team of programmers available to do this, then you can make the compiler
less dependent on external tools. But in terms of supported platforms
per programming hour you can't beat "C" output.

Really, oo2c *is* a compiler by any reasonable definition of the term.
Sure, it uses another program to generate the final object code, but
then so do many other compilers (eg. gcc).

Cheers,
Stewart

[noch]

Post by Stewart Greenhill
I hope that you can see the
irony in what you are
suggesting. You don't
like oo2c because its "just
a translator", yet you
consider and oberon
to pascal translator a "good
solution".

Yes, sure, but I'm not propose it as a "good solution".
But if we I have no useful compiler, which translates oberon directly
to machine code, then I prefer oberon2pascal more than oberon2c for the
following reasons:
1. fpc is much more fast than gcc.
2. code produced with fpc much smaller than code produced with gcc.
3. code produced with fpc appeal kernel calls, not glibc calls, so we
stay away from glibc bugs, and it is much faster

Thanks

Norayr Chilingaryan

---
http://www.geocities.com/asprayama

[Ulrich]

Post by Stewart Greenhill

Post by noch
There are no suitable for me oberon-2 compiler for linux yet.

[...]

Post by noch
xds, oo2c.
xds doesn't do garbage collection for swapped data.
oo2c is mot useful, but it is not real compiler, just translator.

[...]

Post by noch
So, I tell you I need oberon to pascal compiler more than pascal to
oberon because if I have no suitable compiler for programming, and I am
forced to use the best available: oo2c, that just making translation
from oberon to c code. So it will be a good solution write oberon
program, translate to pascal and compile it with kylix or better
freepascal compiler.

I hope that you can see the irony in what you are suggesting. You don't
like oo2c because its "just a translator", yet you consider and oberon
to pascal translator a "good solution".
Ultimately, all compilers are just translators. They take a source
language and produce object code. Often there are many intermediate
stages; sometimes there are none.
oo2c has a higly modular internal structure, consisting of multiple
intermediate stages. The parser builds an abstract syntax tree ("AST"),
which is then converted into a SSA intermediate representation ("IR").
OOC does extensive optimisation and transformation on the IR code. This
includes data-flow analysis which allows it to pick up problems like
uninitialised objects, and unused objects at compile time. It also
allows certain "run-time" checks to be factored out at compile time,
which is important for achieving best performance for complex array and
record manipulations. The IR code is then translated to assembley
language. For portability OOC uses "C" as its assembley language, and
"gcc" as its assembler.
Alternatively, you could write your own native back-end to generate
other kinds of output from the IR code. That would cost you a large
amount of your time, and would not likely produce any benefit except
perhaps some philosophical satisfaction. Indeed, OOC includes an
experimental x86 back-end which I suspect was developed for that very
reason. If you can write a better optimizer than OOC + gcc combined then
you might gain something in terms of performance. If you have a large
team of programmers available to do this, then you can make the compiler
less dependent on external tools. But in terms of supported platforms
per programming hour you can't beat "C" output.
Really, oo2c *is* a compiler by any reasonable definition of the term.
Sure, it uses another program to generate the final object code, but
then so do many other compilers (eg. gcc).
Cheers,
Stewart

Do you think it's feasible to replace the C generating backend of OOC by a Pascal generating one?

[noch]

;)

Do you think it's feasible to replace the C generating backend of >OOC by a Pascal generating one?

I did not propose that.
I only answered to mr. Burrow's question, why I need more oberon2pascal
than pascal2oberon translator.

Norayr

[Chris Burrows]

Post by noch
;)

Do you think it's feasible to replace the C generating backend of >OOC by
a Pascal generating one?

I did not propose that.
I only answered to mr. Burrow's question, why I need more oberon2pascal
than pascal2oberon translator.

OK. It is easy to say what you don't want but what exactly *do* you want?
e.g. Would a version of BlackBox Component Pascal running natively on Linux
be the perfect solution for you?

If you let us know what task or range of tasks you are trying to achieve,
then somebody may be able to advise you what is the optimum solution for
you. e.g.

1. Do you have existing software that you want to port to a different
platform? What is it currently written it and what platform is it running
on?

2. Do you have a particular need for high-speed processing? If so in what
areas? Number-crunching? Graphics?

3. Are you writing new software from scratch and want to target more than
one platform?

4. Do you expect to have to pay any money for such development software. If
so, what is your budget?

5. Do you have any constraints for what language it is written in? If so
what are they?

etc. etc.

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[noch]

;)
Hello ;)

Post by Chris Burrows
Would a version of BlackBox Component Pascal running natively on Linux

be the perfect solution for you?

I have to look on it.

Post by Chris Burrows
OK. It is easy to say what you don't want but what exactly *do* you want?

I want oberon-2 compiler which:

1. Had standard oakwood libraries, not more, not less
2. producing native code for linux
3. Compiler and its libraries should be written completely in oberon-2
and have ability to compile itself
4. Binaries run without libc

In fact I am already writing that kind of compiler in oo2c

Norayr Chilingaryan

[Ulrich]

Post by noch
;)

Do you think it's feasible to replace the C generating backend of >OOC by a Pascal generating one?

I did not propose that.

I didn't imply that.
If you look at the sequence of related messages you'll understand that I replied to Greenhill Stewart's message.

Post by noch
I only answered to mr. Burrow's question, why I need more oberon2pascal
than pascal2oberon translator.

I understood it that way but I still think there might be 3 better ways to accomplish what you want:

1.Replace the back-end of OO2C by a Pascal generating one. Or, to re-phrase it: implement a Pascal generating back-end for OOC,
i.e. create an OO2P.

2.Get rid of the C-Lib calls which are introduced by the back-end of OO2C. I'm not sure whether that's feasible because the C
compiler be it the gcc or any other ANSI-C compliant one might automatically generate C-Lib calls for certain language
constructs which unfortunately can't be avoided.

3.Write a back-end for OOC which directly generates processor instructions. You might probably use the fpc back-end as an
example. Using this back-end to write a back-end for OOC shouldn't be too hard although you will probably need some time to
learn how the GSA representation of OOC can be mapped to the fpc back-end calls.

Anyway, if you're happy with your construction pipline stick to it!

[Stewart Greenhill]

Post by Ulrich
I understood it that way but I still think there might be 3 better ways
1.Replace the back-end of OO2C by a Pascal generating one. Or, to
re-phrase it: implement a Pascal generating back-end for OOC, i.e.
create an OO2P.

This might be possible, but it would certainly be more difficult than
implementing a C back-end. For example, oo2c represents type descriptors
using initialised C arrays and structures. This would have to be done
differently in Pascal since it lacks initialisers. Also, the emitted
code is at a very low level: oo2c maps all Oberon-2 data operations to
integer and floating-point register operations. This involves a lot of
pointer/address arithmetic, goto statements, etc. I'm not saying it
can't be done, but the result would not be pretty...

Post by Ulrich
2.Get rid of the C-Lib calls which are introduced by the back-end of
OO2C. I'm not sure whether that's feasible because the C compiler be it
the gcc or any other ANSI-C compliant one might automatically generate
C-Lib calls for certain language constructs which unfortunately can't be
avoided.

I think gcc can be configured to work independent of libc. It might be
necessary to provide alternative implementations for certain functions
(eg. startup code, exception handling). Some of OOC's standard modules
do depend on libc. For example: file I/O, timer functions, exception
handling, etc. Some of the generated code may depend on things like
memcpy, but most of these should be localised to the run-time module
RT0. I don't know what dependencies exist between the GC (OOC uses Hans
Boehm's conservative GC) and libc.

Post by Ulrich
3.Write a back-end for OOC which directly generates processor
instructions. You might probably use the fpc back-end as an example.
Using this back-end to write a back-end for OOC shouldn't be too hard
although you will probably need some time to learn how the GSA

Actually, OOC dropped GSA in favour of a flatter SSA representation in
the version 2 compiler:
http://sourceforge.net/mailarchive/message.php?msg_id=2686075

Post by Ulrich
representation of OOC can be mapped to the fpc back-end calls.

One alternative would be to use OOC's existing x86 back-end which emits
x86 assembley instructions - it might need some work to get back in sync
with the current language implementation. Alternatively, one could build
an interface between the SSA IR and some other code generator. I don't
know what the fpc back-end looks like, but it might be usable. Another
alternative would be the lcc back-end, which has a well defined
interface to the compiler.

Yet another option might be to use libtcc
(http://fabrice.bellard.free.fr/tcc/). You give it a C string containing
the program, it compiles directly to binary code, and gives access to
all defined symbols and functions. TCC is about 10 times faster than
gcc, and it includes an ELF/PE linker. I recall that someone once got
OOC working with TCC.

Cheers,
Stewart

[Ulrich]

Post by Stewart Greenhill

Post by Ulrich
I understood it that way but I still think there might be 3 better
1.Replace the back-end of OO2C by a Pascal generating one. Or, to
re-phrase it: implement a Pascal generating back-end for OOC, i.e.
create an OO2P.

This might be possible, but it would certainly be more difficult than
implementing a C back-end. For example, oo2c represents type descriptors
using initialised C arrays and structures. This would have to be done
differently in Pascal since it lacks initialisers. Also, the emitted
code is at a very low level: oo2c maps all Oberon-2 data operations to
integer and floating-point register operations. This involves a lot of
pointer/address arithmetic, goto statements, etc. I'm not saying it
can't be done, but the result would not be pretty...

This is only to avoid C. It is in fact another Oberon to Pascal translator which comes at a very high price.

Post by Stewart Greenhill

Post by Ulrich
2.Get rid of the C-Lib calls which are introduced by the back-end of
OO2C. I'm not sure whether that's feasible because the C compiler be
it the gcc or any other ANSI-C compliant one might automatically
generate C-Lib calls for certain language constructs which
unfortunately can't be avoided.

I think gcc can be configured to work independently of libc. It might be
necessary to provide alternative implementations for certain functions
(eg. startup code, exception handling). Some of OOC's standard modules
do depend on libc. For example: file I/O, timer functions, exception
handling, etc. Some of the generated code may depend on things like
memcpy, but most of these should be localised to the run-time module
RT0. I don't know what dependencies exist between the GC (OOC uses Hans
Boehm's conservative GC) and libc.

How would these alternative implementations for certain functions be implemented?
Böhm's GC intercepts the calls to malloc, free and other memory management calls. It uses the libc only for diagnostics as far
as I can see.

Post by Stewart Greenhill

Post by Ulrich
3.Write a back-end for OOC which directly generates processor
instructions. You might probably use the fpc back-end as an example.
Using this back-end to write a back-end for OOC shouldn't be too hard
although you will probably need some time to learn how the GSA

Actually, OOC dropped GSA in favour of a flatter SSA representation in
http://sourceforge.net/mailarchive/message.php?msg_id=2686075

Post by Ulrich
representation of OOC can be mapped to the fpc back-end calls.

One alternative would be to use OOC's existing x86 back-end which emits
x86 assembley instructions - it might need some work to get back in sync
with the current language implementation. Alternatively, one could build
an interface between the SSA IR and some other code generator. I don't
know what the fpc back-end looks like, but it might be usable. Another
alternative would be the lcc back-end, which has a well defined
interface to the compiler.

The gcc back-end could also be used.

Post by Stewart Greenhill
Yet another option might be to use libtcc
(http://fabrice.bellard.free.fr/tcc/). You give it a C string containing
the program, it compiles directly to binary code, and gives access to
all defined symbols and functions. TCC is about 10 times faster than
gcc, and it includes an ELF/PE linker. I recall that someone once got
OOC working with TCC.

This might be the solution which comes closest to fpc. I don't have the time to study the tcc back-end but it might also be a
good idea to use this very fast code generating back-end directly.

[Chris Burrows]

Post by Ulrich
This is only to avoid C. It is in fact another Oberon to Pascal translator
which comes at a very high price.

Just a quick note just in case there any misconceptions about the original
topic (this discussion has strayed into other areas):

The Pascal to Oberon translator I have developed is *not* intended to be
used as 'middleware' to enable Pascal programs to run on targets that
support Oberon.

It is designed to be a porting tool to be used *once only* for each Pascal
program to generate readable (well - as readable as the original that is!)
and maintainable Oberon source code without the need for any additional
translation-support libraries.

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

[Stewart Greenhill]

Post by Ulrich

Post by Stewart Greenhill
I think gcc can be configured to work independently of libc. It might
be necessary to provide alternative implementations for certain
functions (eg. startup code, exception handling). Some of OOC's
standard modules do depend on libc. For example: file I/O, timer
functions, exception handling, etc. Some of the generated code may
depend on things like memcpy, but most of these should be localised to
the run-time module RT0. I don't know what dependencies exist between
the GC (OOC uses Hans Boehm's conservative GC) and libc.

How would these alternative implementations for certain functions be implemented?

Probably in the same way that libc implements them, but that would
require writing code that is very specific to the OS (eg. doing the
required kernel calls for memory management, I/O, etc). At least for
OOC, most of the library functions are written in Oberon-2, and the
number of libc functions used is fairly small. I'm not aware of the
problems that Norayr is concerned about, so I can't comment on the
extent of the problem. I don't know of any issues for OOC.

There are a few environments where gcc runs without gnu libc.
mingw32-gcc uses Microsoft's C run-time library (msvcrtl.dll), which is
shipped on all modern Windows systems. This is my preferred environment
for running OOC under Windows. avr-gcc (for Atmel 8-bit AVR
microcontrollers) uses its own tiny libc which runs on top of the bare
hardware (ie. there is no OS). Other embedded targets proably also work
like this. One difference with avr-gcc is that the compiler needs to do
calls to its libc to implement language primitives (eg. 32-bit
arithmetic on 8-bit ALUs), so there are a heap of utility functions that
support code generation. Obviously, in this situation the compiler is
very tightly bound to its libc.

Post by Ulrich
Böhm's GC intercepts the calls to malloc, free and other memory
management calls. It uses the libc only for diagnostics as far as I can
see.

Yes, it is certainly required for diagnostics. There are lots of
dependencies on native OS functions, some of which need to be
intercepted. This includes heap and stack management, dynamic library
loading, threading, signal handling. But I think most of these are not
normally accessed through libc.

Post by Ulrich

Post by Stewart Greenhill
Yet another option might be to use libtcc
(http://fabrice.bellard.free.fr/tcc/). You give it a C string
containing the program, it compiles directly to binary code, and gives
access to all defined symbols and functions. TCC is about 10 times
faster than gcc, and it includes an ELF/PE linker. I recall that
someone once got OOC working with TCC.

This might be the solution which comes closest to fpc. I don't have the
time to study the tcc back-end but it might also be a good idea to use
this very fast code generating back-end directly.

Yes. This is left as an excercise for the reader ;-) The current system
works fine for me.

Cheers,
Stewart

[j***@yahoo.com]

Post by noch
You asking why I need to go backwards? I do not going backwords!
There are no suitable for me oberon-2 compiler for linux yet.
I am waiting for blackbox release impatiently.
xds, oo2c.

I'm not sure what you're basing this assertion on. There are System 3
and V4 Oberon systems for Linux. All Oberon systems include
(by default) a compiler and it's possible to create "stand alone"
programs with them (at least with System 3) though this is a bit
hairy.

Beyond that here's a standalone Linux Oberon-2 compiler.

http://user.cs.tu-berlin.de/~sepp/jacob/00wurzel.html

It's been available for years.

Regards,

John M. Drake