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.: «пираты»? это Зан, что ли? так её ещё никто не обзывал. %-)