Как оперирует числами процессор?

Есть ALU (в последних процессорах - уже несколько), в который поступают все инструкции и данные, необходимые для целочисленных вычислений, как правило, это один из самых быстрых в плане тактовой частоты модулей процессора. Грубо говоря, процесс его работы можно представить следующим образом: поступили данные (две цифры - 3 и 4), поступила инструкция (операция умножения). На выходе получили результат - 12. Сложение, вычитание, деление, и так далее - в общем, все, с чем мы имеем дело в повседневной жизни.

Очевидно, что хоть используем ли мы числа в 4-бит представлении, хоть в 64-бит, а в данной схеме абсолютно ничего не изменится. Поступили на вход два числа, ALU произвел над ними операцию, выдал результат. Есть, конечно, потенциальная возможность того, что удастся каким-то образом распараллелить этот участок, найдя две пары чисел и пару операций, которые необходимо над ними выполнить, абсолютно не влияющих друг на друга. Случай относительно редкий - на то мы и имеем дело с алгоритмом, то есть, цепочкой последовательных шагов, но все же отнюдь не невозможный. В сегодняшних программах хватает процедур, совершенно друг с другом не связанных.

Возникает вопрос, при чем тут регистры? Как уже говорилось - прежде, чем данные попадут в ALU, они должны быть туда загружены. Загружены из некоего источника. Под которым можно подразумевать все угодно - от винчестера, до кэша процессора. Из кэша данные попадают непосредственно в процессор, в блок хранения данных. Небольшой по объему, но скоростной. Однако, в силу ряда чисто физических ограничений, расположить его вплотную к ALU не получится - роль посредника выполняет набор совсем уж небольших блоков для хранения данных, работающих на очень большой скорости, и называющихся регистрами.

Как раз оттуда ALU данные, с которыми он работает, и получает, и звучит для него вышеупомянутая операция скорее не как "3 * 4", а как "содержимое регистра A * содержимое регистра B". И, разумеется, сохранить результат в один из регистров (может быть, даже один из использовавшихся в операции), откуда он потом, при необходимости, сможет быть взять для еще одной операции, или же записан в оперативную память, освободив драгоценное место. Когда мы говорим о разрядности процессора, то, практически в первую очередь, мы говорим как раз о разрядности этих регистров - могут ли они хранить 8, 16, 32, или 64-бит числа.

С дробными числами, с числами с плавающей запятой ситуация обстоит совершенно другим образом. Для их хранения и операций с ними требуется куда больший объем - это очевидно, учитывая, сколько цифр приходится хранить для подобных чисел. Особенно, если требуется повышенная точность и, соответственно, повышенное число знаков после запятой. Впрочем, поскольку необходимость в работе с ними возникла не вчера, то никто здесь прихода 64-бит процессоров ждать и не собирался.

С числами с плавающей запятой работает отдельный набор инструкций, x87, с ними оперируют отдельные вычислительные блоки, сведенные в модуль с общим названием "сопроцессор", а хранятся они и оперирует с ними процессор во внутреннем формате с 80-бит представлением. Так что здесь пока что все нормально, и ради чисел с плавающей запятой весь сыр-бор затевать явно не требовалось. Тем более, что это направление развивается совершенно автономным образом - SSE, 3DNow, и так далее, так что переход x86 с 32-бит на 64 его затрагивает весьма слабо.

Существует, впрочем, и еще один аспект вопроса, а именно - доступ к памяти. Дело в том, что в базовом режиме, так называемом "flat addressing", те же самые регистры общего назначения используются для хранения адресов доступа к памяти. 32 бита дают нам 4.3 миллиарда возможных комбинаций, так что 32-бит процессор может, таким образом, осилить объем памяти лишь объемом в 4.3 Гбайт. Адреса ячеек, имеющих более старшие номера, он попросту не может хранить в своих регистрах.

Очевидно, что здесь польза от 64 бит проявляется наиболее очевидно, поскольку объем адресуемого пространства сразу увеличивается до 18 миллионов терабайт. И 4 Гбайт то памяти в настоящее время можно встретить лишь в серверах, хотя через несколько лет, очевидно, до таких объемов доберутся и PC, но новые возможности: Их, очевидно, хватит на ближайшие несколько десятков лет, по крайней мере, если иметь дело с теоретической стороной вопроса - на практике дела обстоят отнюдь не столь радужно.

Так вот, раз уж мы заговорили о серверах, то впору вообще задаться вопросом - что толку вообще в переходе на 64-бит? Кто выиграет от этого? В первую очередь в голову, разумеется, приходят пресловутые серверы баз данных. Где серьезные базы давно уже переросли объем в 4 Гбайт, а возможность кэшировать их полностью в оперативной памяти слишком заманчива в плане производительности, чтобы от нее отказываться. Так что, между прочим, как и с сопроцессором, производители серверных решений не стали дожидаться, пока как-то решит проблему - за счет использования различных подходов, 32-бит Xeon позволяет адресовать более 4 Гбайт данных (до 64 Гбйт), хотя, конечно подобные полухакерские решения трудно назвать серьезной платформой под будущее, да и падение производительности при операциях с памятью при этом измеряется в десятках процентов. Впрочем, будущее от Intel - это Itanium, а не Xeon.