Компилятор Oberon-07/11 для x86 Windows

[valexey_u]

Я правильно понял, что это артефакт конкретного кодогенератора?

Не понял. В каком смысле артефакт?

В прямом исконном смысле слова. То есть если бы бекенд был другой (например был бы генератор js-кода), то этого поля могло бы и не быть.

[akron1]

Я знаком только с архитектурой x86, как в других -- не знаю.

Смещение переменной позволяет сгенерировать код обращения к глобальной переменной, когда ее адрес не известен (на этапе компиляции). Компилятор генерирует команды обращения к глобальным переменным, используя смещение вместо адреса и помечает эти команды. На финальном этапе компиляции адрес секции глобальных переменных становится известным и компилятор в помеченных командах заменяет смещение на сумму:
смещение + адрес_начала_секции_глобальны_ переменных

Смещения локальных переменных зависят от архитектуры и соглашения вызова

[valexey_u]

Я знаком только с архитектурой x86, как в других -- не знаю.

Смещение переменной позволяет сгенерировать код обращения к глобальной переменной, когда ее адрес не известен (на этапе компиляции). Компилятор генерирует команды обращения к глобальным переменным, используя смещение вместо адреса и помечает эти команды. На финальном этапе компиляции адрес секции глобальных переменных становится известным и компилятор в помеченных командах заменяет смещение на сумму:
смещение + адрес_начала_секции_глобальны_ переменных

Смещения локальных переменных зависят от архитектуры и соглашения вызова

Спасибо. Понятно.

[akron1]

Немного улучшенная версия.

1. Добавлена поддержка соглашения вызова cdecl
2. Добавлена процедура SYSTEM.TYPEID
3. Действие SYSTEM.ADR теперь распространяется на процедуры
4. Немного изменена кодогенерация
5. Повышена производительность подсветки синтаксиса
6. Появилась возможность настройки цветовой схемы подсветки (пока в упрощенном виде)
7. Обнаружена и исправлена ошибка в компиляторе:

Код: [Выделить]

   PROCEDURE MyProc(x: INTEGER y: INTEGER); (* пропущена ";" в списке формальных параметров *)

   Компилировалось как

   PROCEDURE MyProc(x: INTEGER; y: INTEGER);

   несмотря на синтаксическую ошибку


[Valery Solovey]

Так может всё-таки перейдёте на гитхаб?

Так и проще размещать компилятор для общго пользования: нажал git push и всё (а не возиться с архиватором и размещением на форуме).
Не придётся вспоминать и готовить список изменений: они будут видны в комментариях к коммитам.

Если есть трудности с освоением гитхаба, то я могу помочь установить гит (я использую cygwin-овскую версию) и настроить ssh-ключи. Могу помочь и с базовыми командами гита, но мне кажется, что они в интернете неплохо описаны и без меня.

[valexey_u]

Так может всё-таки перейдёте на гитхаб?

У гитхаба есть одна мелкая проблемка (по крайней мере в веб-интерфейсе) - оно не умеет cp1251 (да и вообще хочет Utf-8 похоже). А строковые литералы в этом компиляторе именно в этой кодировке. Поэтому в веб-морде вместо русского языка получаются крякозябры при просмотре исходников. Например так.

[Romiras]

А IDE работает с кодировкой cp1251??
По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.

[valexey_u]

А IDE работает с кодировкой cp1251??

Да

По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.

По идее да. Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным. Что может повлечь за собой изменения/проблемы в чем-то системозависимом (всякое там ffi и проч).

[akron1]

А IDE работает с кодировкой cp1251??

Да

По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.

По идее да. Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным. Что может повлечь за собой изменения/проблемы в чем-то системозависимом (всякое там ffi и проч).

Ну это только макет. Буду делать нормальный фронт-энд, тогда и перейду на юникод.

[ilovb]

Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным.

Для чего?
Если не разрешать юникодные идентификаторы в языке, то ничего менять не надо и проблем не должно быть. Проблемы будут когда захочется манипулировать строками, которые содержат символы за пределами ASCII. Например длина строки уже не будет равняться LEN - 1. А в присваивании s := 'Ж' будет ARRAY OF CHAR вместо просто CHAR.

[vlad]

Вы все переусложняете.
1. Перегнать исходники в utf8.
2. Фикснуть вызов Windows API (вывод на консоль и т.п.) - использовать юникодные версии функций (перекодировать utf8 -> utf16).
Все.

P.S. Да, нельзя будет использовать единичный CHAR как юникодный символ. Т.е., CONST s = "Ф"; не сможет быть использован вместо CHAR (например, в CASE), только как ARRAY OF CHAR.  Ну и фиг с ним.

[Valery Solovey]

У гитхаба есть одна мелкая проблемка (по крайней мере в веб-интерфейсе) - оно не умеет cp1251 (да и вообще хочет Utf-8 похоже).

разве это достаточная причина, чтобы им не пользоваться?

[valexey_u]

У гитхаба есть одна мелкая проблемка (по крайней мере в веб-интерфейсе) - оно не умеет cp1251 (да и вообще хочет Utf-8 похоже).

разве это достаточная причина, чтобы им не пользоваться?

Ну, я то пользуюсь :-)

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

[Romiras]

Сообщения компилятора имеет смысл перегнать в файловые ресурсы.

[Romiras]

Сообщения компилятора имеет смысл перегнать в файловые ресурсы.