Конечно, программисты были влюблены в этот инструмент создания программ, представленный С и его последователями. А вот с исполнением полученного кода на конкретном "железе" всё было далеко не так гладко. Перефразируя поэта, можно сказать: "Любовная лодка эффективности языка программирования разбилась о быт процессорных архитектур". В чём же крылась причина этого кораблекрушения?
Вспомним в общих чертах, как процессор выполняет программу. Все необходимые для работы программы компоненты, а именно код и данные, располагаются в определённом адресном пространстве оперативной памяти. Процессоры, как правило, избегают обращаться к оперативной памяти напрямую, поскольку считается, что это сильно замедляет их работу. Поэтому в состав процессора входит специальный модуль вызова команд, который занимается выборкой инструкций программы из оперативной памяти и передаёт найденные инструкции исполнительному устройству процессора. В подавляющем большинстве случаев модуль вызова команды размещает найденную инструкцию и данные для обработки в специальные регистры процессора, к которым имеет доступ исполнительное устройство.
Процессоры с традиционной архитектурой хранят инструкции и данные в регистрах
Фактически процессор классической архитектуры (неважно, CISC или RISC) общается только с этими регистрами, знать не зная о том, что же происходит в памяти. Конечно же, у такой схемы обработки есть варианты. Например, регистры могут быть заменены или дополнены аппаратно реализованным пулом в виде очереди FIFO или же специальной кэш-памятью. Эти изменения и дополнения позволяют модулю вызова команды осуществлять предварительную выборку сразу нескольких инструкций, подыгрывая суперскалярности исполнительного устройства. Однако регистровая суть работы процессора при этом не меняется.
Беда же заключается в том, что языки программирования высокого уровня, подобные С (ассемблеры, вплотную приближенные к архитектуре процессора, не в счёт), создавая программу, используют совершенно другую методологию. Они размещают необходимые программе локальные переменные и иные структуры, необходимые для выполнения основной ветви программы и вызываемых из неё процедур, в области памяти, называемой "стек". Стек устроен по принципу оружейного магазина и на своей вершине содержит наиболее актуальные в данный момент данные.
Одним словом, стековая идиллия программ, которую создаёт компилятор, сталкивается с суровыми регистровыми буднями реальных процессорных архитектур. В этом не было бы ничего страшного, если бы не вызовы процедур.
В больших программных проектах достаточной редкостью является наличие одной линейно развивающейся ветви выполнения программы. То и дело её течение приостанавливается, чтобы вызвать какую-либо подпрограмму. А это значит, что информация о последней инструкции и данных основной ветви, хранящаяся в регистрах процессора, должна быть заменена на инструкции и данные вызываемой процедуры.
А если процедур много и вызываются они довольно часто? Нетрудно догадаться, кто в этом случае работает больше, модуль вызова команды или исполнительное устройство процессора. Вот и выходит, что в реальности архитектура процессора, основанная на регистрах, буксует при выполнении сложных программ с кучей процедур.
Именно об этой нестыковке и задумался коллектив исследователей (в его состав входил и Деннис Ритчи, и другие сотрудники Bell Labs), разрабатывая С-машину – гипотетическую безрегистровую процессорную архитектуру, оптимизированную для выполнения С-программ со множеством процедур и стековой организацией хранения данных.
К разработке С-машины учёные подошли основательно. Предварительно была выполнена трассировка исполнения разных типов С-программ, позволившая собрать уникальную статистику, связанную с обращением к памяти и вызовом процедур. Кстати, позже эта статистика "стрельнула" в проекте виртуальной памяти, без которой немыслимо нынешнее поколение операционных систем.
Приступая к разработке С-машины, исследователи провели трассировку десятков С-программ
Согласно идеологии С-машины, инструкции программы получали доступ к необходимым им данным так, как это задумывалось компилятором языка С, то есть непосредственно обращаясь к находящимся в памяти стекам программы и её процедур и, например, таким элементам, как массивы. Такое неэффективное с точки зрения скорости доступа решение на практике оказывалось более продуктивным, чем постоянное перезаписывание более шустрых регистров.