> Такому аллокатору не нужна ни стдлиб, ни куча. Нужен отдельный от стека
> блок памяти, по типу tread local storage.А сам весьма немаленький код этого аллокатора откуда вообще тогда возьмется? И что есть "thread local storage" в вон том микроконтроллере например? Heap и stack это как бы регионы, абстракции, их startup обеспечивает. Ну и поменять вот это - переделывать очень много придется, до самых оснований. И наверное много чего и кого отвалится.
> Нет дефрагментации, поскольку деаллокация происходит при выходе из области видимости точно
> так как сейчас со стеком.
Только в стеке оно видите ли железом некисло подперто, начиная с того что "деаллокацию" stack pointer оформляет с хардварной поддержкой этсамого. Агаблин, когда вы пушпопаете, не надо математику над SP самому делать. Некоторые типа cortex M еще дальше развили идею и при входе в исключение (irq/fault/etc) проц сам сэйвит соотв. регистры ABI, меняет SP, и вот вы завалились в ваш стандартный сишный void handler(void) по бырому, и это стандартное сишное ABI сразу, просто функцию железка дернула.
А в случае heap всякие там корректировки указателей будут уже значительно менее халявны. Да и использование там предполагается в ином стиле, с возможностью фрагментации. В стеке это обычно не практикуется, и пойнт наполовину в том что SP менеджит железо, а не...
> Там нет адресов возврата.
Как бы да, однако в конечном итоге логику программы можно сломать основательно и то что станет сильно лучше уже не факт. А вот железо там уже не будет указатели менеджить за вас, да и стиль использования предполагается несколько иной. Вы хотите SP который как бы SP но не SP? :)
> Это исключает исполнение кода на стеке, но не перезапись адреса возврата и
> исполнение ROP-цепочек.
Да, но это достаточно неудобно и с ALSR не особо хорошо работает. И все же дает шансы сохранить "хардварное" управление указателем. В общем случае софтварные эквиваленты менее эффективны, т.к. лишний опкод на декодирование, лишний бандвиз на шинах в виде этого опкода и проч.
> На Intel адреса возвратов аппаратно «кешируется» отдельно от данных, которые
> пишутся рядом с ними в память стека.
Мне сложно прикинуть насколько все испортится от такого натяга совы на глобус и насколько это вообще проблематично. А еще см. выше, у стека очевидный плюс что он HW-assisted. На хип эта благодать не распостраняется. Потому что он не стек, лол. И в целом hw-assisted все же эффективнее чем софтом это эмулировать, не?
> Аргументы передаются через регистры, но автоматические переменные - это то что в
> тебе блока.
В случае ARM например есть ряд сохраняемых регистров и ряд не сохраняемых регистров. Часть для передачи аргументов, часть для временных вычислений. И в лучшем случае там операций со стеком может по сути и не быть. А зачем, если в ABI дали право менять вон те регистры и возвращать caller'у их испорчеными? Вот если caller'а это колыхало т.к. он имел какие-то виды на эти регистры... но вот это уже очень сильно отдельное "если". Лучший код - которого нет. Лучшая работа с стеком - та которую избежали. Если при этом логика программы обеспечена.
