OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 08 Январь, 2026 04:15

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




Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 01 Январь, 2026 16:31 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
я не совсем про это. я про прикидывание качества prng для конкретной задачи. типа: «а надо ли нам тут такое крутое, или можно обойтись чем попроще, даже если оно biased?

Какой в этом практический смысл, если xoroshiro++, PCG, SFC64 или KISS99 сразу дают достаточное для подавляющего числа задач качество?

Цитата:
но зачем? решение уже давно придумано: интерфейс и реализация. делаем абстрактный интерфейс, при старте загружаем системно-зависимую реализацию.

Скорее из спортивного интереса и как конкуренцию minstd. И реализация 64-битных целых через FPU - это очень странно, т.к. большинство современных компьютеров на аппаратном уровне поддерживают 64-битные целые. Получается, у нас остаются генераторы, генерирующие 31-битные положительные целые, использующие только 32-разрядную целочисленную арифметику и запрещающие переполнение. Тогда круг ГПСЧ резко сужается. Но ситуация тут не безнадёжная.

ScrollLock писал(а):
Избежать -fwrapv можно достаточно легко, вовремя проставляя unsigned
а можно просто отучить компилятор предполагать глупости. я смею утверждать, что абсолютно весь реально используемый си-код более-менее высокой сложности так или иначе полагается на то, что целые — 2-complement.

Цитата:
unsigned же лучше вообще использовать как можно меньше

Если нужны целые с переполнениями, особенно известного размера, то обычно используют вообще типы из stdint.h. И uint32_t или uint64_t приходится видеть часто. Ибо размер unsigned int и особенно unsigned long мы точно не знаем.

Цитата:
for (unsigned f = len - 1; f >= 0; f -= 1) { … }

Обычно длина массива или строки - это не int, это какое-то платформенно зависимое беззнаковое целое типа size_t. И в int оно на большинстве компьютеров не помещается.

Цитата:
или просто прибить гвоздями расфачивание компилятора в сборочных скриптах

Весь вопрос - не попадет ли код куда-то в другой проект, где таких ключиков нет? Или вообще в другой компилятор?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Январь, 2026 16:45 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
Какой в этом практический смысл, если xoroshiro++, PCG, SFC64 или KISS99 сразу дают достаточное для подавляющего числа задач качество?
практический смысл появляется когда у нас нет «стандартной библиотеки», и эти штуки надо запиливать руками.

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

ScrollLock писал(а):
Весь вопрос - не попадет ли код куда-то в другой проект, где таких ключиков нет? Или вообще в другой компилятор?
не попадёт. все мои проекты требуют gcc, и везде прибито гвоздями. а если кто-то пытается забрать код не дав себе труда разобраться с требованиями — то это уже не мои проблемы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Январь, 2026 16:55 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
практический смысл появляется когда у нас нет «стандартной библиотеки», и эти штуки надо запиливать руками.

Как раз те некриптографические алгоритмы запилить достаточно просто. А если так - то брать для самостоятельной реализации надо брать нечто проходящее BigCrush, PractRand и обладающее гарантированным периодом.

Цитата:
а практически строка размером больше двух гигабайт — уже беда кода.

Мне иногда бывали полезны массивы размером больше 2 гигабайт в памяти, и в некоторых специфических случаях они бывают полезны. Но даже если такие большие массивы не нужны, то знать о том, что в malloc или strlen никакого int в качестве размера нет - надо.

Цитата:
все мои проекты требуют gcc, и везде прибито гвоздями. а если кто-то пытается забрать код не дав себе труда разобраться с требованиями — то это уже не мои проблемы.

Да, это выход. Но лично мне бывает проще сразу писать так, чтобы компилятор "лечить" было бы не нужно. Тем более мой код могут компилировать каким-нибудь MSVC или CLang.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Январь, 2026 17:40 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
Мне иногда бывали полезны массивы размером больше 2 гигабайт в памяти, и в некоторых специфических случаях они бывают полезны.
почти наверняка это были не байтовые массивы, и элементов в них было меньше 2^31. впрочем, я не спорю, что иногда такое может быть надо. но это скорее исключения, и для подобных исключений вполне подойдёт использование процедур, а не короткого синтаксиса. ну, я так считаю.

ScrollLock писал(а):
Но даже если такие большие массивы не нужны, то знать о том, что в malloc или strlen никакого int в качестве размера нет - надо.
знать надо. но можно игнорировать. как, например, делает автор SQLite, принимая в API в качестве длины строки как раз int.

ScrollLock писал(а):
Да, это выход. Но лично мне бывает проще сразу писать так, чтобы компилятор "лечить" было бы не нужно. Тем более мой код могут компилировать каким-нибудь MSVC или CLang.
я предпочитаю писать код так, как удобно мне, а не как показалось «правильно» авторам дурацкого стандарта. именно потому, что стандарт дурацкий. даже до авторов это постепенно доходит — вон, в новых крестах размеры целых, наконец, гвоздями приколотили. а в новой сишечке наконец-то заметили, что у нас вся техника, имеющая какое-либо практическое распространение — 2-complement.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Январь, 2026 18:13 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
использование процедур, а не короткого синтаксиса. ну, я так считаю.

А разве size_t - не короткий синтаксис?

arisu писал(а):
что у нас вся техника, имеющая какое-либо практическое распространение — 2-complement.

Там не только в конкретном двоичном представлении знаковых целых дело, а именно что в неопределенном поведении при переполнении знакового целого. Насколько я знаю, C23 эту проблему не устраняет. Возьмём вот такой код:
Код:
typedef struct {
    uint32_t x;
} Lcg32State;

static inline uint64_t get_bits_raw(void *state)
{
    Lcg32State *obj = state;
    uint16_t x_lo = (uint16_t) (obj->x & 0xFFFF);
    uint16_t x_hi = (uint16_t) (obj->x >> 16);
//    obj->x = (uint32_t)63885 * x_lo + x_hi;
//  Causes a glitch in GCC 10 (some UB during optimization?)
    obj->x = 63885 * x_lo + x_hi;
    return obj->x;
}

При компиляции с ключом -O3 под GCC без -fwrapv он ведёт к тому, что функция get_bits_raw может возвращать 64-битное беззнаковое целое, в старшей половине которого - FFFFFFFF.

arisu писал(а):
вон, в новых крестах размеры целых, наконец, гвоздями приколотили

В каком именно стандарте и каких именно целых? Целые типы с "гвоздями приколоченными" размерами ввели уже очень давно, в C++11, в cstdint. А вот размер long в MinGW и gcc под Linux до сих пор может быть разный.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Январь, 2026 20:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
Там не только в конкретном двоичном представлении знаковых целых дело, а именно что в неопределенном поведении при переполнении знакового целого.
а не определено оно именно потому, что стандартизаторы побоялись постулировать формат знаковых целых и модульную арифметику. и пофигу, что весь код (санс небольшая статистическая погрешность) написан подразумевая 2-complement и враппинг: не будем мы это в стандарт вносить, лучше побольше UB накидаем, так веселее.

ScrollLock писал(а):
При компиляции с ключом -O3 под GCC без -fwrapv он ведёт к тому, что функция get_bits_raw может возвращать 64-битное беззнаковое целое, в старшей половине которого - FFFFFFFF.
очень хороший оптимизатор, да. поэтому и надо расфачивать. так спокойней.

ScrollLock писал(а):
В каком именно стандарте и каких именно целых? Целые типы с "гвоздями приколоченными" размерами ввели уже очень давно, в C++11, в cstdint. А вот размер long в MinGW и gcc под Linux до сих пор может быть разный.
не то чтобы я помнил. вроде бы в готовящихся новых что-то такое обсуждали, чтобы int сразу из коробки. а может и нет, может я попутал чего. так-то не слежу, неинтересно: просто иногда эхо долетает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Январь, 2026 23:00 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
очень хороший оптимизатор, да. поэтому и надо расфачивать. так спокойней.

При всей неуклюжести C99+ и весёлой дичи от оптимизаторов компиляторов там есть способы эту дурь обойти: общепринятый через unsigned и stdint.h и строгие ключи предупреждений и хакерский/legacy через -fwrapv. В случае же Оберонов мы получаем недостаточность средств языка для написания шифров, хеш-функций и ГПСЧ, что для языка системного программирования странно. Да, есть расширения, но они везде разные. В качестве портабельного ГПСЧ без 64-битных целых мне пока в голову пришел разве что Subtract With Borrow с децимацией (аналог RANLUX), но он получится ощутимо медленнее аппаратного AES.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 00:29 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
я, признаться, не знаю, что такое «язык системного программирования». никогда не знал. и, кажется, оберон никогда таковым не позиционировался (что бы ни означал загадочный термин). более того: оберон даже не один язык, а целое семейство. сам Вирт говорил, помнится, что оберон — инструмент, и не надо бояться адаптировать его под задачи.

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

в том же CP2, например, вполне можно сделать инлайны для операций над беззнаковыми целыми. я, собственно, в LC сделал, как базовый модуль. да, вместо красивого инфикса — вызовы функций (которые компилятор инлайнит). ну так беззнаковые целые — хак, а хак не должен выглядеть красиво.

одна из идей оберона в том, что не надо бояться испачкать руки использованием SYSTEM или вообще ассемблером, если оно оправдано. реализация prng, или какого-нибудь криптохэша — вполне та задача, где есть смысл спуститься поближе к железу. для того же pcg32 я, например, просто забрал выхлоп gcc -O2 — а почему бы и да. зря я, что ли, нормальный ассемблер обратно в CP2 засовывал?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 01:17 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
реализация prng, или какого-нибудь криптохэша — вполне та задача, где есть смысл спуститься поближе к железу. для того же pcg32 я, например, просто забрал выхлоп gcc -O2 — а почему бы и да. зря я, что ли, нормальный ассемблер обратно в CP2 засовывал?

В реальной жизни ассемблеров по крайней мере три штуки - это x86-64, x86-32 и AARCH64. Под разными операционными системами используются разные Calling Conventions. И если можно писать на Си, а не на Ассемблере - это нужно делать, для того Си и придумали.

Цитата:
если на то пошло, то оберон намного ближе к так называемым «скриптовым» языкам.

Большинство скриптовых языков (например, Python, Ruby, Lua) предоставляют C API для низкоуровневых модулей.

Цитата:
оберон никогда таковым не позиционировался

На нём же писали операционные системы и компиляторы, значит, он всё же позиционировался как язык системного программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 01:23 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
В реальной жизни ассемблеров по крайней мере три штуки
в моей реальной жизни — одна штука. за остальные мне не платят, поэтому их нет.

ScrollLock писал(а):
Большинство скриптовых языков (например, Python, Ruby, Lua) предоставляют C API для низкоуровневых модулей.
не понял, к чему это.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 02:01 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
в моей реальной жизни — одна штука. за остальные мне не платят, поэтому их нет.

И что же это за ассемблер, если не секрет? У меня обычно это - x86-64.

Цитата:
не понял, к чему это.

Если в языке нельзя обойтись без модулей на Си, то язык обычно предоставляет куда более удобный интерфейс, чем выдирание дампов.

Цитата:
низкоуровневые штуки в оберонах не просто спрятаны в псевдомодуль SYSTEM, а ещё и различаются от диалекта к диалекту.

В плане ГПСЧ я увидел тут вот что:
1) Обычно есть циклический сдвиг.
2) Есть логический сдвиг влево. Логический сдвиг вправо есть не всегда.
3) Обычно можно конвертировать в SET и делать побитовый XOR (и так написаны реализации MT19937).
4) Использовать целочисленное переполнение нельзя, т.к. это - неопределенное поведение.
5) Целочисленный тип обычно 32-битный знаковый, типы большей разрядности бывают не всегда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 02:55 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
И что же это за ассемблер, если не секрет? У меня обычно это - x86-64.
x86. есть, конечно, ещё один за который никто не платит (z80), но это в нашем случае вряд ли важно.

ScrollLock писал(а):
Если в языке нельзя обойтись без модулей на Си, то язык обычно предоставляет куда более удобный интерфейс, чем выдирание дампов.
я, видимо, криво выразился. там не было модуля на си, я просто забрал ассемблерный код для `next()` у gcc, потому что мне было лень его руками делать. gcc хорошо соптимизировал умножение, например. можно было и руками написать, но смысл?

ScrollLock писал(а):
4) Использовать целочисленное переполнение нельзя, т.к. это - неопределенное поведение.
на самом деле определённое: программа должна трапаться. просто в том же CP2 это когда-то по умолчанию выключили (видимо, для скорости). можно вернуть обратно.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 03:17 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
x86. есть, конечно, ещё один за который никто не платит (z80), но это в нашем случае вряд ли важно.

Т.е. получаются две ретро-платформы? 32-разрядный x86 тоже становится ретро.

Цитата:
там не было модуля на си, я просто забрал ассемблерный код для `next()` у gcc, потому что мне было лень его руками делать. gcc хорошо соптимизировал умножение, например. можно было и руками написать, но смысл?

Вообще по идее это должно было быть плагином (динамической библиотекой) на Си. Если GCC в виде DJGPP может собирать DXE3-модули, то по идее и для CP2 компилятор мог бы собрать.

Цитата:
в идеале трап вообще должен быть хардварный, как при делении на ноль, ну да ладно уж…

Это осложнило бы реализацию длинной арифметики.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 04:15 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
Т.е. получаются две ретро-платформы? 32-разрядный x86 тоже становится ретро.
что использую, то и поддерживаю.

ScrollLock писал(а):
Вообще по идее это должно было быть плагином (динамической библиотекой) на Си.
зачем? чтобы иметь в зависимостях ещё и совершенно ненужный в этом случае сишный компилятор?

ScrollLock писал(а):
Это осложнило бы реализацию длинной арифметики.
две инструкции: одна трапается, одна нет. или флажок-переключатель.

впрочем, для современных x86 это уже неактуально, потому что jump-not-taken имеет по факту zero cost. просто надо так делать код, чтобы кидалки трапов были подальше от тела процедуры (в конце, можно ещё и на 16/64 байта выравнять), тогда спекулятивка их не достанет и не забьёт конвеер мусором, который всё равно придётся выкинуть. проверено опытным путём, выяснено, что действительно цена в пределах статпогрешности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 16:55 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
зачем? чтобы иметь в зависимостях ещё и совершенно ненужный в этом случае сишный компилятор?

Если нужно передирать ассемблерные дампы из сишного компилятора, особенно нетривиальные, то зависимость от него на самом деле уже существует. И если понадобится перенести код под другую платформу, то без исходников на Си будет сложно.

Экспериментальный ГПСЧ без использования переполнений на Обероне-07 у меня сделать в итоге получилось, взяв за основу одну редкую модификацию комбинированного генератора KISS Марсальи. Он проходит TestU01 BigCrush, PractRand до 2 ТиБ включительно (может, и дальше пройдет, не знаю) и батареи SmokeRand. Период - около 2^83. Конструкция - комбинация LFSR и LCG (с простым делителем) с нелинейной выходной функцией. Алгоритм использует побитовые операции, но не целочисленные переполнения.
Код:
(**
 * 1. https://doi.org/10.1214/aoap/1177005878
 * 2. https://groups.google.com/g/comp.lang.fortran/c/5Bi8cFoYwPE
 *)
MODULE xkiss;
IMPORT SYSTEM, Out;

TYPE XkissArState = RECORD
    x : INTEGER;
    a0, a1, c : INTEGER;
END;

PROCEDURE XkissArInit(VAR obj : XkissArState; x, a0, a1 : INTEGER);
BEGIN
    obj.x := x;
    obj.a0 := a0 MOD 67108863; (* 2^26 - 1 *)
    obj.a1 := a1 MOD 67108863; (* 2^26 - 1 *)
    obj.c  := 1;
    IF obj.x = 0  THEN obj.x  := 123456 END;
    IF obj.a0 < 0 THEN obj.a0 := 0 END;
    IF obj.a1 < 0 THEN obj.a1 := 0 END
END XkissArInit;

PROCEDURE XkissArNext(VAR obj : XkissArState) : INTEGER;
CONST
    mask26 = 03FFFFFFH;
    mask31 = 07FFFFFFFH;
VAR
    t: INTEGER;
BEGIN
    (* LFSR part *)
    obj.x := SYSTEM.VAL(INTEGER, (* x ^= x << 1 *)
        SYSTEM.VAL(SET, obj.x) / SYSTEM.VAL(SET, LSL(obj.x, 1))
    );
    obj.x := SYSTEM.VAL(INTEGER, (* x ^= rotl32(x, 9) ^ rotl32(x, 27) *)
        SYSTEM.VAL(SET, obj.x) / SYSTEM.VAL(SET, ROR(obj.x, 23)) /
        SYSTEM.VAL(SET, ROR(obj.x, 5))
    );
    (* AWC part *)
    t := obj.a0 + obj.a1 + obj.c;
    obj.a1 := obj.a0;
    obj.c  := ASR(t, 26);
    obj.a0 := SYSTEM.VAL(INTEGER,
        SYSTEM.VAL(SET, t) * SYSTEM.VAL(SET, mask26)
    );
    (* Output function *)
    RETURN SYSTEM.VAL(INTEGER, SYSTEM.VAL(SET, mask31) * (
        SYSTEM.VAL(SET, obj.x) / SYSTEM.VAL(SET, LSL(obj.a0, 6)) /
        SYSTEM.VAL(SET, obj.a1 * 29)
    ))
END XkissArNext;

PROCEDURE XkissArTest() : BOOLEAN;
CONST
    uref = 0453EFE6EH;
VAR
    prng : XkissArState;
    i, u : INTEGER;
BEGIN
    u := 0;
    XkissArInit(prng, 12345678, 3, 2);
    FOR i := 1 TO 1000000 DO
        u := XkissArNext(prng)
    END;
    Out.String("Output:    "); Out.Int(u, 10); Out.Ln();
    Out.String("Reference: "); Out.Int(uref, 10); Out.Ln();
    FOR i := 1 TO 10 DO
        Out.Int(XkissArNext(prng), 5);
        Out.Ln()
    END;
    RETURN u = uref
END XkissArTest;

BEGIN
    IF XkissArTest() THEN
        Out.String("Passed")
    ELSE
        Out.String("Failed")
    END
END xkiss.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 19:17 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
Если нужно передирать ассемблерные дампы из сишного компилятора, особенно нетривиальные, то зависимость от него на самом деле уже существует. И если понадобится перенести код под другую платформу, то без исходников на Си будет сложно.
я же сказал, что могу и руками. но зачем. да, там рядом в комментарии лежит тот же код на чистом CP. он медленней. в чём проблема, зачем мне обязательно си?

в Oberon/Ur используется как раз обероновский вариант, потому что там ассемблера ни в каком виде нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 21:00 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
в Oberon/Ur используется как раз обероновский вариант, потому что там ассемблера ни в каком виде нет.

И как тогда они решают проблемы с ГПСЧ, хешами и шифрами?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 22:02 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
И как тогда они решают проблемы с ГПСЧ, хешами и шифрами?
эти «они» — это я. нормально решаю, у меня SYSTEM большой. ассемблера там нет потому что компилируется в IR, потом кодоген. добавил в IR нужного, высунул в SYSTEM, делов-то. RIPEMD есть, SHA2 есть, Ed25519 есть. там даже есть такие штуки как VEC2/VEC3/VEC4, которые кодоген умеет обрабатывать SSE-инструкциями. а, салса и чача тоже есть, сейчас вот глянул. я и забыл, что их сделал. pcg32 вот так, например:
Код:
PROCEDURE (VAR ctx: Context) GenU32* [no_overflow_checks, no_zero_locals] (): INTEGER, NEW;
VAR
  oldstate: LONGINT;
  xorshifted, rot: INTEGER;
BEGIN
  oldstate := ctx.state;
  // it doesn't matter if we'll use `*` or `UMUL` here, but for clarity...
  ctx.state := UMUL(oldstate, LONG(04C957F2DH, 05851F42DH)) + ctx.inc;
  xorshifted := SHR(LONG_XOR(SHR(oldstate, 18), oldstate), 27).lo;
  rot := SHR(oldstate, 59).lo;
  RETURN ROR(xorshifted, rot MOD 32);
END GenU32;

это, понятно, должна быть процедура, а не функция, но Так Получилось, mea maxima culpa.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 22:37 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 207
arisu писал(а):
добавил в IR нужного, высунул в SYSTEM, делов-то.

Всё это выглядит значительно сложнее, чем реализация сходного функционала на Си, где можно написать всё это, вообще не связываясь ни с какими IR и ассемблерами. Причём аж с 1990 года. И для меня совершенно удивительно то, что в Обероне-07 знаковые типы известной ширины типа INT16, INT32, INT64 и аналог size_t, а также какие-нибудь функции для беззнаковых сложений, вычитаний и побитовых операций не вынесли в какой-нибудь псевдомодуль. Более того, оттуда еще и динамические массивы выкинули.

Цитата:
а, салса и чача тоже есть, сейчас вот глянул. я и забыл, что их сделал.

Вот в случае ChaCha я точно помню, что делал векторизованную версию с помощью интринсик компилятора Си. Чтобы работал совсем уж быстро.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Январь, 2026 23:05 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1629
ScrollLock писал(а):
Всё это выглядит значительно сложнее, чем реализация сходного функционала на Си
да и в целом написание своего компилятора оберона сложнее: компилятор си-то есть уже, чего париться?

ScrollLock писал(а):
И для меня совершенно удивительно то, что в Обероне-07 знаковые типы известной ширины типа INT16, INT32, INT64 и аналог size_t, а также какие-нибудь функции для беззнаковых сложений, вычитаний и побитовых операций не вынесли в какой-нибудь псевдомодуль. Более того, оттуда еще и динамические массивы выкинули.
Вирту не надо было. а мне вот дельфиподобные динамические строки с COW удобны — и они у меня есть. оберон — не догма. у меня ещё и конструкция `TRY ^err DO … END TRY` есть. правда, для неё тоже SYSTEM тащить надо.

ScrollLock писал(а):
Вот в случае ChaCha я точно помню, что делал векторизованную версию с помощью интринсик компилятора Си. Чтобы работал совсем уж быстро.
меня в данном случае скорость не волновала, это был больше тест кодогена. в отличие от pcg32, который, например, активно использовался в игре. процитированый выше код в итоге получается чисто регистровый (поэтому он функция). ну, санс обновление состояния, конечно.

я ещё более страшное скажу: у меня своя, с нуля, реализация zlib-компрессора в O/Ur. и читалка/писалка PNG своя. и вместо SDL — свои модули для винды и линуксов. разве что для звука OpenAL.


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

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


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

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


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

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