OberonCore
https://forum.oberoncore.ru/

почему LSH в SYSTEM?
https://forum.oberoncore.ru/viewtopic.php?f=29&t=6949		 Страница 1 из 1
Автор:  arisu [ Пятница, 09 Июнь, 2023 07:59 ]
Заголовок сообщения:  почему LSH в SYSTEM?
собственно, сабж. почему LSH осталось сидеть в SYSTEM, хотя BITS разрешили штатно? пока BITS не было, можно было мотивировать тем, что LSH заточено на битовое представление чисел, так что оно логично спрятано в системно-зависимой части. но когда появился BITS, то LSH — это же просто `ORD(BITS(ASH(c, -1)) * {0..30})`, только через афедрон и с лишними операциями. если уж возможность «видеть» целое как набор битов сделали штатно — нет больше никакого смысла прятать LSH.

как вы считаете, это просто омики недосмотрели (ну, не надо было им, вот и забыли), или есть какая-то ещё причина? потому что я сильно склоняюсь к тому, что это просто недосмотр, и LSH надо из SYSTEM вытащить. как и ROT, кстати, которое с BITS тоже спокойно реализуется без SYSTEM, но ещё более неудобно.

то есть, добавление BITS мгновенно прибивает гвоздями представление целых как 2-complement, и больше нет никакой причины прятать «беззнаковые» операции в SYSTEM.
Автор:  Борис Рюмшин [ Пятница, 09 Июнь, 2023 11:14 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
Я бы поддержал вынос, поскольку эти операции активно используются в криптографии и преобразованиях протоколов. И это, по сути, просто математика, а не системщина. Но вот вопрос в том, что у вас компилятор уже сильно отличается, а хочется в основной это внедрить. Кстати, доступ через SYSTEM, естественно, тоже должен сохраниться для обратной совместимости.
Автор:  arisu [ Пятница, 09 Июнь, 2023 12:05 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
да там внедрить не проблема: копипаста ровно двух строчек в DevCPT. в SYSTEM, конечно, тоже оставить, вы правы. это с точки зрения компилятора особые процедуры со своими уникальными идентификаторами. сейчас они регистрируются только в пространстве имён SYSTEM, а я предлагаю дополнительно их зарегистрировать ещё и в основном. дальше оно будет Просто Работать.

в DevCPT, после
Код:
EnterProc("BITS", bitsfn);

тупо добавляем:
Код:
EnterProc("LSH", lshfn);
EnterProc("ROT", rotfn);

that's it. и DevAnalyzer тоже их магически увидит.
Автор:  Sergej Durmanov [ Пятница, 09 Июнь, 2023 20:42 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
а что будет, например, после LSH(x, 36)
Автор:  arisu [ Пятница, 09 Июнь, 2023 20:57 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
точно то же самое, что и после `ASH(x, 36)` — UB будет. а вот для `ASH(x, y)` таки делается проверка диапазона, и будет трап. почему не проверяются константные сдвиги — я не знаю.

(ASH, LSH и ROT обрабатываются одним и тем же кодом в кодогене, так что между ними можно различий в данном случае не делать.)
Автор:  Sergej Durmanov [ Суббота, 10 Июнь, 2023 08:03 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
это и есть ответ на вопрос: почему эти операции были в простран,тве имён system.
Автор:  arisu [ Суббота, 10 Июнь, 2023 08:36 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
мягко намекаю, что ASH не было в пространстве имён SYSTEM. равно как и BITS. об чём и спич в начальном посте.
Автор:  Sergej Durmanov [ Суббота, 10 Июнь, 2023 15:10 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
ASH тоже должна была быть в SYSTEM, как это было даже в Активном Обероне. Но совместимость с унаследованным кодом оригинального Обероне (1990), требовала, чтобы ASH была доступна в глобальном пространстве, остальные сдвиги там были опциональны и находились в SYSTEM.
Автор:  arisu [ Суббота, 10 Июнь, 2023 16:30 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
я вообще-то не вижу ни одной разумной причины прятать сдвиги в SYSTEM в любом языке. повторю, что проверки времени исполнения в компиляторе есть. почему их не стали делать для константных сдвигов? ну, видимо, посчитали, что программист всё равно ассертами обвешает. однако ж добавить их намного проще, чем проверки в рантайме (которые, напомню, есть).

итак. мы только что устранили все UB (добавив проверки констант прямо в компиляторе, как он делает, например, с константными индексами массивов). проверки во время исполнения тоже есть. какая ещё осталась причина упрятывать сдвиги в SYSTEM?

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

если мы в Обероне/CP начнём утверждать, что и размеры INTEGER неизвестны, и вообще представление этих самых интегеров непонятно какое, и ходите в SYSTEM за обычными арифметическими операциями, которые буквально от сотворения процессоров натурально на них есть, и широко используются в различных алгоритмах — мы добьёмся ровно того же, чего добились авторы стандарта си. то бишь, все будут ходить в SYSTEM, использовать эти операции, продолжать затачивать код на 2-complement, и считать авторов языка идиотами. очень не без причины, смею сказать.

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

с той же переносимостью у софта на классическом обероне всё равно всё очень-очень плохо, потому что там нет типов SYSTEM.ADDRESS и SYSTEM.SIZET, и все кастуют адреса в тридцатидвухбитные инты и наоборот. никакой SYSTEM от этого не спасает. потому что — внимание! — идея SYSTEM была вовсе не в том, чтобы изолировать все архитектурно-зависимые операции, а в том, чтобы изолировать опасные операции. которые могут нарушить гарантии работоспособности системы. ни ASH, ни LSH, ни ROT, ни BITS эти гарантии нарушить не могут — а поэтому им не место в SYSTEM. всё, что делает помещение их в SYSTEM — заставляет импортировать SYSTEM там, где он не нужен, создавая ложное впечатление опасности безопасного модуля.

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

как-то вот так.
Автор:  arisu [ Суббота, 10 Июнь, 2023 16:37 ]
Заголовок сообщения:  Re: почему LSH в SYSTEM?
p.s.: указание в спеках языка требований к размерам и точному битовому представлению интов, кстати, повышает переносимость кода, а не понижает.

к сожалению, омики сделали ещё одну ошибку в спеках, не специфицировав разрядность промежуточных вычислений для чисел с плавающей точкой. в итоге я уверен, что есть код, который ожидает FPU и промежуточное в 80 бит, что весьма затрудняет перенос на архитектуры, где такого FPU нет, а промежуточные, например, те же IEEE doubles. стоило в самом начале запретить FPU так делать, и в спеках чётко прописать, что промежуточные для REAL всегда REAL, что REAL всегда IEEE, и что промежуточные для SHORTREAL — тоже REAL, а обратно с округлением (которое тоже чётко специфицировать).
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/