ACNews #66

Новости - занимаюсь компилятором NedoLang, AmoNik измерил потребление разных устройств

                            Новости
                        by Alone Coder

Сейчас я в основном занимаюсь компилятором NedoLang.

Основную часть программы (10 модулей - раньше было больше из-за
заголовочных файлов), которая непосредственно компилирует, я уже
перевёл на язык NedoLang, модуль за модулем. В язык для этого
пришлось добавить обороты для импорта констант, переменных и
функций (заголовочные файлы и#include не используются). Но это
всё ещё не конечный вариант языка, потому что NedoAsm пока
перевести на этот язык нельзя - сказывается отсутствие оператора
switch и дефайнов (можно было бы обойтись перечислениями вместо
них, но перечислений тоже пока нет). Тем не менее, уже можно
подвести некоторую статистику после 6 месяцев проекта:

- 346 КБ исходников, не считая GUI. Из них 191 КБ - сам
компилятор (выдаёт ассемблерный текст). Остальное - токенизатор
ассемблера, экспортёр ассемблера (детокенизатор) и сам
ассемблер.

- при отключенных комментариях выходной ассемблерный текст
компилятора (который был 191 КБ) получился 500 КБ. Во время
компиляции самого большого модуля используется 11 КБ памяти под
метки (раньше было выделено 10 КБ под это дело, теперь не
хватает).

- из этого ассемблерного текста получился бинарник на 57 КБ
(включая буфер памяти под метки и другие буфера). Во время
ассемблирования используется порядка 60 КБ под метки (я выделил
128 КБ на всякий случай, потому что ассемблер играет роль
линкера и должен знать все метки всех модулей).

Такое пока не имеет смысла релизить. Стоит прикрутить работу с
файлами и экраном, как компилятор вывалится из адресного
пространства, а ассемблер уже вывалился. А сколько нужно дискет
для самокомпиляции... одновременно три?

Можно работать в нескольких направлениях:

- оптимизировать исходник компилятора (например, сократить
текстовые сообщения, которых слишком много);
- улучшить кодогенерацию (хотя бы аллокатор регистров);
- сделать поддержку far calls, чтобы можно было писать сколько
угодно кода;
- сделать поддержку far pointers, чтобы можно было выделить
сколько угодно памяти;
- во время ассемблирования каким-то образом выкидывать из
таблицы локальные метки;
- ассемблировать тоже по частям и добавить в систему линкер;
- стримить ассемблерный текст, чтобы он не занимал место на
диске. Для этого придётся буферизировать в памяти содержимое
переменных и констант. Сейчас оно просто генерируется
параллельно в другой ассемблерный файл. И тогда будет нельзя
компилировать программу по частям (нужно ли это - вот как раз
узнаем, когда измерим скорость компиляции).

Неизвестно, сколько времени займёт каждая из этих работ. Были
другие предложения - например, делать оверлеи (предложил
deathsoft, который насчитал вручную уже порядка 4000
транзисторов в ВГшке, они ещё сLord Vader'ом в трёх разных
компиляторах Си накопали косяков в NedoLang ). Но я не хочу
завязывать систему на постоянную подгрузку оверлеев. Желательно
всю систему (редактор, компилятор, ассемблер и запускаемая
программа) держать одновременно в памяти. Для этого, конечно,
необходима поддержка на уровне операционной системы.

Хотелось бы пораньше суметь запустить самокомпиляцию, чтобы хотя
бы знать, какие места компилятора оптимилировать по скорости. Я
даже пока не знаю, какая вообще будет скорость. Судя по размеру
ассемблерного файла, в существующем виде - явно больше минуты на
3.5 МГц. А хотелось бы не выходить за пределы минуты.

Возможно, выгоднее интегрировать ассемблер в компилятор.
Конечно, встроенный ассемблер не будет таким же быстрым, как
специализированный (который ассемблирует из токенизированного
текста). Но будущий сценарий работы с NedoLang предполагает
прототипирование программы на языке высокого уровня, потом
постепенный перевод самых тормозных процедур на ассемблер. А все
процедуры переводить нет смысла. С другой стороны, кто-то может
захотеть писать сразу на ассемблере.

Можно в качестве компромисса встроить в NedoLang токенизатор,
так что на выходе получится токенизированный ассемблерный текст.
Для этого придётся прибавить к тем 191 КБ ещё 98 КБ исходников,
что в существующий бинарник не поместится.

Или третий вариант, самый удобный для пользователя, но самый
сложный в реализации - переписать ассемблер таким образом, что
он сможет компилироваться и в составе компилятора (т.е. бинарник
компилятора распухнет вдвое), и раздельно. Но нужна возможность
выгружать ассемблерный текст.

Есть, конечно, вариант урезать язык до состояния какого-нибудь
Pseudo-C, где один оператор цикла, два типа, нет параметров 
функций, модульности и т.п. Но тогда им будет невозможно
пользоваться для настоящих задач.

В запасе ещё всегда остаётся вариант перевести компилятор на
язык ассемблера, но тогда будущая поддержка среды разработки
явно осложнится. Поживём - увидим. Может, и так скорости хватит.
Особенно если реализовать компиляцию в фоновом режиме :)

                            * * *

В этот раз не смог зайти ни кJohn'у, ни на киностудию на общее
собрание (точнее, один раз на студию мы сLouis'ой ходили, но
попали не на занятия, а на игру "Что-где-когда").John говорит,
что пишет музон. В основном он ремонтирует компьютеры.

Пока я верстал этот номер, у меня как раз сломался пц - сначала
сошла с ума клавиатура, потом что-то щёлкнуло, комп завис, а
потом вообще перестал включаться. А мышку ещё раньше заиграла
Даша. Осталась пара ноутбуков. И это в тот момент, когда ко мне
обратилсяWanderer (автор игр MURKЗЗ20, MURKЗЗ27 ) на тему
скопировать спектрумовские дискеты с исходником недописанной
игры. Придётся кому-то другому копировать. Внезапно осознал, что
у меня все рабочие компьютеры как минимум 6-летней давности. В
каком-нибудь 2000 году такую ситуацию было трудно было себе
представить, в том числе на Спектруме...

Есть намётки ещё на музыку от других авторов, статьи для журнала
тоже пишутся. Нет только графики.
Очень можно материала прислалAmoNik - старые архивы, эхи,
воспоминания.

Между деломAmoNik измерил потребление разных устройств (видел
сегодня споры в интернете по этому поводу) - это в отдельной
статье. Ещё он доработал драйвер IDE под iS-DOS, который в
1999 году делалОлег Григорьев. Проблема у него была такая же -
не работает с современными устройствами. Вернее, конкретно с его
картой памяти, которая вообще не возвращает координаты сектора в
регистрах.

Передаю ему слово:

┌──────────────────────────────────────────────────────────────┐
Оригинальный драйвер попал ко мне в виде архиваSMUC.ZIPв 
середине двухтысячных напрямую от его автора -Олега Григорьева.
Олег написал быстрый и компактный драйвер, но не дописал для
него настройщик, сказав, что iS-DOS разделов на диске у него 
немного и он их просто прописал все прямо в тело драйвера перед 
его компиляцией. Насколько я понял,Олегвзял за основу драйвер 
Валерия Кожевникова и немного его переделал. После этой
переделки драйвер стал короче и логичнее. 

В 2006-м году я сделал из него LBA-версию, но по какой-то 
причине новый драйвер не прошёл тестирования и я на некоторое 
время забыл про него. В 2017-м году я чистил папкуTEMPна 
системном диске от отладочных версий программ и наткнулся на 
этот драйвер в папкеNOTWORK.ING.Никаких заметок по этому 
поводу в тексте я не нашёл. Поэтому было непонятно, что именно 
не работает. На всякий случай я скомпилировал драйвер и проверил 
его работу на тестовом разделе диска - и драйвер полностью 
прошёл тесты на чтение, но провалил их во время записи. 

Я перетащил драйвер в ALASM и набросал набор тестовых процедур. 
Посидев немного за отладкой я нашёл и исправил тот фрагмент, 
который не работает на современных устройствах. Потом переделал 
подключалку разделов к драйверу, взяв за основу HDDLSERV, и 
после этого провёл всестороннее тестирование драйвера, путём 
копирования своего системного диска размером 8 Мб на тестовый 
раздел устройств MASTER и SLAVE. Проверив контрольные суммы 
файлов на копии я убедился, что драйвер работает. 

Как обычно, драйвер требует постоянно открытых портов SMUC IDE и 
работает в версиях iS-DOS Classic и Chic. Я думаю, что имеет 
смысл переходить на новый драйвер, так как он заметно короче (на 
230 байт) моего HDDLSMUC. На всякий случай я сделал 
универсальную подключалку дисков к драйверу и назвал ей 
HDUNISRV. Эта программа умеет работать как с HDDLSMUC, так и с 
RHDDLBA. Имя драйвера задаётся в виде параметра в командной 
строке. Например: 
hdunisrv Rhddlba - подключит диски к драйверу Rhddlba.

Также выкладываю авторский архивОлега Григорьева.Там несколько 
версий его драйвера, какие-то зачатки утилиты для настройки и 
тестовые процедуры. Может быть, кому-то покажется это 
интересным.