OSDev

После длительного перерыва, вызванного частью объективными (загрузка по работе), частью субъективными (отвлечение на ковыряние с железом, а больше -- лень-матушка, мать её :))) ) причинами вернулся-таки к написанию своего ассемблера. Когда последний раз им занимался, в нём было порядка 1500 строк, но ничего путного делать он ещё не делал. Пока он продолжает делать то же самое, но вчерне закончил модуль вывода листинга. Вчерне, поскольку он ещё не отлаживался (ведь пока нет собственно транслятора), да и его функции, возможно, со временем будут несколько изменены. Нынешняя длина исходников во всех модулях -- ровно 1850 строк, из них на модуль листинга приходится 647. В своей вике (локальной на своём компе) описал все публичные типы, переменные и процедуры-функции модуля листинга, а то ведь сам через месяц всё забуду, хотя их объявления и снабжены комментариями :)

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

Не прошло и четырёх месяцев, как опять добрался до асма. Собсно, переработал ранее сделанное, кой-что более тщательно откомментировал, переделал-таки разбор командной строки и загрузку параметров из конфигфайлов. Получилось 2150 строк (довольно много из них занимают комменты и пустые строки -- в общем, благоукрашательства). Кроме того, перешёл на Дельфи 2009: в языке несколько приятных и полезных изменений.

Теперь можно заняться собственно трансляцией. Правда, опять прибежала работа...

ИМХО, новые версии IDE Delphi слишком жирные. Почему не тот же фрипаскаль?

В нормальной ИДЕ и писать, и отлаживать куда удобнее. У фрипаскаля же его "ИДЕ", смахивающая на старый Турбо Паскаль, не только сильно проигрывает по функциональности дельфозной (в таких задачах, как асм, это не слишком заметно, ведь это не гуй-приложение), но и откровенно глючная. Ну а нафиг мне лишние глюки? Что же касается Лазаруса, то это -- жалкое подобие ранних версий Дельфи, кривое и не шибко удобное. Развращён я удобствами ;)

2009 непробовал. Но раз нато пошло то дельфи призм с visual ide мне видиться интересным решением.

Ну, ИДЕ в 2009 осталась в целом такой же, как в 2006, только кой-какие баги исправили и кой-что улучшили. Главные совершенствования -- в самом языке. Наконец-то ввели Exit(возвращаемое-значение) -- вроде и мелочь, а очень приятно; появился тип UnicodeString, позволяющий обращаться к символам внутри строки как к элементам массива (имевшийся уже в 2006 AnsiString трактует индексы как номера байтов, а не символов, со всеми вытекающими, а WideString ущербный: не поддерживает суррогатные пары); разрешили переопределять операторы и для классов, а не только для записей (в 2006 для классов можно было только под .NET, но не Win32); ввели генерики -- упрощённую версию шаблонов (правда, довольно криво -- в некоторых случаях компилятор сообщает, что обнаружил в своём нутре ошибку; кроме того, проблемы со сравнением значений, чьи типы определяются как параметры шаблона: не действуют никакие операции, кроме равно и не равно, и их приходится делать через большую задницу -- пример в RTL имеется); ещё что-то там улучшили и дополнили. Но в целом я всё ж убедился: хочешь нормальный компилятор Паскаля -- делай сам. Во всяком случае, у фрипаскаля своих заскоков хватает.

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