Средства и методы разработки

Гнусная статья :), очередной холивар. Упование на Forth - наивная вера в то, что аргументы функций "быстрее" хранить в памяти, чем в регистрах. А на на деле основной работой процессора становится бесконечные засовывания и высовывание данных из стека. Регистры у процессора бывают настоящие и жульнические. Настоящие адресуются в поле инструкции, а физически являются частью АЛУ. Простые операции над регистрами не должны превышать одного такта - тогда это регистр настоящий. Но как только разработчики виртуализовали регистры, физически расположив их в памяти, выдергивая/загоняя туда их значения, то получаем регистры жульнические. Т.е. это фактически уже кросс-машина, которая в процессе исполнения инструкций через микрокод все регистры похерила :). В последнем случае создатели процессора могут рапортовать, что у них регистров аж до тыщи, да еще и с дубль-банками, а на деле это чистейшей воды надувательство. Переход на Forth-системы означает лишь косвенное признание в том, что у процессора нет/мало/недостаточно настоящих регистров и отказ эмулировать их микрокодом. А вся выгода такого перехода состоит лишь в экономии тех ресурсов, которые ранее потреблял обман. Такое уже было не раз. Например, RISC-архитектура есть ни что иное, как отказ от вранья, что данные инструкции для процессора якобы родные, тогда как на самом деле интерпретируются ядром. А как только врубили инструкции настоящие (или близкие к ним), то сразу же появился прирост производительности. Откуда он? - От отказа от эмуляции того, что противно настоящей архитектуре процессора. В принципе эффективность процессора тем больше, чем точнее сходство его инструкций с реальными возможностями. Как только между ними расширяется пропасть, эффективность сразу падает. Скажем, архитектура MIPS - предельно ясное признание того, что твой процессор по своим возможностям дебилен :). Становится очевидно, что способен он лишь на выполнение простейших примитивов, а всё остальное собирается из них. И производители железа тоже довольны донельзя - примитивный процессор делать проще, а все заботы сбагрить на тех, кто пишет микрокод. А потом удивляются, что пропадает эффективность. Конечно же, писать программы на одних примитивах тоже неэффективно, а потому среди инструкций процессора вполне могут быть и команды-монстры, исполняемые за много тактов. Это не страшно, если такие команды часто востребованы в той предметной области, где используется такой процессор. Так, например, наличие DSP-инструкций можно только приветствовать, несмотря на то, что реально каждая из них представляет собой отдельную подпрограмму в микрокоде. Хуже другое - когда регистровые примитивы оказываются ненастоящими, а такими же подпрограммами. В последнем случае мы платим дань эффективностью, будучи вынужденными использовать крупные сборки в элементарных случаях (например, таких, как передача параметров в функцию и обратно). А эффективность применения Forth-машины в точности измеряет эти потери эффективности при передаче параметров. Будь регистры настоящими - ни одной Forth-машине за ней не угнаться. А как только регистры деградируют до памяти, то тут ни Forth, ни возня со стеком, уже сильно навредить не могут. Вся эта зараза :), находит наиболее выпуклое выражение в идеях/патентах Трансметы, к настоящему времени усопшей (к великой моей радости!). Но, к сожалению, вурдалак каждую ночь восстает из могилы и сосет мозги разработчикам процессоров. :)