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

Твердыня модульных языков
Текущее время: 28 мар 2024, 10:50

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




Начать новую тему Ответить на тему  [ Сообщений: 13 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 12 сен 2015, 12:56 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Публикую с разрешения.
Đặng Minh Công писал(а):
Thank you for your interest.

I am also following your XDev project with great interest. In my opinion, it has clearly displayed the viability and benefits of the Oberon/Component Pascal family on many platforms, just like the Astrobe compiler of Mr. Chris Burrows. As for my compiler, I didn't intend to make it a full-fledged development tool, but only a demonstration of concept. For many years, I have been searching for a way to cure the bloatware disease that had plagued the whole IT industry all over the world, and now I has found the solution of Niklaus Wirth. So I has written this compiler as a mean of verifying the teachings of Niklaus Wirth.

About myself, my name is Đặng Minh Công and I am Vietnamese. I am just an Informatics (or Computer Science, according to the Anglo-American) student at UET, Hanoi National University of Vietnam. I think it is not a coincident that the Wirthian languages have more followers in Russia and other SNG states than in Western world and Asia. My parents had studied Cybernetics in the Soviet Union during the 70s and I somehow inherited their viewpoints on scientific methods (I was also born in Moscow, but only stayed there for 1 years, so I didn't have the chance to learn the Russian language. I have always wanted to learn Russian, but didn't have time). I believe the Soviet mindset was one of the reason that draw us to Oberon.

In my opinion, the bloatware crisis in IT industry is not origin from the IT industry itself, but has the root in society and the economy. Since 1970s, a neo-liberalism craze had swept all over the world, not even the Soviet Union and the USA were immune from it. Coincidence with it, in the next decades, was the rise of C, UNIX, badly-designed technologies and bloatware. The blame lies on the private enterprises, with their never-ending thirst for profit, they will do anything to compromise the product's quality, in order to raise their profit rate. Many recent airplane accidents were examples of that. And the universities, where many people came to learn and research knowledge, became a place that churned out cheap workforce for the corporations. Until those problems be addressed, I think people who value simplicity and clarity like Niklaus Wirth and us will remain a minority :(

Sorry for my ranting.

Regards,
Đặng Minh Công


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 12 сен 2015, 15:36 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Đặng Minh Công писал(а):
Your article on ZXDev is excellent and here is some suggestions of mine:

Your choice of generating C code instead of native assembly code is totally right. I don't know much about ZX platform but I bet it is a computer architecture belong to 8-bit/16-bit era, and therefore, the need of optimized code is totally necessary. The C compiler had done all the jobs for us, so we don't need to reinvent the wheel. Moreover, interfacing with existing C libraries will be trivial. However, the usage of C language will greatly "simplify" the code generator, and therefore, the compiler writer will be tempted for introducing more "sophisticated extensions". It is a dangerous trap we will need to avoid of. Take a look at vladfolts Oberon-7 compiler, because his compiler generates JavaScript code, he has the freedom to introduce many extensions into Oberon language. In my opinion, many extensions of his are excessive.

As for the problem of unsigned integer, I must say that your tricks are impressive. But in long term, I think you must introduce proper unsigned types. Prof. Wirth had his reason for not using unsigned types, because he is working on machines with several megabytes of memory (and now, several gigabytes). I still remember the days of Turbo Pascal, when the 16-bit INTEGER was too small to do any serious computation.

As for const array extensions, I have a mixed feeling about it. My suggestion is to make a separated CONSTDATA section, so that the syntax of CONST section will be the same as in other Oberon dialects:

Код: "OBERON"
  1. CONST ...
  2. TYPE ...
  3. VAR ...
  4. CONSTDATA ...

About my compiler, I am planning to not making any new features or structural changes, instead, I will focus on bug fixing and making applications with my compiler. By doing that, I can evaluate my compiler quality and the viability of Oberon-07 language.
I think this paper has nailed down the benefits of simplicity: http://smirt23.uk/attachments/SMiRT-23_Paper_103.pdf. With a simple solution, we can quickly apply it in many problems, and therefore, can quickly see its strong and weak points, and then improve it further.

As for permission to publish, feel free to do anything with it. I am not a greedy capitalist, so the idea of "protecting my ideas" and "privacy" are alienated to me Emoji

The filling of the Earth with "garbaged" goods is nothing new, but as a traditional mean to keep the Third World countries stayed in their places. But there is a new dangerous trend, which is the bankruptcy of the old developed countries, for example, Ukraine and Greece. From First World countries in the past, they now become Third World countries. It means that the whole World is declining, just like the collapse of Roman Empire in the past. I afraid that we have to experience a short era of barbarism, with those Neo-Nazi and ISIS are clear examples.

Regards,
Đặng Minh Công


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 13 сен 2015, 15:30 
Не в сети
Администратор
Аватара пользователя

Сообщения: 189
Фига се чувак жжот :D
Свой пацан в доску...

Из предложений. CASE как pointer оч удобная штука, но хотелось бы и простого, старого, доброго:
Код: "OBERON"
  1. CASE C OF
  2. 'a'..'z': |
  3. 'A'..'Z':
  4. END;

Ну и обходиться без FORWARD объявлений, как в AO!!!

Кстати я его компилятор тестирую тоже, так что если что, с багами помогу...
Ну и хотелось бы конечно без DLL, одним файлом... Что бы потом под платформы всякие попробывать!


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 17 сен 2015, 18:46 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
S.Atan писал(а):
Фига се чувак жжот :D
Свой пацан в доску...
Вот! Как раз для того, чтобы все это узнали, я и постю его письма. :) В частности, важно что цель создания Aya — не получение компилятора промышленного уровня, а просто тестирование идей Вирта. Так что насколько далеко он шагнёт — будет зависеть не только от автора.

S.Atan писал(а):
Ну и обходиться без FORWARD объявлений, как в AO!!!
Это уже к вопросу сколько у компилятора проходов. :) Вирт решил не заморачиваться, походу.

S.Atan писал(а):
Кстати я его компилятор тестирую тоже, так что если что, с багами помогу...
Ну и хотелось бы конечно без DLL, одним файлом... Что бы потом под платформы всякие попробывать!
Я передам Минь Цуну. Он может (если захочет) сделать как в BlackBox и ETH Oberon — свой формат кодовых файлов (вместо dll), снабжённый загрузчиком. И отдельный линкер.

В любом случае, компилятор — как бы промежуточный продукт, он будет вертеться только на машине разработчика. Но конечный продукт (для винды там или линукса) уже будет непосредственно у юзера, и зачем ему такой dll hell... так что предложение поддерживаю. Но не исключено, что Минь Цун выбрал решение генерировать dll ради простоты.

Помощь конечно любая приветствуется. Библиотеки нужно писать, опять же. Также можно было бы на основе этого компилятора сделать версию для генерации 32-битного кода. Или, например, для линукса. Серж, ты главное компилятор на Дельфи не переписывай. ;) Я серьёзно.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 17 сен 2015, 19:27 
Не в сети
Администратор
Аватара пользователя

Сообщения: 189
Так я не переписываю. Delphi уже не катит. FreePascal - вот тема.
Уже переписал на FPC :D отлаживаю по малень. Утечки убрал!!!
Вот пример новой студии...


Вложения:
Ide.part2.rar [262.67 КБ]
Скачиваний: 443
Ide.part1.rar [537.11 КБ]
Скачиваний: 441
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 17 сен 2015, 20:17 
Не в сети
Администратор
Аватара пользователя

Сообщения: 273
Откуда: Россия
Đặng Minh Công писал(а):
My suggestion is to make a separated CONSTDATA section, so that the syntax of CONST section will be the same as in other Oberon dialects:

Код: "OBERON"
  1. CONST ...
  2. TYPE ...
  3. VAR ...
  4. CONSTDATA ...
В задании отдельной секции свой резон есть. Константные массивы по своей природе действительно отличаются от константы-числа или строки. И эта разница была проиллюстрирована (уже исправленным) багом SDCC, например.

Но с другой стороны, стоит ли ради этого вводить новое ключевое слово? По-моему, это больший отход от простоты, чем смешение скалярных и структурных констант в одной секции.

Синтаксис через "ТИП( список элементов)" достаточно нагляден, а семантика ближе к "настоящим" константам, чем у типизированных констант Турбопаскаля\Дельфи. Кроме того, если понадобится, можно создать инструментальное средство, чтобы выделить такие отличия от Оберон-ядра.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 18 сен 2015, 03:39 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Серж, ты неисправим! :shock:

Олежек, твой комментарий переведу и отправлю Минь Цуну. Добавлю, что с тобой полностью согласен — мне тоже синтаксис "ТИП (список элементов)" нравится больше, чем новое ключевое слово и отдельная секция. Заметь, Минь Цун советует вводить беззнаковые типы. А вопрос нужны ли константные массивы даже не возник. Хотя он сам расширения не очень-то жалует, наверно ещё мало писал на Обероне-07. ;)


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 18 сен 2015, 10:14 
Не в сети
Администратор
Аватара пользователя

Сообщения: 189
Ну... У каждого свои цели...
У меня не переписать тупо (как раньше лишь бы было), теперь методично использую трейсер...
Смотрю как работают сборщики мусора, вообще логика компилятора...
Да и не только...
Вот тот же Минь Цун... Зачем то переписывал оберон из Project Oberon на FPC, потом на GCPC, потом на самом себе, потом...ну не важно.
У каждого свои цели. Ты вот пишешь для спека, хотя сейчас эмуляторы на тех же планшетах работают быстрее и позволяют больше.
Но ты же пишешь никому не нужный код (для удовольствия). Так же и я пишу для удовольствия.
Причем по ходу движения тестирую полученое... Помогаю так сказать ловить баги.
Вот к стати компилятор Николая Вальтеровича, в трейсинге работает правильно... Без заморочек...
А переписать его - 3 часа работы (в принципе, даже что бы получить банально интерпретатор).
Вот парни мучаются с плагинами для того, для этого... У Вирта это все есть (и в теории и на практике). А так как я СРАВНИВАЮ, мне приходится переписывать под инструмент в котором есть хотя бы простейший трейсер. Ну и кроссплатформенный к тому же ;)


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 18 сен 2015, 20:58 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Серж, с тем, что у каждого свои цели — абсолютно согласен. Я не только пишу для Спека, но и изучаю на себе же фактор ностальгии (или же "тёплых ламповых чувств" и привязок) как сильное средство внутренней мотивации. Плюс пробую на практике кроссплатформенность Оберон-технологий на очень ограниченной по аппаратным возможностям платформе. Ещё меня интересует вопрос: каким может быть представление программы, чтобы автоматически разворачивать (проецировать) его на различные платформы. Такие разработки есть и у мэйн-стрима, но они слишком ресурсоёмкие и обладают другими недостатками.

Трейсер — чрезвычайно полезный инструмент для разбора логики чужого кода (иногда своего ;) ). Но, кстати, ты мог бы не вручную переписывать Aya с Оберона на Паскаль, а автоматически оттранслировать его в Си (например, с помощью XDev) и иметь возможность лазить по нему трейсером, существующим в сишных окружениях. Но это твой выбор. :) Я тебе XDev не навязываю.

Минь Цун взял FPC и пробовал разрабатывать Aya сначала на нём, но разочаровался (он об этом пишет), к тому же он предпочитает более простые инструменты. Миграция же с GPCP на самого себя — это самораскрутка компилятора, практикуемая штука. Уверен, что Минь Цун считает, что теперь уж Aya написана на самом правильном языке и переписывать не нужно. :)

Олежек , кстати Минь Цун при всём нежелании расширений ввёл в свой компилятор типы INT8, INT16, INT32, CARD16, CARD32. Интересно, как он решает проблемы, с которыми столкнулись мы при попытках ввести беззнаковые типы в Ofront?

Đặng Minh Công писал(а):
INT8, INT16, INT32, CARD16, CARD32 types

Reason for introducing: Same as BYTE type, in order to economise the use of memory.

Note: Type inclusion is not the same as in Oberon-2/Component Pascal. All the integer types: BYTE, INT8, CARD16, INT16, CARD32, INT32 and INTEGER are interchangable. All integer variables when loaded to register are signed extended to 64-bit INTEGER type. All integer calculation results are 64-bit INTEGER. That means BYTE + BYTE = INTEGER. Therefore, there is no speed benefit for using small integer types over INTEGER type. The programmer should use only INTEGER type for most of cases, which is good programming practice.

Note: There is no range checking in assignments between integer types!

Note: The 64-bit CARDINAL is not introduced, because 64-bit INTEGER is big enough, and also because of you cannot loselessly convert CARDINAL to INTEGER.

Гм-м, смотрю: у него тут и UNION есть в интерфейсах... Это то, что я так и не сделал в XDev, а в BlackBox'е есть.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Đặng Minh Công, the author of AyaCompiler
СообщениеДобавлено: 18 сен 2015, 21:11 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Ага, оказывается введение целой линейки типов — реверанс в сторону виндоус, как пишет Минь Цун:
Đặng Minh Công писал(а):
And for interfacing with Win32 API, I had to introduce typed-ADDRESS types and multiple INTEGER types into Oberon language, a step back to Modula-2 era.
"Куча целых типов — шаг назад к Модуле-2", вот как.

Остаётся открытым вопрос — вводить ли беззнаковые типы в Ofront на уровне языка. По моим ощущениям: разве что для разработки под Z80, но я легко обхожусь и без них. Так что наверное всё-таки нет...

А на уровне библиотек — конечно вводить. Я видел библиотеку Word для Модулы-3, как раз для беззнаковых, и довольно-таки элегантно смотрится.


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

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


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club