Причины, по которым новые 64-бит процессоры продолжают поддерживать 16-бит

Совместимость. Причем не только 16 бит, но и 8 бит можно отлично использовать.

Под 32 бита толком-то писать и оптимизировать только научились

Тем более, что биосы-то пока не EFI поголовно

Большая вычислительная мощь современных процессоров найдёт применение в том числе и в корпоративном сегменте, точнее в сфере промышленной автоматизации, где могут применяться самые разные типы ОС.

Как-то с дефинициями неубедительно получается... А что такое 64-х битный процессор? А прочая архитектура скольки-битная?
И, наконец, хит сезона. Статья прям-таки в продвинутый журнал. Порты: скорее живы? И мелким шрифтом подзаголовок: "Еще один аспект болезни Айнц-Геймера в пространстве портов".

К сожалению, повышение разрядности регистров и шин не делает программиста умнее. Скорее, наоборот. До сих пор и 8 бит живы, в самом деле. Зачем 64 там, где 8 хватит?

Попытки отрекламировать новые многобитные возможности новых процессоров не было. Хотелось лишь засветить один тонкий момент с толстыми последствиями.

Можно долго рассуждать о "крутости" одних режимов работы процессора (а, соответственно и приложений для него) и отсталости других, однако все "крутые" режимы работы требуют Paging, который требует, собственно, памяти, которая в свою очередь требует инициализации и после RESET недоступна. В результате уже имеем прямую нужду в 16-битах, как единственного примитивно-простого режима доступа к оперативной памяти. Кроме того, для реализации таких примитивных вещей как 16-битный режим нужно минимум места на кристалле, потому глупо от этого отказываться.

Итого - это есть ответ "от обратного". Думаю, "загадку-разминку" можно считать закрытой.

Как-то все говорят, но вот мне хочется вставить "рамку".
64 бит - это не столько система команд, сколько архитектура.
А именно способ выполнения кода и в том числе расширенная шина(физика) и регистры(псевдо-виртуальная часть)!

16 битный код есть потому, что на данный момент еще не разработано ни одного высокоэффективного "Транслятора" кода.
А поскольку сама задача не такая уж и трудная - то лично я делаю вывод, что это связано каким-то образом с финансами, и вполне вероятно связанно как-то с промышленным сговором!

Если вдруг весь код со всех старых платформ начнуть "рекомпилировать" - этож даст фундамент не только рекомпиляции кода между совместимыми платфорамами, а вообще получится код "кросс-приложений"! А это такой удар по экономике многих организаций - что вполне вероятен сговор по этой самой причине.

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

Ну вот, вроде мысль выглядела как-то так

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

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

Процессоры нынче (в принципе, смотря за какие идет речь) не сказал бы что полностью 64-битные(кроме итаниумов), они как были 32-х битные так и остались, ведь везде пишут, что это лишь ПОДДЕРЖКА, которая скорее всего обуславливает увеличение разрядности регистров и набор команд EM64T (ну и идентичный набор в процессорах от AMD) для возможности 64-битной адресации памяти объемом свыше 4 ГБ. К архитектуре IA-64 относятся только серверные камни.

Касательно ПО - тут неоднозначные выводы. х64 оси как новинка хороши, можно сравнить с операционками для смартов и кпк со своими разработками типа палма. Все красиво, быстро, НО... к примеру не очень интересно и удобно покупать платформу Symbian 9.2 или 9.3, когда сейчас только под 9.1 более менее достаточное количество прикладного ПО. Большинство пользователей настольных систем, которые кроме прослушивания музыки и набора текстов занимаются еще чем-то для своих интересов и бизнеса даже не покушаются на ту же 64-битную ХР, уже не говоря о Висте. Зная, что на новой платформе эмуляция в обратную сторону, т.е. лишь поддержка 32-битных приложений, и больше половины программ просто не запустятся или из-за несовпадения билдов осей, на которую их пытаться установить и под которую их писали, или из-за "неродных" методов обращения к памяти (за спеиализированные программы, которые могут быть популярны в узких кругах на территории России/Украины вообще молчу). А приложений, которые полным образом поддерживают 64 бита и/или двухъядерную архитектуру - можно сосчитать по пальцам, в первую очередь очень большие и очень дорогие пакеты для редактирования видео, графики и т.д. Потому нельзя сказать, что время подпадаемое под категорию х64 уже наступило...

htmaxxt
Кардинально не согласен.
IA-64 к данному контексту совершенно не имеет отношения, это VLIW (EPIC). Здесь же рассматривается классическая архитектура x86 с точки зрения 64-битного режима.
Если уж хотите официальное название - "Intel® 64 and IA-32 Architectures" или "AMD64 Architecture".
IMHO процессор может считаться n-битным в том случае, если он имеет n-битные РОН и может производить с ними простейшие операции передачи данных, арифметические операции, логические операции, операции сдвига, операции передачи управления.
Рекомендую к прочтению Intel® 64 and IA-32 Architectures Software Developer’s Manual или AMD64 Architecture Programmer’s Manual.
Да, x86 не родился 64-битным, он тащит за собой тяжелое наследие предков. Но тем не менее на данный момент он является 64-битным.

Пора переходить на обсуждение штрафных тактов... И в этой шутке есть только доля шутки. N-битный процессор в программировании на ОО ЯВУ - это совсем не то, что в ассемблерном программировании. Толку-то от этой 64-битности, как её ни понимай...
Да, и компиляторы не забудем, точнее, их особую одарённость.

А как же бедняги на полноценных компьютерах справляются, где 16bit в принципе вообще никогда небыло?

Некоторое старое ПО все еще использует 16-ти битный режим, в основном это системные утилиты, написанные в 80-ых. В современных процессорах 16-ти битный режим оставили, видимо, как опцию - не мешает и ладно, а запас карман не тянет. Кроме того куча инженеров до сих пор сопровождает этот режим и пишут новые программки - не увольнят же их 
Я недавно узнал, что существует 16 bit Protected Mode, и его поддержка потребовалась в сравнительно новом проекте Montevina.

Выскажу и я свое мнение:

Совместимость с более старыми наработками, изначально являвшаяся верным спутником IBM PC. Если убрать 16-разрядный режим, придется переписать очень много ПО, начиная от диагностического. А как же загрузочные секторы? Загрузчики операционных систем?

Бегло глянул NTLDR от XP32 SP2. 16-разрядный код, исполняемый в реальном режиме процессора (или режиме 8086). По-другому и быть не может - ведь спецификации на то, как осуществляется процесс загрузки ОС, не менялись. Я конечно понимаю, эмуляторы можно понаписать для софта и т.д. И плюнуть на таких, как я, у кого на Бартоне 2500@3200 стоит 98 ради ДОС... Но зачем? Как было правильно подмечено, места на кристалле много не требуется, на стоимость влияет не сильно...

P.S. Или я не уловил сути вопроса?

Вы забыли одну важную вещь - промышленное оборудование и платформенно-зависимые устройства, вроде разнообразных программаторов.  В целях повышения надёжности они до сих пор используют операционные системы Windows 3.x и 9x и даже чистый DOS!!! В других версиях ПО они элементарно не работают.  Так что 16-бит должен жить еще лет эдак 5-7.

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

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

P.S. А вообще оглядывась назад, складывается впечатление, что как-то изначально развитие вычислительной техники не тем путем пошло.

Прошлую пятницу технично увернулся от задания написать модуль для SMM16 на ассембрере, но от интерфейсного модуля к SMM16 никуда не денешься - надо написать. А что поделать? Без 16-ти разрядного режима никуда. Хотя перепрошивка флеш выполняется в SMM64!

Сам до не давнего времяни задавался этим вопросом и ответ нашелся сам по себе. Все конечном итоге упирается в графику. Построение графических пространств ведется по разным стандартам типа RGB, CMYK., есть и еще. Тоесть если говорить проще монитор работает в цветовом пространстве RGB и никакое другое отображать не может а допустим тот же самый принтр может распечатать как и RGB так и CMYK а также в моем случае CMYKcm тоесть "С" это синии от 100 до 0 а "с" от 50 до 0. Качество возрастает в несколько раз но всеравно получается что махсимум на который способна печатающая техника на сагодняшьний день это 16 бит. Конечно в скором времени возможно уже сейчас существует технология выводящая изображение выше 16 битного образца. Но это точно уже не бумага Допустим полупрозрачние объекты не распечатываются полупрозрачными., тоесть распечатываются но это просто такой трюк который перед выводом изображения создается скрин полупрозрачного объекта чтобы сохранить видимость полупрозрачности. А также при работе над графикой всегда возникают проблемы с выводом на печать полупрозрачных объектов которая решается только фокусами ))))))) Короче говоря биты это глубина вложения и если монитор может изобразить 64 битный объект то такая платформа существует а если 128 бит на обычных LCD не отображается то и смысла пока в этом нет...
PS: Вобщем я сам во всем том что написал точно не уверен... Но одно я знаю точно что в этом понятии биты используются для вывода изображения и не для чего больше
PPS: для работы програмы достаточно и 16 бит согласен а для ракеты НАСА вобще 4 битного интерфейса вполне достаточно.
PPPS: извените что так много написанно))))))))))

Вам бы отправиться в эпоху 386/486 и порассуждать о необходимой разрядности процессоров с опорой на достижения печатной техники в то время.

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

Костя (гость)
более забористого бреда за сегодня я еще не слышал... Вы еще порассуждайте об отсутствии необходимости 64-битных и 128-битных вычислений для криптографии - давайте, посмешите нас еще.