Все приведённые условия — прямое следствие из того факта, что основой информационных технологий является двоичная система счисления. С этой позиции число 4 выглядит как-то «круглее» (а следовательно — будет удобнее в использовании), чем число 5. Вы хотите, чтобы я предоставил вам полный список случаев, когда эта разница может оказаться существенной? Довольно странно, что это приходится объяснять программисту микроконтроллеров.
Что я хочу получить? Да вроде уже получил. Просто интересно — кто-нибудь ещё хоть о чём-то задумывается? В моём субъективном понимании, конечно.
Я исхожу из объективного представления о том, что если длина команды будет равна разрядности процессора, то программировать такой процессор будет гораздо удобнее, чем в противном случае. То есть при прочих равных условиях первому случаю следует отдать предпочтение. И для того, чтобы ваше критика была содержательной, вам следует как-то аргументировать своё мнение о том, что 16-ю разрядами никак не обойтись при решении задач, стоящих перед современными ИТ.
Вы хоть представляете себе, что такое гигабайт машинного кода? Да туда движок всего нашего мира с прилегающими параллельными вселенными упаковать можно. По-моему, Ваш комментарий — прекрасное обоснование актуальности поднятой мною темы, а не наоборот.
Я PIC-и программировал, так что пришлось испытать все «прелести» от переключения банков и прочих недоделок, забивающих голову балластной информацией. С AVR-ами не сталкивался, но слышал о них хорошие отзывы от коллег. Удивлён, что 8-разрядные до сих пор в ходу.
PDP-11 мне тоже симпатизирует, с БК-шкой у меня связаны светлые воспоминания из детства, и отчасти эта статья навеяна ностальгией по лучшим годам моей программерской жизни. Но там тоже «дырок» хватает, о которых я уже упоминал. «Без дырок» в моём понимании — значит без избытка и недостатка, то есть командное пространство не должно содержать пустот (резервного кода) и заведомо бесполезных действий. Ключевые моменты здесь можно строго формализовать, причём достаточно тривиальным способом. В том числе и причину, по которой процессор должен быть именно 16-разрядным — не больше и не меньше (по крайней мере, если оставаться в рамках классических представлений о программировании). Принципиальных препятствий для этого нет (замечаний по существу я здесь пока не увидел), а преимущество очевидно (по крайней мере мне). То есть я хотел сказать именно то, о чём гласит заголовок.
Что касается сопроцессора, то это понятие растяжимое (в плане его специализации). Я же имею в виду классическую реализацию. Во многом она должна пересекаться с PDP-11, поскольку реализованная там концепция, на мой взгляд, лучше всех претендует на универсальность (например, ортогональная система команд). А как будут взаимодействовать между собой процессоры («со-», или «обычные») — так это уже вопрос реализации интерфейса обмена данными между устройствами. У меня нет четкого представления о том, как это должно выглядеть, однако уверен, что фундаментальный подход здесь позволит найти оптимальное решение. Моя же задача — максимально эффективно потратить имеющиеся 16 бит на систему команд и способы адресации. При этом от обмена данными можно практически полностью абстрагироваться — скажем, включить в систему команд единственную поштучную (без операндов) команду, осуществляющую взаимодействие с «внешним миром», а всю информацию, определяющую способ этого взаимодействия, хранить в регистрах, стеке, памяти, в общем — где и как угодно. Где именно и как именно выяснится, когда будет реализован интерфейс обмена данными. То есть нет никаких сложностей в том, чтобы состыковать «железо» с «мозгами» бесшовно.
Но в «железе» я, к сожалению, разбираюсь значительно хуже, чем в конструировании абстракций.
А n — это двоичный логарифм от разрядности. Допустим, нам нужно подсчитать количество единиц в каждой ячейке выделенного блока памяти, и сохранить эти данные в другой области. В 16 бит уложится аккурат 4 таких значения по 4 бита каждое. А с 32-битной ячейкой такое уже не прокатит (32 — 6*5 = 2 бита окажутся лишними). На первый взгляд это несущественно, но я к таким «мелочам» отношусь весьма скурпулёзно, особенно если речь идёт о создании информационной модели идеального процессора. Фантазёр и мечтатель, что тут поделаешь )
Я это называю плохим стилем проектирования. В 32 разряда при желании можно втулить полноценный объектно-ориентированный асм, а 64-разрядный вообще должен «стихами разговаривать». Очевидно, у нас разные критерии оценки качества.
Вы привели случай, когда данные представляют собой исполняемый код. Чувствуете разницу между ядром (движком хоста) и остальной кучей кода, способ выполнения которого регулируется движком? Хотя бы в размерах. Да и то я думаю, что эти 5Мб следуют из того, что программисты привыкли к мысли, что памятью можно разбрасываться направо и налево. Если же задачи, выполняемые хостом, действительно настолько сложны, что требуют таких огромных затрат, то что нам мешает использовать несколько процессоров?
Опыт небольшой, но достаточный для того, чтобы оценить степень неудобства разделения указателей на ближние-дальние. А откуда они возьмутся, если ячейка способна вместить адрес любой другой ячейки? В данном случае разбиение данных на фрагменты не подразумевает необходимость плодить сущности, а «накладные расходы» на размер кода и быстродействие незначительны.
Я предлагаю людям, которым не чуждо чувство прекрасного, поделиться со мной своими мыслями о том, как сделать «колесо» наиболее «круглым». Не думаю, что издержки в виде нескольких асемблерных команд, предназначенных для разбивания больших объёмов данных на фрагменты, поломают людям все их высокоточные и высоксложные вычисления.
Бесконечная память — это идеализация. Для решения конкретных задач разница будет состоять лишь в том, что данные, расположенные во внешней памяти непрерывно и предназначенные для обработки процессором, необходимо будет разбивать на фрагменты и пересылать их во внутреннюю память. И вы считаете, что необходимость добавления к программе нескольких машинных команд — это большое неудобство?
Что я хочу получить? Да вроде уже получил. Просто интересно — кто-нибудь ещё хоть о чём-то задумывается? В моём субъективном понимании, конечно.
PDP-11 мне тоже симпатизирует, с БК-шкой у меня связаны светлые воспоминания из детства, и отчасти эта статья навеяна ностальгией по лучшим годам моей программерской жизни. Но там тоже «дырок» хватает, о которых я уже упоминал. «Без дырок» в моём понимании — значит без избытка и недостатка, то есть командное пространство не должно содержать пустот (резервного кода) и заведомо бесполезных действий. Ключевые моменты здесь можно строго формализовать, причём достаточно тривиальным способом. В том числе и причину, по которой процессор должен быть именно 16-разрядным — не больше и не меньше (по крайней мере, если оставаться в рамках классических представлений о программировании). Принципиальных препятствий для этого нет (замечаний по существу я здесь пока не увидел), а преимущество очевидно (по крайней мере мне). То есть я хотел сказать именно то, о чём гласит заголовок.
Что касается сопроцессора, то это понятие растяжимое (в плане его специализации). Я же имею в виду классическую реализацию. Во многом она должна пересекаться с PDP-11, поскольку реализованная там концепция, на мой взгляд, лучше всех претендует на универсальность (например, ортогональная система команд). А как будут взаимодействовать между собой процессоры («со-», или «обычные») — так это уже вопрос реализации интерфейса обмена данными между устройствами. У меня нет четкого представления о том, как это должно выглядеть, однако уверен, что фундаментальный подход здесь позволит найти оптимальное решение. Моя же задача — максимально эффективно потратить имеющиеся 16 бит на систему команд и способы адресации. При этом от обмена данными можно практически полностью абстрагироваться — скажем, включить в систему команд единственную поштучную (без операндов) команду, осуществляющую взаимодействие с «внешним миром», а всю информацию, определяющую способ этого взаимодействия, хранить в регистрах, стеке, памяти, в общем — где и как угодно. Где именно и как именно выяснится, когда будет реализован интерфейс обмена данными. То есть нет никаких сложностей в том, чтобы состыковать «железо» с «мозгами» бесшовно.
Но в «железе» я, к сожалению, разбираюсь значительно хуже, чем в конструировании абстракций.
А n — это двоичный логарифм от разрядности. Допустим, нам нужно подсчитать количество единиц в каждой ячейке выделенного блока памяти, и сохранить эти данные в другой области. В 16 бит уложится аккурат 4 таких значения по 4 бита каждое. А с 32-битной ячейкой такое уже не прокатит (32 — 6*5 = 2 бита окажутся лишними). На первый взгляд это несущественно, но я к таким «мелочам» отношусь весьма скурпулёзно, особенно если речь идёт о создании информационной модели идеального процессора. Фантазёр и мечтатель, что тут поделаешь )