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

Твердыня модульных языков
Текущее время: 05 дек 2023, 06:35

Часовой пояс: UTC + 2 часа

Начать новую тему Ответить на тему  [ Сообщений: 2 ] 
Автор Сообщение
 Заголовок сообщения: Компонентный Паскаль и LLVM
СообщениеДобавлено: 21 дек 2012, 20:58 
Не в сети
Аватара пользователя

Сообщения: 1014
Откуда: Днепропетровская обл.
В рассылке ETH поднята тема о stand-alone компиляторах и средствах разработки на Оберон-языках, непривязанных к Оберон-системам. Вот что думают об этом некоторые оберонщики.
Christian писал(а):
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

Крис Барроуз, как и проф. Вирт против лишних промежуточных уровней типа языка Си, и настаивает на прямой компиляции:
Chris Burrows писал(а):
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!


Всё же складывается ситуация, что надо выбирать один из трёх путей, которые кажутся наиболее подходящими.
Oleg N. Cher писал(а):
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."


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.

Вернуться к началу
Ответить с цитатой  
 Заголовок сообщения: Re: Компонентный Паскаль и LLVM
СообщениеДобавлено: 21 дек 2012, 21:21 
Не в сети
Аватара пользователя

Сообщения: 1014
Откуда: Днепропетровская обл.
А для полноты картины, чтобы было понятно куда шагает Компонентный Паскаль или куда он может шагнуть, думаю, небезынтересны и следующие письма по этой теме.
Chris Molozian писал(а):
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.


А вот что пишут по этому поводу люди, которые вполне ощутимо могли бы повлиять на ситуацию с языком КП.
Marc Frei писал(а):
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,

K John Gough писал(а):
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.


У меня самого есть некоторые идеи для мультиплатформенного компилятора КП. Например, сделать поддержку прямого включения сишных интерфейсов *.h в свои проекты на Обероне. У языка Оберон (и, как видим, у языка D) сейчас наблюдается проблема с использованием готовых сишных библиотек — даже если к ним есть готовые биндинги, они устаревают с выходом новых версий библиотек. Чтобы не гнаться за Си и не актуализировать постоянно биндинги, чтобы не отставать от Си, чтобы не использовать полуавтоматических утилит типа H2O и иметь возможность всегда воспользоваться готовыми наработками на Си, очень хорошо бы применять прямое включение *.h в свои проекты (конечно же с ослаблением строгости безопасности и типизации при обращении к таким "модулям", в духе Си). На эту мысль меня навела многочасовая работа над биндингами к SDL.

Вернуться к началу
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 2 ] 

Часовой пояс: UTC + 2 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club