Board.KolibriOS.org

Ещё один вопросец.
Вот у тебя в документации "Глобальные и локальные переменные инициализируются нулями"
А как быть с теми переменными которые должны инициализироваться определёнными значениями, а не нулём?
Планируется ли как-то решать эту проблему? Это конечно если я всё правильно понимаю.

Разве что, такое устройство языка приводит к некоторому увеличению размера кода и снижению эффективности

Comdiv делал тест накладных расходов при структурном программировании. Вывод у него такой, что не нужно жертвовать структурностью ради возможной копеечной прибавки к производительности.

Кстати, ты сменил лицензию на BSD? Почему?

Maxis wrote:Ещё один вопросец.
Вот у тебя в документации "Глобальные и локальные переменные инициализируются нулями"
А как быть с теми переменными которые должны инициализироваться определёнными значениями, а не нулём?
Планируется ли как-то решать эту проблему? Это конечно если я всё правильно понимаю.

Пока никак не планирую. Для инициализации переменных, просто пишется специальная процедура и вызывается из секции инициализации модуля. Секция инициализации в любом случае, выполняется до первого использования модуля (исключение -- низкоуровневые модули RTL, API, KOSAPI). Конечно, есть неудобство при инициализации структурных переменных. Но я бы не сказал, что мне это сильно мешает. Если же структурных данных очень много, то их можно загрузить из файла.

Maxis wrote:

Разве что, такое устройство языка приводит к некоторому увеличению размера кода и снижению эффективности

Comdiv делал тест накладных расходов при структурном программировании. Вывод у него такой, что не нужно жертвовать структурностью ради возможной копеечной прибавки к производительности.

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

Maxis wrote: Кстати, ты сменил лицензию на BSD? Почему?

Я в этих лицензиях несильно разбирался. Считается, что GPL затрудняет коммерческое использование кода. Тут, конечно, речь не идет о таком использовании, но пусть будет BSD, чтобы не было недовольных (недовольство по поводу GPL в моем коде мне высказывали неоднократно).

akron1 wrote:... Аварийная остановка программы, в случае непредусмотренного значения выражения в CASE, часто сигнализирует о серьезной ошибке и оказывает немалую помощь при разработке программы в блокноте, в условиях отсутствия отладчика. Пока у меня еще остаются сомнения в правильности такого решения Вирта. Всё же, бывают ситуации, когда все возможные значения трудно предусмотреть. Особенно в процессе разработки, когда реализована обработка только части вариантов из нескольких десятков или сотен и надо проверить работоспособность того, что уже сделано, тогда приходится ставить ELSE на пока еще не обработанные варианты.
...

Однако, трап при отсутствии нужного варианта не предусмотрен в лангрепорте по О7.

А прервать цикл можно присвоением итератору цикла, ибо

The for statement
FOR v := beg TO end BY inc DO S END
is, if inc > 0, equivalent to
v := beg;
WHILE v <= end DO S; v := v + inc END

Siemargl wrote:Однако, трап при отсутствии нужного варианта не предусмотрен в лангрепорте по О7.

Это так, но многие реализации считают иначе. В принципе, можно сделать трап отключаемым.

Siemargl wrote:А прервать цикл можно присвоением итератору цикла, ибо

The for statement
FOR v := beg TO end BY inc DO S END
is, if inc > 0, equivalent to
v := beg;
WHILE v <= end DO S; v := v + inc END

Здесь явная недоработка. Как минимум, счетчик надо было сделать доступным только для чтения. А еще лучше, сделать его при этом доступным только изнутри цикла.

Ну что ж, проект KolibriOS, ожидаемо, завершился, но я всё же заменил старый компилятор в дистрибутиве на новый. Компилятор переехал на x86_64, но поддержка x86_32 сохраняется: 64-битная версия производит как 64-, так и 32-битный код; 32-битная -- только 32-битный. Качество кодогенерации примерно соответствует другим неоптимизирующим компиляторам. Появилась базовая поддержка Linux (без dll), текстовые сообщения об ошибках компиляции и др. Поддерживаются исполняемые файлы для Windows32/64, Linux32/64 и KolibriOS. В принципе, можно сделать поддержку Menuet64, но нет мотивации. В будущем, наверно, попробую добавить кодогенерацию для чего-либо отличного от x86.

Как компилировать с Oberon 07под КолибриОС?

Компилировать просто, так же как и для Windows или Linux, только параметр командной строки отличается:

Если компилировать из самой KolibriOS, то надо взять последнюю ночную сборку, запустить приложение RUN (главное меню -> запуск программы) и набрать:
путь к компилятору, путь к главному модулю, параметр "kos", параметр "-out" и имя выходного файла:

/cd2/1/kolibrios/develop/oberon07/Compiler.kex samples/HW_con.ob07 kos -out /temp0/1/HW_con

Аналогично, если из Windows (64-бит) (компилятор взять с гитхаба):
C:\oberon07\Compiler.exe samples\test.ob07 kos -out samples\test

Из Linux (64-бит) (компилятор взять с гитхаба) набрать в терминале:
/home/live/oberon07/Compiler samples/test.ob07 kos -out samples/test

Если программа компилируется для других операционных систем, то вместо "kos", указывается "console", "console64", "elfexe", "elfexe64" и т. д. В документации к компилятору всё написано, какие надо задать параметры командной строки. Единственное что, 32-битная версия компилятора не может компилировать 64-битные программы. Но если для KolibriOS, то это не критично, а в репозитории находятся только 64-битные бинарники компилятора для Windows и Linux, которые могут компилировать также и 32-битные программы.

rev.7983
Update Oberon07 to the latest version from https://github.com/AntKrotov/oberon-07-compiler

When I try to compile like here, I get error Linux Mint 19 64bit

maxcodehack wrote:When I try to compile like here, I get error

Code: Select all

user@user-pc:~$ '/path_to_SVN/programs/develop/oberon07/Compiler' '/path_to_SVN/programs/develop/oberon07/Samples/HW.ob07' kos -out HW.kex

Akron Oberon Compiler v1.29 (64-bit)
Copyright (c) 2018-2020, Anton Krotov
--------------------------------------------

bad parameter <target>

Linux Mint 19 64bit

Try pass "help" option or something like that, to find out how to use this compiler properly.

Параметры командной строки изменены. "kosexe" вместо "kos". И лучше скачать последнюю версию компилятора.

I get it from SVN
Necessary from github?
Thanks you!

Да, конечно, брать с github. В новой версии исправлены ошибки и улучшен кодогенератор. Кстати, консольные примеры для Windows в папке \samples\Windows\Console можно компилировать для KolibriOS без модификаций (кроме HelloRus.ob07 - там юникод, который в KolibriOS не поддерживается).

What about put github version to SVN? I can do it.

Я утратил доступ к SVN и уже не буду восстанавливать. Если хотите, можете обновить компилятор.
Для этого, возьмите последнюю версию и скомпилируйте сам компилятор для KolibriOS:

Из Windows64
Compiler.exe source\Compiler.ob07 kosexe -out source\Compiler.kex -stk 2

Из Linux64
Compiler source/Compiler.ob07 kosexe -out source/Compiler.kex -stk 2

Полученный файл source/Compiler.kex поместите в корневой каталог, там где находятся бинарники для Windows/Linux.

Компилятор для KolibriOS готов.