Прошу прощения, забыл. Если стек это не выделенная область памяти, то вообще все достаточно жестоко - надо поддерживать многопоточность, т.е. иметь всю ту механику которая есть сейчас в стиле store queues, load queues, решать load/store конфликты и т.п. - с тем исключением что собственно hazards будут на каждом шагу - записали на стек, прочитали со стека, записали, прочитали, и т.п. - т.е. если сейчас некоторые архитектуры могут себе позволить пенальти в 60 тактов за Load Hit Store (read after write hazard), например, то в стековых пощады не будет.

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

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