Оберон-клуб «ВЄДАsoft»

I would recommend against this way unless you are experienced with gcc internals already.

Several years ago I evaluated this way and unless things have changed very much since then gcc internals are a mess, documentation is soso and gcc is a huge and moving target not easy to handle if you have been exposed to Wirth style. gcc today uses 3 internal representations, one is SSA form; as far as I know RTL is not SSA.

Probably easier to handle is llvm (llvm.org) which has a well defined SSA intermediate language <http://llvm.org/docs/LangRef.html> which is somewhat stable over the years.

There was also a paper about generating SSA by MARC M. BRANDIS and HANSPETER MÖSSENBÖCK "Single-Pass Generation of Static Single Assignment Form for Structured Languages" which could come in handy.

>>The above mentioned documentation for OOC is not for the current
>>release 2.1.11 but for an older one 1.5.1. Anything newer must
>>be fished for ...

OOC uses GSSA and has a considerable complexity of his own. While an interesting concept I would suggest starting from scratch or using Coco to keep things easy and manageable unless you are doing this fulltime.

Greetings, Christian

When I first heard the notion of writing an Oberon compiler to generate C it did sound like a good way to leverage off all the platforms that C is
available. Unfortunately, the end result is doomed to inherit the quirky and inconsistent behaviour you can expect when develop software in C for different platforms.

Where this approach could be very useful would be as a temporary intermediate step when porting an Oberon compiler written in Oberon to a new target. That is if you wanted to develop the compiler on the target itself instead of writing a cross-compiler.

Wirth's compilers don't even generate assembler code instructions to pass onto an assembler. That extra step is thought to be unnecessary and inefficient. His compilers generate machine code instructions directly. That is why the Oberon compiler is so incredibly fast. One day I'll put a timestamp on the compiler log output - it compiles so fast that often I'm not sure that I have actually clicked on the compile button!

Regards,
Chris

I absolutely agree with Christian. If we want to have high quality and multi-target Oberon compiler under modern OS, probably exist 3 ways: GCC, LLVM and direct translation to C language.

If I had to plan this work, I would start with a study of GPCP sources (COCO/R is used for it), because Component Pascal language has several important features than clean Oberon/Oberon-2, for example, working with wide strings. And this compiler is open, and its frontend is designed rather independently from the backend.

Prof. K John Gough has plans to add LLVM support to GPCP. I believe any enthusiast could have done something for this project.

K John Gough wrote:

"I am currently exploring the possibility of a major revision that includes an LLVM-based native-code backend as well as the current .NET and JVM backends. If this goes ahead then I will definitely do full Unicode as part of the revision."

http://tech.groups.yahoo.com/group/GPCP/message/565

So we have a chance to see GPCP for ARM and x86-64. But if you need to do something today, we can only way of translation to C language. I understand that many people are confused by an extra level. And you do not confused that FreePascal and SDCC do not generate direct machine code, and assembler source code? And I've heard that C language is native assembler for UNIX/Linux.

Hi Oleg,

It's very interesting to hear from another Oberon-2 user, you're a rare bunch these days... thanks for reaching out to me.

At Bath University during my Masters one of my lecturers was a huge Oberon-2 fan, she introduced me to the language and piqued my interest enough to combine my passion with building programming languages & compilers to work on a compiler for Oberon-2.

I built the compiler to generate code for a subset of the language (although the lexer, parser and AST represented the full Oberon-2 semantics). I wrote the compiler in the D programming language using the LLVM-D bindings and re2c for the parser generator.

One of the major weaknesses of the project work, was that I didn't have time to write a language runtime for the compiler (i.e. libob2 like you'd find with libc). As a result, I cheated and made the compiler aware of libc and statically linked that to the generated executable, not ideal but I had a limited amount of time (and lots to learn about writing a language runtime...).

Unfortunately, UK universities don't share much information publicly about the projects that their students work on and usually the research is considered intellectual property of the university. In any case, since the project's completion I've had a series of laptops stolen, one of which had the source code for the compiler.

I'd considered resurrecting the project idea, and writing the compiler again from scratch (I've learnt a lot since then) but I wasn't sure anyone would be interested in an Oberon-2 compiler. With your email to me showing interest, it makes me think that it might be worth considering the idea again.

If I were to help write a compiler for Oberon-2 again I'd probably use the following technologies:

Write it in the D programming language (D code can be compiled on Windows, Linux and Mac OSX).
Use the Pegged parser generator for D.
Use the LLVM for the compiler backend (it continues to get more awesome as a code generator).
Use a build tool like Jam (or Waf) to handle cross-platform builds.

Let me know if you (and other people at the Oberon Club) would *definitely* be interested on working on this idea and I can setup a Git repository (on GitHub). I'm very busy at the moment in my new job (I work for Basho Technologies) and would not be able to be the project manager for the code repository but I'd certainly be very happy to contribute code.

Cheers,
Chris

Dear Oleg,

a LLVM backend for Oberon would certainly be a very interesting project but unfortunately we are not able to contribute any resources -- neither work nor funding.

>> did you use any automatic front-end builder, and have you CP notation
>> for it? (in EBNF, for example)

The frontend of our own compiler is handwritten. Its design is based on Régis Crelier's OP2 (ftp://ftp.inf.ethz.ch/pub/publications/ ... xx/125.pdf). If you would like to reuse parts of our code for your project, we would be willing to license it under the simplified BSD license (http://opensource.org/licenses/bsd-license.php).

We are sorry if this reply is disappointing but we are a small company and our current focus lies on other projects.

Kind regards,
Marc

Hi Oleg

Thanks for the email.

First, yes I am familiar with LLVM, it is used in another project that I am currently working on. In principle it would be possible to construct a back-end for GPCP using LLVM. This would be relatively simple given that GPCP was already designed to support multiple backends. Originally I had expected to connect GPCP to the JVM, the .NET framework, and the native-code "D-Code" backends of my 1990s Modula-2 compilers. The main obstacle was the construction of the runtime and a quality garbage collector. LLVM currently supports accurate garbage collection, so that problem is solved.

I am happy to plan to do this. However, I should warn you that I am unable to give it high priority, as I have several other projects that I am already committed to.

I will post more information when I have had time to produce a project plan.

Regards
John