Страница 1 из 1

Re: дневник русификации компилятора компонентного Паскаля

Добавлено: 21.12.18 18:23
MihalNik
БудДен писал(а):
21.12.18 17:02
Я взял ББ по той причине, что там уже есть какая-никакая среда. Люди раскручивают компилятор по спирали с нуля, а я тоже по спирали, но уже с большой высоты. Честно сказать, я очень не в восторге от многого в ББ. Но есть минимум, от которого нельзя отказаться: среда должна быть полной, т.е. должен быть динамический линкер и своя генерация в маш.код, а не генерация кодов для стороннего ассемблера. Если есть что-то проще ББ, обладающее теми же свойствами? Глагол не подходит, уже проверено. И плюс я не люблю GPL.
FASM/NASM идут вроде по BSD. С лицензией универа Иллинойса для LLVM не очень понятно. Без стороннего ассемблера сразу либо проблема с архитектурами, либо с оптимизацией. Проблемы динамической связки и генерации решаются в любом языке за счет некоторой потери производительности введением косвенного уровня.
Если есть что-то проще ББ, обладающее теми же свойствами?
Тут скорее вопрос - что лишнее, ведь оптимизации можно резать а модули сливать вместе, сам код - перестраивать.

Re: дневник русификации компилятора компонентного Паскаля

Добавлено: 21.12.18 20:15
БудДен
В ББ модули, связанные с генерацией кода - около 6000 строк на КП, а ведь он довольно рыхлый. Про линкер не знаю. Сколько строк кода занимает NASM? Сделать лишний уровень косвенности легко только на словах, а на деле это тяжело. Т.к. в КП есть уже целый набор инструментов, включая пошаговый отладчик и инспектор данных на стеке. Любое изменение влияет сразу на большое количество частей системы. При этом там линковка динамическая на уровне модулей, а модули образуют дерево, т.е. не факт, что там нужен этот уровень.

Насчёт выкидывать оптимизации - это часто означает, что код нужно переписывать. Например, компилятор хранит состояние в виде набора глобальных переменных. Вся логика вывернута так, что разные логические этапы чередуются по времени. Зато можно сказать "ошибка здесь", не говоря конкретно, в каком месте, это будет "ошибка в текущем месте". Мы можем переделать это, храня эту инфу о месте в узлах дерева (так делает SBCL и думаю, что большинство навороченных компиляторов так делают, потому что иначе сложность создания компилятора становится неимоверной из-за сильной связанности этапов), но это потребует изменений в тысячах мест, и тут легко накосячить.

Пока что ощущение такое, что компилятор в основном подлежит переписыванию. Основные модули (не считая тривиального лексера):

Д - 2300 строк
Использование - 300
Парсер - 1800
ФС - 1700

Не так уж и много. В хоббийном режиме, думаю, за полгода можно управиться в одно лицо.

Re: дневник русификации компилятора компонентного Паскаля

Добавлено: 23.12.18 01:40
БудДен
Не совсем про русификацию. Вчера наконец-то сделал отдельный режим для КП в VS Code, потому что раньше была только инструкция о том, как пропатчить режим Паскаля. Проблема в том, что Паскаль обновляется и изменения затираются.

Сегодня попытался провентилировать вопрос о том, можно ли сделать нормальную интеграцию VS Code с КП, позволяющую совершать действия в запущенном экземпляре КП из VS Code. Т.е. то, что делает SLIME для лиспа. На этом строятся основные удобства в динамических средах, т.е. автодополнение, переход к определению и проч.

В примерах есть довольно клиент и сервер. Вроде удалось написать код, к-рый берёт строку и выполняет соотв. команду, теперь нужно сделать более прилично по аналогии с DevCommanders.Execute (там есть обработка ошибок с помощью ловца исключений).

Re: дневник русификации компилятора компонентного Паскаля

Добавлено: 27.12.18 20:37
БудДен
Одно цепляется за другое, стек задач растёт. Решил потихоньку ползти в сторону более полноценной поддержки VS Code. Для этого нужен сокет-сервер. Сокет сервер реализован ужасно в стиле 70-х, т.е. операции со списками вписаны прямо в тело функций. Такое г. не для нас. Пришлось немного поподбирать библиотеки контейнеров. Подходящей под вкус не нашёл, но получилось пока вот что https://gitlab.com/budden/nkp/blob/mast ... Страниц.kp

Для таких вещей сам Бог велел писать модульные тесты. Но нет фреймворка. Теперь делаю фреймворк. Позавчера-вчера решил задачу перехвата исключений - поскольку некоторые тесты должны быть тестами о том, что падает ASSERT, а падение ASSERT по умолчанию показывает стек и дальше пользователь должен нажать на кнопочку. Понадобился способ перехвата этой ситуации, и я его нашё.

Сегодня решил задачу "как по указателю на процедуру достать из метаданных имя этой процедуры". Теперь каждый тест можно делать функцией без параметров - фреймворк получится достаточно лёгкий в использовании.

Осталось в этом направлении сделать достаточно немного, но теперь пора и поработать.

Помимо этого, расшифровал TProc, IProc, XProc и прочие абракадабры.

Re: дневник русификации компилятора компонентного Паскаля

Добавлено: 02.01.19 01:00
БудДен
Доделал расшифровку "частей речи", везде их прописал, в т.ч. в модуле Проводник, в котором они, сцуко, были названы по-другому. Также нашёл аналогичное понятие для генератора кода и назвал низкоуровневое поле по-другому. Т.е. теперь два близких по смыслу, но разных поля и называются по-разному. Это не так тривиально, т.к. слово mode в исходниках компилятора встречается около 700 раз - удалось разбить на частные случаи. Все эти 700 всё равно пришлось просмотреть, но в облегчённой форме.

Re: дневник перевода компилятора Оберона КП на русский язык

Добавлено: 04.01.19 01:37
БудДен
Массово поменял терминологию, и после этого понял кое-что о принципах именования вещей, принятых в существующем Обероне КП. Когда чукча-писатель, то это обычно до добра не доводит.

Подбешивает меня уже этот Оберон. После лиспа это выглядит как пересадка с мерседеса на тачку, которую нужно руками толкать. Но ничего, ещё потерпим. Хотя, честно сказать, уже погуглил «Lisp bare metal».

Re: дневник перевода компилятора Оберона КП на русский язык

Добавлено: 04.01.19 17:35
atz
КП настолько ужасен
Бгг... А как же хвалёное лисповое метапрограммирование? Неужели оно не обеспечивает решения требуемых задач? Ведь оно так везде расхваливается, как будто можно используюя такие инструменты ОС с нуля за неделю сделать =)

Re: дневник перевода компилятора Оберона КП на русский язык

Добавлено: 04.01.19 19:49
БудДен
В контексте лиспа - да, лисповые макросы очень мощны. Если их применять отдельно, то преимущества их весьма спорны без мощной инструментальной поддержки. Даже в лиспе с помощью макросов код легко сделать непостижимым, а в другом языке - и подавно.

Re: дневник перевода компилятора Оберона КП на русский язык

Добавлено: 05.01.19 01:51
БудДен
Переведено примерно за 2 месяца 17% названий процедур компилятора. Плюс к тому переведено ещё много другого, но не так просто посчитать.

Re: дневник перевода компилятора Оберона КП на русский язык

Добавлено: 15.01.19 18:06
БудДен
Проект остановлен, скорее всего навсегда. Оберон КП отныне снова называется «компонентным Паскалем», т.к. раз интереса к предмету нет, то нечего и придумывать для него названия. Причина в том, что система Bluebottle выглядит по многим направлениям более интересной.