Потери при выравнивании.

[Aether]

Доброго вечера. Что-то много уже тем политических, позвольте разбавить их небольшими рассуждениями.

Заметил вот какую вещь: некоторые виды данных, как бы недоиспользуют вычислительные ресурсы. Например, видеоданные, в большинстве случаев представляются массивами RGB, где каждый цветовой компонент представлен восемью битами. Таким образом, в сумме это представляется как 24бита, но ближайший размер регистра (условно), способный поглотить этот объём - 32бита. Отсюда, делаю вывод: либо усложнять алгоритм упаковки, то есть первым заходом считываю RGB первого пикселя плюс R от второго, потом, вторым заходом считываю GB второго и RG третьего. Либо просто храню данные в выровненном по границе двойного слова виде, заполняя старшие 8бит - нулями. В обоих случаях не выходит оптимума: первое ведёт к потери во времени, второе к потери в объёме затрачиваемой памяти.

Подобные рассуждения касаются не только видео, но и других типов информации: работая с оцифровкой аналоговых данных, часто 8бит - мало, а 16бит - много. В общем случае, имело бы смысл задуматься о том, что разрядность архитектуры для плотной компоновки должна иметь численно наибольшее число делителей нацело. Отсюда, непонятно: почему, исторически было выбрано развитие в линейке 4-8-16-32-64 бит? Не было бы более логичным, например, предложить 48бит архитектуру?

[RXL]

Не было бы более логичным, например, предложить 48бит архитектуру?

Значение двойки в степени. В цифровой электронике проще оперировать именно такими числами. Например, в гипотетической 48-битной системе адрес n-го элемента в списке находится умножением, а в нормальной системе - статическим сдвигом.
48 не подходит, но можно 2-битную замутить.

[Aether]

Если так, то как быть, например, с 286, если мне память не изменяет, то адреса там 24бит. Ну и про пень тоже стоит вспомнить - адреса 36бит. Производить вычисления сдвигом можно в любой двоичной системе.

Добавлено через 5 минут и 20 секунд:
А 2 битную то зачем??? Увеличение разрядности ША позволяет адресоваться к большему объёму памяти/портов... Увеличение ШД позволяет увеличить объём вычислений за 1 такт - тоже понятно.

[Sla]

Потому что 48 бит плохо сдвигаются.
Нужен "байтовый" сдвиг, в том числе и адресном пространстве.
Добавление только одного "домена" это умножение на 2
8 бит мало, а 16 - уже на уровне помех
Потому и ЦАП/АЦП многоразрядные(от 16) - это сверхточные , прецизионные схемы.

[Aether]

Можно привести пример?

Возможно, непонимание происходит от того, что Вы исходите: адрес соответствует байту, как в х86. То есть:
mov al, byte ptr [500] - считать в al значение из адреса 500.
mov ax, word ptr [500] - считать в al значение из 500, в ah - значение из 501.
mov eax, dword... - считать в al... верх eax слово из 502, 503.
...

А при 48 бит и таком подходе кратного деления самих регистров не будет?

[Sla]

byte
dword - какая размерность?

Я начинал "программировать" еще на "чемоданах" построенных на процессорной серии 1804 (4 битные) , и у них что пространство данных, что адресное пространство определялось байтом в 4 бита, и было наборным, т.е. 48 битные данные можно было достаточно легко собрать
Но на процессорах с 8битным байтом, увы... вы получите избыточность.

Упаковывать вы можете как хотите, основная задача распаковать без потери.

[Aether]

byte = 8 бит
word = 16 бит
dword = 32 бит

Я так понял смысл задачи, которая вызывает затруднения при адрессации:
у нас есть массив из данных по 32бита на значение (long int), нужно адресоваться к произвольному его элементу, получается:
требуемый адрес = базовый адрес таблицы + 4*(номер элемента), но в данном случае умножение на 4 можно заменить более быстрым сдвигом влево на 2.

В случае массива из 48 бит с адрессацией по 8бит (по байту) получается:
требуемый адрес = базовый адрес таблицы + 6*(номер элемента), и
замены умножения на сдвиг не получится.

Но, давайте взглянем с другой стороны:
1) Представление x86: 8бит х 4 = 32бит. Того же можно добиться имея 6бит х 8 = 48бит и используйте сдвиг на здоровье, правда это не очень прогрессивно.
2) Зачем делить 48бит на мелкие части при адрессации?

Кстати, у обычного х86 при массиве состоящем из структур те же проблемы, например, есть массив из структуры short int (8) + float (80) итого 11байт, тогда доступ к произвольному элементу будет идти через умножение на 11. Так что сдвиг не везде возможен.

[darkelf]

Прошу прощения, что вмешиваюсь, но выравнивание, имхо, это немного не то, и на самом деле, оно уже не сильно относится к размерам регистров и типов данных (по крайней мере теперь уже не так, хотя в некоторых случаях ещё такие зависимости кое-где остались), а больше - к системной шине и размерам кеша.

Например, Вам надо прочитать 16-ти разрядное слово по выравненному адресу, тогда процессор выставляет запрос на шину данных, насколько я помню, она сейчас там 64-х битная, т.е. за раз, можно считать двойное слово и адрес соответственно на чтение выставляется кратный 8. Если данных для указанного адреса нет в кеше, то при этом выдаётся запрос на чтение из ОЗУ в кеш, но чтение выполняется уже не 8-ми байт, а 32-х (это так называемая строка кеша), а уже потом из кеша уже вычитывается нужное слово. Всё происходит за минимальное число тактов (если данные были в кеше или медленнее, если данных в кеше не было).

Более худший вариант: вычитываем слово, адрес которого не кратен, тогда всё происходит как и раньше, процессор обращается к кешу, кеш - к памяти, но вот при вычитывании процессором из кеша надо делать два обращения - сначала прочитать младшую часть слова, потом старшую слова, потом их соединить и положить в регистр - уже чуть медленнее.

Худший вариант - адрес слова попадает на границу строки кеша, соответственно процессор должен попросить кеш вычитать не одну строку по 32 байта, а две. А далее опять-же вычитать из одной строки младшую часть, из другой старшую. Объединить их и положить в регистр. Это будет ещё медленее.

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

Это всё очень упрощенно, если интересно более подробно и точно есть очень неплохая статья про всё это: http://rus-linux.net/MyLDP/hard/memory/memory.html

PS: не совсем уверен, что это подходящая тема.

[Aether]

Нет, Вы уже в аппаратную часть переходите. Пока речь о более простом:

Например, нужно создать bitmap под 24бит цвет, размер 1024х1024 пикселей. Вопрос: сколько будет весить файл и сколько будет весить буфер?

С файлом всё просто: 1024х1024х24/8 = 3Мб.

А буфер? Если выделить массив, исходя из соображения упростить вычисления, то выделить придётся 1 dword / 1 pixel. То есть, 4Мб. Как видно, 1Мб испарится ввиде нулей. Теперь представим, что такой подход будет с большими объёмами - на 4Гб будут потери в (25%) 1Гб, что уже не так мало!

В 64бит счетверённое слово можно запихнуть два пикселя, то есть 48бит, но станется недоиспользовано 16бит (25%), то есть в этом плане даже более совершенная 64бит архитектура не экономит ресурсы.

[darkelf]

насколько я могу судить разработчики для видео пошли другим путём - просто придумали 10 бит на компоненту цвета, соответственно на каждый пиксель теряется 2 бита.

а по поводу 64-х битных систем - они более расточительные по памяти чем 32-х битные. Взять вызов  подпрограммы - при вызове в 32-х битном режиме процессора 386 и выше надо сохранить регистры eax, ebx, ecx, edx, esi, edi, ebp и eip - т.е. 8*4=32 байта. А для x86_64 во первых все регистры уже станут 64-х разрядными, т.е. rax, rbx, rcx, rdx, rsi, rdi, rbp, rip, а кроме того, ещё появятся регистры r8-r15, т.е. уже 16*8=128 байт.

На самом деле, конечно, не всё так печально, например для C при использовании cdecl сохраняются не все регистры, но тем не менее, при тех-же переключениях контекстов задач или потоков в ОС уже нужно больше памяти. Да и на другие процессоро-зависимые служебные структуры..

Да что там, даже обычные указатели уже становятся 64-битными и если у Вас есть структура, например, элемента двунаправленного списка, то для 32-х разрядной системы один элемент будет три 32-х разрядных слова (указатель на предыдущий элемент, на следующий элемент и на данные элемента) - 12 байт, а для 64-разрядной уже три 64-х разрядных слова - 24 байта. Кстати в Linux даже попытались обойти такие ограничения, правда только для прикладных задач придумав x32 abi, в котором есть все возможности 64-х битного режима - куча 64-х битных регистров и т.д. но при этом указатели всё-равно 32-х битные.

Сорри, наверное я опять перехожу к аппаратной части, но в данном случае она и диктует многие программные решения.

[Aether]

10 бит на канал проблему не совсем решает. Дело в том, что у любой информации есть физическая сущность. Применительно к графике я проводил лет 8 назад небольшое исследование: взял исходную картинку фото качества в формате BMP24, создал программу, которая работает по следующему алгоритму:
- переключает видеоадаптер в режим родного разрешения монитора и 24 бит цветности,
- обрезает исходную картинку в габарит разрешения монитора,
- <3> выводит картинку на монитор,
- обрабатывает события клавиш вверх/вниз,
- с нажатием вверх у каждого пикселя изображения в каждом канале срезается 1 бит снизу (в 0) по-очереди, с каждым нажатием вниз биты восстанавливается от исходного изображения.
- переход на <3>.
Таким образом, можно моделировать, как выглядело бы изображение будь оно 1, 2, 3...8 бит на канал. В итоге, один человек не смог различить контраст перехода при цветности в 6 бит на канал, затем у значительного числа людей не проглядывалась разница в двух соседних тонах при цветности в 7 бит, 8 бит - перекрывает возможности глаза гарантировано. 10 бит в канале можно создать, если пытаться вести вычисления с повышением точности, например, сглаживание, но в этом случае лучше не мудрить, а раскладывать каждый канал в 16 бит и считать, а потом нормировать в положенные 8 бит - на х86 это проще. Другое дело: возможности монитора и видеоадаптера - пока не встречал моделей способных выдать 10 бит качества.

Некоторые программы используют 8 бит старшего байта, как, так называемый альфа-канал, то есть - это маска прозрачности текстуры. Но опять же, монитор альфа-канал не показывает - это мера для расчётов внутри.

Кстати, интересно было бы провести подобный эксперимент со звуком, но я с ним никогда не работал.( Интересно было бы послушать не 16, а, например, 12 бит звук. 8 - не надо))) Уже слышал.

[Джон]

В итоге, один человек не смог различить контраст перехода при цветности в 6 бит на канал, затем у значительного числа людей не проглядывалась разница в двух соседних тонах при цветности в 7 бит, 8 бит - перекрывает возможности глаза гарантировано.

Непоказательно. Какой монитор использовался?

[darkelf]

Aether, простым людям, возможно, 8-ми бит на канал хватает за глаза, но для полиграфии, думаю, всё не так однозначно - кому-то и специальные мониторы покупают и разные CMyK-и придумывают.. Да и сейчас лишние мегабайты, а иногда даже и гигабайты никого не волнуют вон для UHDTV - 7680 на 4320 - 33.18 мегапикселя - 128Мбайт памяти на картинку если 4 байта на пиксель.. при штатных 8-ми гигабайтах ОЗУ на ПЭВМ - не очень и большой размер. плюс ко всему - для этого есть выделенная память видеокарты, так-что основную память оно вроде как не сильно загружает.

Про звук не могу сказать, но там аналогичная картина - в каких нибудь плохоньких наушниках Вы 16 от 12-ти возможно не отличите, а какой нибудь меломан, с хорошим оборудованием - вполне себе расслышит.

[Aether]

Непоказательно. Какой монитор использовался?

ЭЛТ 19" Я подрабатывал рисуя в Lightwave, поэтому в конторе стояли мониторы нормальные. Фирму-производителя, естественно, забыл, впрочем, эксперимент можно повторить, и даже сделать его проще.

Да и сейчас лишние мегабайты, а иногда даже и гигабайты никого не волнуют вон для UHDTV - 7680 на 4320 - 33.18 мегапикселя - 128Мбайт памяти на картинку если 4 байта на пиксель.. при штатных 8-ми гигабайтах ОЗУ на ПЭВМ - не очень и большой размер.

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

Добавлено через 3 минуты и 46 секунд:

CMyK-и придумывают.

Кстати, это формат не для монитора а для вывода на печать, изначально хотели сделать его CMY, так как в теории при полном смешении должно выйти чёрное, но из-за свойств краски на деле вышло тёмно-коричневое, поэтому добавили чёрный - так сказать, для гарантии. Получилось CMYK (32бит).

[darkelf]

Да и сейчас лишние мегабайты, а иногда даже и гигабайты никого не волнуют вон для UHDTV - 7680 на 4320 - 33.18 мегапикселя - 128Мбайт памяти на картинку если 4 байта на пиксель.. при штатных 8-ми гигабайтах ОЗУ на ПЭВМ - не очень и большой размер.

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

Да, но выбора-то нет. Возьмём очередную революцию в мобильном секторе - внедрение 64-х битных ARMv8. Кому в телефонах нужны 64-х битные вычисления? Там памяти обычно 1G, может 2G, не больше. Но ведь нет, внедряют вовсю.

Кстати, это формат не для монитора а для вывода на печать, изначально хотели сделать его CMY, так как в теории при полном смешении должно выйти чёрное, но из-за свойств краски на деле вышло тёмно-коричневое, поэтому добавили чёрный - так сказать, для гарантии. Получилось CMYK (32бит).

да, я знаю. я про то, что задачи бывают разные, и под задачу уже могут придумывать и технологии, и 32-х битный цвет. В wikipedia читал, что для каких-то рабочих станций и 48-ми битный цвет придумывали.

[Джон]

Aether, простым людям, возможно, 8-ми бит на канал хватает за глаза, но для полиграфии, думаю, всё не так однозначно - кому-то и специальные мониторы покупают и разные CMyK-и придумывают.

Абсолютно верно. darkelf только немного "оговорился" , не "CMyK-и придумывают" (CMYK действительно для печати, там ещё больше заморочек, например, краска, бумага),  а "придумывают" sRGB, Adobe RGB. На сегодняшний момент 16 бит - это минимум де факто. Да и алгоритмы всяких а ля Фотошопов работают тем качественней, чем инфы больше.

Я к чему про монитор заикнулся. Субъективная оценка, в принципе, не показательна.
А если ещё и на мониторе... Если ЭЛТ, то его надо, как минимум 2 часа "прогревать". Плюс внешнее освещение. Плюс калибровка, создание профилей. И это, при прочих равных условиях, ещз и качество самого монитора должно быть на ооочень большой высоте.

[RXL]

Если так, то как быть, например, с 286, если мне память не изменяет, то адреса там 24бит. Ну и про пень тоже стоит вспомнить - адреса 36бит. Производить вычисления сдвигом можно в любой двоичной системе.

Размер адресуемой памяти вообще не к месту. Регистры все равно 16 и 32 бита для 286 и 386 соотв.

[Ochkarik]

нюансик: 8 бит на цвет/10 бит может и не заметно. а контраст?

[Aether]

Кому в телефонах нужны 64-х битные вычисления? Но ведь нет, внедряют вовсю.

Да! И поэтому я иной раз матерюсь.))) У каждого нового телефона зарядки хватает на всё и всё меньше, а 90% его функций мне не нужны.

Субъективная оценка, в принципе, не показательна.
А если ещё и на мониторе... Если ЭЛТ, то его надо, как минимум 2 часа "прогревать". Плюс внешнее освещение. Плюс калибровка, создание профилей. И это, при прочих равных условиях, ещз и качество самого монитора должно быть на ооочень большой высоте.

Субъективно? Если в плане эксперимента, то я организовывал, стараясь исключить ложь. То есть, пациент отворачивается - меняю картинку, смотрит - говорит видит или не видит разницу. Иногда, показывал одну и ту же. Если же субъективно в плане - все мы люди разные, то да. Тем не менее, стоит понимать, что как тяжелоатлет не тренируется - тонну не поднимет, поэтому у всего есть предел. Ну и, естественно, автомобиль, например, рассчитывают не под атлета-гиппопотама, а под среднее значение в выборке с запасом на пару среднеквадратичных отклонений.

Второе: если качество монитора на недостаточно большой высоте уже не влазит в 8 бит, то о 10 бит и речи быть не может, так как это в 4 раза круче. А про ЖК можно, вообще, промолчать, так как долгий срок было оно на уровне 6 бит чистыми и всё.

нюансик: 8 бит на цвет/10 бит может и не заметно. а контраст?

Контраст, яркость, тоже, конечно, влияют, но разницу между двумя площадями, закрашенными в ближайшие два цвета не удаётся рассмотреть даже сидя в темноте.

В целом, вопрос, фундаментальный, возможно, кто-то предложит способ лучше определить границу восприятия? Может, капать в стакан с дистиллированной водой краситель по каплям, и попробовать понять разницу между 178 и 179 каплями в разных стаканах, но тут будет мешать нелинейность процесса окрашивания от концентрации?(

[Dale]

Не было бы более логичным, например, предложить 48бит архитектуру?

Уже было, причем было классикой, учите матчасть. И благополучно сплыло. Ибо:

Что было в прошлом, то и теперь,
               И что делалось прежде, то происходит и ныне.
                             Ничего под солнцем нового нет.

Иногда говорят: Смотри, что-то новое!
               Но это уже было давным давно,
                             В веках, минувших задолго до нас.

Если действительно так важно экономить на этих крохах (ну мало ли, вдруг задача действительно требует максимального быстродействия), почему бы не сделать спецвычислитель на базе FPGA, например? Вполне оправданное применение.

[Aether]

Я разьве говорю о новом? Всегда можно покопаться и найти что-то уже сделанное, и применённое, но, тем не менее, нужно вместе с этим приводить и контекст. В 70-х годах вычислительная техника претерпевала период поиска решения. До этих лет элементная база была скудна, но с появлением возможностей каждый пытался лепить горбатого сам. Эволюция, политика, экономика многих этих горбатых отправили в утиль, и осталась классика - х86. Вопрос исходный был примерно таков: чем х86, х86-64 лучше х48? Почему сейчас, тот же ARM, не ищет решение, а клепает ветку 16-32-64?

Ещё, не стоит забывать, что в те годы речь о ПК не шла, также эти машины использовались для сугубо математических вычислений, то есть решение диффур, нахождение интегралов, итерационные методы, ряды Фурье... О просмотре видеофильмов, аудио воспроизведении, ЧПУ машиностроении и многом другом речь не шла. Бесспорно, что х64 архитектура будет превосходить по пиковой производительности вычислений и 16 и 32 и 48 бит системы, но то, что ресурсы просаживаются на типовых каждодневных задачах как бы факт. Кстати, такие меры, как конвейеры, кэш... - каждая добавляет быстродействию по нескольку процентов или десятков процентов, но в сумме выходит неплохо, а здесь теряется до четверти ресурсов сразу.

[RXL]

Уже было, причем было классикой, учите матчасть. И благополучно сплыло. Ибо:

Гардвардская архитектура допускает такое. Пожалуйста: PIC12: машинное слово - 12 бит, слово данных - 8 бит. Но для универсальных процессоров лучше архитектура фон Неймана, и здесь снова 48 бит не удобно.

[Dale]

чем х86, х86-64 лучше х48?

Принципиально - ничем. Всего лишь более "круглое" с точки зрения двоичной арифметики число.

Вопрос из той же категории, что и "чем метрическая система мер лучше, чем дюймы-футы-ярды-мили..."? Да ничем принципиально. Равно как и 12 пенсов в шиллинге или 20 шиллингов в фунте никого не свели с ума.

Кто к чему привык, тому то и лучше. Просто десятичная метрическая система выглядит логичнее. Но измерить расстояние можно в любой одинаково точно.

Почему сейчас, тот же ARM, не ищет решение, а клепает ветку 16-32-64?

Видимо, потому, что оно им и даром не нужно, технических сложностей здесь нет. Это "решение" реально не решает насущных проблем. А если даже какие-то и решит, то породит другие.

эти машины использовались для сугубо математических вычислений, то есть решение диффур, нахождение интегралов, итерационные методы, ряды Фурье...

И сейчас x86 используются для тех же целей, и длина слова не является непреодолимым препятствием для этого.

Бесспорно, что х64 архитектура будет превосходить по пиковой производительности вычислений и 16 и 32 и 48 бит системы

И что с того? А x96 или X192 превзойдет еще больше.

Повторяю, используя современные FPGA, можно реализовать за копейки любую вычислительную архитектуру, и с этим справится даже достаточно толковый студент. Была бы только реальная потребность.

Добавлено через 8 минут и 3 секунды:

Гардвардская архитектура допускает такое.

Абсолютно без разницы. Различие между этими архитектурами заключается отнюдь не в числе двоичных разрядов для кодирования команд или данных.

для универсальных процессоров лучше архитектура фон Неймана, и здесь снова 48 бит не удобно.

Опять же, не факт. Знаменитая PDP-10 имела архитектуру фон Неймана при длине слова 36 бит, и никому это неразрешимых проблем не создавало. По крайней мере, в MITе и Стенфордском университете это была одна из базовых исследовательских платформ в свое время.

[RXL]

Если ячейка памяти нужной размерности, то проблемы нет.
Гарвардскую архитектуру я привел именно в этом контексте: разрядность ячеек памяти данных не зависит от разрядности ячеек кода.

[Dale]

Кстати, забавный сайт для староверов в тему: http://www.inwap.com/pdp10/

[Aether]

Вопрос из той же категории, что и "чем метрическая система мер лучше, чем дюймы-футы-ярды-мили..."? Да ничем принципиально. Равно как и 12 пенсов в шиллинге или 20 шиллингов в фунте никого не свели с ума.
Кто к чему привык, тому то и лучше. Просто десятичная метрическая система выглядит логичнее. Но измерить расстояние можно в любой одинаково точно.

Измерять физические величины и вести их счёт, естественно, можно в любой системе мер и счислений. Если угодно, можно даже мерить лопатами #Г, причём как массу, так и габарит. Но, представьте, велосипед - без человека он бессмысленен, что есть - что нет. А человеку, обладателю, он даёт определённые преимущества в передвижении. С системами счёта тоже не так всё просто, говорите логичнее? А логика в чём? Человеческая память, увы, тоже имеет нюансы, Вы обращали внимание: сколько может бегло запомнить цифр человек? Обычно, это 5-6, иногда 7 цифр. Поэтому считать в системах малого основания для человека сложновато - мал объём, например 6 цифр в двоичной будет иметь объём лишь до 64 единиц, а десятичная уже до миллиона. С другой стороны, слишком большое основание, например, шестнадцатеричное - увеличивает нагрузку на долговременную память. Таблица умножения будет иметь уже 256 вариаций. Довольно большая численность людей в среде рабочих и не только, надо сказать, и десятичную таблицу умножения знает посредственно - реалии жизни.
Исторически, между собой конкурировали системы вблизи "золотой середины" - восьмеричная, десятичная и двенадцатеричная. Так логика получается в том, что среднего примата оказалось проще научить считать на пальцах хотя бы до десяти?
Дюймовая система мер и вложенная в неё двенадцатеричная система счёта - большая тема, кто работал на ручных станках с дюймами, тот поймёт без лишних слов.
Рекомендую, также провести небольшой опыт: взять листок формата А4, нарисовать отрезок произвольной длины и при помощи циркуля (без линейки) разделить его на 10 равных частей. Это даст возможность оценить трудности десятичной метрологии.

[Aether]

[И что с того? А x96 или X192 превзойдет еще больше.

А с того вот что: более сложная архитектура содержит большее число элементов, соответственно, дороже стоит и потребляет больше энергии. Поэтому общая задача, я полагаю, состоит в том, чтобы обеспечить практические потребности людей при минимальных затратах ресурсов. Запас х32 - уже исчерпан возможностями современной технологии, запас х64 - гигантский. Так, возможно, между ними есть некая середина? В плане этого х96 и далее - лишены смысла.

Аргумент, который приводил я: возможность плотной упаковки данных внутри слова максимального размера. Для различных архитектур они следующие:

х86:
32бит х1, 16х2, 8х4, 4х8, 2х16, 1х32 - 6 комбинаций,

х64:
64х1, 32х2, 16х4, 8х8, 4х16, 2х32, 1х64 - 7 комбинаций,

х48:
48х1, 24х2, 16х3, 12х4, 8х6, 6х8, 4х12, 3х16, 2х24, 1х48 - 10 комбинаций.

[zubr]

Aether, имхо, экономически нецелесообразно переходить на другие архитектуры, так как издержки намного превысят эффект. Под издержками я вижу как минимум, кучу созданного и работающего ПО, которое превратится в кучу ненужного мусора. Или городить эмуляторы, но смысл этих потуг?

[Aether]

Не спорю, так и есть. Я сам пользуюсь тем, что есть - и так забот хватает, но задело, что  соседней ветке мне тёрли, что программисты впереди планеты всей, а железячники где-то рядом, образно. Решил затеять тему, чтобы посмотреть: насколько далеко уйдём хотя-бы в рамках теории.

[Finch]

Слор перетек в, что круче мозг или тело, которое его окружает. Как одно не может жить без второго, так и "программы" не могут жить без железа, которое их окружает. В принципе железо может жить само по себе. И даже приносить какой то результат работы.

Насчет 286 машинок, Хотя адрессная шина и была 24 битная, Но процессор все равно оперировал с 16 битами. Было лва адресных регистра. по 16 бит. Например CS:IP.  

Архитектурно, 48 битную структуру сложнее делать. Да и она не нужна в системвх обшего назначения. Скорее всего ее будут применять и применяют в каких либо графических процессорах. Там это дейтсвительно оправдано, и приносит ошутимое увеличение производительности.

[Aether]

Насчет 286 машинок, Хотя адрессная шина и была 24 битная, Но процессор все равно оперировал с 16 битами. Было лва адресных регистра. по 16 бит. Например CS:IP. 

Я это привёл не для сопоставления 24->48, а для другого. RXL, сказал, что здесь плохо работает механизм сдвигов... а я иллюстрирую, что программные трудности на этом уровне присутствуют везде и, если они существенны, решаются аппаратно.

В 286-ом в реальном режиме, например, мы опрашиваем ds:si, а что делается аппаратно: ds сдвигается на 4 влево и к этому прибавляется si, итого физический адрес. В защищённом режиме преобразование виртуального адреса в физический ещё сложнее и дольше. Если нужно организовать умножение на 6 при адресации побайтно, то можно сделать команду умножения на 6 отдельной, быстро исполнимой на аппаратном уровне, условно, за 1 такт, также, как и shl.

[Finch]

Aether, Умножение на шесть будет разлогаться в двоичной системе:
1) А = ...
2) B = A <<= 1
3) A <<= 1
4) А += B

Согласись, что это чуть сложнее реализовывается, чем умножение на восемь скажем
1) А = ...
2) A <<= 3

[Aether]

Конечно сложнее, но что весомее: экономия памяти в гигабайты или десяток другой ЛЭ в чипе?

Для Вас, как для программиста это будет выглядеть:

mov ax, ...
shl ax, 3

// на 8

mov ax, ...
mul6 ax

// на 6

(условно)

[Finch]

Aether,

Жесткий диск фирмы IBM 1956 год Вместимость 5 Мб

 640 K ought to be enough for anybody. (с) Bill Gates 1981 год


А что сейчас, Память уже измеряется в гигабайтах, Память на жестком диске перевалила за террабайты. И стоит это намного дешевле чем, тогда 5 Мб и 640 килобайт.

А что будет через 10 - 20 лет?

[Aether]

Откуда нам знать? Но, несомненно, это будет то, что разрабатывается уже сейчас.

Билл, для своего времени, сказал всё верно. Тем не менее, в каждой отрасли есть свои пределы, например, бензиновому двигателю уже  более 100 лет, но КПД выше 40% подниматься не хочет, ибо термодинамику Карно не отменишь. Однако, совершенствовать всё же есть что: массу, характеристику работы, долговечность... Так и в электронике: одно другое не исключает.

PS: хорошая фотка. 

[darkelf]

Конечно сложнее, но что весомее: экономия памяти в гигабайты или десяток другой ЛЭ в чипе?

Для Вас, как для программиста это будет выглядеть:

mov ax, ...
shl ax, 3

// на 8

mov ax, ...
mul6 ax

// на 6

(условно)

Сорри, но Вы немного не чувствуете, имхо. Попытаюсь, как я понял, что объяснить то, что хотел сказать Finch.

Возьмём гипотетический процессор, с АЛУ, у которого есть модуль сдвига (пусть этот модуль даже позволяет сдвигать сразу на несколько бит за раз) и модуль сложения (тоже выполняющий операцию сложения за раз).

Умножение на 6 потребует задействования обоих этих модулей, причём:
1 такт засылаем на модуль сдвига исходное значение
2 такт сдвигаем на 2
3 такт засылаем результат сдвига на модуль сложения
4 такт засылаем на модуль сдвига исходное значение
5 такт сдвигаем на 1
6 такт засылаем результат сдвига на модуль сложения
7 такт выполняем сложение
8 такт выгружаем результат.

А теперь для сравнения умножаем на 8
1 такт засылаем на модуль сдвига исходное значение
2 такт сдвигаем на 3
3 такт выгружаем результат

В итоге для умножения на 6 нам понадобилось 8 тактов и оба устройства, а для умножения на 8 - всего 3 такта и одно устройство.

Можно немного ускорить умножение на 6, например, добавив ещё один сдвигатель и попытавшись выполнить операции сдвига параллельно:
1 такт засылаем на модуль сдвига 1 исходное значение и на модуль сдвига 2 исходное значение
2 такт сдвигаем на модуле сдвига 1 на 2, а на модуле сдвига 2 на 1
3 такт засылаем результат сдвига с модуля сдвига 1 на модуль сложения
4 такт засылаем результат сдвига с модуля сдвига 2 на модуль сложения
5 такт выполняем сложение
6 такт выгружаем результат.

Уже быстрее, но всё равно медленее, это раз, теперь у нас задействовано три устройства, это два, и теперь схема всего этого гораздо сложнее, т.к. придётся обеспечивать параллельное выполнение этих операций и соответственно какую-то их синхронизацию и выборку сдвигателей, это три.

А если сдвигатели выполняют по одному сдвигу за такт, то всё становится ещё хуже.

Умножение на 6
1 такт засылаем на модуль сдвига исходное значение
2 такт сдвигаем на 1
3 такт сдвигаем на 1
4 такт засылаем результат сдвига на модуль сложения
5 такт засылаем на модуль сдвига исходное значение
6 такт сдвигаем на 1
7 такт засылаем результат сдвига на модуль сложения
8 такт выполняем сложение
9 такт выгружаем результат.

Умножение на 8
1 такт засылаем на модуль сдвига исходное значение
2 такт сдвигаем на 1
3 такт сдвигаем на 1
4 такт сдвигаем на 1
5 такт выгружаем результат

Умножение на 6 два сдвигателя:
1 такт засылаем на модуль сдвига 1 исходное значение и на модуль сдвига 2 исходное значение
2 такт сдвигаем на модуле сдвига 1 на 1, а на модуле сдвига 2 на 1
3 такт сдвигаем на модуле сдвига 1 на 1, на модуле сдвига 2 ничего не делаем
4 такт засылаем результат сдвига с модуля сдвига 1 на модуль сложения
5 такт засылаем результат сдвига с модуля сдвига 2 на модуль сложения
6 такт выполняем сложение
7 такт выгружаем результат.

А если вспомнить, что в реальности операция сложения выполняется через тот-же сдвиг и операцию "или", то всё становится ещё хуже (т.е. реально операция сложения будет занимать не один такт, а вовсе даже и больше, плюс она потребует очередной сдвигатель).

Сорри, за много букв.

[Aether]

Finch привёл схему:
6*а = 2*а + 2* (2*а)

Любой регистр ax, bx, ecx - это наборы триггеров, когда процессор получает команду она отпирает некий "затвор" из элементов "И" (вообще, БЛЭ обычно "И-НЕ", но не суть). Открыв затвор токи с выходов триггера начинают течь в глубину требуемой схемы. Так вот, модуля сдвига тут не требуется - для того, чтобы организовать сдвиг влево, например, на 2 нужно всего лишь добавить 2 дорожки с логическими нулями справа, для сдвига на 4 добавить 4 нулевых дорожки, а потом оба значения подать на сумматор. В целом работать это будет не дольше ADD. Примерную схему рисовать? (Естественно, не для 48 бит, но хотя-бы для 4)))

Но, сначала, вопрос про сумматор:

А если вспомнить, что в реальности операция сложения выполняется через тот-же сдвиг и операцию "или", то всё становится ещё хуже (т.е. реально операция сложения будет занимать не один такт, а вовсе даже и больше, плюс она потребует очередной сдвигатель).

Вот это я подзабыл, но чую что-то здесь не так.

[Ochkarik]

че-то мне за железячников обидно) они там обычно стараются,  за каждый такт и мегагерц сражаются, каждый милливат считают.. каждый свободный миллиметр кристалла используют.
а потом приходит программист и говорит что херня какая то?! все так медленно и умножения на 6 за один такт не реализовано!...и еще стопясяттысячкоманд за один такт.

а вот у меня, блин, папка Windows - 20ГБ занимает! это что, лишних 32 бита потому что?

PS извините, крик души, наболело)

[Finch]

Ochkarik, Не думаю, что 20 Гигов у тебя из-за 32 разрядности . У меня раздел, где сидит 64 битная система + все мне нужные программы занимает 11 гигов. Правда там еше висит кэш апдейтов. его я давно не чистил

[Ochkarik]

Finch, фиг его знает, но это домашний ноут, я на нем вообще ничего не делаю практически. фильмы, фотки, интернет)
PS это как раз 64 бита.

[Aether]

...и еще стопясяттысячкоманд за один такт.

С умножением, естественно, не получится. Зря, я как раз железячников защищаю, конечно борются они и за то и за это, но борются они, выполняя тех. задание коммерсантов, военных... А программисты, потом, из сделанного ими, пытаются  разносторонние продукты разработать, поэтому у Вас винда и весит 20Гб. А ещё есть такая вещь, как спешка, когда приходит срок сдавать работу, а она ещё на пол пути, сами понимаете, будет сделано хоть как, лишь бы работало.

[Dale]

а вот у меня, блин, папка Windows - 20ГБ занимает! это что, лишних 32 бита потому что?

Нет, Вам же только что всё объяснили - из-за потерь при выравнивании, обусловленных неправильным выбором архитектуры. Переходите на 48 бит, и все нормализуется. На БЭСМ-6 у Вас куда скромнее системный раздел будет.

[RXL]

Aether, Умножение на шесть будет разлогаться в двоичной системе:
...
Согласись, что это чуть сложнее реализовывается, чем умножение на восемь скажем

Сдвиг в электронике достигается перекоммутацией линий и не требует вычислительных блоков и тем более тактов на выполнение. Умножение, всегда требует времени, за исключением табличного метода с ПЗУ, требующего N*M адресных линий.

[Aether]

Сдвиг вне МП, возможно, тактов и не требует. Внутри же МП любая операция обзаводится дополнениями. Если я не прав, поправьте:
команда shl ax, 3 примерно:
- с приходом восходящего фронта тактового импульса происходит установка значений промежуточного регистра, назовём его W, в соответствие со значениями регистра источника: ax -> W,
- выходы регистра W соединены таким образом, чтобы обеспечить перекоммутацию со смещением на 3 линии: W -> Res,
- с приходом нисходящего фронта происходит запись текущего перекоммутированного значения в ax: Res -> ax.
Строго говоря, любая команда требует времени, а не тактов, для обеспечения перехода логики в устойчивое состояние с гарантией результата. Если это время менее времени протекания одного такта, то команда займёт - один полный такт.
У меня нет актуальных данных сколько тактов занимает какая команда и когда, но нужно разделять задачи: умножение двух произвольных чисел и умножение произвольного числа на константу. Именно, поэтому Вы, умножая на 8 на деле используете сдвиг, но поэтому же можно реализовать отдельной логикой умножение и на 6.

Мне, впрочем, более уместным, кажется, адресация целыми словами без деления на байты, но с наличием в аппаратной базе команд упаковки/распаковки, аналогично, например, имеющимся в MMX.

[Ochkarik]

беда в том, что ни один программист не будет использовать явное умножение на 6. никогда... ибо 99.999999999% программистов (пардон) вообще редко думают об аппаратной платформе. даже я бы сказал - специально не думают об платформе.

вероятность того, что в коде встретится команда которую компилятор однозначно сможет развернуть в такую последовательность? мне кажется маловато будет...

да, и никто из производителей не согласится на внесение дополнительных команд, чья целесообразность вообще говоря довольна сомнительна, и кроме как к удорожанию кристалла мало к чему приведет.

[Dale]

Сдвиг в электронике достигается перекоммутацией линий и не требует вычислительных блоков...

В тех архитектурах, где мне посчастливилось заглянуть в самые пороха реализации, этот самый сдвигатель через коммутацию все-таки входил в состав АЛУ.

...и тем более тактов на выполнение.

Верно, сдвиг, как и прочие асинхронные операции АЛУ, тактов не требует (поскольку выполняется "мгновенно" за вычетом задержек на логических вентилях). Такт потребуется на фиксацию результата в регистре-получателе (если только результат не направляется в память, там тактом вряд ли дело обойдётся).

[RXL]

Я все таки имел в виду не АЛУ.

[Aether]

да, и никто из производителей не согласится на внесение дополнительных команд, чья целесообразность вообще говоря довольна сомнительна, и кроме как к удорожанию кристалла мало к чему приведет.

Итак, суть вопроса разделилась на три ветки:

х48А: добавить к существующим решениям набор команд для работы с 48 бит структурами. Это, как раз то о чём Вы говорите. И это, действительно имеет минимум смысла, так как к существующему оборудованию добавится довесок принципиально дело не меняющий, кроме усложнения аппаратной части. Но стоит также упомянуть: а как относится к, например, режиму виртуального 86? Кому сейчас нужен реальный режим и поддержка соответствующего ПО?

х48Б: предложить новую архитектуру, которая будет поддерживать адресацию побайтно с ограничениями до размера максимального слова в 48 бит. Естественно, для тех, кто программирует, например, на "С" вся нагрузка ляжет на компилятор. Тем не менее стоит тоже вспомнить: изначально "С" разрабатывался, как язык имеющий уровень абстракций достаточный для построения аппаратно независимых программ. Например, int означало объявление просто целого числа без знания конкретного размера, который при необходимости вычислялся компилятором через sizeof. Реально же, используются понятия short int и long int, которые подразумевают размерность. Таким образом, я считаю, вполне допустимо объявить массив структуры int48 и компилятор поймёт, что на самом деле при поиске произвольного элемента нужно номер этого элемента умножить на 6, введя специальную команду, аналогично, могут быть оформлены структуры int24, int16, int12, int8.

х48В: предложить новую архитектуру, которая будет поддерживать только адресацию словами по 48 бит, с наличием только 48 бит регистров и комплектом команд упаковки/распаковки внутри самих регистров. При программировании на "С" подход будет похожим на ранее описанный, и нагрузка также ляжет на компилятор. Но с точки зрения аппаратной базы, естественно, кое что усложнится, но кое что и упростится.

PS: 99.999999999% - это получается менее одного человека, живущего сегодня.) Как же быть с системными программистами, разработчикауи драйверов... Имхо, когда программист исходит из предположения, что ресурсов для текущей задачи хватит, то да, на многое можно смотреть сквозь. Но, когда находятся узкие места, то так или иначе ему придётся спуститься на уровень ассемблера и понимания того, как работает его железо.

[Sla]

Кому сейчас нужен реальный режим и поддержка соответствующего ПО?

Я так понимаю, что товарищ совсем не знает об embedded system