OberonCore

Предлагаю обсудить эту тему отдельно. (отсюда https://forum.oberoncore.ru/viewtopic.php?f=134&p=116500#p116500)

А как вы представляете себе "парзер GNU/Linux"? Анализатор в СР2 платформо-независимый.

Далее: на 32-разрядной Windows ничего не меняется. Платформа не меняется. Зачем что-то менять в компиляторе?
На 32-разрядной Линукс вроде тоже ничего не меняется. И там, где нужно, стоят в интерфейсных модулях ccall16. А где не нужно - ccall. А если нужно поменять - то нужно ж поменять, в интерфейсных модулях для Линукс.

Непонятно про библиотеки. Сейчас схема такая:
Универсальный модуль <- Платформенный модуль <- Интерфейсный модуль с [ccall], [ccall16].
Ports <- LinPorts <- LinGtk2Gdk
Ports <- WinPorts <- WinGdip

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

Но, опять же, неясно, в контексте какой задачи? Это сейчас уже есть 32-битные библиотеки, которые нужно вызывать, и которые требуют такого выравнивания? Это libgit2?

норм решение с флажком align16 в массивах/структурах.
а держать стек выровненным замучаешься

пускай модуль-прослойка решает вопросы выравнивания указателей и перепаковки стурктур когда это надо.

Пускай, конечно, решает. Не на компилятор же это возлагать. Компилятор должен проверять и гарантировать - за руку схватить, если что.

ровно так, как я у себя и сделал: универсальная опция по замене в компиляторе, и детект хоста в DevCompiler, который при необходимости ставит опцию (и позволяет override).

я же написал: сломан x86 ABI, а не x86_64. именно в этом и проблема. у меня, если что, 32-битная система. не гибрид. и этот поломаный ABI в своё время мне хорошо попортил жизнь, пока я не разобрался, что происходит.

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

а теперь представим, что я делаю обёртку для SQLite, например. и у меня всё в ней отлично, имя .so/.dll выбирается селектором… и я вынужден вместо каждого `[ccall]` тоже ставить селектор. выполняя ровно ту механическую работу, с которой прекрасно справляется транслятор вообще без моего участия.

поэтому я и говорю, что всё на самом деле намного хуже, и авторы GCC конкретно подгадили всем. увы.

выравнивание динамики более-менее можно захачить средствами языка. захачить так же выравнивание локальных переменных — в общем случае операция опасная, потому что нигде в стандарте языка не гарантируется, что переменные на стеке идут строго в порядке объявления в VAR, что компилятор их не объединяет, и ещё есть множество нюансов. введение подобного флага позволит свести платформо-зависимые трюки до минимума.

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

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

да, см выше. это может быть любая библиотека. совершенно любая. не просто «может быть», а на регулярной основе происходило. один из языков, которые я использую — D. официальный компилятор dmd там тоже не делает таких выравниваний на 32-х битах, и вот оттуда я и знаю про этот баг в GCC. потому что совершенно легальный дишный код, взятый копипастой из си — в си работал, в ди падал. пришлось смотреть дизасм сишных либ, а потом кодоген GCC. и обнаружилось, что GCC выравнивает стек один раз в начале исполнения программы, и потом везде поддерживает инвариант «выравнено на 16 байт». и ожидает того же самого от всех остальных.

проблема, повторюсь, в кодогенераторе GCC, который обожает генерировать SSE-команды для пересылки данных. простое присваивание структур (а это используется в си довольно часто) может быть сделано через загрузку и запись SSE-регистров, потому что так быстрее получается на машинном уровне. копирование массивов. и ещё масса неочевидных ситуаций, где встречается необходимость копировать данные в памяти, и они больше машинного слова. достаточно собрать какую-нибудь сишную библиотеку с `-march=native` (даже какого-нибудь древнего `-march=pentium4` уже достаточно!) — и всё, мы только что заложили недетектируемую во время компиляции CP-кода мину.

поэтому на данный момент — к сожалению — можно сказать, что как минимум для GNU/Linux использовать `[ccall]` нельзя в принципе, только `[ccall16]`. однако для других систем это излишне (`[ccall16]` добавляет пролог и эпилог к каждому вызову, который на других системах совершенно не нужен). и если поправить код, входящий в системные модули, несложно, то заставлять программиста править все его личные/сторонние модули-импорты, и поддерживать две версии модуля для разных систем вместо того, чтобы починить компилятор — мне кажется не самым лучшим решением.

а это будет именно починка компилятора, потому что технически флаг `[ccall]` обозначает не конкретную реализацию, а намерение программиста: «я хочу вызвать внешнюю функцию, написаную на си, и чтобы оно Просто Работало». заставлять программиста зачем-то думать, где какие стандарты вызова внешних функций — лишает этот флаг смысла. тогда с таким же успехом мы можем заставить программиста каждый раз явно прописывать, как и какие параметры передавать, что на стеке, что на FPU, и прочая. гибко? да. удобно? нет. `[ccall]` и был придуман, чтобы скрыть эти детали. а `[ccall16]` — это платформо-зависимый хак, который вообще не должен был быть показан программисту. но на то время, когда его сделали, было не очень ясно, что происходит. теперь ясно: изменился ABI. поэтому надо привести стандарный флаг `[ccall]` в соответствие с новым ABI, который уже стандарт де-факто.

После примера с SQLite стало понятно, какую конкретно задачу вы решаете.

Непонятно другое. Вот вы определили платформу в DevCompiler. А что дальше? Компилятор должен сделать машкод, не зависящий от Win/Lin. Ocf зависит от архитектуры, не от ОС. Т.е. для i386 одному модулю должен соответствовать один ocf. Как тут помогут селекторы и определение платформы в DevCompiler?

Как я понимаю, если такие несовместимо различные требования на Вин/Лин, то придется иметь два модуля с интерфейсными определениями, напр SqlLiteWin, SqlLiteLin, и каждому - по отдельной паре ocf/sym.

Про проверки - я там использовал "заведомо". Если дано
PROCEDURE [gcc] P* (VAR a: ARRAY OF CHAR);
и модульная переменная
VAR array: ARRAY N OF CHAR;
то компилятор может сообразить, допустимо ли
P(array)
В других случаях, конечно, это может быть дорого или вовсе невычислимо.

дальше я ставлю флаг в DevCPM.options: «заменять [ccall] на [ccall16]». или наоборот, сбрасываю. ровно так же, как там ставятся/сбрасываются другие флаги.

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

как я уже сказал, я считаю, что для каждой ОС должна быть отдельная сборка «с нуля». благо, BBCB пересобирается за считаные секунды. соответственно, в скрипте полной пересборки я явно указываю селектор-цель. а автоматическое определение платформы в DevCompiler используется уже в нормальном процессе разработки «изнутри коробки».

а зачем? зачем мне на GNU/Linux модуль от винды, и наоборот, если вся их разница — это соглашение о вызове импортируемых функций, и имя библиотеки? да, «просто скопировать Ocf в сборку для другой ОС» в общем случае не выйдет — но это и не надо. просто кросс-компилируем из тех же самых исходников, и получаем дистрибутив для нужной ОС.

собственно, теперешнее разделение подсистем на Win/Lin/Bsd — это отчасти костыль от неумения BBCB кросс-компилировать себя с нуля в отдельный каталог, заодно подтягивая туда все остальные нужные файлы (документацию, исходники, etc.). а если у нас появится кодоген под ARM, то?.. то всё, схема сломалась, и мы стремительно приближаемся к комбинаторному взрыву.

то есть, это можно частично эмулировать при помощи "/USE", я полагаю, но скрипты сборки это не используют. и копировать недостающие файлы не умеют.

Говорят, "Ладил мужичок челночек, а свел на уховертку". А у вас наоборот получается: начали с уховертки ("в парзере слегка подправим"), а закончили эпохальным предложением - ввести новую платформу в формат ocf и поменять подход к многоплатформенности.

Собственно, мы 5 минут назад ушли от перенацеливания при компиляции ББ. Сейчас компиляция - сразу всего набора модулей, для всех поддерживаемых платформ.
Это потребовало уникальности имен модулей.
Таким образом, ББ - это многоплатформенное приложение. Одна команда - и оно компилируется целиком, для всех платформ. Благо, делается это за считанные секунды.

Далее, есть универсальные модули, а есть платформенные. Конечно, в дистрибутив для платформы П нет нужды включать модули от платформы Н.
Но эта задача - составления дистрибутива - решается выкопировкой нужного подмножества файлов. А не "частичной компиляцией для платформы П".
Выкопировка обеспечит, что у вас на Линукс не будет файлов от Виндофс.
В настоящее время эта задача выкопировки - и, что важнее, выделения подмножества - не решена.
(Кроме выделения подмножества, выкопировка может включать или не включать тексты и символы модулей.)

Иван настаивает, что это нужно делать вручную - скопировал нужные папки, и вот тебе дистрибутив. Я считаю, что нужно автоматизировать, и у меня уже есть частичное решение, которым я пользуюсь.

Погодите, а что значит селекторы в модулях? Это получается, что у вас один текст (т.е. одно имя модуля), но при этом два+ разных ocf?
Т.е. ваш модуль не может находиться в многоплатформенном приложении по определению.

Если я правильно понимаю, по принятому сейчас правилу именования файлов эти файлы оцф не должны никогда встречаться, т.е. их надо как-то хранить в разных местах, разных папках, и это все дополнительное именование выходит за рамки принятого в Dev. Т.е. это возвращение к файловой магии, от которой мы старательно уходили.

Проблему обозначенную про выравнивание - нужно, конечно, решать, чтобы можно было спокойно написать модули-интерфейсы и к либгит, и к sqllite. Но нужно какое-то другое решение, без файловой магии.

Подумать про будущие возможные архитектуры тоже стоит. В один оцф файл, вроде, нет смысла запихивать и i686, и, напр., android; хотя... Но это стоит обсудить.

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

я вижу некоторый смысл в том, чтобы части базовой системы не конфликтовали (и то, честно признаться, не очень большой при наличии /USE). но для пользовательских компонентов считаю это излишним. копипаста, где отличается только имя .so/.dll — это гарантированый источник ошибок синхронизации, поскольку никакого механизма include или прокси-реэкспорта в BBCB/CP нет. поэтому остаётся или селектор, или оголтелая копипаста.

всё равно все благие начинания по одним и тем же Ocf для разных ОС/архитектур сломаются ровно по прибытию x86_64. это уж не говоря о том, что — какой мне смысл держать в системе код для 64-битной винды, например, если у меня 32-битная GNU/Linux? я даже сборку в таком виде (один Ocf) слабо себе представляю: это компилятору каждый раз надо будет генерировать код для всех возможных сочетаний ОС/архитектура (а потому что у разных 64-битных ОС разный ABI), чтобы получить валидный Ocf? ненененене, я так не играю.

кстати сказать, существующее разделение осей по разным подсистемам уже кусает за афедрон. вот мне надо из либц взять `size_t`, например. и вместо какого-нибудь `IMPORT libc;` я вынужден делать селектор с импортами конкретных либц для всех существующих осей. и надеяться, что порта на какую-нибудь ось, которую я не учёл, не будет никогда, иначе мой компонент, который в принципе мог бы там спокойно работать без изменений, попросту не соберётся. воля ваша, но я в этом подходе smell something wrong.

ну, значит, прибить гвоздями замену `[ccall]` на `[ccall16]` абсолютно везде. это ничего не сломает.

Человеку, конечно, хорошо. Плохо программисту, который делает многоплатформенное приложение - это ему нужно жонглировать файлами, чтобы они друг друга не видели. С помощью /USE и подобных трюков, типа симлинков, (сохраните небеса!).

Кажется, у нас разная перспектива, и вот почему.
Чтобы сделать LinPorts и WinPorts нужны совершенно разные модули с платформенными определениями.
А чтобы сделать доступ к libgit вам нужно, почти независимо от платформы, одни и те же определения (текстуально одинаковые).
Поэтому вам неохота два разных модуля с одним текстом (исключая название внешней библиотеки). А у меня только так и возможно.


Заметьте, что при едином множестве модулей для всех платформ отпадает мутное понятие сборки.
И от рассинхронизации платформенных модулей компиляция моментально помогает.


Ну т.е. вы предлагаете и для Вин тоже все выравнять по 16 байт? Мне лично байт не особо жалко, вроде. Но тогда надо просто везде заменить одно на другое. А не подменять тихоненько.

Селекторы ≈ #ifdef #include.
заменять внутри компилятора [ccall] на [ccall16] ≈ #define TRUE FALSE
Есть же куча языков и тулчейнов, где так уже можно. Зачем в КП это тянуть?

да, вы правы, это несколько разные уровни платформозависимости.

не отпадает, всё ещё надо открывать "Quick-Start.odc", и жать там коммандер «скомпилировать». это я и называю «сборка». вот только если это попытаются сделать на какой-нибудь DragonFlyBSD, например, поддержку которой введут после того, как я компонент выложил — он попросту не скомпилируется («не соберётся» в моих терминах). хотя это такая же POSIX-система, как и все остальные POSIX-системы, и никаких особенных правок для неё не надо.

собственно, необходимо выделить общее для всех POSIX-ос в отдельную подсистему `Posix`, например. чтобы я мог вместо нудного перечисления той же либц для каждой оси просто дёрнуть позикс, взять оттуда нужное — и мой код будет автомагически компилироваться даже на тех позикс-осях, поддержки которых не было в момент написания этого моего кода. но в текущей конфигурации это сделать невозможно, потому что позикс гарантирует некоторые условия, но не, например, точные размеры целых типов навроде `size_t` или `time_t`. поэтому такая подсистема тоже будет зависеть от ОС и от архитектуры, и держать «одну на всех» не получится.

я смотрю с точки зрения программиста, который «просто использует среду». и не вижу для него никакой необходимости держать кучей всё-всё для всех-всех ОС. даже если он пишет что-то кроссплатформенное — он будет выкладывать отдельные архивы с готовым к использованию приложением для GNU/Linux, для BSD, для Windows. ну так заодно и скомпилирует свой код в среде под соответствующую ос: он же не будет выкладывать его без тестов — значит, среду запустить может. может и скомпилировать в ней.

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

снова повторюсь: `[ccall16]` — это хак. он был сделан именно как хак. правильный синтаксис для вызова C-функций — `[ccall]`. он и должен оставаться, а хак надо спрятать. но убирать совсем его нельзя, потому что на свете наверняка уже есть исходный код, который его использует, и просто так этот код поломать будет неправильно. так мы убиваем двух зайцев: сохраняем совместимость со старым исходным кодом, который использует `[ccall]`/`[ccall16]` (ну да, придётся перекомпилировать один раз), и почти полностью убираем проблему «необъяснимых падений».

[ccall16] применяется везде в привязке к линуксовским библиотекам. Нет какого-то платформенно-независимого кода с этим ключом. Поэтому нет ситуаций, где требовалась бы подмена обратно на [ccall], делось как не хак, а как нормальный ключ. Может быть я что-то не до конца понял, но не вижу необходимости что-то менять. Вызов с [cсall] в Windows будет происходить быстрее, чем [ccall16], так как не делается это выравнивание. Также как на Windows не было пока замечено падений из-за выравнивания. Из-за чего вы хотите заменять всё на один ключ?

потому что вызов сишных функций — это `[ccall]`. а `[ccall16]` — хак. я несколько раз в теме расписывал же, включая причины. и я не хотел заменять на один, я хотел такую замену только при сборке GNU/Linux версии. но если охота иметь общие Ocf для всех — то проще всего и заменить для всех.

тут я много (как обычно) текста вывалил, но там, вроде бы, на все ваши вопросы я отвечал. у меня аргументы кончились, если не убедил — ну, не убедил тогда, бывает.

У меня наверняка не хватает квалификации, чтобы понять, почему вы называете [ccall16] хаком. Поддержку этого ключа делал luowy, и он там достаточно качественно пропатчил всё для поддержки этого ключа. Я не думал, что это какой-то хак. И никто такого мнения не высказывал до вас. Сишные библиотеки, как выяснилось, бывают разные, поэтому и ключи разные.

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

сишные библиотеки не бывают разные (в данном случае), это GCC забагован (несмотря на то, что его разработчики так не считают). `[ccall16]` — это идеологический хак для обхода бага GCC. идеологически же, вызов си-функций на любой платформе — это `[ccall]`. уважаемый китайский (он же китаец, вроде бы?) товарищ сделал рабочее решение в плане «поддержка обхода бага GCC в компиляторе CP2». теперь надо сделать следующий шаг, и унифицировать обратно `[ccall]`. `[ccall16]` — это, по сути, внутренняя специфика компилятора, которую пользователю показывать не надо. так же, как компилятор не заставляет пользователя описывать точную раскладку стека для передачи параметров. эти кишочки надо упрятать обратно, нечего им наружу торчать.

хак в парзере же вместо более красивого решения я предлагаю для совместимости с существующими исходниками, где уже написано `[ccall16]`.

overhead на вызов довольно neglible, и если его использовать в том числе на windows, то ничего страшного не случится. красиво, понятно, унифицировано. по принципу: «не надо плодить сущности без особой нужды».

As I remember, the [ccall16] patch was used to port SDL2.
SDL2 using the SSE instruction requires an aligned stack. I only work on windows, No linux experience.
However, gcc is known to always align the stack to 16bytes. I didn't know that these array also requires a 16-byte alignment....
the op2 is simple, add such feature is easy, But the difficulty lies in testing and community acceptance;

1,Merging [ccall] and [call16] :
DevCPM.GetProcSysFlag


2,Add the align16 syntax as your suggestion
1)DevCPM.GetArraySysFlag, add this line:

2) DevCPV486

and test the Do's decode