OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Сентябрь, 2023 23:18

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 14:23 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Предлагаю обсудить эту тему отдельно. (отсюда https://forum.oberoncore.ru/viewtopic.php?f=134&p=116500#p116500)

arisu писал(а):
по ходу, предложение: на GNU/Linux прибить гвоздями безусловную замену `[ccall]` в парзере на `[ccall16]`. к сожалению, GCC сломали настолько, что `[ccall]` сейчас имеет мало смысла, а замена чинит всё, и ничего не ломает (проверено у себя)



arisu писал(а):

adimetrius писал(а):
А чем ccall отличается от ccall16?
выравнивает стек на 16 байт. бравые парни из GCC давно возложили детородный орган на x86 ABI (который требует только выравнивания на 4 байта), и генерируют код с SSE (в том числе для memory transfers, так что даже не обязательно плавающую точку использовать), который ожидает 16-байтовых выравниваний. и подразумевают, что всё на свете GCC, и всё гарантирует на входе эти 16 байт. `[ccall16]` как раз и реализует хак для такого выравнивания. старому коду плевать, а новый код доволен. недостаток только в чуть более медленном вызове, потому что код для выравнивания надо везде пихать.

adimetrius писал(а):
Если ccall уже точно не нужен, и если он точно равносилен ccall16, то можно, не трогая парсер и не вводя "не верь глазам своим", поменять в документации SYSTEM@Linux и в реализации кодогенератора.
тогда будет проблема с библиотеками: если использовать селекторы, можно делать один модуль для нескольких систем. в винде, например, `[ccall]` вполне достаточно. оборачивать каждое объявление функции в селектор — замахаешься, так что проще сделать подмену в парзере, и не мусорить в коде. это всё равно системная фишка, зависящая от ABI конкретной ОС и архитектуры, так что компилятор вправе подменять её на то, что будет работать для конкретной цели, мне кажется.

p.s.: на самом деле всё сломано ещё кардинальней, и всяческие массивы тоже надо равнять на 16 байт. то есть, если мы передаём в библиотечную функцию буфер, и он не выравнен на 16 байт, то мы играем в русскую рулетку. в идеале надо просто сломать кодоген, чтобы он держал инвариант «всё выравнено» автоматически (так и делает GCC), но мне очень эта идея не нравится. не потому что кодоген сломать сложно (это дело нехитрое), а потому что это… неизящно. нужен флажок для локалов, который будет говорить: «этот локал надо выравнять для системного ABI», наподобие `[ccall]` для процедур. что-то типа:
Код:
VAR arr: ARRAY [align16] OF SHORTCHAR;

и кодоген гарантирует, что `arr` будет выравнен на 16 байтов. и то же самое надо для всех остальных типов, на которые требуется передать указатель. синтаксис получается уродливый, но зато можно будет гарантировать, что GCC останется доволен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 14:40 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
А как вы представляете себе "парзер GNU/Linux"? Анализатор в СР2 платформо-независимый.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 15:06 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 110
Откуда: Equestria
норм решение с флажком align16 в массивах/структурах.
а держать стек выровненным замучаешься


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 15:30 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 110
Откуда: Equestria
adimetrius писал(а):
Флажком для процедурных переменных не обойтись, я ведь могу создать безымянную, динамическую переменную-массив, или массив-в-записи, и его пытаться передать платформенной процедуре.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 15:44 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Пускай, конечно, решает. Не на компилятор же это возлагать. Компилятор должен проверять и гарантировать - за руку схватить, если что.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 16:44 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
adimetrius писал(а):
А как вы представляете себе "парзер GNU/Linux"? Анализатор в СР2 платформо-независимый.
ровно так, как я у себя и сделал: универсальная опция по замене в компиляторе, и детект хоста в DevCompiler, который при необходимости ставит опцию (и позволяет override).

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

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

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

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

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

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

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

adimetrius писал(а):
Но, опять же, неясно, в контексте какой задачи? Это сейчас уже есть 32-битные библиотеки, которые нужно вызывать, и которые требуют такого выравнивания? Это libgit2?
да, см выше. это может быть любая библиотека. совершенно любая. не просто «может быть», а на регулярной основе происходило. один из языков, которые я использую — 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, который уже стандарт де-факто.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 19:15 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
После примера с 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)
В других случаях, конечно, это может быть дорого или вовсе невычислимо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 19:51 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
adimetrius писал(а):
Непонятно другое. Вот вы определили платформу в DevCompiler. А что дальше?
дальше я ставлю флаг в DevCPM.options: «заменять [ccall] на [ccall16]». или наоборот, сбрасываю. ровно так же, как там ставятся/сбрасываются другие флаги.

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

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

adimetrius писал(а):
Как я понимаю, если такие несовместимо различные требования на Вин/Лин, то придется иметь два модуля с интерфейсными определениями, напр SqlLiteWin, SqlLiteLin, и каждому - по отдельной паре ocf/sym.
а зачем? зачем мне на GNU/Linux модуль от винды, и наоборот, если вся их разница — это соглашение о вызове импортируемых функций, и имя библиотеки? да, «просто скопировать Ocf в сборку для другой ОС» в общем случае не выйдет — но это и не надо. просто кросс-компилируем из тех же самых исходников, и получаем дистрибутив для нужной ОС.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Четверг, 05 Январь, 2023 23:44 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 00:01 
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 00:06 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Погодите, а что значит селекторы в модулях? Это получается, что у вас один текст (т.е. одно имя модуля), но при этом два+ разных ocf?
Т.е. ваш модуль не может находиться в многоплатформенном приложении по определению.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 00:13 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Проблему обозначенную про выравнивание - нужно, конечно, решать, чтобы можно было спокойно написать модули-интерфейсы и к либгит, и к sqllite. Но нужно какое-то другое решение, без файловой магии.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 01:36 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
adimetrius писал(а):
Погодите, а что значит селекторы в модулях? Это получается, что у вас один текст (т.е. одно имя модуля), но при этом два+ разных ocf?
Т.е. ваш модуль не может находиться в многоплатформенном приложении по определению.
да. по моей задумке он и не должен: человек скачал компонент, человек поставил (собрал) компонент, человек пользуется. это не часть базовой системы, ей не обязательно не конфликтовать с разными ОС. вся разница для разных ОС там заключается в разных именах динамической библиотеки, всё остальное одинаковое.

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

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

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

adimetrius писал(а):
Проблему обозначенную про выравнивание - нужно, конечно, решать, чтобы можно было спокойно написать модули-интерфейсы и к либгит, и к sqllite. Но нужно какое-то другое решение, без файловой магии.
ну, значит, прибить гвоздями замену `[ccall]` на `[ccall16]` абсолютно везде. это ничего не сломает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 03:29 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
arisu писал(а):
да. по моей задумке он и не должен: человек скачал компонент, человек поставил (собрал) компонент, человек пользуется.

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

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

arisu писал(а):
... иначе мой компонент, ...попросту не соберётся

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 04:29 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
adimetrius писал(а):
Кажется, у нас разная перспектива, и вот почему.
Чтобы сделать LinPorts и WinPorts нужны совершенно разные модули с платформенными определениями.
А чтобы сделать доступ к libgit вам нужно, почти независимо от платформы, одни и те же определения (текстуально одинаковые).
Поэтому вам неохота два разных модуля с одним текстом (исключая название внешней библиотеки). А у меня только так и возможно.
да, вы правы, это несколько разные уровни платформозависимости.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 08:06 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 16:04 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
Иван Денисов писал(а):
Из-за чего вы хотите заменять всё на один ключ?
потому что вызов сишных функций — это `[ccall]`. а `[ccall16]` — хак. я несколько раз в теме расписывал же, включая причины. и я не хотел заменять на один, я хотел такую замену только при сборке GNU/Linux версии. но если охота иметь общие Ocf для всех — то проще всего и заменить для всех.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 17:00 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 17:11 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
это хак идеологически, а не по реализации. прошу прощения, это надо было явно проговорить, а то путаница.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модификаторы ccall ccall16
СообщениеДобавлено: Пятница, 06 Январь, 2023 20:33 

Зарегистрирован: Суббота, 04 Май, 2019 10:21
Сообщения: 29
arisu писал(а):
хак в парзере же вместо более красивого решения я предлагаю для совместимости с существующими исходниками, где уже написано `[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
Код:
ELSIF id = "ccall" THEN num :=  -12(*-10*)


2,Add the align16 syntax as your suggestion
1)DevCPM.GetArraySysFlag, add this line:
Код:
ELSIF (num = 8) OR (id = "align16") THEN
  IF (options * {sysImp, sys386, sys68k, interface, com, som} # {}) & (old = 0) THEN flag := 8 END

2) DevCPV486
Код:
 CONST
  .... union = 7;align16=8;(*add*)

PROCEDURE NegAlign (VAR offset: INTEGER; align: INTEGER);
...
| 8: DEC(offset, offset MOD 8)
| 16: DEC(offset, offset MOD 16) (*add*)

PROCEDURE  GetTypeSize
....
ELSIF typ.sysflag = align8 THEN alignLimit := 8
ELSIF typ.sysflag = align16 THEN alignLimit := 16;(*add*)

PROCEDURE VariablesAlloc
....
DEC(adr, vtyp.size);
IF vtyp.sysflag = align16 THEN NegAlign(adr, 16); (*add*)
ELSE NegAlign(adr, BaseAlign(vtyp, 4));
END;(*add*)

and test the Do's decode
Код:
MODULE ObxAlign16;
   
   IMPORT S := SYSTEM;
   PROCEDURE Do();
      VAR arr: ARRAY [align16] 12 OF SHORTCHAR;
   BEGIN
      arr[0] := 12X;
   END Do;
END ObxAlign16.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2023, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB