Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
16ГБ это слишком много, легко преодолеть 1мегабит, PDP-11… 32 разряда это последние достижения в области ИТ индустрии. Мало одного процессора, возьмите два..
Эта статья для какого года писалась? Или это такой замаскированный перевод?
Вот сами и программируйте на PDP-11. А мы предпочтем «Франкенштейнов».
Ок, а теперь продемонстрируйте работающий майнинг биткоинтов на PDP-11.
640 килобайт хватит всем…
640 килобайт хватит всем…
.
Внешняя память предполагается условно-бесконечной, вы наверное невнимательно читали.
И вы считаете, что адресовать условно-бесконечную память с помощью 16 разрядов — это удобно?
Бесконечная память — это идеализация. Для решения конкретных задач разница будет состоять лишь в том, что данные, расположенные во внешней памяти непрерывно и предназначенные для обработки процессором, необходимо будет разбивать на фрагменты и пересылать их во внутреннюю память. И вы считаете, что необходимость добавления к программе нескольких машинных команд — это большое неудобство?
А у вас какой опыт программирования на малоразрядных системах? На ассемблере?
Даже при программировании на C под ДОС в девяностых все эти сегменты, модели памяти, ближние-дальние указатели были крайне неудобны. И эти несколько инструкций добавляются почти к каждому доступу к памяти.
Даже при программировании на C под ДОС в девяностых все эти сегменты, модели памяти, ближние-дальние указатели были крайне неудобны. И эти несколько инструкций добавляются почти к каждому доступу к памяти.
Опыт небольшой, но достаточный для того, чтобы оценить степень неудобства разделения указателей на ближние-дальние. А откуда они возьмутся, если ячейка способна вместить адрес любой другой ячейки? В данном случае разбиение данных на фрагменты не подразумевает необходимость плодить сущности, а «накладные расходы» на размер кода и быстродействие незначительны.
Ну и назрядность процессора никакого отношения к размеру комманд не имеет. На x86-64 размер комманд начинается с 1 байта.
Я это называю плохим стилем проектирования. В 32 разряда при желании можно втулить полноценный объектно-ориентированный асм, а 64-разрядный вообще должен «стихами разговаривать». Очевидно, у нас разные критерии оценки качества.
Ещё раз: вы исходите из ложной посылки что длина команд как-то связана с «разрядностью» процессора. Это очень редко так. Вообще поняттие «разрядность» в современном мире не существует. Потому что разрядность команд, разрядность регистров, разрядность арифметических операций, разрядность адресного пространства, разрядность минимально адресуемого слова, разрядность физической шины адреса и разрядность физической шины данных (а их ещё может быть несколько) — они все в любой современной архитектуре очень слабо связаны друг с другом.
PS Да я сам считаю что x86 некрасив. Но 16-разрядные системы намного хуже.
PS Да я сам считаю что x86 некрасив. Но 16-разрядные системы намного хуже.
Я исхожу из объективного представления о том, что если длина команды будет равна разрядности процессора, то программировать такой процессор будет гораздо удобнее, чем в противном случае. То есть при прочих равных условиях первому случаю следует отдать предпочтение. И для того, чтобы ваше критика была содержательной, вам следует как-то аргументировать своё мнение о том, что 16-ю разрядами никак не обойтись при решении задач, стоящих перед современными ИТ.
Например, проблемы будут с непосредственными операндами. Сколько бит непосредственный операнд будет в 16-битной команде? 8?
извините, конечно же стоило так написать sarcasm 640 килобайт хватит всем… /sarcasm
Я же говорю — хобби у меня такое: ограничить себя 16-ю битами, а потом думать, как из этого выкручиваться.
Ну а у меня профессия — ограничивать себя 8 или 16 битами и работать с этим (я разработчик устройств на микроконтроллерах), хотя и 32 разряда мне не чужды — все зависит от задач, стоимости разработки и конечного решения.
Мне симпатизирует PDP-11, так как я люблю использовать семейство контроллеров MSP430. У него похожая архитектура. И после плотного ассемблерного взаимодействия с 8-разрядными AVR, сопряженного особой болью при работе с адресацией, соглашусь с утверждением, что:
Микропроцессор должен быть Как Минимум, 16-ти разрядным.
Вы это хотели сказать своей статьей? Или что-то другое?
Вы посчитали степень двойки и написали что PDP-11, которому уже больше 40 лет — это хорошо, а современный многоядерный процессор(кой неявно упоминается в статье) — это плохо. Кстати, что можете сказать на счет математических сопроцессоров? Зло? Или можно использовать?
Ну и технический вопрос по статье — что такое n? Просто в формуле он присутствует, но практически не подписан. Это ваша попытка объяснить, почему разрядность шины адреса есть степень двойки? Так в эпоху 286 и 16-разрядного 386SX шина адреса вполне успешно была 24 бит.
Мне симпатизирует PDP-11, так как я люблю использовать семейство контроллеров MSP430. У него похожая архитектура. И после плотного ассемблерного взаимодействия с 8-разрядными AVR, сопряженного особой болью при работе с адресацией, соглашусь с утверждением, что:
Микропроцессор должен быть Как Минимум, 16-ти разрядным.
Вы это хотели сказать своей статьей? Или что-то другое?
Вы посчитали степень двойки и написали что PDP-11, которому уже больше 40 лет — это хорошо, а современный многоядерный процессор(кой неявно упоминается в статье) — это плохо. Кстати, что можете сказать на счет математических сопроцессоров? Зло? Или можно использовать?
Ну и технический вопрос по статье — что такое n? Просто в формуле он присутствует, но практически не подписан. Это ваша попытка объяснить, почему разрядность шины адреса есть степень двойки? Так в эпоху 286 и 16-разрядного 386SX шина адреса вполне успешно была 24 бит.
Я PIC-и программировал, так что пришлось испытать все «прелести» от переключения банков и прочих недоделок, забивающих голову балластной информацией. С AVR-ами не сталкивался, но слышал о них хорошие отзывы от коллег. Удивлён, что 8-разрядные до сих пор в ходу.
PDP-11 мне тоже симпатизирует, с БК-шкой у меня связаны светлые воспоминания из детства, и отчасти эта статья навеяна ностальгией по лучшим годам моей программерской жизни. Но там тоже «дырок» хватает, о которых я уже упоминал. «Без дырок» в моём понимании — значит без избытка и недостатка, то есть командное пространство не должно содержать пустот (резервного кода) и заведомо бесполезных действий. Ключевые моменты здесь можно строго формализовать, причём достаточно тривиальным способом. В том числе и причину, по которой процессор должен быть именно 16-разрядным — не больше и не меньше (по крайней мере, если оставаться в рамках классических представлений о программировании). Принципиальных препятствий для этого нет (замечаний по существу я здесь пока не увидел), а преимущество очевидно (по крайней мере мне). То есть я хотел сказать именно то, о чём гласит заголовок.
Что касается сопроцессора, то это понятие растяжимое (в плане его специализации). Я же имею в виду классическую реализацию. Во многом она должна пересекаться с PDP-11, поскольку реализованная там концепция, на мой взгляд, лучше всех претендует на универсальность (например, ортогональная система команд). А как будут взаимодействовать между собой процессоры («со-», или «обычные») — так это уже вопрос реализации интерфейса обмена данными между устройствами. У меня нет четкого представления о том, как это должно выглядеть, однако уверен, что фундаментальный подход здесь позволит найти оптимальное решение. Моя же задача — максимально эффективно потратить имеющиеся 16 бит на систему команд и способы адресации. При этом от обмена данными можно практически полностью абстрагироваться — скажем, включить в систему команд единственную поштучную (без операндов) команду, осуществляющую взаимодействие с «внешним миром», а всю информацию, определяющую способ этого взаимодействия, хранить в регистрах, стеке, памяти, в общем — где и как угодно. Где именно и как именно выяснится, когда будет реализован интерфейс обмена данными. То есть нет никаких сложностей в том, чтобы состыковать «железо» с «мозгами» бесшовно.
Но в «железе» я, к сожалению, разбираюсь значительно хуже, чем в конструировании абстракций.
А n — это двоичный логарифм от разрядности. Допустим, нам нужно подсчитать количество единиц в каждой ячейке выделенного блока памяти, и сохранить эти данные в другой области. В 16 бит уложится аккурат 4 таких значения по 4 бита каждое. А с 32-битной ячейкой такое уже не прокатит (32 — 6*5 = 2 бита окажутся лишними). На первый взгляд это несущественно, но я к таким «мелочам» отношусь весьма скурпулёзно, особенно если речь идёт о создании информационной модели идеального процессора. Фантазёр и мечтатель, что тут поделаешь )
PDP-11 мне тоже симпатизирует, с БК-шкой у меня связаны светлые воспоминания из детства, и отчасти эта статья навеяна ностальгией по лучшим годам моей программерской жизни. Но там тоже «дырок» хватает, о которых я уже упоминал. «Без дырок» в моём понимании — значит без избытка и недостатка, то есть командное пространство не должно содержать пустот (резервного кода) и заведомо бесполезных действий. Ключевые моменты здесь можно строго формализовать, причём достаточно тривиальным способом. В том числе и причину, по которой процессор должен быть именно 16-разрядным — не больше и не меньше (по крайней мере, если оставаться в рамках классических представлений о программировании). Принципиальных препятствий для этого нет (замечаний по существу я здесь пока не увидел), а преимущество очевидно (по крайней мере мне). То есть я хотел сказать именно то, о чём гласит заголовок.
Что касается сопроцессора, то это понятие растяжимое (в плане его специализации). Я же имею в виду классическую реализацию. Во многом она должна пересекаться с PDP-11, поскольку реализованная там концепция, на мой взгляд, лучше всех претендует на универсальность (например, ортогональная система команд). А как будут взаимодействовать между собой процессоры («со-», или «обычные») — так это уже вопрос реализации интерфейса обмена данными между устройствами. У меня нет четкого представления о том, как это должно выглядеть, однако уверен, что фундаментальный подход здесь позволит найти оптимальное решение. Моя же задача — максимально эффективно потратить имеющиеся 16 бит на систему команд и способы адресации. При этом от обмена данными можно практически полностью абстрагироваться — скажем, включить в систему команд единственную поштучную (без операндов) команду, осуществляющую взаимодействие с «внешним миром», а всю информацию, определяющую способ этого взаимодействия, хранить в регистрах, стеке, памяти, в общем — где и как угодно. Где именно и как именно выяснится, когда будет реализован интерфейс обмена данными. То есть нет никаких сложностей в том, чтобы состыковать «железо» с «мозгами» бесшовно.
Но в «железе» я, к сожалению, разбираюсь значительно хуже, чем в конструировании абстракций.
А n — это двоичный логарифм от разрядности. Допустим, нам нужно подсчитать количество единиц в каждой ячейке выделенного блока памяти, и сохранить эти данные в другой области. В 16 бит уложится аккурат 4 таких значения по 4 бита каждое. А с 32-битной ячейкой такое уже не прокатит (32 — 6*5 = 2 бита окажутся лишними). На первый взгляд это несущественно, но я к таким «мелочам» отношусь весьма скурпулёзно, особенно если речь идёт о создании информационной модели идеального процессора. Фантазёр и мечтатель, что тут поделаешь )
Еще раз, что за значения такие в 4 бит и 5 бит? Откуда они взялись и зачем они нужны? Просто сначала это степень двойки, а потом… это почему-то длина в битах.
Зачем (R % n == 0) должно быть true? что это дает? кому это дает?
Ну хорошо, в 16 бит влезет 4 значения по 4 бит, ну а в 32 разрядную 8 значений по 4 бит или 4 раза по 8 бит, или 2 раза по 16 бит или один раз по 32 бит… и.и.и… и чо?
Если мне нужны будут переменные длинной в 1-2 бита(например для хранения статусов), так я воспользуюсь битовыми полями и наберу столько бит, сколько мне потребуется. Надо будет выровнять — выровняю.
И еще один, конкретный вопрос — что вы хотите получить в итоге?
Зачем (R % n == 0) должно быть true? что это дает? кому это дает?
Ну хорошо, в 16 бит влезет 4 значения по 4 бит, ну а в 32 разрядную 8 значений по 4 бит или 4 раза по 8 бит, или 2 раза по 16 бит или один раз по 32 бит… и.и.и… и чо?
Если мне нужны будут переменные длинной в 1-2 бита(например для хранения статусов), так я воспользуюсь битовыми полями и наберу столько бит, сколько мне потребуется. Надо будет выровнять — выровняю.
И еще один, конкретный вопрос — что вы хотите получить в итоге?
Все приведённые условия — прямое следствие из того факта, что основой информационных технологий является двоичная система счисления. С этой позиции число 4 выглядит как-то «круглее» (а следовательно — будет удобнее в использовании), чем число 5. Вы хотите, чтобы я предоставил вам полный список случаев, когда эта разница может оказаться существенной? Довольно странно, что это приходится объяснять программисту микроконтроллеров.
Что я хочу получить? Да вроде уже получил. Просто интересно — кто-нибудь ещё хоть о чём-то задумывается? В моём субъективном понимании, конечно.
Что я хочу получить? Да вроде уже получил. Просто интересно — кто-нибудь ещё хоть о чём-то задумывается? В моём субъективном понимании, конечно.
Но мы начали с того что число 4 и число 5 это бессмысленные степени двойки в формуле R=2^n! Которые дают «более круглые» 16 бит и «круглые» 32 бит разрядности. А n=6 даст опять таки «круглые» 64 бит.
Поэтому задам вопрос еще раз — вы вообще о чем?
Поэтому задам вопрос еще раз — вы вообще о чем?
О том, что 4 — это 2 в целой степени, а 5 и 6 таковыми не являются. А 2 — это система счисления, принятая в сфере ИТ. Если вы не видите в этом смысла, то очевидно, что вам не приходилось задумываться в предложенном мной направлении. Если бы вы потратили достаточное количество времени на подобные размышления, то уверяю вас — таких вопросов бы не возникло. Один из примеров, где это свойство может оказаться полезным, я привёл. Пример не самый убедительный, но там если копать дальше, то можно найти случаи и поинтереснее.
Еще раз — 4 и 5 это уже степени двойки, которыми лично я никогда не пользуюсь, поэтому что они лишены смысла.
зачем и их тоже представлять в виде степени двойки? :)
уже в третий раз кстати:
адресуемое пространство = 2^разрядность
разрядность = 2 ^ непоймичто(пресловутые 4 и 5)
непоймичто = 2 ^ непоймизачем (пресловутая 4 = 2^2)
Пожалуйста, приведите примеры того, где мне понадобится совершать два последних действа.
зачем и их тоже представлять в виде степени двойки? :)
уже в третий раз кстати:
адресуемое пространство = 2^разрядность
разрядность = 2 ^ непоймичто(пресловутые 4 и 5)
непоймичто = 2 ^ непоймизачем (пресловутая 4 = 2^2)
Пожалуйста, приведите примеры того, где мне понадобится совершать два последних действа.
2 ^ 0 = 1
2 ^ 1 = 2
2 ^ 2 = 4 ( = n )
2 ^ 4 = 16 ( = R )
2 ^ 16 = 65536 ( = A = C )
Первые два случая приведены для проформы — типа начинаем с нуля и идём дальше. По третьему пункту я приводил пример, но вы сочли его неубедительным. Признаю, что вы оказались правы. Действительно, если пренебречь эстетическими соображениями (не остаётся неиспользуемых битов), то мне нечего сказать в обоснование необходимости соблюдения этого условия. Главное, на чём я делаю акцент, так это то, что 16 бит задают оптимальный объём командного пространства для реализации языка низкого уровня в его классическом представлении. И если бы удалось подогнать под них всё остальное (в том числе и объём адресуемой памяти), то программировать на таком асемблере было бы одно удовольствие.
2 ^ 1 = 2
2 ^ 2 = 4 ( = n )
2 ^ 4 = 16 ( = R )
2 ^ 16 = 65536 ( = A = C )
Первые два случая приведены для проформы — типа начинаем с нуля и идём дальше. По третьему пункту я приводил пример, но вы сочли его неубедительным. Признаю, что вы оказались правы. Действительно, если пренебречь эстетическими соображениями (не остаётся неиспользуемых битов), то мне нечего сказать в обоснование необходимости соблюдения этого условия. Главное, на чём я делаю акцент, так это то, что 16 бит задают оптимальный объём командного пространства для реализации языка низкого уровня в его классическом представлении. И если бы удалось подогнать под них всё остальное (в том числе и объём адресуемой памяти), то программировать на таком асемблере было бы одно удовольствие.
Я вот прочитал про магическое число 5 и сразу прыгнул в комментарии — неужели до одного меня не доходит в чем суть алхимической формулы
А тут прям дискуссия. В общем до сих пор непонятно чем автору числа 5, 6, ну в обще которые не степени двойки не угодили. Ну нельзя всунуть 5 битовых кортежей одинаковой длины в 32 бита. Ну и что? Я лично знаю очень мало примеров где используется упаковка по 4x4 бита, Если идет жесткое кодирование(как, например, передачи данных по воздуху), то никто не выравнивают и у Вас может быть нечетное количество полей в байте.
Более интересно это то, чтоб желательно машинное слово было кратно степени двойки. В таком случае относительная адресация пространства — всего лишь операция сдвига:
Да и если все сводить к степени 2ки, то получается, что 16-разрядные PICи с машинным словом 12 бит неудел =(.
R % n = 0.А тут прям дискуссия. В общем до сих пор непонятно чем автору числа 5, 6, ну в обще которые не степени двойки не угодили. Ну нельзя всунуть 5 битовых кортежей одинаковой длины в 32 бита. Ну и что? Я лично знаю очень мало примеров где используется упаковка по 4x4 бита, Если идет жесткое кодирование(как, например, передачи данных по воздуху), то никто не выравнивают и у Вас может быть нечетное количество полей в байте.
Более интересно это то, чтоб желательно машинное слово было кратно степени двойки. В таком случае относительная адресация пространства — всего лишь операция сдвига:
ADDR(MEM[idx]) == log2(access_size_bytes) << idx
Да и если все сводить к степени 2ки, то получается, что 16-разрядные PICи с машинным словом 12 бит неудел =(.
.
То есть, если я Вас верно понял, вы предлагаете людям которые занимаются высокоточными вычислениями, да еще и не дай бог в реальном времени, сидеть на 16 битах?
Я предлагаю людям, которым не чуждо чувство прекрасного, поделиться со мной своими мыслями о том, как сделать «колесо» наиболее «круглым». Не думаю, что издержки в виде нескольких асемблерных команд, предназначенных для разбивания больших объёмов данных на фрагменты, поломают людям все их высокоточные и высоксложные вычисления.
А если посмотреть на это с другой стороны, то удельная плотность записи будет максимальной, согласно формуле y=ln(x)/x (где х — основание системы счисления), при x=e.
Давайте делать 2,718281828… -чные процессоры!
Давайте делать 2,718281828… -чные процессоры!
Действительно, в ОЗУ современных компьютеров на долю машинного кода приходится лишь малая части памяти, всё остальное — данные.
На основании чего это предположение?
Вот, беру я обычный хост виртуализации…
На виртуалке (почти ничем не занятой) кодом занято 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. Но в данном случае мы же говорим про адресуемое пространство, да?
На основании чего это предположение?
Вот, беру я обычный хост виртуализации…
На виртуалке (почти ничем не занятой) кодом занято 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. Но в данном случае мы же говорим про адресуемое пространство, да?
Если про 100 виртуалок, то не shared libraries роляет, а KSM
Вы привели случай, когда данные представляют собой исполняемый код. Чувствуете разницу между ядром (движком хоста) и остальной кучей кода, способ выполнения которого регулируется движком? Хотя бы в размерах. Да и то я думаю, что эти 5Мб следуют из того, что программисты привыкли к мысли, что памятью можно разбрасываться направо и налево. Если же задачи, выполняемые хостом, действительно настолько сложны, что требуют таких огромных затрат, то что нам мешает использовать несколько процессоров?
Не чувствую. При аппаратной виртуализации код исполняется процессором напрямую, без слоя «интерпретации», то есть является текстом в оригинальном смысле .text.
Вы хоть представляете себе, что такое гигабайт машинного кода? Да туда движок всего нашего мира с прилегающими параллельными вселенными упаковать можно. По-моему, Ваш комментарий — прекрасное обоснование актуальности поднятой мною темы, а не наоборот.
Ещё раз: это код программ. Это может быть повторяющийся код (изолированный между различными тенантами), но это реальный текст, который исполняет ЦП ЭВМ. И он загружен в память.
Так что утверждение о «в ОЗУ современных компьютеров на долю машинного кода приходится лишь малая части памяти, всё остальное — данные» опровергается ближайшим сервером в продакшене.
Для интереса решил посчитать то же самое на моём ноуте. 3.8Гб. Только VmExe и VmLib.
За вычетом VmLib — 400Мб.
Так что утверждение о «в ОЗУ современных компьютеров на долю машинного кода приходится лишь малая части памяти, всё остальное — данные» опровергается ближайшим сервером в продакшене.
Для интереса решил посчитать то же самое на моём ноуте. 3.8Гб. Только VmExe и VmLib.
За вычетом VmLib — 400Мб.
Да, в современные технологии я даже и не пытаюсь глубоко вникать (мне достаточно одной фразы — «64-разрядный процессор», чтобы потерять к ним интерес). Поэтому могу допускать неточности в суждениях.
Стоп. Т. е. сейчас вы публично заявляете, что не имеете достаточного представления об архитектуре современных микропроцессорных систем, но при этом фанатично заявляете о том, что 16 разрядов хватит всем и всегда?
Понимаете, тут такая проблема: старые компьютеры работали примерно на таком уровне, на котором работал, условно говоря, ремесленник образца 18 века. Много тонких деталей, местами виртуозное мастерство, но сам уровень технологий охватываем простым взглядом.
Современное ПО — это безумный бушующий монстр, в котором никто не знает систему целиком, но все используют те её части, которые не знают. Программист линкуется с библиотекой, которая линкуется с библиотекой, которая умеет рендерить svg. Автор программы в душе не знает, что он умеет рендерить svg и не потратил ни секунды времени на поддержку svg. Но она магически появляется (и пользователи довольны).
Цена этому обжорству функционалом — гигабайты кода, который исполняется и исполняется. Выкинуть этот код? Можно. Но на выходе будет скудный функционал без адекватной поддержки ВСЕГО.
Условно говоря: самописное приложение по X'ы не будет уметь многомониторной конфигурации, поддержки HighDPI, поддержки планшетов для рисования, автореакции на поворот экрана, мультиточ, поддержки тем трёх разных window-manager'ов и т.д. Программа, написанная под фреймворк на 300Мб исполняемого кода — будет. И на её написание уйдёт меньше времени и её будет легче сопровождать.
Да, это страшно неуютно. Но функционал требует.
Современное ПО — это безумный бушующий монстр, в котором никто не знает систему целиком, но все используют те её части, которые не знают. Программист линкуется с библиотекой, которая линкуется с библиотекой, которая умеет рендерить svg. Автор программы в душе не знает, что он умеет рендерить svg и не потратил ни секунды времени на поддержку svg. Но она магически появляется (и пользователи довольны).
Цена этому обжорству функционалом — гигабайты кода, который исполняется и исполняется. Выкинуть этот код? Можно. Но на выходе будет скудный функционал без адекватной поддержки ВСЕГО.
Условно говоря: самописное приложение по X'ы не будет уметь многомониторной конфигурации, поддержки HighDPI, поддержки планшетов для рисования, автореакции на поворот экрана, мультиточ, поддержки тем трёх разных window-manager'ов и т.д. Программа, написанная под фреймворк на 300Мб исполняемого кода — будет. И на её написание уйдёт меньше времени и её будет легче сопровождать.
Да, это страшно неуютно. Но функционал требует.
Рад, что Вы меня понимаете. Действительно, я испытываю некоторый дискомфорт, глядя на описанного Вами «монстра». Но дело здесь не в тщетном желании объять необъятное, а в информационной избыточности, вызванной в основном проблемами совместимости. Ничего до конца не продумывается, потом эти недоделки с прилегающими способами их устранения расширяются в геометрической прогрессии, отсюда — «франкенштейн».
Какой толк от такого прогресса, если интереснейшая работа превращается в рутину? Всё нужно делать быстро, пока не опередили конкуренты — сплошное толчение воды в ступе. Не у всех, конечно, так, но я думаю, что как правило, судя по результатам.
Поэтому осваивать новый функционал просто не хватает терпения — мысли сразу перескакивают на то, как бы я там всё переделал. Вот и занимаюсь изобретением «велосипедов».
Какой толк от такого прогресса, если интереснейшая работа превращается в рутину? Всё нужно делать быстро, пока не опередили конкуренты — сплошное толчение воды в ступе. Не у всех, конечно, так, но я думаю, что как правило, судя по результатам.
Поэтому осваивать новый функционал просто не хватает терпения — мысли сразу перескакивают на то, как бы я там всё переделал. Вот и занимаюсь изобретением «велосипедов».
Скажите пожалуйста, а ваша профессия никак не связана с юриспруденцией?
Откуда такие ассоциации? Слишком строго сужу лучшие достижения человечества? Да нет, в общем-то впечатляет — столько светлых голов думало над тем, как заставить это всё заработать. Просто жаба давит — столько ресурсов расходуется впустую. В то время как 16-ти бит вполне хватает. Проверить это в этой жизни у меня вряд ли будет возможность, так — субъективная уверенность, куда от неё денешься. Ну и логика немало ей способствует.
тратить несколько дней/недель на придумывание/подведение формул без которых уже полвека работают компы и на редактирование статьи…
размеры адресуемой памяти могут быть независимы от количества бит регистров процессора: 64бит CPU и 40бит шина памяти
размеры адресуемой памяти могут быть независимы от количества бит регистров процессора: 64бит CPU и 40бит шина памяти
Если Вы читаете это, значит это предупреждение именно для Вас. Каждое слово, которое вы прочитаете, бессмысленно — вы просто тратите напрасно очередную частичку своей жизни. Неужели Вам больше нечего делать? Неужели Ваша жизнь настолько пустая и серая, что Вы даже не можете найти, чем занять себя в свободное время? Неужели Вы прочитали все, что хотели прочитать? Неужели Вы подумали обо всем, о чем хотели подумать? Немедленно отправляйтесь на улицу. Найдите себе особу противоположного пола. Прекратите совершать дурацкие покупки и завязывайте с мастурбацией. Увольтесь с работы. Начните драку. Докажите, что Вы живы. Если Вы не начнете действовать, то так и проживете свою никчемную жизнь. Я Вас предупредил… Тайлер
Мдааа.
Я бы для начала просветился как устроены современные процессоры.
Всё это уже было. Сегментные регистры, near-far переходы, миллион режимов адресации, EMM, PAE, отображаемое в память пространство ввода вывода. Всё это существует именно по тому, что раньше памяти было мало и она была дорогая.
Никто не мешал сделать 128-битный процессор в 1970г (да и наверняка были такие). Просто это было нецелесообразно. Теперь памяти вагон, куда проще тупо юзать прямую адресацию (ну, конечно, со страничной трансляцией) чем мудрить с оптимизацией, какой же код команды подставить, что бы файл программы занимал на 1 байт меншье.
Я бы для начала просветился как устроены современные процессоры.
Всё это уже было. Сегментные регистры, near-far переходы, миллион режимов адресации, EMM, PAE, отображаемое в память пространство ввода вывода. Всё это существует именно по тому, что раньше памяти было мало и она была дорогая.
Никто не мешал сделать 128-битный процессор в 1970г (да и наверняка были такие). Просто это было нецелесообразно. Теперь памяти вагон, куда проще тупо юзать прямую адресацию (ну, конечно, со страничной трансляцией) чем мудрить с оптимизацией, какой же код команды подставить, что бы файл программы занимал на 1 байт меншье.
В том-то и дело, что «тупо юзать» вместо «тщательно продумывать». Тут же дело в принципе, а не в байте.
а принцип, стало быть, в увеличении стоимости?
Не все понял, но понял, о чем в общем идет речь. Не обращайте внимания на недотеп. Много людей думают, что они умные только потому, что сидят здесь, а суть не уловили… Такое впечатление, буд-то это развлекательный сайт… Я всегда думал о том, зачем процессору нужно 64бит? Чтобы адресовать память? Да как-то смешно немного. Значит несколько сот комманд, тоже нужно писать в 64-битном формате, все нужно писать в 64-битном формате… 64-битные программы занимают чуть ли не вдвое больше 32-битных, а никакой разницы… Если нужно адресовать память, так 2 такта это уже будет 32 бита, 4 — 64 бита. А если обьединить четыре процессора работающих параллельно, автоматически при надобности (такое тяжело представить, если думать о x86 архитектуре, но это же «наш» новый «велосипед»). На мой взгляд идеальный процессор это 8-битный, просто потому, что это кратно байту.
P.S. Когда-то в ютубе (еще в 90-х) смотрел видео где 300МГц UltraSPARC уделывал 1ГГц intel за счет паралеллизма. Так что можно сделать и 8-битный процессор, только чтобы он смог тягаться с современным процессором параллелить вычислительные мощьности придется. Сопроцессор я бы тоже убрал, лутше еще один процессор параллельно и на софтверном уровне все будет считаться даже быстрее, чем с ним.
P.S. Когда-то в ютубе (еще в 90-х) смотрел видео где 300МГц UltraSPARC уделывал 1ГГц intel за счет паралеллизма. Так что можно сделать и 8-битный процессор, только чтобы он смог тягаться с современным процессором параллелить вычислительные мощьности придется. Сопроцессор я бы тоже убрал, лутше еще один процессор параллельно и на софтверном уровне все будет считаться даже быстрее, чем с ним.
На ютубе, в 90-х?
ну так и байт не всегда 8 бит…
.
Тут часто бывает так, что комментарии не туда попадают?
.
И как с этим бороться?
Вы-то, horlon, хоть считать умеете )))
/* что-то не получилось добавить ответ в вашу ветку */
/* что-то не получилось добавить ответ в вашу ветку */
Ну как Вам сказать, кроме адресации еще есть потребность в вычислениях с большим машинным словом — криптография, кодирование.
Конечно, можно разделять регистры адресов и данных, но во первых — неэффективно: может простаивать часть тех или этих, во вторых нет особой экономии в плане реализации в железе, в третьих постоянная путаница в арифметике(что хуже всего).
Также не видно большого выигрыша по памяти. Был даже эксперимент в linux — x32 abi, но не выжил из-за нерентабельности.
Я согласен с тем, что инструкции должны иметь фиксированную длину. Декодировать для CPU проще, возможность быстро предсказывать переходы, распараллеливание выполнения. Если не хватает разрядов — можно добавить расширенные — по два машинных слова(смотрите ARM Thumb2). Или что-то вроде VLIW.
К стати intel(по примеру amd) перегоняет все свои x86x инструкции в RISC-подобный микрокод перед тем как начать выполнять их. Если я не ошибаюсь последним пиком совершенства у них было декодирование 5-7 инструкций за такт. Естественно плата за это — усложнение внутренней архитектуры, необходимость в повышенной частоте, повышенном энергопотреблении. В то время как в архитектуре с фиксированной длинной инструкции такой блок просто-напросто ненужен, его нет.
Даже если опустить кэш, то это разрядность и частота шины данных между CPU и RAM. Ну и обычно все передается burst-ами, так что нет большой разницы для 1 или 4 байта.
Конечно, можно разделять регистры адресов и данных, но во первых — неэффективно: может простаивать часть тех или этих, во вторых нет особой экономии в плане реализации в железе, в третьих постоянная путаница в арифметике(что хуже всего).
Также не видно большого выигрыша по памяти. Был даже эксперимент в linux — x32 abi, но не выжил из-за нерентабельности.
Я согласен с тем, что инструкции должны иметь фиксированную длину. Декодировать для CPU проще, возможность быстро предсказывать переходы, распараллеливание выполнения. Если не хватает разрядов — можно добавить расширенные — по два машинных слова(смотрите ARM Thumb2). Или что-то вроде VLIW.
К стати intel(по примеру amd) перегоняет все свои x86x инструкции в RISC-подобный микрокод перед тем как начать выполнять их. Если я не ошибаюсь последним пиком совершенства у них было декодирование 5-7 инструкций за такт. Естественно плата за это — усложнение внутренней архитектуры, необходимость в повышенной частоте, повышенном энергопотреблении. В то время как в архитектуре с фиксированной длинной инструкции такой блок просто-напросто ненужен, его нет.
Если нужно адресовать память, так 2 такта это уже будет 32 бита, 4 — 64 бита.
Даже если опустить кэш, то это разрядность и частота шины данных между CPU и RAM. Ну и обычно все передается burst-ами, так что нет большой разницы для 1 или 4 байта.
Хорошо, давайте попытаемся подойти к этому вопросу с другой стороны. Допустим (гипотетически), что Вам предлагают решить эту задачу, предоставив соответствующий проект, призванный решить основные проблемы, вызванные столь радикальным сокращением объёма адресуемой памяти (полагаю, что ограничение по объёму командного пространства становится в таком случае несущественным). Во всём остальном Вы ничем не ограничены (кроме, естественно, законов физики и возможностей современных технологий). У Вас есть время, необходимое на разработку концептуальной информационной модели, по истечении которого Вы предоставляете свой проект, и если это решение окажется адекватным современным требованиям, то становитесь миллиардером. Ну и вопрос, соответственно, в том, насколько велика степени Вашей уверенности в том, что это дело безнадёжно и даже не стоит тратить на него своё время?
Я подумаю над этим, но если честно, то у меня есть сомнения в эффективной организации работы CPU-RAM, если последней на много порядков больше. Можно взять чистую гарвардскую архитектуру, тогда у вас адресуемое пространство удваивается ;) — 64K под инструкции, 64K под данные. Собственно подавляющее большинство микроконтроллеров на 8/16 бит используют этот трюк.
Как выход — можно сделать кластер из таких 16-битных CPU. У каждого по своей функции. Правда расходы на коммуникацию будут губительными.
Как выход — можно сделать кластер из таких 16-битных CPU. У каждого по своей функции. Правда расходы на коммуникацию будут губительными.
К стати такой вот подход был у Parallax Propeller.
Из-за сложностей развития такой сложной архитектуры проект похоже умер.
Из-за сложностей развития такой сложной архитектуры проект похоже умер.
Кластер подразумевает плотное взаимодействие между устройствами, неужели прям-таки «губительные»?
Возможно, я как дилетант недооцениваю сложностей. Приведённые ниже рассуждения тоже слабо обоснованы?
Возможно, я как дилетант недооцениваю сложностей. Приведённые ниже рассуждения тоже слабо обоснованы?
Конечно, на данный момент это одно из узких мест многопроцессорных и многоядерных систем.
Если этот «кластер» не будет выполнять операции параллельно то можно про накладные расходы закрыть глаза. Но зачем тогда строить кластер?
Если этот «кластер» не будет выполнять операции параллельно то можно про накладные расходы закрыть глаза. Но зачем тогда строить кластер?
А если устройство процессора будет на порядок проще, это будет как-то способствовать решению описанных проблем?
Вы знакомы с lock contention? Не приходит на ум русский термин. Суть в том, что сами сообщения не тяжеловесны, но вот когда они нагружают шину одновременным доступом — производительность X АЛУ проседает практически до 1.
Решение мне представляется таким. Помимо обмена сообщениями, шина данных должна обеспечивать блочную пересылку данных из памяти одного процессора в заданный участок памяти другого (а также между буфером внешней памяти размером 8 Гб, описанным ниже, и памятью процессоров). Для этих целей определяем 2*2 канала для каждого процессора: командный и канал данных (на ввод и на вывод). Ширину первого можно сделать, скажем, 64 бита или больше, чтобы поместить в него исчерпывающую информацию о том, что куда перебрасывать (ну или просто сообщения и запросы без аргументов). С участка памяти-источника снимается соответствующая матрица, шина открывает доступ от памяти-источника к памяти-приёмнику, после чего эта память обновляется одним «залпом». То есть все действия, выполняемые шиной, будут элементарными, сложность может состоять лишь в том, чтобы обеспечить доступ от каждого к каждому, для чего их количество придётся ограничивать.
Мне не совсем понятно, из чего конфликт при блокировках следует с необходимостью? Если скорость выполнения операций шиной соизмерима со скоростью выполнения команд процессором, то эта проблема должна возникать лишь в том случае, когда задачи, распределяемые между процессорами, слишком уж мелко фрагментируются среднее количество команд, выполняемых в рамках одного фрагмента, становится меньше, чем количество процессоров. Тогда понятно, почему шина не успевает обрабатывать их запросы. Но зачем их (задачи) так мелко дробить?
Если не затруднит, дайте, пожалуйста, минимально-содержательный ответ, что я здесь не так понимаю.
Мне не совсем понятно, из чего конфликт при блокировках следует с необходимостью? Если скорость выполнения операций шиной соизмерима со скоростью выполнения команд процессором, то эта проблема должна возникать лишь в том случае, когда задачи, распределяемые между процессорами, слишком уж мелко фрагментируются среднее количество команд, выполняемых в рамках одного фрагмента, становится меньше, чем количество процессоров. Тогда понятно, почему шина не успевает обрабатывать их запросы. Но зачем их (задачи) так мелко дробить?
Если не затруднит, дайте, пожалуйста, минимально-содержательный ответ, что я здесь не так понимаю.
Допустим, что у вашего процессора хитрая индексация памяти и когда дается команда «дай мне данные по адресу X» процессор по факту будет выдавать 16 бит по адресу X << 1. Так получится адресовать 1MB, но отсутствует возможность выборки/сохранения байта — придется самостоятельно делать сдвиг. Это по сути то же, что многие процессоры делают при невыровненном доступе к памяти, только проблема обратная.
Другая проблема в том как разделять состояние между окнами? В регистрах вряд ли получится — слишком жесткое ограничение.
Возможно делать дополнительный набор «разделяемых» окон и вводить специальные инструкции(что-то вроде
Мне все-таки пока непонятно каковы могут быть причины требования разрядности 16бит если стоит задача адресовать большое количество памяти.
На самом деле надо рассчитать требуемое количество вентилей(gates) для одного случая и представить сколько это займет на кристалле. При нынешних тех процессах ALU+register file занимает не более нескольких процентов площади. Основной «прожора» — память(cache, sram, etc.)
Разве что этот процессор должен быть выполнен по тех процессу «лампа накаливания» — тогда да, разница будет ощутима =D.
Из этого мысленного эксперимента могу сделать вывод — да, конечно, реально иметь такую архитектуру, если это оправданно технологически. В противном случае вводимые ограничения влияют как на удобство разработки(придется писать хитрый компилятор и загрузчик, затачивать программы под архитектуру) так и поддержку.
Если я правильно понял то Sony потому и перешла на x86_64 в PS4 потому, что всех задолбало переписывать игрушки под их хитрую архитектуру. Да, IBM Cell был бесподобен но вызывал головную боль у разработчиков.
Другая проблема в том как разделять состояние между окнами? В регистрах вряд ли получится — слишком жесткое ограничение.
Возможно делать дополнительный набор «разделяемых» окон и вводить специальные инструкции(что-то вроде
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 был бесподобен но вызывал головную боль у разработчиков.
Из соображений удобства и эффективности, каждое звено должно представлять из себя целостное и завершённое решение. Завершённость — это то, чего, на мой взгляд, не зватает современным ИТ. Поскольку асемблер за всё время их развития принципиально не изменился, мне видится уместным принять объём командного пространства фиксированным, а именно — 16 бит, которых вполне хватает. То же самое с объёмом адресуемой памяти. Мегабитом кода тоже можно представить некое целостное и завершённое (и при этом достаточно ёмкое) решение, например — ядро ОСи. Отсюда — идеализация в виде формулы: A = C = 2 ^ 16. Вы понимаете, что принципиальных сложностей для аппаратной реализации этой концепции не существует. Не пойму только, почему Вы считаете, что компилятор в этом случае должен быть «хитрее»? По моему, очень даже наоборот, чему выше даны наглядные обоснования:
«Соблюдение данного условия означает, что любая ячейка способна вместить адрес любой другой ячейки, а также содержит исчерпывающую информацию о выполняемом действии. Уменьшение адресного пространства чревато ссылками на несуществующую память, а увеличение — избыточной информацией, необходимой для обеспечения возможности адресовать всю память. То же самое с командным пространством.»
Думаю, если отвлечься от существующих стереотипов, преимущество предложенного подхода станет очевидным.
«Соблюдение данного условия означает, что любая ячейка способна вместить адрес любой другой ячейки, а также содержит исчерпывающую информацию о выполняемом действии. Уменьшение адресного пространства чревато ссылками на несуществующую память, а увеличение — избыточной информацией, необходимой для обеспечения возможности адресовать всю память. То же самое с командным пространством.»
Думаю, если отвлечься от существующих стереотипов, преимущество предложенного подхода станет очевидным.
/* не скопипастил начало предыдущего сообщения */:
Больше всего меня смущает то, что асемблер не меняется, а разрядность растёт. Или даже считается устаревшим понятием — что смущает меня ещё больше. Ладно бы изобрели машинный язык, заменяющий ЯП высокого уровня — тогда бы я ещё мог понять 64 бита в основе архитектуры. Попытаюсь обосновать.
Иерархию развития ИТ можно представить в виде следующей цепочки:
железо => асм => ЯП => ОСь => сеть
Из соображений удобства и эффективности,…
Больше всего меня смущает то, что асемблер не меняется, а разрядность растёт. Или даже считается устаревшим понятием — что смущает меня ещё больше. Ладно бы изобрели машинный язык, заменяющий ЯП высокого уровня — тогда бы я ещё мог понять 64 бита в основе архитектуры. Попытаюсь обосновать.
Иерархию развития ИТ можно представить в виде следующей цепочки:
железо => асм => ЯП => ОСь => сеть
Из соображений удобства и эффективности,…
В основном все утыкается в обратную совместимость. Потому intel до сих пор поддерживает набор инструкций i386.
И это на самом деле позволило intel вырваться вперед.
Если вас не беспокоит обратная совместимость — не проблема. Большая часть альтернативных архитектур либо забивают на это, либо их ISA была изначально грамотно составлена и не меняется уже годами. Посмотрите на RISC архитектуры.
На сегодняшний день если задача не требует адресации более чем разрядность регистров — никто привентивно не пытается ее увеличить. Посмотрите сколько 16-ти битных контроллеров. Но штука в том, что сам ALU там выполняет административную функцию в то время как основная задача выполняется в железе(кодеки, сеть, etc.)
А придумывать сложность чтоб выиграть на «паре» вентилей — это удел 60х где вентили были размером с кулак и жрали больше чем нынешний ноутбук средней паршивости.
И это на самом деле позволило intel вырваться вперед.
Если вас не беспокоит обратная совместимость — не проблема. Большая часть альтернативных архитектур либо забивают на это, либо их ISA была изначально грамотно составлена и не меняется уже годами. Посмотрите на RISC архитектуры.
На сегодняшний день если задача не требует адресации более чем разрядность регистров — никто привентивно не пытается ее увеличить. Посмотрите сколько 16-ти битных контроллеров. Но штука в том, что сам ALU там выполняет административную функцию в то время как основная задача выполняется в железе(кодеки, сеть, etc.)
А придумывать сложность чтоб выиграть на «паре» вентилей — это удел 60х где вентили были размером с кулак и жрали больше чем нынешний ноутбук средней паршивости.
Да, обратная совместимость меня не беспокоит, ибо в своих мысленных экспериментах я вообще абстрагируюсь от современных ИТ. У меня к ним ничего личного (как это могло показаться из моих сообщений), просто интересно строить идеальные абстрактные модели, предполагая, что их аппаратная реализация — дело наживное. Наиболее интересной была задача втулить систему команд с прилегающим набором адресаций в 16 бит, так чтобы прийти к наилучшему соответствию с принципом «есть всё что нужно и нет ничего лишнего». 32 бита для этой цели подходят гораздо хуже, появляется информационный избыток, что весьма затрудняет соблюдение второй части принципа (желательно ведь решить эту задачу наиболее лаконичным способом, чтобы приходилось рассматривать как можно меньше частных случаев).
В общем, асемблер у меня получился — просто загляденье. А сюда я зашёл в надежде встретить людей, которые тоже задавались подобными вопросами, и сопоставить их ход мысли со своим.
В общем, асемблер у меня получился — просто загляденье. А сюда я зашёл в надежде встретить людей, которые тоже задавались подобными вопросами, и сопоставить их ход мысли со своим.
Получается сферический конь в вакууме.
Во первых ISA может быть таковой, что размер инструкции 16 бит, а машинное слово 32 бит. Во вторых если уж идеализировать — вы знакомы с mill CPU. Хотя я не согласен с автором насчет ISA(VLIW уже провалилась у intel), он излагает весьма, весьма веские доводы в пользу свое архитектуры(черпает много из DSP, что в принципе логично учитывая текущие задачи CPU — декодирование аудио, видео, распознавание образов и текстов). Я бы скорее отнес mill CPU к универсальным DSP, а как основной CPU поставил бы RISC.
Вы упомянули, что у вас уже есть готовая ISA — можете поделиться?
Во первых ISA может быть таковой, что размер инструкции 16 бит, а машинное слово 32 бит. Во вторых если уж идеализировать — вы знакомы с mill CPU. Хотя я не согласен с автором насчет ISA(VLIW уже провалилась у intel), он излагает весьма, весьма веские доводы в пользу свое архитектуры(черпает много из DSP, что в принципе логично учитывая текущие задачи CPU — декодирование аудио, видео, распознавание образов и текстов). Я бы скорее отнес mill CPU к универсальным DSP, а как основной CPU поставил бы RISC.
Вы упомянули, что у вас уже есть готовая ISA — можете поделиться?
Я тоже думал о том, что хорошо бы байту состоять из 2^(2^2) бит. Но при этом разрядность адресной шины стоит оставить равной 32 или 64 битам. Тогда предел 32-битных систем подошёл бы чуть позже — это раз (т.к. адресовалось бы 8 нынешних гигабайт) и было бы меньше проблем с кодировками (16-битный Unicode был бы стандартом).
P.S. Ещё иногда посещают мысли о том, почему самые точные из обрабатываемых сопроцессором чисел содержат 10 байт, а не 16. Но вряд ли кто-то возьмётся выкидывать все возможные архитектурные костыли из нынешних процессоров.
P.S. Ещё иногда посещают мысли о том, почему самые точные из обрабатываемых сопроцессором чисел содержат 10 байт, а не 16. Но вряд ли кто-то возьмётся выкидывать все возможные архитектурные костыли из нынешних процессоров.
Меня такие мысли посещают часто, оттого и занимаюсь подобной ерундой. В электронике разбираюсь слабо, впечатление такое, что специалисты в этой области просто чудеса творят. Отсюда уверенность в том, что практически любую абстрактную модель можно легко запечатлеть в железе. Если любую, то почему бы не выбрать наиболее простую и ненадуманную? Я полагал, что всё сводится к вопросу совместимости или там юридическим нюансам, но никак не технологическим. Возможно, мои представления несколько преувеличены.
Я понимаю причины, по которым предложенный мною подход может показаться неприемлемым. Обычно мы отталкиваемся от задачи (в общем виде обозначим её, как «задачи, стоящие перед современными ИТ»), и подбираем под неё адекватное решение (способов которого современные ИТ предлагают великое множество). А тут получается наоборот — в качестве исходной посылки предлагается ограничение, взятое исключительно из эстетических соображений, под которое вроде бы как должна подстроиться вся компьютерная индустрия. Надеюсь, что последний тезис вы не воспринимаете всерьёз и понимаете, что я не предлагаю здесь выходить за рамки мысленного эксперимента.
Результат которого по сути видится мне примерно таким. Берём буфер, выполняющий роль кэша, обеспечивающего быстрый обмен данными между процессором(-ами) и устройствами (из соображений соответствия 16-разрядной архитектуре принимаем его размер равным 65536 * 65536 * 16 бит = 8 Гбайт). Реализация возможности обновления памяти за 1 такт путём оптовой пересылки мегабита кода/данных, я полагаю, у современных ИТ не вызовет особых затруднений — скорости света, вроде бы хватает (кстати, довольно впритык, если полагать расстояние между процессором и кэш-памятью на превышающим 10 см при тактовой частоте 1 Ггц). Вот, собственно, и весь способ устранения ограничения на объём памяти. В остальном (касательно реализации самого интерфейса) имеем бесконечное и неопределимое множество способов, как это можно сделать.
Да, придётся вводить дополнительные параметры, как минимум 4 штуки: номер блока памяти в кэше [0...65535], начальный адрес [0...65535], длину [0...65535], и смещение [0...65535] — это чтобы пересылать данные из любого места кэша в любое место ОЗУ процессора и обратно. Но это можно делать один раз за «пробег» текущего фрагмента кода, а не по любому поводу. В конце концов, простота в устройстве может значительно облегчить реализацию параллельных вычислений путём организации многопроцессорных систем.
Вообще я не сторонник перекладывания функционала на «плечи» процессора, даже аппаратного умножения на признаю. Может, ностальгия по детству сказывается, но скорее меня здесь смущает расхождение с представлением о низкоуровневом программировании: выполнение любой команды я должен представлять себе визуально, иначе абстракции получаются оторванными от физики, а такие пробелы в представлениях на базовом уровне нежелательны. Конечно, это условность — всю программу в голове не прокрутишь, и тем не менее я думаю, что этим не стоит пренебрегать ради выжимания тактов.
Результат которого по сути видится мне примерно таким. Берём буфер, выполняющий роль кэша, обеспечивающего быстрый обмен данными между процессором(-ами) и устройствами (из соображений соответствия 16-разрядной архитектуре принимаем его размер равным 65536 * 65536 * 16 бит = 8 Гбайт). Реализация возможности обновления памяти за 1 такт путём оптовой пересылки мегабита кода/данных, я полагаю, у современных ИТ не вызовет особых затруднений — скорости света, вроде бы хватает (кстати, довольно впритык, если полагать расстояние между процессором и кэш-памятью на превышающим 10 см при тактовой частоте 1 Ггц). Вот, собственно, и весь способ устранения ограничения на объём памяти. В остальном (касательно реализации самого интерфейса) имеем бесконечное и неопределимое множество способов, как это можно сделать.
Да, придётся вводить дополнительные параметры, как минимум 4 штуки: номер блока памяти в кэше [0...65535], начальный адрес [0...65535], длину [0...65535], и смещение [0...65535] — это чтобы пересылать данные из любого места кэша в любое место ОЗУ процессора и обратно. Но это можно делать один раз за «пробег» текущего фрагмента кода, а не по любому поводу. В конце концов, простота в устройстве может значительно облегчить реализацию параллельных вычислений путём организации многопроцессорных систем.
Вообще я не сторонник перекладывания функционала на «плечи» процессора, даже аппаратного умножения на признаю. Может, ностальгия по детству сказывается, но скорее меня здесь смущает расхождение с представлением о низкоуровневом программировании: выполнение любой команды я должен представлять себе визуально, иначе абстракции получаются оторванными от физики, а такие пробелы в представлениях на базовом уровне нежелательны. Конечно, это условность — всю программу в голове не прокрутишь, и тем не менее я думаю, что этим не стоит пренебрегать ради выжимания тактов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микропроцессор должен быть шестнадцатиразрядным (формальное обоснование)