R — разрядность (ширина единицы памяти в битах)
A — количество адресуемых единиц памяти (объём адресного пространства)
C — количество исполняемых команд (объём командного пространства)
Задаём ключевое условие, способствующее целостности и завершённости информационной модели (и как следствие — эффективности и удобству в использовании устройства, реализованного на её базе):
A = C = 2 ^ R
Соблюдение данного условия означает, что любая ячейка способна вместить адрес любой другой ячейки, а также содержит исчерпывающую информацию о выполняемом действии. Уменьшение адресного пространства чревато ссылками на несуществующую память, а увеличение — избыточной информацией, необходимой для обеспечения возможности адресовать всю память. То же самое с командным пространством. Таким образом наше гипотетическое множество не перестаёт быть бесконечным, зато становится более определимым.
Существуют ли другие условия, удовлетворяющие перечисленным выше критериям и очевидные без углубления в детали разработки низкоуровневой архитектуры? Да, по крайней мере одно такое условие существует:
R = 2 ^ n
Соблюдение данного условия означает, что для задания номера любого бита в ячейке требуется целое число бит (опять же, избыток или недостаток здесь нежелателен из соображений удобства написания и надёжности работы машинного кода).
Очевидно, что n=4 — это минимальное приемлемое значение, поскольку 256 байт памяти при n=3 годится разве что для программирования ёлочных гирлянд. При n=5 получаем объём памяти, соответствующий последним достижениям в сфере ИТ. Но если считать главным назначением памяти, адресуемой процессором, хранение машинного кода (движка), а данные, которыми манипулирует этот движок, вынести за пределы адресного пространства (то есть если исходить из представления, что их носителями будут внешние устройства), то такой объём памяти (16 Гб) будет явно избыточным. Действительно, в ОЗУ современных компьютеров на долю машинного кода приходится лишь малая части памяти, всё остальное — данные. Кроме того, разделение кода и данных на аппаратном уровне вполне согласуется с представлением о хорошем стиле как проектирования микропроцессора, так и программирования на его асемблере. В мегабит машинного кода, написанного на эффективном асме (при условии вынесения данных за пределы адресуемого процессором ОЗУ), можно вместить полноценную ОСь. Если же этой памяти окажется недостаточно (например, для реализации многозадачности), можно использовать несколько процессоров, ведь «разделение труда» в области ИТ тоже, как правило, способствует удобству разработки программ и эффективности их функционирования. В принципе, для реализации многозадачности ничего не мешает обойтись и одним процессором: можно, скажем, реализовать быстрый интерфейс обмена данными между ОЗУ и внешней памятью — благо, небольшой объём ОЗУ позволяет обновлять его не последовательно, а параллельно (одним «кадром»), так что любой участок процессорной памяти можно будет перезаписать за считанные такты.
Я это всё к тому, что любые препятствия, вызванные ограничением объёма адресуемой памяти до одного мегабита, несложно обойти посредством аппаратной реализации обмена данными с внешней памятью. Преимуществу же использования именно шестнадцатиразрядной архитектуры, помимо приведённых выше соображений, можно дать формальное обоснование, а именно:
R % n = 0
Соблюдение данного условия означает, что в одной ячейке памяти можно разместить целое число значений в диапазоне [ 0..R-1 ] (например, для n=5 это условие не соблюдается — в данном случае R, равное 32-м битам, не делится на 5 без остатка). Поскольку разрядность процессора является фундаментальным параметром, такое свойство может оказаться в дальнейшем весьма полезным.
Ну и наконец главным аргументом в пользу числа 16, положенного в основу низкоуровневой архитектуры, является то обстоятельство, что оно задаёт оптимальный объём командного пространства — примером тому может послужить процессор PDP-11 (впрочем как и большинство современных процессоров, расширение разрядности которых практически не сказалось на их системе команд).
Для наглядности приведу последовательность, отражающую фундаментальность приведённых выше обоснований:
2 ^ 0 = 1
2 ^ 1 = 2
2 ^ 2 = 4 ( = n )
2 ^ 4 = 16 ( = R )
2 ^ 16 = 65536 ( = A = C )
Стоит также упомянуть о том, что с тех пор как ИТ начали развиваться бешенными темпами, не было предложено, пожалуй, ни одного завершённого решения. Даже PDP-11 (в моём представлении наиболее удачная реализация) вряд ли использует командное пространство больше, чем на 50% — довольно значительную его часть составляет резервный код, а также способы адресации, формально допустимые (так как попадают под общие правила), но реально неиспользуемые, поскольку они либо приводят к гарантированному зависанию программы ( MOV -(PC),… ), либо просто бесполезны ( MOV R1,R1 ).
Другими словами, в области информационных технологий до сих пор не изобрели «колесо», ну или все они не совсем «круглые» — что делает «езду на велосипеде» не совсем удобной. Возможно именно по этой причине «первобытные» компьютеры (БК, ДВК, Спектрум, ...) и по сей день пользуются большим спросом. Мне, например, как человеку, искушённому в программировании, современные программные технологии, при всей их мощности и надёжности, напоминают Франкенштейна, вызывая противоречия эстетического характера. Хотя это скорее радует, чем огорчает, ибо изобретение неизобретённых колёс является моим хобби. Возможно, не один я задумываюсь в этом направлении и кто-нибудь ещё сочтёт такое занятие интересным.
Комментарии (97)
IronHead
01.09.2015 10:57+2Ок, а теперь продемонстрируйте работающий майнинг биткоинтов на PDP-11.
640 килобайт хватит всем…
axby
01.09.2015 11:43Внешняя память предполагается условно-бесконечной, вы наверное невнимательно читали.
Amomum
01.09.2015 11:59+5И вы считаете, что адресовать условно-бесконечную память с помощью 16 разрядов — это удобно?
axby
01.09.2015 12:47Бесконечная память — это идеализация. Для решения конкретных задач разница будет состоять лишь в том, что данные, расположенные во внешней памяти непрерывно и предназначенные для обработки процессором, необходимо будет разбивать на фрагменты и пересылать их во внутреннюю память. И вы считаете, что необходимость добавления к программе нескольких машинных команд — это большое неудобство?
encyclopedist
01.09.2015 13:33+3А у вас какой опыт программирования на малоразрядных системах? На ассемблере?
Даже при программировании на C под ДОС в девяностых все эти сегменты, модели памяти, ближние-дальние указатели были крайне неудобны. И эти несколько инструкций добавляются почти к каждому доступу к памяти.axby
01.09.2015 15:12Опыт небольшой, но достаточный для того, чтобы оценить степень неудобства разделения указателей на ближние-дальние. А откуда они возьмутся, если ячейка способна вместить адрес любой другой ячейки? В данном случае разбиение данных на фрагменты не подразумевает необходимость плодить сущности, а «накладные расходы» на размер кода и быстродействие незначительны.
encyclopedist
01.09.2015 16:35Ну и назрядность процессора никакого отношения к размеру комманд не имеет. На x86-64 размер комманд начинается с 1 байта.
axby
01.09.2015 19:27Я это называю плохим стилем проектирования. В 32 разряда при желании можно втулить полноценный объектно-ориентированный асм, а 64-разрядный вообще должен «стихами разговаривать». Очевидно, у нас разные критерии оценки качества.
encyclopedist
01.09.2015 20:02+4Ещё раз: вы исходите из ложной посылки что длина команд как-то связана с «разрядностью» процессора. Это очень редко так. Вообще поняттие «разрядность» в современном мире не существует. Потому что разрядность команд, разрядность регистров, разрядность арифметических операций, разрядность адресного пространства, разрядность минимально адресуемого слова, разрядность физической шины адреса и разрядность физической шины данных (а их ещё может быть несколько) — они все в любой современной архитектуре очень слабо связаны друг с другом.
PS Да я сам считаю что x86 некрасив. Но 16-разрядные системы намного хуже.axby
01.09.2015 20:30Я исхожу из объективного представления о том, что если длина команды будет равна разрядности процессора, то программировать такой процессор будет гораздо удобнее, чем в противном случае. То есть при прочих равных условиях первому случаю следует отдать предпочтение. И для того, чтобы ваше критика была содержательной, вам следует как-то аргументировать своё мнение о том, что 16-ю разрядами никак не обойтись при решении задач, стоящих перед современными ИТ.
encyclopedist
01.09.2015 20:35+1Например, проблемы будут с непосредственными операндами. Сколько бит непосредственный операнд будет в 16-битной команде? 8?
andy_p
01.09.2015 20:47Motorola 680x0 был более продвинутым микропроцессором. В частности, там было разделение на регистры данных и регистры адреса и значительно более продвинутая система команд, чем у x86. Однако в итоге выжил x86.
axby
01.09.2015 20:53Да.
tyomitch
03.09.2015 22:35Как быть с командами перехода?
Как вы себе представляете 16-битную команду перехода по 16-битному адресу?axby
03.09.2015 22:58JMP (PC)+
Команда, заметьте, 16-битная, хотя и использует следующее слово памяти. Ну а для локальных переходов можно обойтись и одним словом — в пределах одной подпрограммы их обычно хватает.
IronHead
01.09.2015 12:36-1извините, конечно же стоило так написать sarcasm 640 килобайт хватит всем… /sarcasm
axby
01.09.2015 11:32+2Я же говорю — хобби у меня такое: ограничить себя 16-ю битами, а потом думать, как из этого выкручиваться.
radiolok
01.09.2015 13:46+1Ну а у меня профессия — ограничивать себя 8 или 16 битами и работать с этим (я разработчик устройств на микроконтроллерах), хотя и 32 разряда мне не чужды — все зависит от задач, стоимости разработки и конечного решения.
Мне симпатизирует PDP-11, так как я люблю использовать семейство контроллеров MSP430. У него похожая архитектура. И после плотного ассемблерного взаимодействия с 8-разрядными AVR, сопряженного особой болью при работе с адресацией, соглашусь с утверждением, что:
Микропроцессор должен быть Как Минимум, 16-ти разрядным.
Вы это хотели сказать своей статьей? Или что-то другое?
Вы посчитали степень двойки и написали что PDP-11, которому уже больше 40 лет — это хорошо, а современный многоядерный процессор(кой неявно упоминается в статье) — это плохо. Кстати, что можете сказать на счет математических сопроцессоров? Зло? Или можно использовать?
Ну и технический вопрос по статье — что такое n? Просто в формуле он присутствует, но практически не подписан. Это ваша попытка объяснить, почему разрядность шины адреса есть степень двойки? Так в эпоху 286 и 16-разрядного 386SX шина адреса вполне успешно была 24 бит.axby
01.09.2015 19:31Я PIC-и программировал, так что пришлось испытать все «прелести» от переключения банков и прочих недоделок, забивающих голову балластной информацией. С AVR-ами не сталкивался, но слышал о них хорошие отзывы от коллег. Удивлён, что 8-разрядные до сих пор в ходу.
PDP-11 мне тоже симпатизирует, с БК-шкой у меня связаны светлые воспоминания из детства, и отчасти эта статья навеяна ностальгией по лучшим годам моей программерской жизни. Но там тоже «дырок» хватает, о которых я уже упоминал. «Без дырок» в моём понимании — значит без избытка и недостатка, то есть командное пространство не должно содержать пустот (резервного кода) и заведомо бесполезных действий. Ключевые моменты здесь можно строго формализовать, причём достаточно тривиальным способом. В том числе и причину, по которой процессор должен быть именно 16-разрядным — не больше и не меньше (по крайней мере, если оставаться в рамках классических представлений о программировании). Принципиальных препятствий для этого нет (замечаний по существу я здесь пока не увидел), а преимущество очевидно (по крайней мере мне). То есть я хотел сказать именно то, о чём гласит заголовок.
Что касается сопроцессора, то это понятие растяжимое (в плане его специализации). Я же имею в виду классическую реализацию. Во многом она должна пересекаться с PDP-11, поскольку реализованная там концепция, на мой взгляд, лучше всех претендует на универсальность (например, ортогональная система команд). А как будут взаимодействовать между собой процессоры («со-», или «обычные») — так это уже вопрос реализации интерфейса обмена данными между устройствами. У меня нет четкого представления о том, как это должно выглядеть, однако уверен, что фундаментальный подход здесь позволит найти оптимальное решение. Моя же задача — максимально эффективно потратить имеющиеся 16 бит на систему команд и способы адресации. При этом от обмена данными можно практически полностью абстрагироваться — скажем, включить в систему команд единственную поштучную (без операндов) команду, осуществляющую взаимодействие с «внешним миром», а всю информацию, определяющую способ этого взаимодействия, хранить в регистрах, стеке, памяти, в общем — где и как угодно. Где именно и как именно выяснится, когда будет реализован интерфейс обмена данными. То есть нет никаких сложностей в том, чтобы состыковать «железо» с «мозгами» бесшовно.
Но в «железе» я, к сожалению, разбираюсь значительно хуже, чем в конструировании абстракций.
А n — это двоичный логарифм от разрядности. Допустим, нам нужно подсчитать количество единиц в каждой ячейке выделенного блока памяти, и сохранить эти данные в другой области. В 16 бит уложится аккурат 4 таких значения по 4 бита каждое. А с 32-битной ячейкой такое уже не прокатит (32 — 6*5 = 2 бита окажутся лишними). На первый взгляд это несущественно, но я к таким «мелочам» отношусь весьма скурпулёзно, особенно если речь идёт о создании информационной модели идеального процессора. Фантазёр и мечтатель, что тут поделаешь )radiolok
01.09.2015 19:50Еще раз, что за значения такие в 4 бит и 5 бит? Откуда они взялись и зачем они нужны? Просто сначала это степень двойки, а потом… это почему-то длина в битах.
Зачем (R % n == 0) должно быть true? что это дает? кому это дает?
Ну хорошо, в 16 бит влезет 4 значения по 4 бит, ну а в 32 разрядную 8 значений по 4 бит или 4 раза по 8 бит, или 2 раза по 16 бит или один раз по 32 бит… и.и.и… и чо?
Если мне нужны будут переменные длинной в 1-2 бита(например для хранения статусов), так я воспользуюсь битовыми полями и наберу столько бит, сколько мне потребуется. Надо будет выровнять — выровняю.
И еще один, конкретный вопрос — что вы хотите получить в итоге?
axby
01.09.2015 20:49Все приведённые условия — прямое следствие из того факта, что основой информационных технологий является двоичная система счисления. С этой позиции число 4 выглядит как-то «круглее» (а следовательно — будет удобнее в использовании), чем число 5. Вы хотите, чтобы я предоставил вам полный список случаев, когда эта разница может оказаться существенной? Довольно странно, что это приходится объяснять программисту микроконтроллеров.
Что я хочу получить? Да вроде уже получил. Просто интересно — кто-нибудь ещё хоть о чём-то задумывается? В моём субъективном понимании, конечно.radiolok
01.09.2015 21:14Но мы начали с того что число 4 и число 5 это бессмысленные степени двойки в формуле R=2^n! Которые дают «более круглые» 16 бит и «круглые» 32 бит разрядности. А n=6 даст опять таки «круглые» 64 бит.
Поэтому задам вопрос еще раз — вы вообще о чем?axby
01.09.2015 21:40О том, что 4 — это 2 в целой степени, а 5 и 6 таковыми не являются. А 2 — это система счисления, принятая в сфере ИТ. Если вы не видите в этом смысла, то очевидно, что вам не приходилось задумываться в предложенном мной направлении. Если бы вы потратили достаточное количество времени на подобные размышления, то уверяю вас — таких вопросов бы не возникло. Один из примеров, где это свойство может оказаться полезным, я привёл. Пример не самый убедительный, но там если копать дальше, то можно найти случаи и поинтереснее.
radiolok
01.09.2015 21:47Еще раз — 4 и 5 это уже степени двойки, которыми лично я никогда не пользуюсь, поэтому что они лишены смысла.
зачем и их тоже представлять в виде степени двойки? :)
уже в третий раз кстати:
адресуемое пространство = 2^разрядность
разрядность = 2 ^ непоймичто(пресловутые 4 и 5)
непоймичто = 2 ^ непоймизачем (пресловутая 4 = 2^2)
Пожалуйста, приведите примеры того, где мне понадобится совершать два последних действа.axby
02.09.2015 00:142 ^ 0 = 1
2 ^ 1 = 2
2 ^ 2 = 4 ( = n )
2 ^ 4 = 16 ( = R )
2 ^ 16 = 65536 ( = A = C )
Первые два случая приведены для проформы — типа начинаем с нуля и идём дальше. По третьему пункту я приводил пример, но вы сочли его неубедительным. Признаю, что вы оказались правы. Действительно, если пренебречь эстетическими соображениями (не остаётся неиспользуемых битов), то мне нечего сказать в обоснование необходимости соблюдения этого условия. Главное, на чём я делаю акцент, так это то, что 16 бит задают оптимальный объём командного пространства для реализации языка низкого уровня в его классическом представлении. И если бы удалось подогнать под них всё остальное (в том числе и объём адресуемой памяти), то программировать на таком асемблере было бы одно удовольствие.
niamster
02.09.2015 01:06Я вот прочитал про магическое число 5 и сразу прыгнул в комментарии — неужели до одного меня не доходит в чем суть алхимической формулы
R % n = 0.
А тут прям дискуссия. В общем до сих пор непонятно чем автору числа 5, 6, ну в обще которые не степени двойки не угодили. Ну нельзя всунуть 5 битовых кортежей одинаковой длины в 32 бита. Ну и что? Я лично знаю очень мало примеров где используется упаковка по 4x4 бита, Если идет жесткое кодирование(как, например, передачи данных по воздуху), то никто не выравнивают и у Вас может быть нечетное количество полей в байте.
Более интересно это то, чтоб желательно машинное слово было кратно степени двойки. В таком случае относительная адресация пространства — всего лишь операция сдвига:
ADDR(MEM[idx]) == log2(access_size_bytes) << idx
Да и если все сводить к степени 2ки, то получается, что 16-разрядные PICи с машинным словом 12 бит неудел =(.axby
02.09.2015 01:54Я же говорю, ошибочка вышла — насчёт преимущества 4-ки над 5-кой. Хотя это не опровергает остального.
demimurych
01.09.2015 12:03То есть, если я Вас верно понял, вы предлагаете людям которые занимаются высокоточными вычислениями, да еще и не дай бог в реальном времени, сидеть на 16 битах?
axby
01.09.2015 13:06Я предлагаю людям, которым не чуждо чувство прекрасного, поделиться со мной своими мыслями о том, как сделать «колесо» наиболее «круглым». Не думаю, что издержки в виде нескольких асемблерных команд, предназначенных для разбивания больших объёмов данных на фрагменты, поломают людям все их высокоточные и высоксложные вычисления.
Koroed
01.09.2015 12:25+3А если посмотреть на это с другой стороны, то удельная плотность записи будет максимальной, согласно формуле y=ln(x)/x (где х — основание системы счисления), при x=e.
Давайте делать 2,718281828… -чные процессоры!
amarao
01.09.2015 12:54Действительно, в ОЗУ современных компьютеров на долю машинного кода приходится лишь малая части памяти, всё остальное — данные.
На основании чего это предположение?
Вот, беру я обычный хост виртуализации…
На виртуалке (почти ничем не занятой) кодом занято 117228Кб виртуальной памяти (egrep 'VmExe|VmLib' /proc/*/status|awk '{a+=$2}END{print a}'). Плюс примерно 5Мб под ядро. Итого 122Мб.
На хосте запущено примерно сто виртуалок. 100*117Мб = 12Гб. Плюс код на хосте виртуализатора — ~500Мб (можно пренебречь).
Итого — 12Гб только машинного кода, без полезной нагрузки. Для сравнения, сервер с умеренной нагрузкой (logstash/elastic/kibana/shinken) кушает уже 1Гб _ТОЛЬКО_КОДА_. В контексте сотни виртуалок это уже 100Гб.
Да, я в курсе про shared libraries. Но в данном случае мы же говорим про адресуемое пространство, да?axby
01.09.2015 15:34Вы привели случай, когда данные представляют собой исполняемый код. Чувствуете разницу между ядром (движком хоста) и остальной кучей кода, способ выполнения которого регулируется движком? Хотя бы в размерах. Да и то я думаю, что эти 5Мб следуют из того, что программисты привыкли к мысли, что памятью можно разбрасываться направо и налево. Если же задачи, выполняемые хостом, действительно настолько сложны, что требуют таких огромных затрат, то что нам мешает использовать несколько процессоров?
amarao
01.09.2015 17:14+1Не чувствую. При аппаратной виртуализации код исполняется процессором напрямую, без слоя «интерпретации», то есть является текстом в оригинальном смысле .text.
axby
01.09.2015 20:10Вы хоть представляете себе, что такое гигабайт машинного кода? Да туда движок всего нашего мира с прилегающими параллельными вселенными упаковать можно. По-моему, Ваш комментарий — прекрасное обоснование актуальности поднятой мною темы, а не наоборот.
amarao
01.09.2015 20:17Ещё раз: это код программ. Это может быть повторяющийся код (изолированный между различными тенантами), но это реальный текст, который исполняет ЦП ЭВМ. И он загружен в память.
Так что утверждение о «в ОЗУ современных компьютеров на долю машинного кода приходится лишь малая части памяти, всё остальное — данные» опровергается ближайшим сервером в продакшене.
Для интереса решил посчитать то же самое на моём ноуте. 3.8Гб. Только VmExe и VmLib.
За вычетом VmLib — 400Мб.axby
01.09.2015 21:03Да, в современные технологии я даже и не пытаюсь глубоко вникать (мне достаточно одной фразы — «64-разрядный процессор», чтобы потерять к ним интерес). Поэтому могу допускать неточности в суждениях.
radiolok
01.09.2015 21:26+2Стоп. Т. е. сейчас вы публично заявляете, что не имеете достаточного представления об архитектуре современных микропроцессорных систем, но при этом фанатично заявляете о том, что 16 разрядов хватит всем и всегда?
amarao
01.09.2015 23:43Понимаете, тут такая проблема: старые компьютеры работали примерно на таком уровне, на котором работал, условно говоря, ремесленник образца 18 века. Много тонких деталей, местами виртуозное мастерство, но сам уровень технологий охватываем простым взглядом.
Современное ПО — это безумный бушующий монстр, в котором никто не знает систему целиком, но все используют те её части, которые не знают. Программист линкуется с библиотекой, которая линкуется с библиотекой, которая умеет рендерить svg. Автор программы в душе не знает, что он умеет рендерить svg и не потратил ни секунды времени на поддержку svg. Но она магически появляется (и пользователи довольны).
Цена этому обжорству функционалом — гигабайты кода, который исполняется и исполняется. Выкинуть этот код? Можно. Но на выходе будет скудный функционал без адекватной поддержки ВСЕГО.
Условно говоря: самописное приложение по X'ы не будет уметь многомониторной конфигурации, поддержки HighDPI, поддержки планшетов для рисования, автореакции на поворот экрана, мультиточ, поддержки тем трёх разных window-manager'ов и т.д. Программа, написанная под фреймворк на 300Мб исполняемого кода — будет. И на её написание уйдёт меньше времени и её будет легче сопровождать.
Да, это страшно неуютно. Но функционал требует.axby
02.09.2015 05:38Рад, что Вы меня понимаете. Действительно, я испытываю некоторый дискомфорт, глядя на описанного Вами «монстра». Но дело здесь не в тщетном желании объять необъятное, а в информационной избыточности, вызванной в основном проблемами совместимости. Ничего до конца не продумывается, потом эти недоделки с прилегающими способами их устранения расширяются в геометрической прогрессии, отсюда — «франкенштейн».
Какой толк от такого прогресса, если интереснейшая работа превращается в рутину? Всё нужно делать быстро, пока не опередили конкуренты — сплошное толчение воды в ступе. Не у всех, конечно, так, но я думаю, что как правило, судя по результатам.
Поэтому осваивать новый функционал просто не хватает терпения — мысли сразу перескакивают на то, как бы я там всё переделал. Вот и занимаюсь изобретением «велосипедов».amarao
03.09.2015 00:40+1Товарищи, которые не хотели бежать изо всех сил продолжают пилить архитектурно совершенный Hurd.
radiolok
01.09.2015 20:28Скажите пожалуйста, а ваша профессия никак не связана с юриспруденцией?
axby
01.09.2015 21:12Откуда такие ассоциации? Слишком строго сужу лучшие достижения человечества? Да нет, в общем-то впечатляет — столько светлых голов думало над тем, как заставить это всё заработать. Просто жаба давит — столько ресурсов расходуется впустую. В то время как 16-ти бит вполне хватает. Проверить это в этой жизни у меня вряд ли будет возможность, так — субъективная уверенность, куда от неё денешься. Ну и логика немало ей способствует.
zelyony
01.09.2015 13:00+4тратить несколько дней/недель на придумывание/подведение формул без которых уже полвека работают компы и на редактирование статьи…
размеры адресуемой памяти могут быть независимы от количества бит регистров процессора: 64бит CPU и 40бит шина памяти
Если Вы читаете это, значит это предупреждение именно для Вас. Каждое слово, которое вы прочитаете, бессмысленно — вы просто тратите напрасно очередную частичку своей жизни. Неужели Вам больше нечего делать? Неужели Ваша жизнь настолько пустая и серая, что Вы даже не можете найти, чем занять себя в свободное время? Неужели Вы прочитали все, что хотели прочитать? Неужели Вы подумали обо всем, о чем хотели подумать? Немедленно отправляйтесь на улицу. Найдите себе особу противоположного пола. Прекратите совершать дурацкие покупки и завязывайте с мастурбацией. Увольтесь с работы. Начните драку. Докажите, что Вы живы. Если Вы не начнете действовать, то так и проживете свою никчемную жизнь. Я Вас предупредил… Тайлер
axby
01.09.2015 13:22-1Если вы испытываете потребность давать незнакомым людям советы о том, как часто им следует мастурбировать, то у кого из нас никчемная жизнь?
Deranged
01.09.2015 13:25+2Мдааа.
Я бы для начала просветился как устроены современные процессоры.
Всё это уже было. Сегментные регистры, near-far переходы, миллион режимов адресации, EMM, PAE, отображаемое в память пространство ввода вывода. Всё это существует именно по тому, что раньше памяти было мало и она была дорогая.
Никто не мешал сделать 128-битный процессор в 1970г (да и наверняка были такие). Просто это было нецелесообразно. Теперь памяти вагон, куда проще тупо юзать прямую адресацию (ну, конечно, со страничной трансляцией) чем мудрить с оптимизацией, какой же код команды подставить, что бы файл программы занимал на 1 байт меншье.axby
01.09.2015 20:16В том-то и дело, что «тупо юзать» вместо «тщательно продумывать». Тут же дело в принципе, а не в байте.
pavlick
01.09.2015 20:36а принцип, стало быть, в увеличении стоимости?
axby
01.09.2015 21:15Переделать все технологии обойдётся, конечно, недёшево, но в перспективе лет на 1000, я думаю, это окупится.
pavlick
02.09.2015 00:07на ум приходят счеты, которые продержались 500 лет. Какая-нибудь в голову приходит технология, которая продержалась 1000 лет? Думаю, что с микропроцессорами будет та же история
axby
02.09.2015 00:33Да, я понимаю, что будущее, по всей видимости, за квантовыми технологиями. И кому-то будет интересно всё это создавать. У меня пока мозгов не хватает содержательно об этом думать. Поэтому думаю о том, на что хватает.
horlon
01.09.2015 16:07Не все понял, но понял, о чем в общем идет речь. Не обращайте внимания на недотеп. Много людей думают, что они умные только потому, что сидят здесь, а суть не уловили… Такое впечатление, буд-то это развлекательный сайт… Я всегда думал о том, зачем процессору нужно 64бит? Чтобы адресовать память? Да как-то смешно немного. Значит несколько сот комманд, тоже нужно писать в 64-битном формате, все нужно писать в 64-битном формате… 64-битные программы занимают чуть ли не вдвое больше 32-битных, а никакой разницы… Если нужно адресовать память, так 2 такта это уже будет 32 бита, 4 — 64 бита. А если обьединить четыре процессора работающих параллельно, автоматически при надобности (такое тяжело представить, если думать о x86 архитектуре, но это же «наш» новый «велосипед»). На мой взгляд идеальный процессор это 8-битный, просто потому, что это кратно байту.
P.S. Когда-то в ютубе (еще в 90-х) смотрел видео где 300МГц UltraSPARC уделывал 1ГГц intel за счет паралеллизма. Так что можно сделать и 8-битный процессор, только чтобы он смог тягаться с современным процессором параллелить вычислительные мощьности придется. Сопроцессор я бы тоже убрал, лутше еще один процессор параллельно и на софтверном уровне все будет считаться даже быстрее, чем с ним.axby
01.09.2015 22:00Вы-то, horlon, хоть считать умеете )))
/* что-то не получилось добавить ответ в вашу ветку */
niamster
02.09.2015 00:33Ну как Вам сказать, кроме адресации еще есть потребность в вычислениях с большим машинным словом — криптография, кодирование.
Конечно, можно разделять регистры адресов и данных, но во первых — неэффективно: может простаивать часть тех или этих, во вторых нет особой экономии в плане реализации в железе, в третьих постоянная путаница в арифметике(что хуже всего).
Также не видно большого выигрыша по памяти. Был даже эксперимент в linux — x32 abi, но не выжил из-за нерентабельности.
Я согласен с тем, что инструкции должны иметь фиксированную длину. Декодировать для CPU проще, возможность быстро предсказывать переходы, распараллеливание выполнения. Если не хватает разрядов — можно добавить расширенные — по два машинных слова(смотрите ARM Thumb2). Или что-то вроде VLIW.
К стати intel(по примеру amd) перегоняет все свои x86x инструкции в RISC-подобный микрокод перед тем как начать выполнять их. Если я не ошибаюсь последним пиком совершенства у них было декодирование 5-7 инструкций за такт. Естественно плата за это — усложнение внутренней архитектуры, необходимость в повышенной частоте, повышенном энергопотреблении. В то время как в архитектуре с фиксированной длинной инструкции такой блок просто-напросто ненужен, его нет.
Если нужно адресовать память, так 2 такта это уже будет 32 бита, 4 — 64 бита.
Даже если опустить кэш, то это разрядность и частота шины данных между CPU и RAM. Ну и обычно все передается burst-ами, так что нет большой разницы для 1 или 4 байта.axby
02.09.2015 01:45Хорошо, давайте попытаемся подойти к этому вопросу с другой стороны. Допустим (гипотетически), что Вам предлагают решить эту задачу, предоставив соответствующий проект, призванный решить основные проблемы, вызванные столь радикальным сокращением объёма адресуемой памяти (полагаю, что ограничение по объёму командного пространства становится в таком случае несущественным). Во всём остальном Вы ничем не ограничены (кроме, естественно, законов физики и возможностей современных технологий). У Вас есть время, необходимое на разработку концептуальной информационной модели, по истечении которого Вы предоставляете свой проект, и если это решение окажется адекватным современным требованиям, то становитесь миллиардером. Ну и вопрос, соответственно, в том, насколько велика степени Вашей уверенности в том, что это дело безнадёжно и даже не стоит тратить на него своё время?
niamster
02.09.2015 02:44Я подумаю над этим, но если честно, то у меня есть сомнения в эффективной организации работы CPU-RAM, если последней на много порядков больше. Можно взять чистую гарвардскую архитектуру, тогда у вас адресуемое пространство удваивается ;) — 64K под инструкции, 64K под данные. Собственно подавляющее большинство микроконтроллеров на 8/16 бит используют этот трюк.
Как выход — можно сделать кластер из таких 16-битных CPU. У каждого по своей функции. Правда расходы на коммуникацию будут губительными.niamster
02.09.2015 04:35К стати такой вот подход был у Parallax Propeller.
Из-за сложностей развития такой сложной архитектуры проект похоже умер.
axby
02.09.2015 05:53Кластер подразумевает плотное взаимодействие между устройствами, неужели прям-таки «губительные»?
Возможно, я как дилетант недооцениваю сложностей. Приведённые ниже рассуждения тоже слабо обоснованы?niamster
03.09.2015 01:53Конечно, на данный момент это одно из узких мест многопроцессорных и многоядерных систем.
Если этот «кластер» не будет выполнять операции параллельно то можно про накладные расходы закрыть глаза. Но зачем тогда строить кластер?axby
03.09.2015 23:11А если устройство процессора будет на порядок проще, это будет как-то способствовать решению описанных проблем?
niamster
03.09.2015 23:54Вы знакомы с lock contention? Не приходит на ум русский термин. Суть в том, что сами сообщения не тяжеловесны, но вот когда они нагружают шину одновременным доступом — производительность X АЛУ проседает практически до 1.
axby
04.09.2015 01:49Решение мне представляется таким. Помимо обмена сообщениями, шина данных должна обеспечивать блочную пересылку данных из памяти одного процессора в заданный участок памяти другого (а также между буфером внешней памяти размером 8 Гб, описанным ниже, и памятью процессоров). Для этих целей определяем 2*2 канала для каждого процессора: командный и канал данных (на ввод и на вывод). Ширину первого можно сделать, скажем, 64 бита или больше, чтобы поместить в него исчерпывающую информацию о том, что куда перебрасывать (ну или просто сообщения и запросы без аргументов). С участка памяти-источника снимается соответствующая матрица, шина открывает доступ от памяти-источника к памяти-приёмнику, после чего эта память обновляется одним «залпом». То есть все действия, выполняемые шиной, будут элементарными, сложность может состоять лишь в том, чтобы обеспечить доступ от каждого к каждому, для чего их количество придётся ограничивать.
Мне не совсем понятно, из чего конфликт при блокировках следует с необходимостью? Если скорость выполнения операций шиной соизмерима со скоростью выполнения команд процессором, то эта проблема должна возникать лишь в том случае, когда задачи, распределяемые между процессорами, слишком уж мелко фрагментируются среднее количество команд, выполняемых в рамках одного фрагмента, становится меньше, чем количество процессоров. Тогда понятно, почему шина не успевает обрабатывать их запросы. Но зачем их (задачи) так мелко дробить?
Если не затруднит, дайте, пожалуйста, минимально-содержательный ответ, что я здесь не так понимаю.
niamster
02.09.2015 05:40Допустим, что у вашего процессора хитрая индексация памяти и когда дается команда «дай мне данные по адресу X» процессор по факту будет выдавать 16 бит по адресу X << 1. Так получится адресовать 1MB, но отсутствует возможность выборки/сохранения байта — придется самостоятельно делать сдвиг. Это по сути то же, что многие процессоры делают при невыровненном доступе к памяти, только проблема обратная.
Другая проблема в том как разделять состояние между окнами? В регистрах вряд ли получится — слишком жесткое ограничение.
Возможно делать дополнительный набор «разделяемых» окон и вводить специальные инструкции(что-то вродеld|st reg, addr, win, где значения addr и win хранятся в регистрах). Но это по сути тоже самое, что сегментная память у x86 от которой intel слава богу отказался. Да и тогда прийдется вводить либо понятие расширенных инструкций, либо увеличивать разрядность инструкции, либо уменьшать количество регистров, потому, что если архитектура использует 16 регистров, то при 3х операндных инструкциях остается всего лишь 4бита под OpCode, что достаточно печально.
Мне все-таки пока непонятно каковы могут быть причины требования разрядности 16бит если стоит задача адресовать большое количество памяти.
На самом деле надо рассчитать требуемое количество вентилей(gates) для одного случая и представить сколько это займет на кристалле. При нынешних тех процессах ALU+register file занимает не более нескольких процентов площади. Основной «прожора» — память(cache, sram, etc.)
Разве что этот процессор должен быть выполнен по тех процессу «лампа накаливания» — тогда да, разница будет ощутима =D.
Из этого мысленного эксперимента могу сделать вывод — да, конечно, реально иметь такую архитектуру, если это оправданно технологически. В противном случае вводимые ограничения влияют как на удобство разработки(придется писать хитрый компилятор и загрузчик, затачивать программы под архитектуру) так и поддержку.
Если я правильно понял то Sony потому и перешла на x86_64 в PS4 потому, что всех задолбало переписывать игрушки под их хитрую архитектуру. Да, IBM Cell был бесподобен но вызывал головную боль у разработчиков.axby
03.09.2015 22:16Из соображений удобства и эффективности, каждое звено должно представлять из себя целостное и завершённое решение. Завершённость — это то, чего, на мой взгляд, не зватает современным ИТ. Поскольку асемблер за всё время их развития принципиально не изменился, мне видится уместным принять объём командного пространства фиксированным, а именно — 16 бит, которых вполне хватает. То же самое с объёмом адресуемой памяти. Мегабитом кода тоже можно представить некое целостное и завершённое (и при этом достаточно ёмкое) решение, например — ядро ОСи. Отсюда — идеализация в виде формулы: A = C = 2 ^ 16. Вы понимаете, что принципиальных сложностей для аппаратной реализации этой концепции не существует. Не пойму только, почему Вы считаете, что компилятор в этом случае должен быть «хитрее»? По моему, очень даже наоборот, чему выше даны наглядные обоснования:
«Соблюдение данного условия означает, что любая ячейка способна вместить адрес любой другой ячейки, а также содержит исчерпывающую информацию о выполняемом действии. Уменьшение адресного пространства чревато ссылками на несуществующую память, а увеличение — избыточной информацией, необходимой для обеспечения возможности адресовать всю память. То же самое с командным пространством.»
Думаю, если отвлечься от существующих стереотипов, преимущество предложенного подхода станет очевидным.axby
03.09.2015 23:03/* не скопипастил начало предыдущего сообщения */:
Больше всего меня смущает то, что асемблер не меняется, а разрядность растёт. Или даже считается устаревшим понятием — что смущает меня ещё больше. Ладно бы изобрели машинный язык, заменяющий ЯП высокого уровня — тогда бы я ещё мог понять 64 бита в основе архитектуры. Попытаюсь обосновать.
Иерархию развития ИТ можно представить в виде следующей цепочки:
железо => асм => ЯП => ОСь => сеть
Из соображений удобства и эффективности,…
niamster
03.09.2015 23:27В основном все утыкается в обратную совместимость. Потому intel до сих пор поддерживает набор инструкций i386.
И это на самом деле позволило intel вырваться вперед.
Если вас не беспокоит обратная совместимость — не проблема. Большая часть альтернативных архитектур либо забивают на это, либо их ISA была изначально грамотно составлена и не меняется уже годами. Посмотрите на RISC архитектуры.
На сегодняшний день если задача не требует адресации более чем разрядность регистров — никто привентивно не пытается ее увеличить. Посмотрите сколько 16-ти битных контроллеров. Но штука в том, что сам ALU там выполняет административную функцию в то время как основная задача выполняется в железе(кодеки, сеть, etc.)
А придумывать сложность чтоб выиграть на «паре» вентилей — это удел 60х где вентили были размером с кулак и жрали больше чем нынешний ноутбук средней паршивости.axby
04.09.2015 00:18Да, обратная совместимость меня не беспокоит, ибо в своих мысленных экспериментах я вообще абстрагируюсь от современных ИТ. У меня к ним ничего личного (как это могло показаться из моих сообщений), просто интересно строить идеальные абстрактные модели, предполагая, что их аппаратная реализация — дело наживное. Наиболее интересной была задача втулить систему команд с прилегающим набором адресаций в 16 бит, так чтобы прийти к наилучшему соответствию с принципом «есть всё что нужно и нет ничего лишнего». 32 бита для этой цели подходят гораздо хуже, появляется информационный избыток, что весьма затрудняет соблюдение второй части принципа (желательно ведь решить эту задачу наиболее лаконичным способом, чтобы приходилось рассматривать как можно меньше частных случаев).
В общем, асемблер у меня получился — просто загляденье. А сюда я зашёл в надежде встретить людей, которые тоже задавались подобными вопросами, и сопоставить их ход мысли со своим.niamster
04.09.2015 00:36Получается сферический конь в вакууме.
Во первых ISA может быть таковой, что размер инструкции 16 бит, а машинное слово 32 бит. Во вторых если уж идеализировать — вы знакомы с mill CPU. Хотя я не согласен с автором насчет ISA(VLIW уже провалилась у intel), он излагает весьма, весьма веские доводы в пользу свое архитектуры(черпает много из DSP, что в принципе логично учитывая текущие задачи CPU — декодирование аудио, видео, распознавание образов и текстов). Я бы скорее отнес mill CPU к универсальным DSP, а как основной CPU поставил бы RISC.
Вы упомянули, что у вас уже есть готовая ISA — можете поделиться?axby
04.09.2015 02:20Я ведь упоминал о системе команд и способах адресации, а они практически полностью абстрагируются от коммуникаций между устройствами. То есть у меня готовое АЛУ, а не ISA. Мне несложно поделиться, но предполагаю, что это не совсем то, что было бы Вам интересно. Уточните, пожалуйста.
vmchaz
02.09.2015 01:59Я тоже думал о том, что хорошо бы байту состоять из 2^(2^2) бит. Но при этом разрядность адресной шины стоит оставить равной 32 или 64 битам. Тогда предел 32-битных систем подошёл бы чуть позже — это раз (т.к. адресовалось бы 8 нынешних гигабайт) и было бы меньше проблем с кодировками (16-битный Unicode был бы стандартом).
P.S. Ещё иногда посещают мысли о том, почему самые точные из обрабатываемых сопроцессором чисел содержат 10 байт, а не 16. Но вряд ли кто-то возьмётся выкидывать все возможные архитектурные костыли из нынешних процессоров.axby
02.09.2015 06:20Меня такие мысли посещают часто, оттого и занимаюсь подобной ерундой. В электронике разбираюсь слабо, впечатление такое, что специалисты в этой области просто чудеса творят. Отсюда уверенность в том, что практически любую абстрактную модель можно легко запечатлеть в железе. Если любую, то почему бы не выбрать наиболее простую и ненадуманную? Я полагал, что всё сводится к вопросу совместимости или там юридическим нюансам, но никак не технологическим. Возможно, мои представления несколько преувеличены.
axby
02.09.2015 04:03Я понимаю причины, по которым предложенный мною подход может показаться неприемлемым. Обычно мы отталкиваемся от задачи (в общем виде обозначим её, как «задачи, стоящие перед современными ИТ»), и подбираем под неё адекватное решение (способов которого современные ИТ предлагают великое множество). А тут получается наоборот — в качестве исходной посылки предлагается ограничение, взятое исключительно из эстетических соображений, под которое вроде бы как должна подстроиться вся компьютерная индустрия. Надеюсь, что последний тезис вы не воспринимаете всерьёз и понимаете, что я не предлагаю здесь выходить за рамки мысленного эксперимента.
Результат которого по сути видится мне примерно таким. Берём буфер, выполняющий роль кэша, обеспечивающего быстрый обмен данными между процессором(-ами) и устройствами (из соображений соответствия 16-разрядной архитектуре принимаем его размер равным 65536 * 65536 * 16 бит = 8 Гбайт). Реализация возможности обновления памяти за 1 такт путём оптовой пересылки мегабита кода/данных, я полагаю, у современных ИТ не вызовет особых затруднений — скорости света, вроде бы хватает (кстати, довольно впритык, если полагать расстояние между процессором и кэш-памятью на превышающим 10 см при тактовой частоте 1 Ггц). Вот, собственно, и весь способ устранения ограничения на объём памяти. В остальном (касательно реализации самого интерфейса) имеем бесконечное и неопределимое множество способов, как это можно сделать.
Да, придётся вводить дополнительные параметры, как минимум 4 штуки: номер блока памяти в кэше [0...65535], начальный адрес [0...65535], длину [0...65535], и смещение [0...65535] — это чтобы пересылать данные из любого места кэша в любое место ОЗУ процессора и обратно. Но это можно делать один раз за «пробег» текущего фрагмента кода, а не по любому поводу. В конце концов, простота в устройстве может значительно облегчить реализацию параллельных вычислений путём организации многопроцессорных систем.
Вообще я не сторонник перекладывания функционала на «плечи» процессора, даже аппаратного умножения на признаю. Может, ностальгия по детству сказывается, но скорее меня здесь смущает расхождение с представлением о низкоуровневом программировании: выполнение любой команды я должен представлять себе визуально, иначе абстракции получаются оторванными от физики, а такие пробелы в представлениях на базовом уровне нежелательны. Конечно, это условность — всю программу в голове не прокрутишь, и тем не менее я думаю, что этим не стоит пренебрегать ради выжимания тактов.
radiolok
Эта статья для какого года писалась? Или это такой замаскированный перевод?
axby
.
axby
/* Вам ниже ответил, не попал с первой попытки */