> Код сейчас это sub rsp, NN. Будет add rbp, NN. Но можно
> и sub, не суть.1) Что-то мне подсказывает что в HEAP оно только этим не отделывается :P. Парадигма динамической аллокации допускает что в середине деаллоцировано раньше чем в хвосте. Сломать эту парадигму = дофига ограничений на аллокации. Заимплементить как стэк без использования дыр в середине ведет к ацкому оверхеду по жрачу RAM т.к. деаллоцированые дыры в середине считаются занятыми. Вероятно это объясняет почему стэк сватают для маленьких локальных аллокаций.
2) sp железо так то в ряде случаев менеджит.
3) А еще локальная переменная может и вообще сразу в регистрах быть, например. Почему нет, если абстракция держится? Даже кейворд "register" для этого есть. Оно вообще не stack и не heap. И при возможности компилер это пытается. На IA32 это ессно плохо получится, но на ARM и даже x86-64 уже вариант.
4) Если "это будет rbp" - окей, но его тогда не удастся юзать для других целей. Минус эффективность кода.
5) Декодирование stack frames станет хрупче и сложнее.
Еще возможны всякие гибридные компромиссы, типа [локальный стек функции1][redzone][локальный стек функции2][redzone] ... где redzone это например страница с запретом доступа. Но оно RAM на такое выравнивание жрет. Кажется asan/ubasn что-то сравнимое делают. Лайтовый вариант - ловушка только в хвосте, но даже так есть некий оверхед, не решит проблему с адресами возврата, да еще в сях точный лимит использования стека не всегда предвычислим, скажем, удачи для VLA + user input. Это только в рантайме ловить, и будет это дотнет какой-то по оверхеду.
> Ещё один стек добавить, в чём вопрос то?
Вероятно, добавит оверхеда и деоптимизирует код. А если из сей очередной дотнет получится - ну и кому такой си будет нужен? В принципе из него это сейчас вполне делаемо, ubsan врубить (относительно лайтово, есть сверхлегкий режим который даже на MCU работает) а при параное и asan, но вот тут уже будет полная ява с дотнетом. Зато ловит практически все что я с наскока смог вообразить. Нормальные люди делают это с дебагбилдов и пускают fuzzer на это, а потом иногда узнают о своем коде кое-что новое. Вот такой damage control.
> Их и так два, один в ядре, другой в юзермоде. И кстати в ядре всё
> хоть немного крупное вручную аллоцируют не в стеке,
Смотря как крупное определено. IIRC там возбухают если >1К stack у функции. У них к тому есть очень особые предпосылки, это огромная многотредовая штука с модулями, кучей функций и всем таким, и все это в 1 адресном пространстве, хотя сущностей на дюжину процессов хватило бы.
> даже если оно живёт мало.
Они же не могут выгрузить вон того жиртреста в отдельный полноценный процесс.
> Проблемы есть, придётся всё пересобирать из исходников, но они
> решаемы. Для микроконтроллеров не обязательно это делать.
На мк при желании заводится лайтовый ubsan, там забавно сделано: при срабатывании вызывает "bad opcode". Ну а дальше сами разбирайтесь в обработчике как на это реагировать. А, ну это на приличных процах типа cortex M. Хрень типа avr не имеет понятия bad opcode и исключений и в этом смысле кажется пролетает. Пофигистичному процу - пофигистичный рантайм. Даже оверхед кстати не такой дикий, процентов 20 кода добавляет, ну и скорость алго ессно убивает на сколько то проверками.
