OberonCore

Очень актуальная для меня тема. У себя отказался от longjmp - сделал свой ‘кроссплатформенный jump’. Пока конечно очень примитивный, скорее всего макет. Но исключения перехватывает на всех OS. Хочу прикрутить к нему раскрутку стека (если мозгов конечно хватит) !!!

я лично в Oberon/Ur на сигналы от ОС просто забил. сегфолта не должно произойти никогда, а если произошёл — там нечего ловить, там надо сразу падать: разыменование NIL проверяется кодом явно. деление на ноль тоже. любой «штатный» трап вызывает внутреннюю процедуру из Kernel, которая опционально показывает backtrace, и разматывает стек до глубины, на которой находится последний поставленый TRY (а если его нет — то собираем мусор, чтобы вызвать финализаторы, и `abort()`). поскольку у меня явный список стековых карт, то и бэктрэйсы, и разматывание стека — тривиальный поход по обычному списку.

Ormcode для Linux X11 X86-64. Две сборки вместе. Первая (scode.elf, snote.elf) с использованием библиотек libxcb.so и libxkbcommon.so, вторая (xcode.elf, xnote.elf) на основе стандартной xlib библиотеки. Можно сравнивать параллельно. Обе позволяют готовить исполняемые файлы в обоих вариантах. Соответствующие примеры в папке ../BEXM/.

На этом считаю эксперимент с xcb+xkb завершенным. Если он окажется удачным, то будет целых два взаимозаменяемых варианта X11 . . . ВАУ . . . !!!

Основная причина почему, конечно убрать непонятную ошибку: «xcode.elf: ../../src/xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.» Иногда проще переписать, чем искать нечто . . . , в чем то . . . ???

Из мистического. В тестовом примере xkb при нажатом shift выдает кодировку в верхнем регистре (как положено). В окончательном варианте xkb изменило свое поведение на прямо противоположное. При нажатом shift в нижнем регистре, отпущенном - в верхнем. Поправил конечно программно, там две строчки. Но мистика не иначе (((.

Ещё, по ощущениям стало чуть быстрее. Хотя при общей тормознутоности моих Linux, может и кажется. Самым быстрым оказался Armbian. И это понятно. Ноль наворотов, черный экран по умолчанию - сказка относительно остальных вырви глаз ))).

Ormcode - кросс компилятор для Linux X11 X86-64. Две сборки вместе. Исправленная версия. Решил научить рисовать правильные цвета в стандартной цветовой кодировке ARGB. Две ночи не ел, два дня не спал ))). Переставлял маски в bmpimage и visual - не помогло. Затем распечатал все стандартные visual системы Linux в надежде найти подходящий. Оказалось, что все 304 найденых visual - есть bgr, и не одного rgb (((.

Расстроился. Затем вспомнил про замечательный LC. Залез в исходники, и . . . сделал также ))). Теперь Ormcode в правильных цветах. Спасибо за разрешение ))).

По ходу нашел и вычистил пару больших и кучу мелких жуков. Откуда только берутся (((. При этом xkb поменял свое поведение. Перестал путать строчные с прописными. Но в замен стал выдавать 9-ти значные коды для функциональных F1-F24 клавиш ??? Но зато научил его не обращать внимание на порядок расположения кириллица, латиница раскладок клавиатуры в Layout системы ))).

И кому интересно, в архив положил тестовый пример построения GUI приложения на чистом, хотел сказать winapi, но нет голом xcb+xkb x11 api ))).

Заодно обновил (привел в соответствие текущим реалиям) все архивы на сайте: https://ormcode.ru

Михаил, как ваши успехи в разработке?

Есть мнение, что ваш проект уже пора добавить в каталог
https://oberon.org/

Можете небольшой текст предложить для описания?

"Не, не тараписса ненада". Там даже текстовый редактор к повседневной эксплуатации не готов.

)))))))).

Иван, давайте действительно подождем. Хочется сделать реальный кросс платформенный компилятор. И пока Ormcode не дотягивает. Только десктопных недостаточно. Не хватает мобильной платформы. Решил начать с Android !!!.

Пошел по стандартному пути, с реализации байт кода JVM. Оказалось, что впрямую Android не поддерживает JVM. Требуется затем прогнать через компилятор D8 для перевода в байт код Dalvik VM. Появляется лишнее звено (((.

Решил отойти от стандарта и генерить сразу apk. Чуть сложнее. Зато никаких лишних прокладок и сторонних инструментов. На сегодня перегнал инструкции orm (Oberon Risc Machine) в инструкции Dalvik - регистровой машины. Несмотря на похожую структуру (в следствии особенностей реализации) одна orm инструкция превращается в 3-5 инструкций dalvik. А для операций чтения/записи и до десятка доходит. Для примера конвертация orm -> risc-v идёт один в один. Зато понимаю почему Android приложение ‘здравствуй мир’ занимает 1.5Mb (((.

Следующий этап. Формирование dex - исполняемого файла Android. Дошагал до середины. Осталась скучная, неинтересная часть. Архитекторы андроид превзошли даже макосевцев с их мужественным файлом. Придумали восьмое чудо света - башню, чудом не дотянувшую до Вавилонской. Зато с кучей промежуточных уровней и многосвязных сортировок (((.

Решил отвлечься и разобраться с zip форматом. Заодно научится рисовать png картинку. В процессе узнал, что есть еще один графический формат qoi сопоставимый по степени сжатия с deflate, но в 10-ки раз быстрее и проще для реализации. Похоже надо qoi поддержку тоже делать. Если таможня даст добро ))).

декодер пингов есть в LC. и декодер deflate-потока тоже. в пинге там мааааленький баг, правда, но то мелочи — пофиксится как только в первый раз наступить. (проблема с пингами у которых информация о пикселе занимает меньше 8 бит). зато декодер поддерживает (кажется %-) все типы пингов, со всеми фильтрами, умеет декодировать interlaced images, и даже даунсэмплить пинги с 16-битными цветовыми каналами.

ещё там есть стыреный из оригинального оберона декодер жопегов. иногда он даже работает.

а писать пинги можно вообще без компрессии: получится, конечно, жирно — зато быстро, дёшево, и не надо inflate-компрессор сочинать. впрочем, у меня в O/Ur компрессор тоже есть (не порт zlib); если очень надо…