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

Так и сделано


[ccall], [noalign], ... -- такое же расширение, как и DISPOSE, WCHAR.



По поводу SYSTEM.
Нижние 512 байт адресного пространства (0H-01FFH) занимают регистры специальных функций и регистры 8- и 16-битной периферии.
Сейчас, обращение к ним осуществляется через SYSTEM.GET/SYSTEM.PUT. Это просто, универсально, но выглядит некрасиво.
Возможные решения:

- использовать переменную-указатель

недостатки: длинная запись, т. к. нет указателей на массивы; обращение к устройствам по индексу в массиве, а не по адресу; кроме того, компилятор будет вставлять ненужную проверку на NIL (но это можно отключить).

- сделать возможным указать адрес переменной при объявлении


Второй вариант выглядит лучше и должен быть эффективнее и компактнее.

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

Если нужен обобщённый механизм, то всё равно лучше использовать процедуры
И пусть всё будет эффективно за счёт псевдомодульности или иных, менее хардкодных способов оптимизации

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

Абстракции же не обязаны отнимать дополнительные ресурсы во время исполнения программы.

Я переписал RTL (MSP430) в машинных кодах и встроил его в компилятор, так, чтобы в прошивку добавлялись только те процедуры RTL, которые используются. Это позволило снизить минимально допустимый размер ПЗУ до 2048 байт, а также значительно увеличило производительность для некоторых операций. В процессе переписывания, выяснилось, что рукописный машинный код получается в 2-3 раза меньше и в 2-4 раза быстрее. Впрочем, я ожидал получить результат еще хуже. Компилятор всё же написан не для хорошей кодогенерации, а для быстрого добавления бэк-эндов. Кое-что в кодогенерации еще можно улучшить, ну а пока, если я ничего не забыл, для простых экспериментов уже подходит.

Почему бы не маркировать используемые процедуры? Все равно используется IL, а не прямая генерация, можно без проблем дропать неиспользуемое.

Для пользовательских процедур так и сделано. Фронт-энд, перед передачей промежуточного кода в бэк-энд, удаляет неиспользуемые процедуры. Но для RTL все намного сложнее. Фронт-энд знает только имена процедур, но не знает об их назначении. Например, если фронт-энд встречает операцию целочисленного умножения, то он генерирует команду MUL промежуточного кода. Бэк-энд, встречая команду MUL, если это x86, транслирует ее в машинную команду imul, а если это MSP430 - в вызов процедуры RTL._mul. Таким образом, фронт-энд не знает, какая операция потребует вызов RTL-процедуры (и не должен знать). Бэк-энд получает линейный список команд промежуточного кода и не имеет информации об использовании процедур (RTL-процедура может вызвать другую RTL-процедуру или вспомогательную). Поэтому модуль RTL всегда добавляется в результирующий файл полностью. Фронт-энд считает, что все процедуры RTL._* используются. Для больших машин, удалять неиспользуемые части RTL не нужно: размер RTL для x86(64) < 10 кб. А для контроллеров лучше встроить RTL в бэк-энд и, тем самым, сэкономить байты и такты без усложнения компилятора. Сложно, разве что, программировать в маш. кодах, но для MSP430 это оказалось сравнительно просто.

Сделал бэк-энд для микроконтроллеров STM32 Cortex-M3. Пока качество машинного кода оставляет желать лучшего (сравнение с компилятором Александра Ширяева показало 70-90% производительности), но вроде всё работает. Хотя компилятор предназначен для архитектуры ARMv7, он пока производит очень старый машинный код (thumb-1) и кроме одной команды совместим с ARMv4T. Размер пустой программы тоже немаленький - 12 кб, хотя флэш-памяти в этих микроконтроллерах обычно довольно много и нет причин сильно экономить. В дальнейшем, переход от thumb-1 к thumb-2, а также частичное переписывание RTL в маш. кодах позволит несколько улучшить эффективность и уменьшить размер прошивки.

Не подскажете, почему так? Ведь компилятор Ширяева максимально прямой с минимумом преобразований

Ну, во-первых, набор инструкций thumb-1 менее эффективный, чем thumb-2. Сейчас компилятор уже транслирует в thumb-2, не везде где можно, но там, где это наиболее важно. Благодаря этому, эффективность кода теперь 80-100% от компилятора Ширяева. Размер пустой программы уменьшен до 7400 байт.

Во-вторых - плохая трансляция логических операций OR/&.

Я хоть и не запутался, но сделал это через одно место... Кодогенератор сохраняет значение логического выражения в регистре, затем сравнивает значение регистра с нулем и выполняет условный переход, вместо того, чтобы сразу генерить условный переход. И так во всех бэк-эндах. Я пока не придумал, как это исправить без переписывания значительной части. С другой стороны, "хорошая" трансляция логических выражений позволит выиграть лишь 10-20% производительности, и только для некоторых задач.

Есть еще некоторые существенные отличия в кодогенерации от компилятора Ширяева:
- компилятор Ширяева генерит специальные машинные инструкции для вещественной арифметики, мой - эмулирует вещественную арифметику, т. к. в ядрах Cortex-M3 нет FPU, а компилятор сейчас тестируется именно на Cortex-M3. Эмуляция пока очень неэффективная (здесь надо будет переписать в машинных кодах). В дальнейшем, можно также сделать поддержку вещественных инструкций, чтобы получить более эффективный код для микроконтроллеров с FPU (Cortex-M4F).
- компилятор Ширяева генерит только короткие команды переходов. Если расстояние перехода слишком большое - программа не компилируется. Мой - генерит длинные либо короткие переходы в зависимости от расстояния, а также поддерживает инструкцию cbz/cbnz. Это несколько сглаживает недостатки трансляции OR/&.

Ну а вообще... Я сейчас испытываю определенное разочарование и в Обероне и в своем компиляторе. Добавление очередного кодогенератора превратилось в рутину, творческий процесс почти отсутствует. Игрушечные языки и компиляторы мне надоели. Нужен или более серьезный язык, или оптимизирующий компилятор...