Я просто к тому говорю, что объем и сложность документирования зависят от архитектуры компилятора. В gcc, к сожалению, ситуация близка к классическому big ball of mud :)

Причем, причины не просто исторические-технические у такого положения вещей, но еще и идеологические, если я правильно помню :)

Ого, а какие идеологические?

Что-то в духе того, что если сделать архитектуру и интерфейсы в gcc удобными-открытыми-документированными, то тогда враги свободного ПО смогут паразитировать на gcc.
См., например, здесь: https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html

Лол, зачем тогда вообще исходники открывать?

Читайте письмо, он там все объясняет :)

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

К слову, не могу сказать что у llvm в этом плане на много лучше дела обстоят. До фронтенда я не дошёл, но когда надо было сделать кодогенератор, у них все советы свелись к "смотрите как сделано для sparc и делайте по аналогии"

В gcc есть таргет x86_64-elf, у меня с ним две проблемы:

Первая в том LINK_SPEC пустой, то есть флаги -m32/-m16/-mx32 не превращаются в -m elf_i386 и т.п. и в итоге не доходят до GNU ld.

Вторая проблема с тем что multilib не multilib и не содержит операций для (unsigned) long long: __udivdi3, __umoddi3, и т.п. Из-за этого  в u-boot (https://lists.denx.de/pipermail/u-boot/2017-December/313443.html) и ранее в coreboot ходят со своими функциями вместо того чтобы использовать libgcc :)

Может кто-то сталкивался с этими проблемами?

Там ключевая фраза:

"The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real.  If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon."

Поэтому в gcc и не используется открытая и модульная архитектура в духе фронтенд (clang) -> IR -> бэкенд (LLVM).

"The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real.  If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon."

«Назло врагу откушу себе ухо»

если в школе, разве что в школе КГБ

У нас это был 3й курс

Ну что, пора опрос сделать в чате (когда познакомились — в школе, 1 курс, 2... самостоятельно, до сих пор не знаю этих ваших мультиплексоров и "мне норм")? :)

-- не помню когда познакомился.

Ещё вариант: -- давно забыл что это. 😊

самостоятельно, всё постигаю самостоятельно🥺

Может быть это «ребёнок познаёт мир», но вот простое описание переупорядоченного отсортированного массива для бинарного поиска. Интересно то, что алгоритм cache-friendly, и, почти как в старой шутке «не зависит от длины линии».

https://nponeccop.livejournal.com/661112.html

Ну то есть, это eytzinger layout. Удивительным образом совершенно недавно изобретённый.

То есть, возможно есть целый класс таких алгоритмов.

Есть еще van Emde Boas layout
https://cglab.ca/~morin/misc/arraylayout

А вообще самый крутой способ это отсортировать по z-order curve (morton order). Он мало того что cache-friendly так еще и отлично масштабируется на n-мерное пространство (1d, 2d, 3d  и т д)

Кстати это дефолтовый layout для текстур в памяти GPU

Так это же классический вариант представления n-арного дерева массивом. С формулами для доступа от родителя к детям. Есть в любом учебнике по алгоритмам :)

eytzinger layout может быть даже быстрее b-tree но только с префетчем (без него он хуже van Emde Boas)
https://cglab.ca/~morin/misc/arraylayout/prefetch-test/xxx/run_data/index.html