OberonCore

Hershel не смотрели?

конечно смотрел.

следует дополнить, наверное: возможно, тесты оттуда стоит потырить. всё остальное сделано не в том стиле, который я предпочитаю, поэтому мне проще написать заново. это не значит, что плохо: просто не так, как я привык. плюс — я хочу Свою Особую Лицензию.

если новый компилятор случится — то это будет, скорее всего, диалект Oberon/Ur. и поддержки 64 бит в нём точно не окажется, гыг.

>>>> если новый компилятор случится — то это будет, скорее всего, диалект Oberon/Ur. и поддержки 64 бит в нём точно не окажется, гыг.

Очень хочется, чтобы случился ))).

И Вы только не ругаетесь. Возможно ересь скажу. Но у меня в risc получилось именно так, подозреваю с ssa, должно быть также. Промежуточный код - универсальный. Ему по барабану 32 или 64 разряда. Естественно, если компилировать с опцией 32 или 64. А эта опция - не что иное как размер адресного типа. И не важно, как адресный тип представлен. В виде эквивалента целому числу (integer, longint - мой случай), или как у Вас, полностью самостоятельный системный тип, со всеми сопутствующими проверками.

основная проблема с разрядностью в том, что BBCB внутри себя весело кастует указатели в INTEGER и обратно. вторичная — все указатели радостно раздуваются в два раза без практической необходимости. и дополнительная: у меня 32-битная система, меня она устраивает, и ничего менять я не собираюсь. ;-)

И не надо. Потому, что сейчас понимаю. Если такая необходимость случится. Вы это сделаете очень быстро. Особенно учитывая, что программирование 64-х разрядов значительно проще, чем 32-х. Не знаю, многие ли это понимают. Например, мне сделать полноценные 32 разряда не удалось.

да не то чтобы x86_64 чем-то сильно проще, по-моему. регистров больше, это да. для LONGINT можно обычные регистры использовать, а не XMM… тоже мелочь. а calling conventions вот мне кажутся менее удобными. плюс тотальная заточка на PIC-код — который я и для x86 принципиально не делаю, например.

для x86 надо разве что знать, что афедроноруки из gcc плевать хотели на ABI, и если не выравнивать стек на 16 байт (чего ABI не требует) — то очень быстро получим весёлые сегфолты при попытке использовать внешние библиотеки. о том, что это (выравнивание, не сегфолты) давно уже обязательно — никто, конечно, нигде большими буквами не пишет. ну, и довольно своеобразные правила выравнивания в сишных структурах (легко налажать из-за невнимательности). плюс передача структур как аргументов by value поэлементно (всё ещё лучше, чем в x86_64, где в зависимости от размера и типа полей структуры вообще иногда надо в регистры совать).

>>>> да не то чтобы x86_64 чем-то сильно проще, по-моему. регистров больше, это да. для LONGINT можно обычные регистры использовать,

Вы не представавляете, насколько это упрощает жизнь. Вообще ни о чем думать не надо. Бери и пиши ))).

>>>> а calling conventions вот мне кажутся менее удобными.

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

>>>> плюс тотальная заточка на PIC-код — который я и для x86 принципиально не делаю, например.

А это потому, что в x86 нет соответствующей поддержки со стороны процессора (приходиться через фиктивный call с нулевым смещением), а в x64 есть.

>>>> и если не выравнивать стек на 16 байт (чего ABI не требует) — то очень быстро получим весёлые сегфолты при попытке использовать внешние библиотеки

Да здесь, без вариантов. Причем выравнивать надо с учетом адреса возврата запихиваемого в стек. Но только для внешних вызовов. А в внутри выравнивание не требуется. Процессору по барабану.

>>>> ну, и довольно своеобразные правила выравнивания в сишных структурах (легко налажать из-за невнимательности).

Столкнулся с этим, но и в 32 разрядах наверное тоже самое. Хотя как правило продвинутые общепринятые библиотеки предоставляют две версии функции. Во второй, структуры по адресу передаются. По крайней мере в objective-c runtime так.

я в PIC-коде смысла не вижу. когда памяти было мало, машины и диски медленные — отчего-то всех устраивали фиксапы. а как памяти стало дофига, всё обсыпали ссд, и домашние машины считают в реальном времени то, что раньше кластерами считали — у всех внезапно пик зачесался. а может просто не надо писать код, который требует 60 гб диска и 16+ гб памяти для сборки?

Да, мне теперь эти 60 Гб во сне приходить будут ))). Сайт показался таким красивым, синеньким. А то что все остальное ж . . . (((.

А PIC в Windows 64 совсем необязателен. Там, в каком то поле PE32+, что-то надо написать (навскидку не помню, надо смотреть) и грузится по фиксированному адресу. По началу и делал без PIC.

беда многих современных компиляторов: «а давайте притащим LLVM!» на этом месте можно проект выкидывать: если у людей ничего внутри от такого решения не переворачивается — то всё остальное в проекте очень, очень плохо. не можете асилить кодоген — ну компилируйте в сишечку тогда, зачем бяку-то в рот тащить…

Согласен абсолютно. Постоянно посещают такие мысли. Только боялся озвучить. Вдруг неправильно поймут (((. И при этом считают, что если LLVM платформенно независим, то и их компилятор автоматом кроссплатформенный. Наивные ))).

Утащил LC с репозитория к себе. Раньше не получалось, или архива не было, или искал не там. И раза с 10-го, лишь получилось. Развернул на 7-ку. Очень быстрый. Только почему пираты, такие бледные. Вы их, не кормите ))).

там недавно багфикс в ядре (мелкокосяк с выделением больших кусков памяти). увы, мой фоссил-сервер сейчас лежит. впрочем, раз за столько лет никто (включая меня) не заметил — то время терпит. ;-)

p.s.: «пираты»? это Зан, что ли? так её ещё никто не обзывал. %-)

Зан симпотяшка ))).

Вопрос по IS. Сравнил 2 спецификации:
Oberon-2: v IS T stands for "the dynamic type of v is T (or an extension of T)" and is called a type test.
Oberon16: v IS T stands for "v is of type T" and is called a type test.

Решаю задачи. Пусть задана последовательность наследников o0, o1, o2 … oN. Требуется:
1. узнать, что v наследник o3
2. узнать, что v однозначно o3.

Решение: Oberon16:
1. ~(v IS o0) & ~(v IS o1) & ~(v IS o2)
2. v IS o3

Решение: Oberon-2:
1. v IS o3
2. ~(v IS o4) & ~(v IS o5) & . . . & ~(v IS oN) <—- а N то нам неизвестно, и получается ситуация если не UB, то какая-то неопределенность точно.

Тыщу лет знаю BB и всегда придерживался концепции Oberon16. Правда потому, что спецификацию не читал (((. Не может быть такого, что в последующих версиях Оберон и выпилили эту неопределенность, поправив спецификацию ))).

дык! воодушевляет и мотивирует.

я вторые спеки не помню, надо перечитать. но как по мне — это просто избавление от лишних слов. расширение записи является одновременно и родительской записью, и расширеной. так что «or an extension of» — не нужно, оно и так подразумевается.


зачем? вся идея с расширениями типов как раз в том, что этот вопрос не надо задавать: расширение реализует в том числе интерфейс родителя. если надо — то с дизайном кода что-то не так.

выпилили излишнее уточнение, по-моему. никакого смысла в `IS` как проверке «точно это, не расширение» попросту нет. а для всяких извращений у нас есть Meta.

алсо, я тут вспомнил. Зан — она родом из этой игры. автор няша, игра отличная, категорически рекомендую.

Прикольно, прям настольжи пробило ))). Беседы Клиффа. Спасибо за подгон. Колоритный дядька. Напоминает древнего самурая, искореняющего мракобесие в рядах компиляторщиков ))). Жаль, что с разговорным у меня не очень. Только чтение, со словарем (((.

>>>> но вообще, LC сделан так, что ему от оси надо только способ получать оконные сообщения, и возможность кидать на экран картинку (RGBx или BGRx, мы умеем оба формата) из буфера в памяти.

У меня для win, mac, wayland - и rgb и bgr легко. А вот с xlib затык. Не реагирует на переключение. И в bmp заголовке менял и с visual пробовал. Не хочет (((.

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

способ реально рабочий, не продажи, не МММ! ;-) очень рекомендую не пожалеть времени и научиться понимать — без этого тяжко будет. я знаю, что будет: мне очень тяжко было. а с течением времени интересных материалов всё больше. да и вдруг с кем-то поговорить придётся? конечно, произношение будет ужасным, построение фраз корявым — ну и что? когда какой-нибудь индиец на английском говорит — у меня уши трубочками. но ничего, понять можно.

ну так у меня же исходник есть! ;-) LC может в двух режимах работать: если есть XShm — то с отображённым в общую память битмапом; если нет — будет честно отсылать битмап по сети. я официально разрешаю посмотреть в мою реализацию портов и забрать что надо не соблюдая GPL.

p.s.: а рисовать, рисовать по LC пробовали? зажимаем правую кнопку и рисуем знак вопроса, например. или маленькую букву «e» начиная с горизонтальной палочки. по-моему, это уберкрутая фича — а никто не оценил! T_T

Ok, спасибо. Вовремя к себе LC утащил ))). А, ссылку на авторство все равно в исходник приклею, под кодовым именем arisu ))). Случайно, это не перевод имени с японского и, что нас ждет много чудес . . . , в стране чудес ???.

совершенно не случайно, и совершенно верно. и японскую стилизацию угадали, и отсылку к книге.