Да, основное достоинство стековой архитектуры -- простота. И простота является залогом эффективной реализации, поскольку, больше времени можно уделить оптимизации вместо реализации различных corner-cases, которых, чем сложнее -- тем больше.
Как я себе представляю, многих проблем, для которых придуманы красивые методы оптимизации, в стековой архитектуре просто бы не было.
Ведь регистры -- это просто близкая к ALU, специализированная кэш-память. В стековой архитектуре они не нужны вообще, вместо них была-бы просто кэш-память, не специализированная, которая хранила бы наиболее часто адресуемые адреса из основной памяти, содержащей номинально безграничный стек. Это позволило-бы делать процессоры более масштабируемыми, сделало бы оптимизацию более динамической (что хранить в кэше на этапе выполнения программы виднее, чем на этапе статического ее анализа). Не нужно было-бы перекомпилировать программу под разные под-типы процессоров, с разной шириной и количеством регистров, а просто процессор с большим кэшем, автоматически использовал бы его полностью и содержал бы по-сути большее количество регистров совершенно прозрачно для программиста и компилятора.
Стековая архитектура (с кэшем вместо регистров и неограниченным стеком) лучше в многозадачной среде, поскольку при переключении задач не нужно было бы сохранять содержимое всех регистров, задачи совершенно прозрачно использовали бы по-максимуму общий кэш.
Никаких проблем нет и с суперскалярной архитектурой. В стековой машине можно применить по-сути целиком и полностью register renaming, только переименовывать не регистры, а несколько верхних элементов стека (сколько -- опять-же было-бы всего-лишь несущественной деталью реализации), что позволило бы развязать кажущиеся зависимости по данным и выполнять несколько инструкций параллельно.
В стеке, конечно, нужно хранить не какие-то конкретные типы данных, а машинные слова. Типы данных определяются поверх машинных слов, это более высокоуровневая концепция.
Многие вещи, которые в регистровой архитектуре можно оптимизировать, как, например, распределение регистров (особенно если они немного различаются функционально, как в x86, что делает проблему нетривиальной), в стековой оптимизировать не нужно, поскольку нет регистров -- нет проблем.
Поскольку инструкции простые и "свободы" в них мало, львиная доля оптимизации была бы в процессоре (а не в компиляторе), который имеет возможность подстроиться под конкретный свой обьем кэша и времена выполнения каждой инстркции. Это, повторюсь, позволило бы сделать процессоры более масштабируемыми. Мыслимо было бы сделать целую линейку процессоров (от встраиваемых и до высокопроизводительность), которые выполняли бы одни и те-же команды без перекомпиляции (и без черной магии в виде instruction scheduling) с максимальной эффективностью на каждом из них. Причем, транзисторов для этого потребовалось бы меньше (а значит их можно было бы использовать для дополнительного параллелизма, лучшего управления кэшем-регистрами и т.д.).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2010-12-19 04:35 pm (UTC)Как я себе представляю, многих проблем, для которых придуманы красивые методы оптимизации, в стековой архитектуре просто бы не было.
Ведь регистры -- это просто близкая к ALU, специализированная кэш-память. В стековой архитектуре они не нужны вообще, вместо них была-бы просто кэш-память, не специализированная, которая хранила бы наиболее часто адресуемые адреса из основной памяти, содержащей номинально безграничный стек. Это позволило-бы делать процессоры более масштабируемыми, сделало бы оптимизацию более динамической (что хранить в кэше на этапе выполнения программы виднее, чем на этапе статического ее анализа). Не нужно было-бы перекомпилировать программу под разные под-типы процессоров, с разной шириной и количеством регистров, а просто процессор с большим кэшем, автоматически использовал бы его полностью и содержал бы по-сути большее количество регистров совершенно прозрачно для программиста и компилятора.
Стековая архитектура (с кэшем вместо регистров и неограниченным стеком) лучше в многозадачной среде, поскольку при переключении задач не нужно было бы сохранять содержимое всех регистров, задачи совершенно прозрачно использовали бы по-максимуму общий кэш.
Никаких проблем нет и с суперскалярной архитектурой. В стековой машине можно применить по-сути целиком и полностью register renaming, только переименовывать не регистры, а несколько верхних элементов стека (сколько -- опять-же было-бы всего-лишь несущественной деталью реализации), что позволило бы развязать кажущиеся зависимости по данным и выполнять несколько инструкций параллельно.
В стеке, конечно, нужно хранить не какие-то конкретные типы данных, а машинные слова. Типы данных определяются поверх машинных слов, это более высокоуровневая концепция.
Многие вещи, которые в регистровой архитектуре можно оптимизировать, как, например, распределение регистров (особенно если они немного различаются функционально, как в x86, что делает проблему нетривиальной), в стековой оптимизировать не нужно, поскольку нет регистров -- нет проблем.
Поскольку инструкции простые и "свободы" в них мало, львиная доля оптимизации была бы в процессоре (а не в компиляторе), который имеет возможность подстроиться под конкретный свой обьем кэша и времена выполнения каждой инстркции. Это, повторюсь, позволило бы сделать процессоры более масштабируемыми. Мыслимо было бы сделать целую линейку процессоров (от встраиваемых и до высокопроизводительность), которые выполняли бы одни и те-же команды без перекомпиляции (и без черной магии в виде instruction scheduling) с максимальной эффективностью на каждом из них. Причем, транзисторов для этого потребовалось бы меньше (а значит их можно было бы использовать для дополнительного параллелизма, лучшего управления кэшем-регистрами и т.д.).
К.Л.М.