> Проблема в том, что стек растёт в обратную сторону относительно обычной памяти
> Т.е, для него изначально выделили отдельный небольшой блок и далее он в
> нём растёт пока не дойдёт до потолка
> И это всё далеко от общего количества ОЗУ Ну, вообще, реально выделяют страницу или две (если физически), а заказывают столько, сколько считают нужным. Если происходит исключение, то подсистема памяти видит, что физически страница закончилась и выделяет новую.
Для однопоточных программ было следующее распределение памяти (от младших адресов к старшим):
КОД
ДАННЫЕ
КУЧА (растёт вниз)
/свободное место/
СТЕК (растёт в верх)
т.е. для стека можно было указать виртуальный адрес 0x7ffffffc и дальше пусть растёт сколько влезет, единственно, что его будет ограничивать - это куча, которая растёт ему на встречу.
С многопоточными всё стало сложнее. Тем не менее, если необходимо, то есть межанизм заказать столько стека, сколько надо.
В Unix см. https://man7.org/linux/man-pages/man3/pthread_attr_setstack.... и https://man7.org/linux/man-pages/man3/pthread_attr_setstacks...
В Windows - см. https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...
Тут больше проблема в том, что для многопоточных программ все потоки находятся в одном адресном пространстве, и, в итоге, если сильно постараться, можно налезть и на стек другого потока, и на его данные.
> С другой стороны, тот же LLVM выдаёт промежуточный процессорно-независимый выхлоп, который
> не зависит от регистров и даже архитектуры, а лишь упирается в
> идею бездонного стека. И его там нереально оптимизируют ради.. а чего,
> собственно ?
не совсем, насколько я понимаю, в LLVM используется идея бесконечного числа регистров.
