Проблемы современной архитектуры x86

Какие основные проблемы современной архитектуры x86 вы видите?

Энергоэффективность.

и внезапно Intel

Внезапно Intel делал чипы с ARM ещё много лет назад. Полуркай про StrongARM и XScale.

Intel делал чипы с ARM ещё много лет назад

мы же про настоящее время говорим, XScale засох вместе с Windows CE на пипирке Билла.

На столе стоит? Стоит. На экран картинку выводит? Выводит. Мышку с клавиатурой умеет? Умеет. Значит десктоп.

Ну так воткни в планшет мышку с клавой, и поставь на стол. От этого он десктопом не станет.

Ичо? Это примерно как вещать, что не x86 зарулил десктопы, а intel и amd.

Да.

Кто ж виноват, что другие производители ARM-чипов не почесались?

Сперва историческое отсутствие вменяемых денег и мозгов. Затем технологический отрыв.

На данный момент, архитектура не столь важна, сколь важна поддержка процессором всяких новомодных технологий, AVX, VT-d и тд итп, которые надо поддерживать, которые надо изобретать, и которые надо продвигать. Это могут делать лишь крупные производители, могущие позволить себе штат R&D. Apple смогла взять архитектуру ARM в качестве платформы, и навешала на нее много интересных приблуд, поэтому их процессор фактически перестал быть ARM, и стал конкретным M1.

Поэтому вскукареки про то, что патенты чему-то там мешают - всего лишь вскукареки. Платформа открыта, но проблема в том, что когда попенсорсник будет лепить процессор по «архитектуре», то у него получится 386, ну или 686 максимум. А чтоб получится конкурент хотя бы процам 10-летней давности - мало взять архитектуру, придется еще придумывать СВОИ решения для поддержки популярных технологий: распаковка видео, аппаратная виртуализация, дробные вычисления, энергопотребление. А вот здесь уже ОЙ.

Ну так воткни в планшет мышку с клавой, и поставь на стол. От этого он десктопом не станет.

Кхе кхе… https://www.apple.com/imac-24/

Ровно тот же самый чип, что и в iPad Pro. Тем не менее, это десктопный компьютер. Никак иначе ты его не назовёшь.

Платформа открыта

Давай начнём вот с этого: нет. x86 – это не открытая платформа. Если ты начнёшь делать свои чипы на x86 и поймаешь хоть какой-то рынок, Intel тебя засудит по самые гланды. AMD и некоторые другие могут делать x86-совместимые чипы, потому что Intel в 1980х продавал лицензию на это налево и направо. У IBM есть такая лицензия. У AMD с Intel вообще соглашение о том, что они могут копировать инструкции и расширения к x86 друг у друга.

Вот тебе юридический обзор на тему x86 и связанной с этим фигни: https://jolt.law.harvard.edu/digest/intel-and-the-x86-architecture-a-legal-perspective

Ну так воткни в планшет мышку с клавой, и поставь на стол. От этого он десктопом не станет.

Станет, проверено. Главное чтобы десктопная ОС была, Андроид не годится.

Это не юридический обзор, а краткий экскурс в прошлое с аналитикой на уровне реферата 10-летней давности.

Патенты за небольшими исключениями, абсолютно открыты до 586 включительно.

Но смысл не в этом. Смысл в том, что открыты базовые реализации этой технологии. Регистры, команды, режимы и прочая. Все остальное, как я уже писал выше, требует R&D.

То есть если сегодня попенсорсник, сваяет на коленке процессор, то работать этот процессор будет на уровне максимум 586. В остальном, попенсорснику либо придется копировать уже существующие реализации (и лицензировать, ога), либо костылить свои реализации решений, как Apple. Что разумеется он ниасилит, потому что одно дело клонировать, а другое дело изобретать.

Патентование - не является синонимом закрытости, равно как и открытость не является синонимом бесплатности.

Основная проблема x86 состоит в её гегемонии. Всё хорошо, пока не становится плохо. И плохо тогда становится сразу и всё.

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

Основная проблема x86 состоит в её гегемонии. Всё хорошо, пока не становится плохо. И плохо тогда становится сразу и всё
Второй проблемой является, фактически, монополия у одной конторы

Кто-то объясняет это просто всякими сетевыми эффектами, просто инерцией, и заговорами жидов. На самом деле, экономика производства чипов такова, что большая часть затрат — это производство масок. Дальше стоимость масок делится на количество чипов — и вуаля, даже очень неэффективный процессор оказывается востребованным, пока он востребован (популярен своей популярностью). Интель много раз подходил к снаряду, он и i860 делал, и i960, но рынок говорит «нет, хочу жрать говно». В прошлом армосраче я пояснял, что вообще-то центральные процессоры в принципе не могут быть эффективными, причем, речь идет не про два-три раза, речь идет про 10-100-1000 раз, но рынок будет крутиться вокруг каменных топоров до тех пор, пока неадекватность каменных топоров выполняемым задачам станет совсем уж страшной и очевидной.

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

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

Это неизбежное следствие усложнения системы. Не было бы проблем со сспекулятивным исполнением — были бы проблемы с каким-нибудь когерентным кэшем. Spectre/Meltdown — это даже не вершина айсберга, это тонкая корочка по поверхности айсберга. Багов в процессорах ВАЛОМ, их только успевают затыкать и обходить. Заткнули spectre/meltdown — вылезли новые баги эксплуатации спекулятивного исполнения, MMU, и кэшей.

https://www.ibm.com/support/pages/how-disableenable-spectremeltdown-mitigaton-power9-systems

А в этом тоже монополия Intel виновата? В том, что процессоры IBM для совсем другого сегмента рынка подвержены тем же атакам?

он и i860 делал, и i960, но рынок говорит «нет, хочу жрать говно».

Ох лол… i960 был довольно успешным RISC чипом и юзался очень много. В той же вики написано, что Intel перестал его делать, потому что получил права на ARM.

https://en.wikipedia.org/wiki/StrongARM

DEC agreed to sell StrongARM to Intel as part of a lawsuit settlement in 1997.[4] Intel used the StrongARM to replace their ailing line of RISC processors, the i860 and i960.

i860 был VLIW, в итоге это заигрывание вылилось в Itanium. Что с ним случилось, мы все знаем.

А в этом тоже монополия Intel виновата? В том, что процессоры IBM для совсем другого сегмента рынка подвержены тем же атакам?

Будешь смеяться, но да. Опосредованно. Интел после Core 2 совсем с внутрипроцессорными махинациями разогналась, что межделмашу пришлось тоже подтягиваться.

Это как воровать. Если все знают, что Васян ворует, но его не наказывают, то начинают воровать все.

Тяжёлое наследие прошлого. Систему команд бы переработать, убрать древнее наследие DOSа

Вероятно, уже проще сделать с нуля.

Уже пофиг. Микроархитектура от ISA уже напрямую не зависит.

А в этом тоже монополия Intel виновата? В том, что процессоры IBM для совсем другого сегмента рынка подвержены тем же атакам?

Будешь смеяться, но да. Опосредованно. Интел после Core 2 совсем с внутрипроцессорными махинациями разогналась, что межделмашу пришлось тоже подтягиваться

Вообще-то, межделмаш и разработал внеочередное выполнение:

https://en.wikipedia.org/wiki/Tomasulo_algorithm

Первым он был реализован в межделмашевских FPU, и лишь сильно позже в появился в PowerPC. В это время RISC-и за годы до PowerPC из коробки делались суперскалярами, и интель именно в эту нишу хотел запрыгнуть. Но рыночек ответил сишкой, PHP, Perl, Python, Visual Basic, и прочими исконно однопоточными-однозадачными ЯП, а также неисправимо однопоточными GUI, которые как раз входили в моду в середине 90-х.

Рыночек ждет выполнения закона Мура, который на самом деле не выполним, и рыночек готов отдать все деньги тому, кто пообещает иллюзию выполнения онного. То есть, у «рыночка» деньги уже заняты, перезаняты, и переперезаняты на пять лет вперед под закон Мура для однопоточных технологий, потому выпуск интелем сегодня процессора в два раза быстрее значит, что наш стартап разорится не через 2 месяца, а через два года (здравствуй, доткомовский пузырь). А два года — это уже заявка на серьезный бизнес!

Внеочередное выполнение — это вынужденная однозадачностью мера. Спекулятивное выполнение — вынужденная мера для ускорения выполнения C++/Java лапши из сплошных вызовов однострочных виртуальных функций, и просто для однозадачного кода на бесконечных ветвлениях. Большие кэши — костыль для подпирания связанных списков, деревьев, Quicksort-а, и прочего устаревшего мусора (в частности, в составе РСУБД), изменяющего огромные объемы данных по месту. Обязательно огромные, и обязательно по месту, и обязательно чтобы задержка доступа была пару наносекунд. Абсолютно та же история сейчас один в один повторяется в распределенных системах, где точно так же последние 40 лет никак не могут наконец отказаться от слегка устаревших подходов к написанию логики:

Мода на облака, бигдату, и распределенные БД [теория тупости] (комментарий)

В это время RISC-и за годы до PowerPC из коробки делались суперскалярами, и интель именно в эту нишу хотел запрыгнуть. Но рыночек ответил сишкой, PHP, Perl, Python, Visual Basic, и прочими исконно однопоточными-однозадачными ЯП, а также неисправимо однопоточными GUI, которые как раз входили в моду в середине 90-х.

Суперскалярность - это не про многопоточность на уровне архитектуры, совсем. Суперскалярным был пенёк в уже далёком 93-м. До массовых смелтдаунов оставалось, как минимум, 15-20 лет.

Суперскалярность - это не про многопоточность на уровне архитектуры, совсем

Я писал про многопоточность на уровне софта. Единственный способ развивать полупроводниковые вычисления — это осознанно параллелизоваться. Кредо софтостроения — не развиваться никогда ни при каких условиях, пока это возможно. Оно писало программы 60 лет на фортране и коболе — оно бы еще 60 на них же и писало дальше. Но тут вдруг стало ясно, что видюха в сотни раз уделывает ЦП по числодроблению. И тогда выпустили CUDA для фортрана.

Суперскалярным был пенёк в уже далёком 93-м

А RISC-и были суперскалярными уже в 80-х. Я не упомянул одного важного логического звена — RISC ядра намного меньше, а потому для них логичным путем развития является размещение большого числа ядер на кристалле. Например, уже в 1996 выпускались кристаллы, на которых можно было бы уместить 50-100 процессоров ARM. То есть, RISC естественным образом толкает на многозадачность. Индустрия ответила «вы что, с ума сошли? Как мы на Коболе будем многозадачные системы писать? Так не годится, давайте нам нормальное железо».

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

Multicore OCaml таки вмержат в апстрим (комментарий)
Multicore OCaml таки вмержат в апстрим (комментарий)

То есть, всю вычислительную мощность стойки серверов на Зионе можно уместить в смартфон на 20 Вт энергопотребления — проблема только в подключении накопителей и сети.

Например, уже в 1996 выпускались кристаллы, на которых можно было бы уместить 50-100 процессоров ARM. То есть, RISC естественным образом толкает на многозадачность. Индустрия ответила «вы что, с ума сошли?

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

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

на компе во время сессии юзера активны одновременно сотни тредов

То есть, считай что их не существует. Есть только пару-тройку объектов ядра, которые по необходимости могут воссоздать поток (не путать с процессом).

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

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

сотни слабых ядер не нужны. они нужны для задач с высокой степенью параллелизма

Назови мне задачу, на которой нельзя достигнуть высокой степени параллелизма.

Назови мне задачу, на которой нельзя достигнуть высокой степени параллелизма.

Счётчик. Загрузил страничку - у тебя 1. Нажал «Обновить» - у тебя 2. Это тяжело распараллелить. В смысле, можно, но зачем?

Назови мне задачу, на которой нельзя достигнуть высокой степени параллелизма.

любая мало мальски сложная задача…навроде поиска построки в файле. конечный автомат какой-нить, нечто вроде цепей маркова, любой алгоритм где, есть if(результат_предыдущего_вычисления)…, парсинг и компиляция…

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

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

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

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

Счётчик. Загрузил страничку - у тебя 1. Нажал «Обновить» - у тебя 2. Это тяжело распараллелить. В смысле, можно, но зачем?

Отвечаю своей цитатой:

Мода на облака, бигдату, и распределенные БД [теория тупости] (комментарий)

А проблему распределенной БД со строгой согласованностью можно выразить очень просто: как сделать распределенный отказоустойчивый атомарный целочисленный счетчик?.. С этим номером я, например, могу разослать свою операцию кластеру (без необходимости взаимодействия и вообще наличия «лидера» при этом), и получив большинство успешных сохранений я заканчиваю транзакцию успешно, мне даже никаких two-phase commit не нужно.

Как только вы решили проблему счетчика — вы получили бесконечно масштабируемую распределенную СУБД.

То есть, на этом вся непараллелизуемость заканчивается. Ровно на одном счетчике. Есть еще системы немедленного ответа, вроде фильтра Калмана, который упоминался в многосраче год назад. То есть, пользователь двигает мышкой — ему нужна реакция прямо сейчас. Самолет меняет положение — реакция нужно на текущее положение, а не на какие-то прошлые. Всё остальное же параллелизуется.

навроде поиска построки в файле

Непараллелизуемо? Ты серьезно?

конечный автомат какой-нить

Конечный автомат — это форма реализации, а не задачи.

нечто вроде цепей маркова

Одно событие цепи маркова непараллелизуемо. Правда, если тебе нужно все-таки принимать в рассмотрение предыдущие состояния, то внезапно возникает потенциал для параллелизации. Цепи маркова часто применяются для систем с большим числом одномоментных состояний, и тут снова есть возможность параллелизации.

парсинг и компиляция

Крестовикам расскажи, что они на самом деле не могут параллельно компилировать свои проекты.

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

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

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

Давай будем подходить к задаче конкретно и в лоб — какие задачи ты сам решаешь ежедневно, которые, на твой взгляд, ну никак не параллелизуемы? Цепями маркова занимаешь? Или на крестах пишешь? Ищешь в файлах подстроки?

какие задачи ты сам решаешь ежедневно, которые, на твой взгляд, ну никак не параллелизуемы?

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

и что тут мы будем паралеллить на 1000 ядер?

Крестовикам расскажи, что они на самом деле не могут параллельно компилировать свои проекты.

это я вот тебе щас расскажу, что компиляция исходника(1 штука) - существенно последовательный процесс(хотя и там есть местами некий локальный паралелелизм), а билд из НАБОРА ИСХОДНИКОВ - процесс существенно параллельный, и его так и делают. Но не надо их путать.

Назови мне задачу, на которой нельзя достигнуть высокой степени параллелизма.

Рендеринг этого моего коммента в твоем браузере. Столько вбухано в это усилий, страшно представить, а результат — пшик.

пишу на плюсах

Плюсы — очень плохой в плане архитектуры ЯП, с ним большие проблема даже в однопотоке, а именно — нельзя за один проход скомпилировать программу. Тот же паскаль со модификациями из модулы (это тот, который в делфи и FPC) позволяет достаточно независимо работать с частями одного модуля, например, раздельно компилировать функции, будто это разные модули.

читаю всякую пургу на лоре

Servo в том числе делали для того, чтобы распараллелить рендеринг страниц. Например, считать CSS. Делать что-то с JS бесполезно, потому что оно изначально и принципиально пошаговое однопоточное, как конкретная реализация. Расчет макета страницы подразумевает проход вглубь дерева и обратно — расчет отдельных ветвей при этом может производиться параллельно. Причем, этот расчет порой сводит с ума, поскольку эта двунаправленность влияния дочерних на родительские и родительских на дочерние элементы мягко говоря не очевидна. У меня даже было такое, что текст с float блоками в нем на хроме вылезал черт пойми куда, где его в принципе ни при каких условиях не должно было быть. А вот потому что текст меняет геометрию родительского блока, но родительский блок влияет на положение текста, и находящиеся на одном уровне с текстом другие дочерние блоки тоже влияют на геометрию текста. Получается безумная гремучая смесь.

Современный HTML — запредельно перегруженная шняга, под которую уже никто не может написать клиент, кроме корпораций с многомиллиардными бюджетами. Тут как бы хоть многопоток, хотя не многопоток, сам макет, CSS, JS имеют неподъемную сложность.

А вот сами пиксели вполне рисуются на видеокартах тем же хромом. И простой HTML расчитать тоже можно параллельно.

билд из НАБОРА ИСХОДНИКОВ - процесс существенно параллельный, и его так и делают. Но не надо их путать

А вот исходные разрабы Rust из мозилы этого не понимали, гы-гы. Но это уже идет скатывание в «вот тебе файл с набором строго последовательных инструкций. Как ты сможешь выполнить их параллельно?». Параллелизм на уровне функций-модулей в компиляции ЯП достижим, параллелизм расчета GUI достижим, если разрабы изначально не ставят палки в колеса, сплетая систему в тесную лапшу. Причем, я подчеркиваю, что эта лапша создает огромные проблемы даже для однопоточного расчета.

Если же мы будем брать задачу «отобразить пользователю страничку с текстом, картинками, ссылками, и кнопочками», то внезапно выясняется, что без HTML эта задача весело параллелизуется.

Рендеринг этого моего коммента в твоем браузере. Столько вбухано в это усилий, страшно представить, а результат — пшик

Да, HTML неисправим, потому Facebook перекочевал в натив. Мне страшно подумать, сколько еще денег придется вбухать в поддержку бесконечных гор говна, которые были/будет написаны на HTML/Electron. Конечно, проблема немного облегчается тем, что многие SaaS бесследно исчезнут вместе со своими создателями, или даже раньше, как это происходит со многими проектами гугла.

Тот же паскаль со модификациями из модулы (это тот, который в делфи и FPC) позволяет достаточно независимо работать с частями одного модуля, например, раздельно компилировать функции, будто это разные модули.

не позволяет. вы не можете скомпилировать вызов функции или любое примение обьекта, если вы не скомпилировали его декларации. то есть функция A не может быть скомпилирована, если она вызывает Б, а декларация Б еще не скомпилирована.

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

и еще раз. не надо путать некую локальную параллельность, которая есть всегда, например тут - x=100; y=200; и возможность распараллелить нетривиальные алгоритмы на тысячи слабых ядер.

Назови мне задачу, на которой нельзя достигнуть высокой степени параллелизма.

Книжку хоть какую то почитал про распаралеливание алгоритмов. И да, не в, е паралелится. Паралелизмом маятся уже сто лет в обед.

не позволяет. вы не можете скомпилировать вызов функции или любое примение обьекта, если вы не скомпилировали его декларации. то есть функция A не может быть скомпилирована, если она вызывает Б, а декларация Б еще не скомпилирована

Может. Вызов функции в синтаксисе паскаля — это всегда вызов функции. Там нет перегрузки операторов, и потому операторы значит одно и то же во всей программе.

и еще раз. не надо путать некую локальную параллельность, которая есть всегда, например тут - x=100; y=200; и возможность распараллелить нетривиальные алгоритмы на тысячи слабых ядер

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

Книжку хоть какую то почитал про распаралеливание алгоритмов. И да, не в, е паралелится. Паралелизмом маятся уже сто лет в обед

Честно говоря, я не понял смысла твоей фразы. Ты упрт?

Может. Вызов функции в синтаксисе паскаля — это всегда вызов функции.

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

если нет ее декларации, тут все встает. и ждет, когда эта декларация появится в области видимости.

при вызове функции проверяется верность подстановки параметров, а если она возвращает результат - то берется тип ее результата для дальнейшего парсинга выражения

Проверку типов параметров и результатов можно отложить на сколько угодно долго.

из подставленного параметра, если он - имя переменной, непонятно - это подстановка по значению или ссылке

Особенно это пофигу.

Проверку типов параметров и результатов можно отложить на сколько угодно долго.

что и говорит о том, что процесс существенно последовательный, который пытались превратить в параллельный, но не получилось.

Особенно это пофигу.

кому как. если есть вызов вида (типа паскаль)

var x:int;
...
ff(x);

а декларации ff - пока нет, то есть два варианта предполагаемой декларации

function ff(p:int) //по значению
function ff(var p:int) //по ссылке

в первом случае надо передавать значение x, во втором - адрес x. итак - компилятор не знает, что передавать. и таким образом не может сгенерировать код вызова.

Аминь.

а декларации ff - пока нет, то есть два варианта предполагаемой декларации
function ff(p:int) //по значению
function ff(var p:int) //по ссылке
в первом случае надо передавать значение x, во втором - адрес x. итак - компилятор не знает, что передавать. и таким образом не может сгенерировать код вызова

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

И одним из важных механизмом в этих этапах является то, что можно назвать «линковка», то есть, связывание имен идентификаторов в программе

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

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

Не та линковка. Линковка при компиляции одного модуля.

А как же L1i и L1d кэши через которые проходит всё?

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

А про кэши я ничего не знаю.

Отчего же? Адрес возврата хранится в памяти инструкций или в памяти данных? В памяти инструкций данные стэка не могут храниться, значит они в памяти данных, а значит подвержены buffer overflow. Вот и бумага есть https://link.springer.com/content/pdf/10.1007%2F978-3-642-04798-5_13.pdf Да, передать управление на шеллкод не получится, но скипнуть проверку выполнения некоторого условия вполне

Да, это не волшебная таблетка, но выполнить произвольный код возможности нет.

Но эксплуатировать переполнение буфера возможность есть. Ну и ядра x86-64 все-таки по гарвардской архитектуре построены

Да, это не волшебная таблетка, но выполнить произвольный код возможности нет.

не знаю о чем треск и шум… но поскольку стек в интеле растет в сторону меньших адресов, то расписав его переполнением буфера в сторону больших(куда растет индекс массива), вы запросто забиваете адрес возврата нужным адресом(если он не в регистре, а на стеке, как положено), и улетаете по ретурну куда вам захотелось.

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

Как верно заметил предыдущий оратор, это защищает не от всех атак.