Oberon space
General Category => Общий раздел => Тема начата: akron1 от Декабрь 11, 2012, 02:40:58 pm
-
Написал компилятор Oberon-07/11 для x86 Windows. Конечно, компилятор неоптимизирующий, создает безобразный (хотя и вполне рабочий) машинный код, кроме того, отсутствует сборщик мусора. Зато есть небольшая стандартная библиотека (консольный и файловый двоичный ввод-вывод, математические функции и некоторые другие). Также есть текстовый редактор с подсветкой синтаксиса, нумерацией строк и автокапсом (как в Astrobe), что практически снимает проблему прописных букв. К сожалению, производительность подсветки синтаксиса, особенно в сочетании с нумерацией строк оставляет желать лучшего, однако в большинстве случаев работать можно с комфортом. И еще: я не профессиональный программист, поэтому не претендую на разработку качественного продукта.
Скачать можно здесь http://rusfolder.com/34057068
-
Написал компилятор Oberon-07/11 для x86 Windows. Конечно, компилятор неоптимизирующий, создает безобразный (хотя и вполне рабочий) машинный код, кроме того, отсутствует сборщик мусора. Зато есть небольшая стандартная библиотека (консольный и файловый двоичный ввод-вывод, математические функции и некоторые другие). Также есть текстовый редактор с подсветкой синтаксиса, нумерацией строк и автокапсом (как в Astrobe), что практически снимает проблему прописных букв. К сожалению, производительность подсветки синтаксиса, особенно в сочетании с нумерацией строк оставляет желать лучшего, однако в большинстве случаев работать можно с комфортом. И еще: я не профессиональный программист, поэтому не претендую на разработку качественного продукта.
Скачать можно здесь http://rusfolder.com/34057068
Как на счет исходников? Чтобы народ мог помочь улучшить компилятор и сопутствующий инструментарий.
Репозиторий на github'е был бы в самый раз.
-
Неожиданно :o
И даже редактор есть юзабельный... (проблема капсов решена :D)
akron1, респект!
-
А у меня не компилит из редактора ;) - то ли стандартные библиотеки найти не может .. то ли фиг знает что (структура каталогов как в архиве, win7x64).
-
скорее фиг знает что.. ибо копирование редактора с компилятором в папку с библиотеками не помогло...
-
с командной строки все OK , следовательно глючит BIDE
-
Я библиотеки скопировал в папку с моим исходником и все скомпилилось.
-
из бидэ ?
-
Я пока не пробовал, ибо винды под рукой нет. Как доберусь - попробую.
-
из бидэ ?
Угу
-
из бидэ ?
Угу
у меня тоже.. не прошло в том случае если исходник в другой папке.. короче бидэ виновато...
-
Добрался до винды. Проблему с редактором подтверждаю - все используемые модули должны быть в текущей директории редактора. Иначе компилятор их не находит.
PS. akron1, поздравляю с днем рожденья нового компилятора :-)
-
Вызывают уважение такие работы. Спасибо.
-
Я тестировал свою программу в Win7x86 и WinXPx86, про x64 ничего сказать не могу. У меня все работает при условии размещения всех используемых модулей (в том числе и стандартных) в одной папке (неважно какой), редактор и компилятор также должны располагаться в одной папке (неважно какой). Если вы перемещаете файлы модулей во время работы редактора - перезапустите редактор. Кроме того, перед компиляцией и запуском, убедитесь, что:
- правильно назначен главный модуль
- правильно выбран тип приложения
- вызываются процедуры In.Open и Out.Open (для консольных приложений)
- если используется подключение сторонней dll, то ее экспортируемые процедуры должны быть stdcall
-
Я тестировал свою программу в Win7x86 и WinXPx86, про x64 ничего сказать не могу. У меня все работает при условии размещения всех используемых модулей (в том числе и стандартных) в одной папке (неважно какой), редактор и компилятор также должны располагаться в одной папке (неважно какой)....
А мы что телепаты, чтобы знать это.. кроме того, какого рожна вы разнесли в архиве файлы по папкам.. - что бы пользователям жизнь малиной не казалась? - нехорошо это...
-
akron1, действительно родные примеры должны компилироваться сразу без танцев с бубном.
-
DIzer, вообще-то я написал в about о необходимости размещения всех используемых модулей в одной папке. Хотя согласен, что это неудачное решение.
-
... написал в about ...
Ну вы прям будто не в России живете! :D
В этой стране инструкцию открывают после пользования, а не наоборот ;)
-
... написал в about ...
Ну вы прям будто не в России живете! :D
В этой стране инструкцию открывают после пользования, а не наоборот ;)
Ну, почему же? Иногда вместо :-)
-
DIzer, вообще-то я написал в about о необходимости размещения всех используемых модулей в одной папке. Хотя согласен, что это неудачное решение.
решение МОЖЕТ быть неудачным (по многим причинам) - но примеры ДОЛЖНЫ компилироваться без проблем "из коропки" - то есть ошибка в том, что вы структурировали архив - не было бы этого, не было бы вопросов...
-
Ну вы прям будто не в России живете! :D
В этой стране инструкцию открывают после пользования, а не наоборот ;)
а в какой стране делается иначе?... :D
-
... написал в about ...
Ну вы прям будто не в России живете! :D
В этой стране инструкцию открывают после пользования, а не наоборот ;)
Ну, почему же? Иногда вместо :-)
тем более когда есть бидэ - не было бы его , то же бы не было вопросов - короче, проблема в Бидэ
-
но вообще говоря , нужно в компиляторе предусмотреть ключ для задания директорий просмотра , ну и соответственно определить порядок поиска модулей
например: папка где главный модуль->папка где компилятор-> папки указанные после ключа директорий в порядке их перечисления - без этого тяжко использовать это хозяйство (в особенности с бидэ)..
-
Написал компилятор Oberon-07/11 для x86 Windows. ...
Скачать можно здесь http://rusfolder.com/34057068
Нельзя ли выложить тут, а то:
На данный момент иностранный трафик у этого файла превышает российский.
-
Редактор интересный, в добавок к вышесказанным пожеланиям добавлю, что хорошо бы иметь возможность менять не только размер шрифта, но и сам шрифт;
так же хорошо было бы уметь менять раскраску (тему) текстового окна, а то тонкие тёмные буквы на белом фоне утомительны;
и ещё клавиатурные шорткуты Ctrl-X, Ctrl-C, Ctrl-V хорошо бы продублировать на Shift-Del, Ctrl-Ins и Shift-Ins соответственно...
-
Редактор интересный, в добавок к вышесказанным пожеланиям добавлю, что хорошо бы иметь возможность менять не только размер шрифта, но и сам шрифт;
так же хорошо было бы уметь менять раскраску (тему) текстового окна, а то тонкие тёмные буквы на белом фоне утомительны;
и ещё клавиатурные шорткуты Ctrl-X, Ctrl-C, Ctrl-V хорошо бы продублировать на Shift-Del, Ctrl-Ins и Shift-Ins соответственно...
я бы, все таки , посоветовал сконцентрироваться на компиляторе - с бидэ проблем быть не должно..
-
Немного осилил еще доку.
Compiler.exe – транслятор исходного кода (*.ob07) в машинные коды x86 (формат исполняемых файлов – PE (*.exe и *.dll)), написан на Oberon-07/11 (самотранслятор).
Таки респект. Однако вопрос про исходники остается открытым и неотвеченным.
-
Редактор интересный, в добавок к вышесказанным пожеланиям добавлю, что хорошо бы иметь возможность менять не только размер шрифта, но и сам шрифт;
так же хорошо было бы уметь менять раскраску (тему) текстового окна, а то тонкие тёмные буквы на белом фоне утомительны;
и ещё клавиатурные шорткуты Ctrl-X, Ctrl-C, Ctrl-V хорошо бы продублировать на Shift-Del, Ctrl-Ins и Shift-Ins соответственно...
Хорошо, попробую усовершенствовать редактор
Редактор интересный, в добавок к вышесказанным пожеланиям добавлю, что хорошо бы иметь возможность менять не только размер шрифта, но и сам шрифт;
так же хорошо было бы уметь менять раскраску (тему) текстового окна, а то тонкие тёмные буквы на белом фоне утомительны;
и ещё клавиатурные шорткуты Ctrl-X, Ctrl-C, Ctrl-V хорошо бы продублировать на Shift-Del, Ctrl-Ins и Shift-Ins соответственно...
я бы, все таки , посоветовал сконцентрироваться на компиляторе - с бидэ проблем быть не должно..
Добавлю для компилятора еще один параметр, который позволит ему находить стандартные модули
Немного осилил еще доку.
Compiler.exe – транслятор исходного кода (*.ob07) в машинные коды x86 (формат исполняемых файлов – PE (*.exe и *.dll)), написан на Oberon-07/11 (самотранслятор).
Таки респект. Однако вопрос про исходники остается открытым и неотвеченным.
Чтобы открыть исходники, их нужно привести в порядок. Потребуется время.
-
Также есть текстовый редактор с подсветкой синтаксиса, нумерацией строк и автокапсом (как в Astrobe), что практически снимает проблему прописных букв.
Проблему капсов снимает не редактор а просто изъятие из синтаксиса языка обязательного их написания в ключевых словах.
-
Также есть текстовый редактор с подсветкой синтаксиса, нумерацией строк и автокапсом (как в Astrobe), что практически снимает проблему прописных букв.
Проблему капсов снимает не редактор а просто изъятие из синтаксиса языка обязательного их написания в ключевых словах.
Мы в данной теме рассматриваем все же стоковый Оберон.
-
Мы в данной теме рассматриваем все же стоковый Оберон.
Какой-какой Оберон? о_О
-
Мы в данной теме рассматриваем все же стоковый Оберон.
Какой-какой Оберон? о_О
Стоковый :-) As is. Искаробочный. Чистый, не порочный, не модифицированный. Имени Вирта.
-
Стоковый :-) As is. Искаробочный. Чистый, не порочный, не модифицированный. Имени Вирта.
Таких, судя по всему, в природе не существует. Все реализации (даже описанная в этой теме) имеют какие-то отличия от оригинального виртовского языка...
-
Как я заметил, этот компилятор в случае ошибки в коде программы ждёт, когда пользователь нажмёт Enter. Обычно так не делается, и это осложняет использование компилятора с другими редакторами. Нельзя ли убрать такое поведение?
И ещё -- планируется ли версия для линупсов/юнипсов?
-
Как я заметил, этот компилятор в случае ошибки в коде программы ждёт, когда пользователь нажмёт Enter. Обычно так не делается, и это осложняет использование компилятора с другими редакторами. Нельзя ли убрать такое поведение?
сделаю
И ещё -- планируется ли версия для линупсов/юнипсов?
а вот в линуксах я совершенно не разбираюсь
-
а вот в линуксах я совершенно не разбираюсь
А вот поэтому я и прошу выложить исходники на github, пусть даже они ужасны. Доводить их можно в процессе до нормального состояния. Прямо на github'е и доводить. Так это будет быстрее, и будет хоть какая-то гарантия что оно не повторит судьбу Оберон-07М компилятора.
-
а вот в линуксах я совершенно не разбираюсь
А вот поэтому я и прошу выложить исходники на github, пусть даже они ужасны. Доводить их можно в процессе до нормального состояния. Прямо на github'е и доводить. Так это будет быстрее, и будет хоть какая-то гарантия что оно не повторит судьбу Оберон-07М компилятора.
Вобщем-то, исходников мне конечно не жаль и я могу их завтра выложить, но предупреждаю, что у меня весьма плохой стиль: длинные процедуры ~300 строк, большое количество глобальных переменных, невнятные идентификаторы (из-за практически нулевого знания английского) и полное отсутствие комментариев (пишу для себя)
-
Вобщем-то, исходников мне конечно не жаль и я могу их завтра выложить, но предупреждаю, что у меня весьма плохой стиль: длинные процедуры ~300 строк, большое количество глобальных переменных, невнятные идентификаторы (из-за практически нулевого знания английского) и полное отсутствие комментариев (пишу для себя)
Выкладывай уже, мы все простимпоймем! ;)
-
akron1, не боги горшки обжигают ;)
-
Вобщем-то, исходников мне конечно не жаль и я могу их завтра выложить, но предупреждаю, что у меня весьма плохой стиль
В то время как профессионалы никак не могут родить 64 бита для ББ, твоя работа заведомо достойна респекта. Выкладывай! :)
-
Выложу ка я это тут. А то не все скачать могут.
-
Как я заметил, этот компилятор в случае ошибки в коде программы ждёт, когда пользователь нажмёт Enter. Обычно так не делается, и это осложняет использование компилятора с другими редакторами. Нельзя ли убрать такое поведение?
сделано
Также исправлено недоразумение с размещением стандартных модулей.
Добавлены исходники компилятора.
-
Как я заметил, этот компилятор в случае ошибки в коде программы ждёт, когда пользователь нажмёт Enter. Обычно так не делается, и это осложняет использование компилятора с другими редакторами. Нельзя ли убрать такое поведение?
сделано
Также исправлено недоразумение с размещением стандартных модулей.
Добавлены исходники компилятора.
Выложил исходники тут: https://github.com/valexey/Oberon-07-11-compiler
-
Добавлены исходники компилятора.
А можешь рассказать подробнее о процессе написания "на самом себе"? Какой оригинальный язык был и сколько итераций (промежуточных языков)?
-
Добавлены исходники компилятора.
А можешь рассказать подробнее о процессе написания "на самом себе"? Какой оригинальный язык был и сколько итераций (промежуточных языков)?
Оригинальный язык был XDS Oberon-2. При этом я старался не пользоваться средствами Oberon-2, отсутствующими в Oberon-07. В какой-то момент исходный код был просто переведен на Oberon-07, что было несложно сделать. Также первое время компилятор производил не машинный код, а ассемблерный masm32. Постепенно ассемблерный код был заменен машинным.
-
Забавно что эта разработка опубликована здесь а не там...
-
Оригинальный язык был XDS Oberon-2. При этом я старался не пользоваться средствами Oberon-2, отсутствующими в Oberon-07. В какой-то момент исходный код был просто переведен на Oberon-07, что было несложно сделать. Также первое время компилятор производил не машинный код, а ассемблерный masm32. Постепенно ассемблерный код был заменен машинным.
Кстати, а чем обусловлено использование в модуле Out функции WriteConsoleA а не WriteFile? Ведь у WriteConsoleA есть противная черта, она не работает с перенаправленными потоками вывода:
WriteConsole fails if it is used with a standard handle that is redirected to a file.
Поменял в Out'e на WriteFile - и перенаправление заработало. То есть теперь в консоли можно спокойно писать
HW.exe > res.txt
После выполнения появится файл res.txt, где будет содержаться то, что программа HW.exe выводила на консоль (точнее на stdout).
-
Кстати, а чем обусловлено использование в модуле Out функции WriteConsoleA а не WriteFile? Ведь у WriteConsoleA есть противная черта, она не работает с перенаправленными потоками вывода:
обусловлено моим недостаточным знанием winapi
-
Кстати, а чем обусловлено использование в модуле Out функции WriteConsoleA а не WriteFile? Ведь у WriteConsoleA есть противная черта, она не работает с перенаправленными потоками вывода:
обусловлено моим недостаточным знанием winapi
Ну, я тоже там не блистаю особо - наткнулся только потому, что привык редиректить, а оно не редиректится :-) Ну и фикс в одну строчку:
(* GetProc("WriteConsoleA", kernel32, sys.ADR(WriteConsole)); *)
GetProc("WriteFile", kernel32, sys.ADR(WriteConsole));
Пошел щупать дальше :-)
-
Оригинальный язык был XDS Oberon-2. При этом я старался не пользоваться средствами Oberon-2, отсутствующими в Oberon-07. В какой-то момент исходный код был просто переведен на Oberon-07, что было несложно сделать. Также первое время компилятор производил не машинный код, а ассемблерный masm32. Постепенно ассемблерный код был заменен машинным.
А как ты оцениваешь - насколько трудоемко добавить поддержку Win64?
-
А как ты оцениваешь - насколько трудоемко добавить поддержку Win64?
Перестроить этот кодогенератор очень непросто и ненадежно, проще к имеющемуся синтаксанализатору приделать новый кодогенератор. Построение нового генератора ассемблерного кода, если конечно он не оптимизирующий, не очень трудоемко.
-
Сколько времени у вас заняло написание компилятора?
-
Сколько времени у вас заняло написание компилятора?
Записал основные даты в истории компилятора:
18 мая 2012 - начало разработки
15 июля 2012 - самокомпиляция в ассемблер
20 сентября 2012 самокомпиляция в машкод
Параллельно с разработкой компилятора приходилось разбираться в ассемблере, структуре исполняемых файлов и многих более мелких системных вопросах (stdcall, выравнивание полей в структурах). Если бы я все это знал раньше, разработка заняла бы меньше времени. Кроме того, я почти не пользовался специализированной литературой. Если бы я воспользовался хотя бы книгой Вирта "Построение компилятора", я бы избежал многих ошибок и меньше пришлось бы вносить исправления, теряя время.
-
Ну вот! А тут стращали что это минимум на 2-3 года работы:)
-
Ну вот! А тут стращали что это минимум на 2-3 года работы:)
В современных условиях только сам компилятор никому не нужен. Нужна платформа -- библиотеки, желательна среда разработки, документация ко всему хозяйству и т.д. А всё это займёт куда больше чем полгода. Одно тело и за три года вряд ли управится...
-
akron1, здесь (http://svn.assembla.com/svn/oberonru/tag/AVRCompiler-0.0.0/) лежат исходники Оберон-07 под AVR. Язык разработки - Активный Оберон.
Может будет полезен.
-
А можно описать что какое поле значит в экспортируемых типах модуля DECL?
Прямо сейчас меня интересует это:
rIDENT* = RECORD (UTILS.rITEM)
Name: SCAN.NODE;
line*, col*: INTEGER;
Number*: INTEGER;
iType*: INTEGER;
T*: pTYPE;
Unit*: UNIT;
Value*: LONGREAL;
Export: BOOLEAN;
StProc*: INTEGER;
VarSize: INTEGER;
ParamSize*: INTEGER;
LocalSize: INTEGER;
Offset*: INTEGER;
VarKind*: INTEGER;
current: BOOLEAN;
Level*: INTEGER;
Parent*: IDENT;
ParamCount*: INTEGER
END;
А еще конкретней - что такое тут Offset.
-
А еще конкретней - что такое тут Offset.
Offset - смещение переменной (это поле применяется только для идентификаторов переменных, для любых других видов идентификаторов оно равно 0)
Для глобальных -- относительно начала секции глобальных переменных (первая объявленная глобальная переменная имеет смещение 0).
Для локальных и параметров - относительно базы кадра стека (на него указывает регистр EBP). У параметров смещение положительное, у локальных переменных отрицательное.
-
А еще конкретней - что такое тут Offset.
Offset - смещение переменной (это поле применяется только для идентификаторов переменных, для любых других видов идентификаторов оно равно 0)
Для глобальных -- относительно начала секции глобальных переменных (первая объявленная глобальная переменная имеет смещение 0).
Для локальных и параметров - относительно базы кадра стека (на него указывает регистр EBP). У параметров смещение положительное, у локальных переменных отрицательное.
Смещение в байтах?
Я правильно понял, что это артефакт конкретного кодогенератора?
-
Смещение в байтах?
Да
Я правильно понял, что это артефакт конкретного кодогенератора?
Не понял. В каком смысле артефакт?
-
Я правильно понял, что это артефакт конкретного кодогенератора?
Не понял. В каком смысле артефакт?
В прямом исконном смысле слова. То есть если бы бекенд был другой (например был бы генератор js-кода), то этого поля могло бы и не быть.
-
Я знаком только с архитектурой x86, как в других -- не знаю.
Смещение переменной позволяет сгенерировать код обращения к глобальной переменной, когда ее адрес не известен (на этапе компиляции). Компилятор генерирует команды обращения к глобальным переменным, используя смещение вместо адреса и помечает эти команды. На финальном этапе компиляции адрес секции глобальных переменных становится известным и компилятор в помеченных командах заменяет смещение на сумму:
смещение + адрес_начала_секции_глобальны_ переменных
Смещения локальных переменных зависят от архитектуры и соглашения вызова
-
Я знаком только с архитектурой x86, как в других -- не знаю.
Смещение переменной позволяет сгенерировать код обращения к глобальной переменной, когда ее адрес не известен (на этапе компиляции). Компилятор генерирует команды обращения к глобальным переменным, используя смещение вместо адреса и помечает эти команды. На финальном этапе компиляции адрес секции глобальных переменных становится известным и компилятор в помеченных командах заменяет смещение на сумму:
смещение + адрес_начала_секции_глобальны_ переменных
Смещения локальных переменных зависят от архитектуры и соглашения вызова
Спасибо. Понятно.
-
Немного улучшенная версия.
1. Добавлена поддержка соглашения вызова cdecl
2. Добавлена процедура SYSTEM.TYPEID
3. Действие SYSTEM.ADR теперь распространяется на процедуры
4. Немного изменена кодогенерация
5. Повышена производительность подсветки синтаксиса
6. Появилась возможность настройки цветовой схемы подсветки (пока в упрощенном виде)
7. Обнаружена и исправлена ошибка в компиляторе:
PROCEDURE MyProc(x: INTEGER y: INTEGER); (* пропущена ";" в списке формальных параметров *)
Компилировалось как
PROCEDURE MyProc(x: INTEGER; y: INTEGER);
несмотря на синтаксическую ошибку
-
Так может всё-таки перейдёте на гитхаб?
Так и проще размещать компилятор для общго пользования: нажал git push и всё (а не возиться с архиватором и размещением на форуме).
Не придётся вспоминать и готовить список изменений: они будут видны в комментариях к коммитам.
Если есть трудности с освоением гитхаба, то я могу помочь установить гит (я использую cygwin-овскую версию) и настроить ssh-ключи. Могу помочь и с базовыми командами гита, но мне кажется, что они в интернете неплохо описаны и без меня.
-
Так может всё-таки перейдёте на гитхаб?
У гитхаба есть одна мелкая проблемка (по крайней мере в веб-интерфейсе) - оно не умеет cp1251 (да и вообще хочет Utf-8 похоже). А строковые литералы в этом компиляторе именно в этой кодировке. Поэтому в веб-морде вместо русского языка получаются крякозябры при просмотре исходников. Например так (https://github.com/valexey/Oberon-07-11-compiler/blob/master/compiler/Compiler.ob07#L1665).
-
А IDE работает с кодировкой cp1251?? :-\
По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.
-
А IDE работает с кодировкой cp1251?? :-\
Да
По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.
По идее да. Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным. Что может повлечь за собой изменения/проблемы в чем-то системозависимом (всякое там ffi и проч).
-
А IDE работает с кодировкой cp1251?? :-\
Да
По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.
По идее да. Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным. Что может повлечь за собой изменения/проблемы в чем-то системозависимом (всякое там ffi и проч).
Ну это только макет. Буду делать нормальный фронт-энд, тогда и перейду на юникод.
-
Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным.
Для чего?
Если не разрешать юникодные идентификаторы в языке, то ничего менять не надо и проблем не должно быть. Проблемы будут когда захочется манипулировать строками, которые содержат символы за пределами ASCII. Например длина строки уже не будет равняться LEN - 1. А в присваивании s := 'Ж' будет ARRAY OF CHAR вместо просто CHAR.
-
Вы все переусложняете.
1. Перегнать исходники в utf8.
2. Фикснуть вызов Windows API (вывод на консоль и т.п.) - использовать юникодные версии функций (перекодировать utf8 -> utf16).
Все.
P.S. Да, нельзя будет использовать единичный CHAR как юникодный символ. Т.е., CONST s = "Ф"; не сможет быть использован вместо CHAR (например, в CASE), только как ARRAY OF CHAR. Ну и фиг с ним.
-
У гитхаба есть одна мелкая проблемка (по крайней мере в веб-интерфейсе) - оно не умеет cp1251 (да и вообще хочет Utf-8 похоже).
разве это достаточная причина, чтобы им не пользоваться?
-
У гитхаба есть одна мелкая проблемка (по крайней мере в веб-интерфейсе) - оно не умеет cp1251 (да и вообще хочет Utf-8 похоже).
разве это достаточная причина, чтобы им не пользоваться?
Ну, я то пользуюсь :-)
Вообще, проблема на самом деле решается проще - нужно просто заменить все русские сообщения в компиляторе на английские. Таким образом двух зайцев - и компилятор интернациональный получается, и на гитхабе все будет ок.
-
Сообщения компилятора имеет смысл перегнать в файловые ресурсы.
-
Сообщения компилятора имеет смысл перегнать в файловые ресурсы.
-
Выложил исходники тут: https://github.com/valexey/Oberon-07-11-compiler
valexey, добавь меня к проекту плиз.
-
Выложил исходники тут: https://github.com/valexey/Oberon-07-11-compiler
valexey, добавь меня к проекту плиз.
А как тебя там звать?
Добавлю вечером. Раньше до компа не доберусь.
-
Выложил исходники тут: https://github.com/valexey/Oberon-07-11-compiler
valexey, добавь меня к проекту плиз.
Добавил.
Кстати, пощупал подвиндовый клиент github'a (то есть не git'a вообще, а конкретно github-овое поделие под github заточенное) - вполне можно жить. Если страшную консоль кто-то пугается, то делать комитты через него вполне можно. Удобно там комменты к комиту вбивать и дифы смотреть (по крайней мере на маленьких проектах вроде этого).
Правда зачем-то у них это приложение в метро-стиле сделано. То есть запускается в обычной семерке, где никакого метро нет, но имеет стиль ровно тот.
-
Пушнул на github свежую версию исходников. Дифы с предыдущей версией смотреть забавно :-)
-
Пушнул на github свежую версию исходников. Дифы с предыдущей версией смотреть забавно :-)
Например видно, что мое исправление: http://oberspace.dyndns.org/index.php/topic,396.msg11495.html#msg11495
Было принято, переработано и добавлено: https://github.com/valexey/Oberon-07-11-compiler/commit/021b154489b9d2599428318947dca14c46798823#L11L16
-
Если можно, перекодируйте в utf-8, а то просмоторщик вопросы вместо комментариев показывает.
-
Если можно, перекодируйте в utf-8, а то просмоторщик вопросы вместо комментариев показывает.
Пока нельзя. См. http://oberspace.dyndns.org/index.php/topic,396.msg12275.html#msg12275 и далее.
-
А IDE работает с кодировкой cp1251?? :-\
Да
По идее, проблем с переходом на utf-8 быть не должно. Равно как и в компиляторе. Надо решить этот вопрос сначала раз и навсегда.
По идее да. Но это повлечет за собой изменение типа CHAR - он должен стать вместо 8ми битного 16ти, а лучше 32х битным. Что может повлечь за собой изменения/проблемы в чем-то системозависимом (всякое там ffi и проч).
Я бы представил CHAR в виде диапазона 0..0FFFFH (упаковывающийся в обероновский INTEGER, хотя зависит от реализации), который представляет собой Code Point (http://"http://en.wikipedia.org/wiki/Code_point") для Basic Multilingual Plane (этот набор символов реализован в КП). В свою очередь, строка может представляться иным способом: хоть UTF-8, хоть UTF-32. Ведь каждый code point кодируется различным количеством байт в целевой кодировке (зависит от выбора кодировки символов).
-
Если можно, перекодируйте в utf-8, а то просмоторщик вопросы вместо комментариев показывает.
Пока нельзя. См. http://oberspace.dyndns.org/index.php/topic,396.msg12275.html#msg12275 и далее.
Уже можно. Теперь формат модулей UTF-8. Редактор сохраняет текст в кодировке UTF-8, но редактирование возможно пока только в кодировке win-1251 (при открытии файла utf-8 -> win-1251, при сохранении win-1251 -> utf-8)
Пушнул на github свежую версию исходников. Дифы с предыдущей версией смотреть забавно :-)
Например видно, что мое исправление: http://oberspace.dyndns.org/index.php/topic,396.msg11495.html#msg11495
Было принято, переработано и добавлено: https://github.com/valexey/Oberon-07-11-compiler/commit/021b154489b9d2599428318947dca14c46798823#L11L16
В связи с переходом на utf-8, пришлось вернуть WriteConsoleW, вместо WriteFile.
-
akron1, я добавил страничку о вашем компиляторе в путеводитель оберон-проектов:
https://sites.google.com/site/oberonsystems/oberon-07-11/kompilator-ot-akron1
Если вышлете мне свой gmail, то я дам вам право на редактирование.
-
А можно нескромный вопрос: поддержка ОС "Колибри" не планируется?
-
А можно нескромный вопрос: поддержка ОС "Колибри" не планируется?
Возможные варианты:
1) Win64
2) Linux
3) Внутреннее представление, оптимизации
4) Транслятор Oberon-07 -> C/C++
С чего начать, пока не выбрал.
Так что и без Колибри есть над чем работать.
-
А можно нескромный вопрос: поддержка ОС "Колибри" не планируется?
Так исходники же доступны -- можно просто так взять и допилить.
Как я понимаю, надо просто выкинуть формирование exe-файла и записывать в бинарном виде.
Или в Колибри есть какой-то свой формат исполнимых файлов? Вроде бы типа досовских com-файлов там?
-
Так что и без Колибри есть над чем работать.
а зря.. возможно там он окажется "в жилу"- ибо (не знаю как сейчас) единственным штатным средством создания софта под нее был ассемблер..
-
Так что и без Колибри есть над чем работать.
а зря.. возможно там он окажется "в жилу"- ибо (не знаю как сейчас) единственным штатным средством создания софта под нее был ассемблер..
http://diamond.kolibrios.org/hll/hll.htm
* Ассемблер FASM
* Ассемблер NASM
* Ассемблер MASM
* Среды Visual C++ 6, C++ из Visual Studio .NET/2005
* Компиляторы GCC, G++
* Компилятор Borland C++
* Компилятор Tiny C
* Компилятор Pascal Pro
-
Так что и без Колибри есть над чем работать.
а зря.. возможно там он окажется "в жилу"- ибо (не знаю как сейчас) единственным штатным средством создания софта под нее был ассемблер..
http://diamond.kolibrios.org/hll/hll.htm
* Ассемблер FASM
* Ассемблер NASM
* Ассемблер MASM
* Среды Visual C++ 6, C++ из Visual Studio .NET/2005
* Компиляторы GCC, G++
* Компилятор Borland C++
* Компилятор Tiny C
* Компилятор Pascal Pro
угу устарели мои данные однако... :D
-
посмотрел более внимательно - вроде ничего у них за 4 года не изменилось (с точки зрения наполнения), с другой стороны, их форум мне понравился...
-
На самом деле большинство языков там на уровне "один студент кое-как адаптировал компилятор и скомпилировал одну программу", как я понимаю. На деле сами разработчики пишут на FASM, GCC (под который есть несколько вариантов Libc и прочего) и C-- (Си-минус-минус -- местная экзотика). Еще есть Lua и Python, но программ на них не припоминаю.
Поддержка FPC делалась когда-то под одну конкретную версию, работа с другими версиями FPC не гарантировалась. Я попробовал в ней разобраться, но понял, что с наскока не получится.
Под самой "Колибри" запускается только FASM. Если ориентироваться на него, то родной компилятор под "Колибри" должен запускаться под ней самой и уметь генерировать mcall -- штатное соглашение о вызовах Menuet/"Колибри", чтобы системные функции импортировать без прокладок.
-
Англоязычные пользователи просят перевести IDE на английский, ну и компилятор. Компилятор я сам могу, а вот IDE нет. Может стоит сделать англоверсию?
-
Англоязычные пользователи просят перевести IDE на английский, ну и компилятор. Компилятор я сам могу, а вот IDE нет. Может стоит сделать англоверсию?
Либо открыть и исходники IDE тоже - я тогда переведу. :-)
-
Англоязычные пользователи просят перевести IDE на английский, ну и компилятор. Компилятор я сам могу, а вот IDE нет. Может стоит сделать англоверсию?
Лучше сделать версию, в которой все эти надписи в файлах локалей записаны, а самих файлов локалей можно будет хоть сотню наклепать тем, кто соответствующие естественные языки понимает...
-
Англоязычные пользователи просят перевести IDE на английский, ну и компилятор. Компилятор я сам могу, а вот IDE нет. Может стоит сделать англоверсию?
Лучше сделать версию, в которой все эти надписи в файлах локалей записаны, а самих файлов локалей можно будет хоть сотню наклепать тем, кто соответствующие естественные языки понимает...
Это сильно сложнее. Это надо делать детект локали винды например. IMHO сейчас лучше сделать просто англоверсию, чтобы народ мог хоть как-то пользоваться.
-
Это сильно сложнее. Это надо делать детект локали винды например. IMHO сейчас лучше сделать просто англоверсию, чтобы народ мог хоть как-то пользоваться.
С фига ли- Идешка же на Делфи... там дохрена компонент локализации.. в последних вроде даже в дефолтной поставке есть... лучше чем трахаться с синхронизацией версий... А детект не нужен... вполне хватит и явного преобразования (через пункт меню) - но дело хозяйское...
-
Это сильно сложнее. Это надо делать детект локали винды например. IMHO сейчас лучше сделать просто англоверсию, чтобы народ мог хоть как-то пользоваться.
С фига ли- Идешка же на Делфи... там дохрена компонент локализации.. в последних вроде даже в дефолтной поставке есть... лучше чем трахаться с синхронизацией версий... А детект не нужен... вполне хватит и явного преобразования (через пункт меню) - но дело хозяйское...
Гм. Действительно, упустил из виду что оно на делфи. Мне казалось что тоже на Обероне. Ну, тогда да, локализовать делфевыми методами (и тут я, к сожалению, не помошник).
А если выбирать текущий язык через пункт меню - то по умолчанию там должен быть английский.
-
А если выбирать текущий язык через пункт меню - то по умолчанию там должен быть английский.
А вот с этим никто не спорит..
-
Пункта меню тоже не надо. Достаочно читать строки из файла типа lang.txt. И сделать различные варианты этого файла. Например, akron1 сделает русский вариант, а кто-нибудь переведёт его. И английскую версию на гитхаб в качестве умолчальной.
-
Пункта меню тоже не надо. Достаочно читать строки из файла типа lang.txt. И сделать различные варианты этого файла. Например, akron1 сделает русский вариант, а кто-нибудь переведёт его. И английскую версию на гитхаб в качестве умолчальной.
Надо... надо быть дружественнее к конечному пользователю.. и они потянутся... а что не надо - так это брать принцип коровят "возможно в принципе и ладно - пользователь разберется" - НЕ БУДЕТ ОН РАЗБИРАТЬСЯ - ПОШЛЕТ НАХЕР.
-
Хорошо, сделаю. Но только через 1-2 недели.
-
miranda
-
Хорошо, сделаю. Но только через 1-2 недели.
ок. Тогда пока попробую локализовать народными (партизанскими) способами :-)
-
Хорошо, сделаю. Но только через 1-2 недели.
ок. Тогда пока попробую локализовать народными (партизанскими) способами :-)
хакать экзе?... фи а ещчо называет себя профессионалом ;D ;D ;D ;D
-
Хорошо, сделаю. Но только через 1-2 недели.
ок. Тогда пока попробую локализовать народными (партизанскими) способами :-)
хакать экзе?... фи а ещчо называет себя профессионалом ;D ;D ;D ;D
Цель оправдывает средства :-)
-
Для локализации приложений Delphi есть, к примеру, популярные пакеты DKLang и GetText.
-
Компилятор не позволяет такое присваивание в случае если массив передан в функцию "по значению" (не-VAR):
array[i].pointer.field := 123;
Я думаю, что это бага. Вот выдержка из обероновского репорта:
9.1
...
If a value parameter is structured (of array or record type), no assignment to it or to its elements are permitted. Neither may assignments be made to imported variables.
Рекорд, на который ссылается указатель, не является элементом массива - следовательно такое присваивание должно работать.
-
И еще одна бага (присуща дельфовым прогам, точно такая же была у драконовского редактора): показываются
????? во всех менюшках на Windows7 (с русской локалью).
-
И еще одна бага (присуща дельфовым прогам, точно такая же была у драконовского редактора): показываются ????? во всех менюшках на Windows7 (с русской локалью).
п.. здеж у меня на моих прогах на D7 под win7-64 усе ок....
-
Компилятор не позволяет такое присваивание в случае если массив передан в функцию "по значению" (не-VAR):
array[i].pointer.field := 123;
Я думаю, что это бага. Вот выдержка из обероновского репорта:
9.1
...
If a value parameter is structured (of array or record type), no assignment to it or to its elements are permitted. Neither may assignments be made to imported variables.
Рекорд, на который ссылается указатель, не является элементом массива - следовательно такое присваивание должно работать.
Спасибо. Надо будет исправить...
-
Компилятор не позволяет такое присваивание в случае если массив передан в функцию "по значению" (не-VAR):
array[i].pointer.field := 123;
Я думаю, что это бага. Вот выдержка из обероновского репорта:
9.1
...
If a value parameter is structured (of array or record type), no assignment to it or to its elements are permitted. Neither may assignments be made to imported variables.
Рекорд, на который ссылается указатель, не является элементом массива - следовательно такое присваивание должно работать.
Странный перевод Влад.. - на мой английский это звучит так:
если параметр передаваемый по значению структурирован (массив или имеет тип -запись), запрещаются присваивания ему или его элементам. То же относится к присваиваниям сделанным импортированным переменным...
-
Очередные недосказанности в репорте...
Думается, нужно сформулировать как-то так:
Правило "только для чтения" действует до первого разыменования указателя в десигнаторе.
Потому что в случае указателей это правило все равно можно легко обойти, просто потребуется написать лишний код:
(* array[i].pointer.field := 123; *)
p := array[i].pointer;
p.field := 123;
-
Странный перевод Влад.. - на мой английский это звучит так:
если параметр передаваемый по значению структурирован (массив или имеет тип -запись), запрещаются присваивания ему или его элементам. То же относится к присваиваниям сделанным импортированным переменным...
Ну да. Т.е. для вот этих случаев все явно прописано:
array := array2; (* запрещено *)
record := record2; (* запрещено *)
array[0] := array2[0]; (* запрещено *)
record.field := record2.field; (* запрещено, если принять, что поле это "элемент" рекорда, хотя тоже желательно уточнить *)
Все. Для всех остальных случаев - не прописано. Можно только угадывать. "Из общих соображений" (кусок памяти под массив/рекорд только для чтения) можно предположить, что такое тоже запрещено:
array[0].field := array2[0].field;
record.record.field := record2.record.field;
Далее, исходя из того же принципа (кусок памяти под массив/рекорд только для чтения) вот такое должно быть разрешено:
array[0].pointer.field := array2[0].pointer.field;
record.pointer.field := record2.pointer.field;
Но это все предположения, которые неплохо было бы отразить непосредственно в репорте.
-
Странный перевод Влад.. - на мой английский это звучит так:
если параметр передаваемый по значению структурирован (массив или имеет тип -запись), запрещаются присваивания ему или его элементам. То же относится к присваиваниям сделанным импортированным переменным...
Ну да. Т.е. для вот этих случаев все явно прописано:
array := array2; (* запрещено *)
record := record2; (* запрещено *)
array[0] := array2[0]; (* запрещено *)
record.field := record2.field; (* запрещено, если принять, что поле это "элемент" рекорда, хотя тоже желательно уточнить *)
Все. Для всех остальных случаев - не прописано. Можно только угадывать. "Из общих соображений" (кусок памяти под массив/рекорд только для чтения) можно предположить, что такое тоже запрещено:
array[0].field := array2[0].field;
record.record.field := record2.record.field;
Далее, исходя из того же принципа (кусок памяти под массив/рекорд только для чтения) вот такое должно быть разрешено:
array[0].pointer.field := array2[0].pointer.field;
record.pointer.field := record2.pointer.field;
Но это все предположения, которые неплохо было бы отразить непосредственно в репорте.
хуже... не очень понятно зачем Вирт это сделал ибо никто не запрещает такой фокус
VAR local:rec;
....
local:=valrec;(* любым полям valrec запрещены явные присваивания*)
local.a:=10; (* но кто мешает сделать это таким образом?*)
лично я привык к трактовке параметра передаваемого по значению - как к локальной переменной в которую скопировано значение из основной программы
-
по сути дела это эквивалент автоматического const на передачу параметров структурированного типа....
-
И на мой взгляд.. все здесь однозначно.. ибо нет понятия глубокого копирования (как в Эйфеле) в том числе и при передаче параметра по значению - то есть.. менять явно указатель запрещено, а то на что он указывает - запросто
-
по сути дела это эквивалент автоматического const на передачу параметров структурированного типа....
Ага. "Стройности" языку такая фича не придает. Стройность принесена в жертву минималистичности (не вводить понятие константности в язык и в то же время сделать передачу структурных параметров всегда эффективной).
-
.....(не вводить понятие константности в язык и в то же время сделать передачу структурных параметров всегда эффективной).
Сомнительный вывод - ибо язык не определяет понятие эффективности (тем более эффективной передачи параметров по значению в произвольной реализации) - только дает возможность использовать эту особенность для оптимизации кода.
-
... а этой возможности может и не быть.
-
.....(не вводить понятие константности в язык и в то же время сделать передачу структурных параметров всегда эффективной).
Сомнительный вывод - ибо язык не определяет понятие эффективности (тем более эффективной передачи параметров по значению в произвольной реализации) - только дает возможность использовать эту особенность для оптимизации кода.
Оберон - очень даже определяет. Там все завязано на "эффективность без изощрений". Взять хотя бы невозможность нормально возвращать рекорды. Применительно к обсуждаемым value-параметрам - нет никакой возможности добиться неизменяемости (регламентируемой для value-параметров), кроме как копированием. А это в общем случае неэффективно.
-
.....(не вводить понятие константности в язык и в то же время сделать передачу структурных параметров всегда эффективной).
Сомнительный вывод - ибо язык не определяет понятие эффективности (тем более эффективной передачи параметров по значению в произвольной реализации) - только дает возможность использовать эту особенность для оптимизации кода.
Оберон - очень даже определяет. Там все завязано на "эффективность без изощрений". Взять хотя бы невозможность нормально возвращать рекорды. Применительно к обсуждаемым value-параметрам - нет никакой возможности добиться неизменяемости (регламентируемой для value-параметров), кроме как копированием. А это в общем случае неэффективно.
ну давайте у akron1 спросим - эфективно ли у него в компиляторе организована эта передача ( или как получится
)
-
ну давайте у akron1 спросим - эфективно ли у него в компиляторе организована эта передача ( или как получится
)
Так исходники открыты -- любой достаточно опытный компиляторщик сам может оценить эффективность...
-
ну давайте у akron1 спросим - эфективно ли у него в компиляторе организована эта передача ( или как получится
)
Так исходники открыты -- любой достаточно опытный компиляторщик сам может оценить эффективность...
я к последним не отношусь вообще и становиться им не хочу.
-
Я думаю, что это бага. Вот выдержка из обероновского репорта:
Я думаю, что это правильное поведение - структурные типы (записи и массивы), передаваемые по значению, по сути являются const-параметрами и не могут быть lvalue.
-
Я думаю, что это бага. Вот выдержка из обероновского репорта:
Я думаю, что это правильное поведение - структурные типы (записи и массивы), передаваемые по значению, по сути являются const-параметрами и не могут быть lvalue.
в чем их "суть" - отличается от сути обычных (неструктурированных) значений?
-
тем, что они всегда передаются по ссылке, но только модификатор VAR дает возможность определить их как параметры-переменные, в противном случае они являются параметрами-константами.
-
тем, что они всегда передаются по ссылке, но только модификатор VAR дает возможность определить их как параметры-переменные, в противном случае они являются параметрами-константами.
с чего вы взяли.. вот в Паскале, например, происходит копирование массива в новую переменную (правильнее сказать, наверное, что ведет этот параметр себя так если бы...), в КП вроде также... с точки зрения "высокоуровневого" программирования (когда не заморачиваешься вопросами реализации) это ИМХО естественно...
-
И ещё -- планируется ли версия для линупсов/юнипсов?
а вот в линуксах я совершенно не разбираюсь
Поторопился с ответом
А можно нескромный вопрос: поддержка ОС "Колибри" не планируется?
Возможные варианты:
1) Win64
2) Linux
3) Внутреннее представление, оптимизации
4) Транслятор Oberon-07 -> C/C++
С чего начать, пока не выбрал.
Так что и без Колибри есть над чем работать.
Здесь тоже
Вобщем, добавил поддержку Linux и KolibriOS. Осталось только немного допилить поддержку линукс.
-
с чего вы взяли.. вот в Паскале, например,
так речь идёт об Обероне-07
-
с чего вы взяли.. вот в Паскале, например,
так речь идёт об Обероне-07
в моем понимании речь идет о том насколько ЯВУ - определяет детали реализации компилятора (в том числе и оберона -07) и разумеется я сужу с высокоуровневой позиции.. ибо нафиг тогда ЯВУ.. фигарили бы все на ассемблере.. так вот , с этой точки зрения базовые модели, задаваемые императивными ЯВУ (что Паскалем , что Обероном, ) несильно отличаются..(пример.. переменная как ящик, значение - как то что хранится в ящике, тип как схема по которой этот ящик создается определяющий емкость и набор операций над значениями.....) и обсуждаемый эффект вносит по факту низкоуровневое исключение.. причем,с моей точки зрения, еще не факт что оно будет на 100% оправдано в конкретной реализации Оберона.
-
Выложил последнюю версию на гуглосайте https://sites.google.com/site/oberon07compiler и приостановил разработку.
-
akron1, один знакомый оберонщик попросил уточнить насчёт лицензии на данный компилятор. Он опасается, что если её сейчас нет никакой, то потом ВДРУГ может появиться совсем неудобная (для его нужд).
-
akron1, один знакомый оберонщик попросил уточнить насчёт лицензии на данный компилятор. Он опасается, что если её сейчас нет никакой, то потом ВДРУГ может появиться совсем неудобная (для его нужд).
Если сейчас никакой, то это уже хуже чем ЛЮБАЯ потом - без лицензии что-либо с кодом (в том числе использование без модификации в любом виде) можно делать только с явного письменного персонального разрешения автора, таково законодательство РФ. Защиты абсолютней не бывает.
-
akron1, один знакомый оберонщик попросил уточнить насчёт лицензии на данный компилятор. Он опасается, что если её сейчас нет никакой, то потом ВДРУГ может появиться совсем неудобная (для его нужд).
О лицензии не задумывался... Ну ладно, значит будет GNU GPL со следующей версии.
-
Лучше сделайте BSD или вообще Public Domain (как у SQLite).
С GPL проблемы возникают в коммерческом использовании.
-
Лучше сделайте BSD или вообще Public Domain (как у SQLite).
С GPL проблемы возникают в коммерческом использовании.
Нет. GPL коммерческому использованию никак не мешает, ну, например у нас в конторе для создания сильно коммерческого продукта используется gcc (а у него лицензия как бы вообще GPLv3), и mono (лицензия GPL). А еще используется OpenJDK (GPL).
Тут не нужно путать компилятор и рантайм языка. Рантайм (равно как и стандартная либа) должен быть под лицензией аля LGPL или там GPL+linking exception.
Единственное чему может помешать лицензия GPL у компилятора - это проприентарным модификациям лицами не являющимися авторами данного компилятора.
-
Единственное чему может помешать лицензия GPL у компилятора - это проприентарным модификациям лицами не являющимися авторами данного компилятора.
Я это и имел в виду -- ведь для реального использования оберона его компилятор или RTL по-любому придётся допиливать...
-
Единственное чему может помешать лицензия GPL у компилятора - это проприентарным модификациям лицами не являющимися авторами данного компилятора.
Я это и имел в виду -- ведь для реального использования оберона его компилятор или RTL по-любому придётся допиливать...
Не вижу тут смысла не GPL лицензии -- допиленный компилятор в исходниках должен быть доступен всем, в том числе и первоначальному автору (akron1). См. как развивается тот же gcc.
-
Переписал редактор на обероне. Исходный код получился страшный -- я никогда раньше не писал GUI на winapi, к тому же сильно мешало отсутствие вшитой в язык поддержки юникода (в моей реализации) и отсутствие в языке операции конкатенации (не говоря уж о типе string). Но каким-то образом оно работает)). Немного расширил и доопределил язык. Усовершенствовал работу с вещественными числами. До промышленных компиляторов, конечно все равно далеко, но все-таки вещественная арифметика стала в несколько раз эффективнее. https://sites.google.com/site/oberon07compiler/versii
-
sys.ADR(s)Труъоберонщики могут за это забить ногами ))
В данном случае значения не имеет, но лучше писать
sys.ADR(s[0])в будущем при расширении будет меньше проблем.
-
Переписал редактор на обероне. Исходный код получился страшный -- я никогда раньше не писал GUI на winapi, к тому же сильно мешало отсутствие вшитой в язык поддержки юникода (в моей реализации) и отсутствие в языке операции конкатенации (не говоря уж о типе string). Но каким-то образом оно работает)).
Серьёзный шаг вперёд в проекте. Теперь осталось сделать библиотеку визуальных компонентов и прикрутить редактор форм -- может получиться не хуже чем в дельфях ))
-
В компиляторе небольшой косяк с форматом PE файла (где не разобрался ещё), при создании гуя антивирусник (Symantec Endpoint) удаляет файл как потенциально опасный. Такое было у меня, когда накосячил с размерностью полей структур.
-
Такс. А я чего-то не понял. Вот есть функция:
RegisterClassEx: PROCEDURE [winapi] (lpWndClass: tagWNDCLASSEX): sys.CARD16;
То есть именно функция, а не процедура.
А вот есть её вызов (в Editor'e):
RegisterClassEx(wc);
Насколько я понимаю, вызов не чистой процедуры (то есть функции) в виде Statement'a в Oberon'e запрещен, вызов таковой функции может быть только в составе expression'a.
Или я не прав?
-
Данная особенность описана в документации:
Системные флаги
При объявлении процедурных типов и глобальных процедур, после ключевого слова
PROCEDURE может быть указан системный флаг соглашения вызова.
Его формат: "[" ( "stdcall" | "cdecl" | "winapi" ) "]", то есть [stdcall], [cdecl] или [winapi]. Например:
PROCEDURE [cdecl] MyProc(x, y, z: INTEGER): INTEGER;
Если указан флаг [winapi], то принимается соглашение stdcall и процедуру-функцию
можно вызвать как собственно процедуру, вне выражения. Флаг [winapi] доступен только для
платформы Windows.
-
Биндинг к SDL еще никто не пробовал сделать для этого компилятора?
-
Хм... Могу попробовать. Все равно заняться в плане кодирования нечем -- новый кодогенератор и сборщик мусора пока делать не хочу.
А пока, изменений немного: улучшена поддержка Kolibri (dll, библиотеки, улучшена работа с динамической памятью), несколько увеличена скорость компиляции и плотность кода и некоторые мелкие поправки.
https://sites.google.com/site/oberon07compiler/versii
-
akron1, сделайте, пожалуйста, для своего детища репозиторий на гитхабе.
-
Извините, Борис, но гитхабом пользоваться не умею и учиться не хочу, потому что мне это не нужно -- я не кодер и не собираюсь им быть.
-
Всем участники форума!
Немного о себе. Программист микроконтроллеров. Работаю с AVR, MSP430, ARM STM32 в проектах, которые передаются на производство и выпускаются для продаж на рынок. Языки программирования: ASM, С, C++ (консольные утилиты), FORTH и др. На С использую RTOS и собственный стековый язык программирования для CAN-шин автомобилей.
Много времени назад в режиме самообразования учился писать компилятор. И, конечно, наследие Н. Вирта Pascal, Modula-2, Oberon. С глубоким погружением изучал встречиЮ когда большое турне Н.Вирт проводил по России (2005). Наконец-то удалось купить книгу
1. Никлаус Вирт, Пер.: Е. Борисов, Л. Чернышов, Построение компиляторов (+ CD-ROM) // [текст] .- Изд. ДМК Пресс .- 2010 г.- ISBN 978-5-94074-585-3, 0-201-40353-6;
Искал компиляторы на Modula-2 и, конечно, "прикипел" к проекту Андреева Андрея Юрьевича "Компилятор "Странник" ( Модула-2(Оберон-2), Си(Си++) - http://home.perm.ru/strannik/
В компиляторе Компилятор Oberon-07/11 хотелось бы добавить ARM.ob07 для генерации целевого кода для ARM STM32.
Теперь первый вопрос.
Для компилятора Oberon-07/11 есть исходные коды. Однако при импорте SYS сама реализация SYSTEM связи с операционной системы спрятана в 'Compiler.exe'.
Я правильно понял?
Второй вопрос.
Есть ли смысл добавить в компилятор "Странник" реализацию Oberon 07?
-
SYSTEM - это псевдомодуль. Реализацию нужно смотреть в компиляторе, да.
Думаю, начинать смотреть нужно тут: https://github.com/ilovb/Oberon07akron1/blob/master/Source/Compiler/DECL.ob07#L1397
Странник... не знаю... какой от него толк может быть? Автор его давно забросил.
Какой смысл добавлять туда O07?
Мне думается, что Оберон имеет смысл только в двух ипостасях. Либо как полноценная система Оберон (т.е. как ОС или фреймворк). Либо как кросскомпилер (без среды) для микроконтроллеров.
-
Есть ли смысл добавить в компилятор "Странник" реализацию Oberon 07?
Смысл - это понятие, привязанное к цели.
Если цель - расширить свой рабочий инструмент Обероном, то да - имеет смысл, раз Вы собираетесь им пользоваться. Или если разработка ведётся ради удовольствия.
Если цель - увеличить популярность Оберона (или Странника), то смысла особого нет: сообщества этих проектов маленькие, увеличить одно из них за счёт другого получится лишь чуть-чуть.
-
Смысл - это понятие, привязанное к цели.
Если цель - расширить свой рабочий инструмент Обероном, то да - имеет смысл, раз Вы собираетесь им пользоваться. Или если разработка ведётся ради удовольствия.
Если цель - увеличить популярность Оберона (или Странника), то смысла особого нет: сообщества этих проектов маленькие, увеличить одно из них за счёт другого получится лишь чуть-чуть.
Цели:
1. В "Страннике" много его имеется: редактор (причём автор сделал его не зависимым от языка программирования), три языка программирования, справочна я система, русско-язычные ключевые слова для Си, Modula-2, Pascal, встроенный ассемблер x86, примеры и компактная реализация.
2. В "Странник" встроена возможность отлаживать программный код в DBG.
3. Хочется выделить в "Страннике" на отдельные части компилятор я зыков, редактор, ассемблер и генерация целевого кода. А так же вернуться к стандарту. Автор внёс изменение в описание языков и отошёл от реуомендованных стандартов.
4. Добавить OBERON-7 с целью сделать возможным запускать проект на микроконтроллерах.
5. Добавить встроенный ARM-ассемблер и генерацию для ARM процессоров.
Здесь многоговорилось о высокой надёжности OBERON. Однако ведь надёжность определяется операционной системой, где собственно и запускается код.
А какая надёжность у операционной системы OS Oberon?
-
А какая надёжность у операционной системы OS Oberon?
Весьма эфемерная -- кооперативная многозадачность без защиты памяти процессов. Любой залетевший дятел легко порушит цивилизацию оберон-системы.
Вот в A2, вроде бы, с этим получше, тут Kemet может подробнее рассказать, наверное...
-
А какая надёжность у операционной системы OS Oberon?
Весьма эфемерная -- кооперативная многозадачность без защиты памяти процессов. Любой залетевший дятел легко порушит цивилизацию оберон-системы.
Строго говоря, там и кооперативной многозадачности нет (то есть там нет ничего похожего например на fiber'ы - нет сохранения контекста).
А безопасность достигается чисто средствами языка. То есть если не пользовать SYSTEM, то порушить что-либо довольно сложно.
-
А так же вернуться к стандарту. Автор внёс изменение в описание языков и отошёл от рекомендованных стандартов.
Насколько я понял, автор так сделал, что бы получить по сути один (семантически) язык, но с тремя разными синтаксисами...
-
Насколько я понял, автор так сделал, что бы получить по сути один (семантически) язык, но с тремя разными синтаксисами...
У него другая идея была. Он (Андреев А.Ю.) искал абстрактное синтаксическое дерево, большая часть которого не зависит от конкретного языка. И сделал это!
Каталог st_sm_src
//СТРАННИК Модула-Си для Win32
//Модуль PRE (модуль межязыкового перевода)
//Файл SMPRE.M
implementation module SmPre;
import Win32,Win32Ext,SmSys,SmDat,SmTab,SmGen,SmLex,SmAsm,SmTra,SmTraC;
procedure preNextLex(var S:preStream); forward;
procedure preGetLex(var S:preStream); forward;
И это ещё не всё. В редакторе исходный код программы хранится в виде абстрактного синтаксического дерева, но не в текстовом виде!! (Конечно реализация не доведена до совершенство и редактор хандрит иногда при редактировании и особенно вставки из буфера кусков кода)...
Вопрос участникам: Есть ли готовый плагин Oberon-07 для подсветки в NotePad++ ?
-
Здесь многоговорилось о высокой надёжности OBERON. Однако ведь надёжность определяется операционной системой, где собственно и запускается код.
Нет. Надёжность языка определяется характеристиками языка, надёжность ОС определяется характеристиками ОС. Всё опять же сводится к целям: у ОС они свои (опреление доступа к ресурсам), а у языка программирования - свои.
Я нигде не видел расчётов или хотя бы оценок надёжности ОС Оберон, поэтому, на этот счёт мне сказать нечего. Да и вообще не встречал методик расчёта надёжности операционных систем. В открытом доступе постоянно встречается только маркетоидный трешак какой-то.
-
А какая надёжность у операционной системы OS Oberon?
Весьма эфемерная -- кооперативная многозадачность без защиты памяти процессов.
Кооперативная многозадачность не является атрибутом ненадёжной операционной системы. А процесс там один, который выполняет поток заданий, именуемых командами.
-
Есть ли смысл добавить в компилятор "Странник" реализацию Oberon 07?
Как пишет сам автор Странника:
При реализации классов и объектов за основу взяты механизмы языка Оберон-2, ставшего фактическим стандартом реализации ООП в Модуле. При этом оператор WITH сохранил свою семантику (т.е. по-прежнему предназначен для работы с записями, а не для проверки типа объекта). Поскольку Модула-2 мощнее Оберон-2 во всем, что не касается ООП, название языка сохранено, хотя реализацию Модулы-2 в Страннике можно смело считать надмножеством языка Оберон-2.
Так что непонятно, какой смысл в добавлении Оберона-07 в этот набор компиляторов...
-
SYSTEM - это псевдомодуль. Реализацию нужно смотреть в компиляторе, да.
Не нашёл в файле Compiler.ob07 реализацию процедур для SYSTEM, тем более в начале объявляется импорт:
IMPORT RTL, DECL, SCAN, UTILS, X86, SYSTEM;
И в других файлах нет реализации SYSTEM.
-
Как вам должно быть известно, в обероне есть "стандартные" процедуры -- INC, LSL, LEN... Эти процедуры не имеют исходного кода и обрабатываются компилятором как обычные операторы и операции. Как правило такие процедуры не вызываются а подставляются. Для компилятора нет принципиальной разницы между "стандартными" и SYSTEM-процедурами. Если компилятор встречает идентификатор "стандартной" или SYSTEM-процедуры, то вызывается процедура StFunc или StProc модуля Compiler, где происходит разбор параметров и генерация машинного кода.
Что касается генерации машинного кода для ARM, то сейчас это бесперспективно. Дело в том, что модуль Compiler (синтаскический разбор операторов и выражений) и модуль DECL (синтаксический разбор объявлений) тесно связаны с модулем X86. По-хорошему, компилятор должен сначала генерировать промежуточный (машино-независимый код), а затем транслировать его в машинный. То есть, модули Compiler и DECL обращаются к модулю генерации промежуточного кода, а потом трансляцию промежуточного кода в машинный выполняет модуль X86 или ARM. А пока, увы... У меня не было цели сделать что-то хорошее, просто "лишь бы работало", поэтому получилось так...
-
Если компилятор встречает идентификатор "стандартной" или SYSTEM-процедуры, то вызывается процедура StFunc или StProc модуля Compiler, где происходит разбор параметров и генерация машинного кода.
Что касается генерации машинного кода для ARM, то сейчас это бесперспективно.
модули Compiler и DECL обращаются к модулю генерации промежуточного кода, а потом трансляцию промежуточного кода в машинный выполняет модуль X86 или ARM. А пока, увы... У меня не было цели сделать что-то хорошее, просто "лишь бы работало", поэтому получилось так...
Автору реализации компилятора Oberon-07 for x86 - огромная благодарность за вклад просветления прогрограммистких умов! Это важная, очень важная задача иметь возможность одной головой "охватить" весь цикл создания целевого кода для процессора.
Благодарбю за подсказку о процедурах StFunc или StProc. Теперь буду смотреть и понимать как SYSTEM связан с модулем модуля Compile.ob7.
Вы утверждаете, что "генерация машинного кода для ARM, то сейчас это бесперспективно" Как Вы пришли к такому поспешному и неверному выводу!?
Программирую микроконтроллеры с прошлого века, а именно 1987 года: 8080, Z80, 8051, Atmega161, AT91Sam3, PIC18, MSP430, STM32. Начинал с ассемблера. Далее желанный Си. В интернете сейчас, словно лампочек на ночном небе, проектов для микроконтроллеров. И, нет НИ КАКОЙ ПЕРЕНОСИМОСТИ исходных кодов из проектов даже на Си! Каждый новый проект вынужден делать несколько месяцев. Иногда сроки проекта пересекают период больше года. Медленно. Очень медленно. Рукодство часто смотри косо на программеров. Переносимости практически нет, а значит опять строить проект приходтся с нуля с пустой тратой драгоценного времени.
Мировое произвоство микроконтроллеров растёт, например в прошлом году продажи ARM 32-разрядные выросли на +12%. И для каждого чипа нужна "прошивка" и реализацию потребительских задач. Поэтому-то имеем дефицит программистов. Не успеваем выполнять "хотелки" руководителей и удовлетворять на рынке потребителя...
А вот Oberon 07 для x86 - это тупичок. В качестве обучающей системы - согласен. В качестве платформы для генерации целевого кода для ARM - согласен. Но использовать Oberon 07 для создания приложений в x86 и продавать - тупичок. Для Windows, Linux имеется множество зрелых IDE и целевых языков программирования... Н. Вирт с сотоваришами так и не смогли вывести на массовый рынок среду компиляции Modula-2, Oberon-2, Oberon-7.
Как подправить Ваш проект Oberon-07, чтобы выводить листинг машинного кода для x86?
-
А вот Oberon 07 для x86 - это тупичок. В качестве обучающей системы - согласен. В качестве платформы для генерации целевого кода для ARM - согласен. Но использовать Oberon 07 для создания приложений в x86 и продавать - тупичок. Для Windows, Linux имеется множество зрелых IDE и целевых языков программирования... Н. Вирт с сотоваришами так и не смогли вывести на массовый рынок среду компиляции Modula-2, Oberon-2, Oberon-7.
Если хочется платный Oberon-компилятор для армов (точнее микроконтроллеров армовых), то он уже есть: http://www.astrobe.com/
Так что создание платного компилятора для ARM-микроконтроллеров - это тоже тупик и не интересно :-)
-
Программирую микроконтроллеры с прошлого века, а именно 1987 года: 8080, Z80, 8051, Atmega161, AT91Sam3, PIC18, MSP430, STM32. Начинал с ассемблера. Далее желанный Си. В интернете сейчас, словно лампочек на ночном небе, проектов для микроконтроллеров. И, нет НИ КАКОЙ ПЕРЕНОСИМОСТИ исходных кодов из проектов даже на Си! Каждый новый проект вынужден делать несколько месяцев. Иногда сроки проекта пересекают период больше года. Медленно. Очень медленно. Рукодство часто смотри косо на программеров. Переносимости практически нет, а значит опять строить проект приходтся с нуля с пустой тратой драгоценного времени.
Кстати, а как тут поможет Оберон? Я немного знаком с миром микроконтроллеров, и непереносимость там вовсе не из за ЯП (точнее ЯП там постольку поскольку - Оберон и Си там в равной степени будут вносить свой вклад в непереносимость, как-то решить проблему может, пожалуй, только Ада, и то не полностью, ибо язык всё же вторичен).
Ну и какие преимущества у Оберона (именно у Оберона, не у Оберона-2) перед скажем Модулой-2? ООП в мире микроконтроллеров не нужно. Да и в том виде в котором оно есть в Обероне, оно, скажем так, более-менее хорошо смотрится только в ОберонОС. На тех задачах. Во всем остальном Оберон слабее Модулы-2. В конце концов Оберон изначально спроектирован под среду исполнения со сборщиком мусора, в отличае от модулы. И изначально Оберон - он для рабочих станций (прошлого века правда, но это не важно), с кучей памяти и толстым процессором, а не встроенки.
Так почему Оберон для микроконтроллеров а не Модула-2?
PS. Сам я Оберон знаю много лучше модулы. Ну и поскольку я вложил в него довольно много времени и сил, испытываю к нему некую симпатия, но на вещи нужно смотреть таки трезво.
-
Да не спроектирован он для работы со сборщиком мусора. Но он поощряет использование автоматического упрвления памятью.
Как использовать Оберон в маленьких контроллерах - не очень понятно. На каждый контроллер можно выделить по модулю и взаимодействие модулей может символизировать взаимодействие контроллеров. Но я не думаю, что несколько контроллеров на одном устройстве - это частый случай. Ещё, можно писать по модулю на разные модели контроллеров и эти модули будут являть собой микро-ОС, которые делают общение с контроллером вмеру однородным (эдакие подсистемы Host). Тогда понятно, как можно присобачить абстрагирование (ООП), но возникает проблема с написанием оптимизирующего компилятора, чтобы программа укладывалась в тайминги и помещалась в память.
-
Кстати, а как тут поможет Оберон? Я немного знаком с миром микроконтроллеров, и непереносимость там вовсе не из за ЯП (точнее ЯП там постольку поскольку - Оберон и Си там в равной степени будут вносить свой вклад в непереносимость, как-то решить проблему может, пожалуй, только Ада, и то не полностью, ибо язык всё же вторичен).
1. Никлаус Вирт, Проектирование системы с нуля. // [текст].-М.-Журнал Мир-ПК, №9, 2002 г. - http://oberon2005.oberoncore.ru/paper/scratch.pdf (http://oberon2005.oberoncore.ru/paper/scratch.pdf)
Система Oberon представляет собой однопользовательскую однопроцессную
многозадачную систему, ориентированную на рабочую станцию. Она разрабатывалась не на базе уже существующего программного обеспечения,
а фактически с нуля. В этой статье освещается последовательность шагов проектирования, которая постепенно привела к построению полной системы. Данный проект в значительной степени использовал такой прием, как раскрутка
(bootstrapping), который применялся как по отношению к разработке компилятора, так и по отношению ко всей системе в целом.
Кратенько и точно обосновываются преимущества Оберона (именно у Оберона, не у Оберона-2) перед скажем Модулой-2...
"... В конце концов Оберон изначально спроектирован под среду исполнения со сборщиком мусора, в отличае от модулы..."
К компилятору это никак не относится. Это реализация OS Oberon, т.е. надстройка для конкретной реализации.
"... И изначально Оберон - он для рабочих станций (прошлого века правда, но это не важно), с кучей памяти и толстым процессором, а не встроенки..."
Oberon "поселили" на компьютере LILITH:
состоял из четырех процессорных наборов Am2901, выполненных на плате, а
не в кристалле (bit-slice). Частота его была 7 МГц, длина слова и ширин а шины 16 разрядов. Оперативная память многопортовая (128 Кбайт). Дисплей, как и
в случае Xerox Alto, был вертикальным, размером 15" (592х768 точек), в качестве диска использовался Honeywell-BullD-120 емкостью 10 Мбайт. Ну и, конечно, имелась трехкнопочная мышь.
Наш случай для ARM. :) Прошлый век перебрался в один кристалл кремния.
"...PS. Сам я Оберон знаю много лучше модулы. Ну и поскольку я вложил в него довольно много времени и сил, испытываю к нему некую симпатия, но на вещи нужно смотреть таки трезво...
Нас уже двое. :)
Установил Astrobe Oberon for Cortex-M3 Microcontrollers (Astrobe website at http://www.astrobe.com (http://www.astrobe.com)/for details of what is included in each edition.) и на днях испытаю примеры Oberon-07 на кремневом камне ARM LPC.
-
http://www.ocp.inf.ethz.ch/forum/index.php?topic=766.0 (http://www.ocp.inf.ethz.ch/forum/index.php?topic=766.0) - Sources for AOS Oberon for ARM, or ARM Compiler
http://matthias.dnsdynamic.com/oberon/doku.php?id=alo (http://matthias.dnsdynamic.com/oberon/doku.php?id=alo) - ARM Linux Oberon
-
Программирую микроконтроллеры с прошлого века, а именно 1987 года: 8080, Z80, 8051, Atmega161, AT91Sam3, PIC18, MSP430, STM32. Начинал с ассемблера. Далее желанный Си. В интернете сейчас, словно лампочек на ночном небе, проектов для микроконтроллеров. И, нет НИ КАКОЙ ПЕРЕНОСИМОСТИ исходных кодов из проектов даже на Си! Каждый новый проект вынужден делать несколько месяцев. Иногда сроки проекта пересекают период больше года. Медленно. Очень медленно. Рукодство часто смотри косо на программеров. Переносимости практически нет, а значит опять строить проект приходтся с нуля с пустой тратой драгоценного времени.
За счёт каких качеств Оберона код должен получиться переносимым, в отличие от Си?
-
За счёт каких качеств Оберона код должен получиться переносимым, в отличие от Си?
Процесс создания полезного приложения:
(1) "Програмист" -> "Текст программы" -> "Oberon" -> "C" -> "ASM" -> "Машинный код камня".
! "Oberon" -> "C" - перевод в код Си - это как стихи А. Пушкина перевести на зулу́сский язык. Тогда уж лучше писать просто на Си, т.е. "нативно" в рамках стандарта C89 или C99.
(2) "Програмист" -> "Текст программы" -> "Oberon" -> "ASM" -> "Машинный код камня".
Этот вариант уже интереснее. Можно быстро адаптировать фонд исходных кодов на языке Oberon. Сам синтаксис не меняется, а лишь меняется реализацию перевода синтаксического дерева в целевой код микроконтроллера.
(3) "Програмист" -> "Текст программы" -> "Oberon" -> "Машинный код камня".
Этот вариант предложил Н.Вирт и реализовал в системе Oberon. Именно это и позволяет получить однопроходный вариант компилятора с языка Oberon.
Самый компактный синтаксис у Oberon. Можно построить вокруг и статические анализатора кода, и хранение исходного кода проекта не в текстовом виде, а в виде объектов синтаксического дерева с атрибутами...
"Программа — не текст, а набор конструкций".
Отправляю Вас почитать отличный материал автора компилятора "Странник".
1. Андрей Андреев, Эволюция современных языков программирования. // [текст].-М.- "Мир ПК ".- № 03, 2001. - http://www.osp.ru/pcworld/2001/03/161246/ (http://www.osp.ru/pcworld/2001/03/161246/)
"...
Большинство алгоритмических языков программирования, таких как Си и Паскаль, были созданы на рубеже 60 и 70-х годов. Иными словами, их возраст (за исключением Java) перевалил за третий десяток, что для компьютерной индустрии срок немалый. Они старше Internet, Windows да и собственно ПК не менее чем на десятилетие. Стоит отметить, что новые языки не переставали регулярно появляться, однако ни один из них не задержался в практике программирования, хотя приносимые ими идеи становились достоянием известных языков (как это произошло с объектно-ориентированным программированием).
..."
-
Получился "каменный цветок"
1. Заехал в питерский "Чип и Дип" и приобрёл за 1040 руб. отладочную плату:
LPC-P1343 - отладочная плата на базе микроконтроллера LPC1343 с ядром Cortex-M3 и тактовой частотой до 72 МГц. Микроконтроллер имеет 32 кБ Flash-памяти и 8 кБ ОЗУ.
2. Скачал и установил AstrobeM3EvalSetup.zip
3. При установке на Windows XP Astrobe Oberon for Cortex-M3 Microcontrollers попал в каталог: 'C:\Program Files\AstrobeM3 Evaluation Edition' Внимание! Этот путь не работает!!
При попытке сделать Build примеров в Astrobe (как в Starter M3 так и в Eval)
выходит ошибка переполнения
Переместите каталог Astrobe из каталога "Мои документы" в другое место, чтобы в путях не было кириллицы.
4. Порадовала реализация программирования микроконтроллера. При замыкании переключателя SW через usb платы windows xp увидел как flash-диск. Просто на него нужно положить bin-файл собранного компилятором (у меня пример Blinker.bin).
5. Исправил вывод импульсов на другой пин микроконтроллера там где светодиод.
Исходный код примера на Oberon-07 для камня LPC1343:
IMPORT Main, MCU, SYSTEM, Timer;
PROCEDURE Run();
CONST
(* led connected to pin P0.7 *)
ledBit = {0};
VAR
direction, data: SET;
BEGIN
(* Set led pin as output by setting the direction bit *)
SYSTEM.GET(MCU.GPIO3DIR, direction);
SYSTEM.PUT(MCU.GPIO3DIR, direction + ledBit);
WHILE TRUE DO
SYSTEM.GET(MCU.GPIO3DATA, data);
SYSTEM.PUT(MCU.GPIO3DATA, data + ledBit);
Timer.MSecDelay(500);
SYSTEM.GET(MCU.GPIO3DATA, data);
SYSTEM.PUT(MCU.GPIO3DATA, data - ledBit);
Timer.MSecDelay(500)
END
END Run;
BEGIN
Run()
END Blinker.
ТЕСТ - УСПЕХ!
-
Дисассемблер online для процессоров
Решил дисассемблировать BIN-файл для ARM LPC1343.
1. Онлайн дисассемблер машинного кода. //[электронный ресурс] .- http://onlinedisassembler.com/odaweb/#view/tab-assembly/offset/00000240 (http://onlinedisassembler.com/odaweb/#view/tab-assembly/offset/00000240)
Нужно настраивать сегменты данных и кода, чтобы правильно дисассемблировать для микроконтроллера.
См. скрин страницы сайта.
-
Я бы рекомендовал создать отдельную тему про Оберон. ARM и микроконтроллеры. Текущее обсуждение более не имеет прямого отношения к x86 компилятору Оберона.
-
VladimirV, так Вы так и не ответили, почему программы на Обероне-07 будут более переносимы, чем на сях.
В сях проблема с переносимостью, в основном, это всякие языковые расширения -- распределение переменных в разных областях памяти типа data|idata|xdata, обработчики прерываний. В обероне эта же проблема останется -- в описании оберона ничего не сказано о том, как распределять переменные, прерывания, значит в разных реализациях транслятора это будет сделано по разному (как, собственно, и в сях). В этом плане Ада предпочтительнее -- там есть необходимые для этого средства.
Кроме того, в сях хотя бы есть указание разрядности типов данных (в хедер-файле limits.h), правда, сомневаюсь, что им реально пользуются, ведь то, что необязательно -- почти никогда не используется.
В Обероне-07 с этим тоже проблема -- разные реализации для разных микроконтроллеров будут по разному отводить память под тот же INTEGER -- где-то это будет 16 бит, где-то -- 32 и тд.
Так и как в таких условиях гарантировать переносимость программ на обероне?
-
Кроме того, в сях хотя бы есть указание разрядности типов данных (в хедер-файле limits.h), правда, сомневаюсь, что им реально пользуются, ведь то, что необязательно -- почти никогда не используется.
В Обероне-07 с этим тоже проблема -- разные реализации для разных микроконтроллеров будут по разному отводить память под тот же INTEGER -- где-то это будет 16 бит, где-то -- 32 и тд.
Так и как в таких условиях гарантировать переносимость программ на обероне?
Есть ещё stdint.h - и этим реально пользуются. Типы вроде uin8_t, uint16_t и так далее. Это резко повышает переносимость. Но в Аде конечно лучше.
-
VladimirV,
(1) почему программы на Обероне-07 будут более переносимы, чем на сях.
(2) В сях проблема с переносимостью, в основном, это всякие языковые расширения -- распределение переменных в разных областях памяти типа data|idata|xdata, обработчики прерываний.
В обероне эта же проблема останется
(3) -- в описании оберона ничего не сказано о том, как распределять переменные, прерывания, значит в разных реализациях транслятора это будет сделано по разному (как, собственно, и в сях). В этом плане Ада предпочтительнее -- там есть необходимые для этого средства.
(4) В Обероне-07 с этим тоже проблема -- разные реализации для разных микроконтроллеров будут по разному отводить память под тот же INTEGER -- где-то это будет 16 бит, где-то -- 32 и тд.
Так и как в таких условиях гарантировать переносимость программ на обероне?
(1)*
Что я ожидаю от исходного кода на языке программирования?
Должна работать в других проектах с помощью "import" и копии реализации драйвера переферии или библиотеки. На Си такое не получается. Заголовочные файлы ссылаются на зависимые библиотеки компилятора. Различные версии Си не совместимы. Часто фирмы поставляющие компиляторы немного изменяют синтаксис и код требует большой ручной правки, чтобы перенести в проект.
Я за строгий и очень компактный синтаксис Oberon. Тогда всё что на нём написано может быть быстро перенесено в другие проекты.
(2)*
В Си нет переносимости из-за очень большой свободы для программиста манипулировать с адресной арифметикой, препроцессором, привязки смешивания Си и ассемблера. Различные реализации даже стандартных библиотек. Всегда требуется проверять, тестировать конечную сборку. Когда проекты становятся большими переносимость мучительная и не факт, что удачная. Код может собраться и не работать.
(3)* Как раз это и правильно. Важно, чтобы конструкции Oberon программы компилировались и просто работали в проекте. Пусть реализация спрятана от программиста, который реализует алгоритм. Было бы желательно иметь несколько реализаций на ассемблере, когда по интегральныи оценкам качества можно выбирать лучший фрагмент кода, который и будет использоваться компилятором Oberon.
(4)* Так и пусть переводит. Целевая задача не экономить биты, а получить сразу работающее приложение для целевого процессора.
(5)* Строгость и дисциплина. Oberon же, как я понял, имеет элементы объектно-ориентированного программирования.
Кочно это моё не окончательное мнение. Нужно построить какую-нибудь достойную задачу и тогда станет ясно про сильные и слабые строны Oberon для создания приложений.
-
Часто фирмы поставляющие компиляторы немного изменяют синтаксис и код требует большой ручной правки, чтобы перенести в проект.
Раз производители изменяют язык у которого есть стандарт, то добавить своих расширений в Оберон им тоже никто не помешает. Правда, самому делать нужный компилятор Оберона проще: синтаксис слегка меньшего объёма и нет стандартной библиотеки, которая в си создавалась не под микроконтроллеры.
-
Часто фирмы поставляющие компиляторы немного изменяют синтаксис и код требует большой ручной правки, чтобы перенести в проект.
Раз производители изменяют язык у которого есть стандарт, то добавить своих расширений в Оберон им тоже никто не помешает. Правда, самому делать нужный компилятор Оберона проще: синтаксис слегка меньшего объёма и нет стандартной библиотеки, которая в си создавалась не под микроконтроллеры.
Вот в этом плане с Адой ситуация лучше -- минобороны сша не выдаст сертификат соответствия компилятору, несоответствующему стандарту на язык Ада...
-
Тоже мне проблема... Будут распространять нестандартную Аду.
-
Тоже мне проблема... Будут распространять нестандартную Аду.
Они не смогут дать название своему транслятору "Транслятор языка Ада" -- минобороны сша их по судам затаскает ))
-
Тоже мне проблема... Будут распространять нестандартную Аду.
Они не смогут дать название своему транслятору "Транслятор языка Ада" -- минобороны сша их по судам затаскает ))
Уже нет. Начиная с Ада 95 минобороны не курирует развитие языка и трансляторов.
-
Тоже мне проблема... Будут распространять нестандартную Аду.
Они не смогут дать название своему транслятору "Транслятор языка Ада" -- минобороны сша их по судам затаскает ))
Уже нет. Начиная с Ада 95 минобороны не курирует развитие языка и трансляторов.
фууууу ))
-
Вот в этом плане с Адой ситуация лучше -- минобороны сша не выдаст сертификат соответствия компилятору, несоответствующему стандарту на язык Ада...
Язык АДА в неоплачиваемом долгом отпуске...а аду военном пента-здании. Это не наш путь.
-
К теме использования Oberon для мета-программирования возвращаюсь регулярно. Это очередной вариант. И негативные чувства нежелания сделать ядром технологии базы знаний программиста с IDE у меня так и не прошли. Не вижу "света в конце туннеля"...
Исследовал виртуальную машину Forth VM. Подключаюсь к источнику идей... Но взять за основу эту древнюю технологий - не реально! Мозг сносит надолго. Потерпеть конечно можно, если светит перспектива, однако только "динозаврам" интересно строить мечты продлить жизнь FORTH в больших проектах.
Что-то хотелось другого и правильного для создания и сопровождения проектов на различных языков программирования.
А это уже интересно:
Евгений Зобнин | Хакер №4/11 - http://www.xakep.ru/55752 (http://www.xakep.ru/55752)
Когда десять лет назад Кена Томпсона, принимавшего активное участие в разработке языка Си, спросили, каким бы он сделал этот язык на тот момент, он ответил, что язык был бы похож на Limbo. Прошло немало времени, и Томпсон совместно с еще одним автором языка Си, Робом Пайком, принял участие в создании Go — языка, который стал переосмыслением и последующим развитием Limbo. Go был представлен миру 10 ноября 2009 года и практически сразу стал бестселлером. Одни только имена авторов, известных как создатели операционной системы UNIX, языка программирования Си и кодировки UTF-8, а также покровительство Google, в лабораториях которых был создан язык, дали Go отличный старт.
В основу Go положено три фундаментальных идеи:
Гарантия высокой скорости компиляции и производительности приложений.
Простота разработки и поддержки приложений, свойственная высокоуровневым скриптовым языкам.
Встроенные средства параллельного программирования, позволяющие задействовать все имеющиеся ядра современных процессоров.
Что все это значит на деле? Разберемся с каждым из пунктов.
Go — системный язык, что, тем не менее, не мешает ему быть достаточно высокоуровневым для того, чтобы обеспечить программиста всем необходимым для комфортного и быстрого написания кода. Язык включает в себя такие высокоуровневые конструкции, как ассоциативные массивы и строки (которые можно сравнивать, копировать, вычислять длину, делать срезы). Он имеет средства для создания собственных типов данных (подобных классам в других языках), средства создания потоков и обмена данными между ними, и, конечно же, он лишен указателей, способных ссылаться на любой участок памяти (срыв стека в программе, написанной на Go, невозможен в принципе). Однако главное, что дает Go программисту, это та самая прямолинейность и очевидность синтаксиса, о которой мы говорили в предыдущем разделе. В этом смысле Go очень похож на языки Pascal, Modula и Oberon: практически любой синтаксический элемент языка следует общей логике и может быть явно и безошибочно интерпретирован вне зависимости от его положения в коде.
В дереве проекта RetroForth нашёл ветку VM .\retro-11.6\vm\complete\go\ Развернул GO и собрал реализацию Forth на GO.
Понимаю Робома Пайкома. Кому как не ему ощущать новый горизонт технологий создания программного кода программистами...
-
Понимаю Робома Пайкома.
Вообще-то его зовут Роб Пайк (http://ru.wikipedia.org/wiki/Пайк,_Роб) ;D