Совместимость. Причем не только 16 бит, но и 8 бит можно отлично использовать :).
Под 32 бита толком-то писать и оптимизировать только научились :)
Тем более, что биосы-то пока не EFI поголовно :)
[off]Большая вычислительная мощь современных процессоров найдёт применение в том числе и в корпоративном сегменте, точнее в сфере промышленной автоматизации, где могут применяться самые разные типы ОС.[/off]
Все процессоры нонче 64-битные. ОС - 64-битные.
Как-то с дефинициями неубедительно получается... А что такое 64-х битный процессор? А прочая архитектура скольки-битная?
И, наконец, хит сезона. Статья прям-таки в продвинутый журнал. Порты: скорее живы? И мелким шрифтом подзаголовок: "Еще один аспект болезни Айнц-Геймера в пространстве портов".
К сожалению, повышение разрядности регистров и шин не делает программиста умнее. Скорее, наоборот. До сих пор и 8 бит живы, в самом деле. Зачем 64 там, где 8 хватит?
Как-то с дефинициями неубедительно получается... А что такое 64-х битный процессор? А прочая архитектура скольки-битная?
Попытки отрекламировать новые многобитные возможности новых процессоров не было. Хотелось лишь засветить один тонкий момент с толстыми последствиями.
Можно долго рассуждать о "крутости" одних режимов работы процессора (а, соответственно и приложений для него) и отсталости других, однако все "крутые" режимы работы требуют Paging, который требует, собственно, памяти, которая в свою очередь требует инициализации и после RESET недоступна. В результате уже имеем прямую нужду в 16-битах, как единственного примитивно-простого режима доступа к оперативной памяти. Кроме того, для реализации таких примитивных вещей как 16-битный режим нужно минимум места на кристалле, потому глупо от этого отказываться.
Итого - это есть ответ "от обратного". Думаю, "загадку-разминку" можно считать закрытой. :)
Как-то все говорят, но вот мне хочется вставить "рамку".
64 бит - это не столько система команд, сколько архитектура.
А именно способ выполнения кода и в том числе расширенная шина(физика) и регистры(псевдо-виртуальная часть)!
16 битный код есть потому, что на данный момент еще не разработано ни одного высокоэффективного "Транслятора" кода.
А поскольку сама задача не такая уж и трудная - то лично я делаю вывод, что это связано каким-то образом с финансами, и вполне вероятно связанно как-то с промышленным сговором!
Если вдруг весь код со всех старых платформ начнуть "рекомпилировать" - этож даст фундамент не только рекомпиляции кода между совместимыми платфорамами, а вообще получится код "кросс-приложений"! А это такой удар по экономике многих организаций - что вполне вероятен сговор по этой самой причине.
А в ручную переписывать код - это долго и муторно, но всёже это происходит... Не стоит забывать, что с "математическими дискретами" - быстрее работает машина, а человек по жизни - машинка для медленного и "точного" взвешивания, хоть и годится для подобных рассчётов, но куда менее эффективна чем кремниевая система заточенная под дискретную логику!
Ну вот, вроде мысль выглядела как-то так :D
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.
Цитата:
<font size="1">... для реализации таких примитивных вещей как 16-битный режим нужно минимум места на кристалле, потому глупо от этого отказываться</font>.
<font size="2">А еще очень глупо отказываться от уже сформировавшихся (а вернее сказать: сформированных) рынков и прибылей соответственно. Господа, в Intel-е и Мелкософте, ну не совсем же лохи работают.
P.S. А вообще оглядывась назад, складывается впечатление, что как-то изначально развитие вычислительной техники не тем путем пошло.</font>
Прошлую пятницу технично увернулся от задания написать модуль для SMM16 на ассембрере, но от интерфейсного модуля к SMM16 никуда не денешься - надо написать. А что поделать? Без 16-ти разрядного режима никуда. Хотя перепрошивка флеш выполняется в SMM64!
Сам до не давнего времяни задавался этим вопросом и ответ нашелся сам по себе. Все конечном итоге упирается в графику. Построение графических пространств ведется по разным стандартам типа RGB, CMYK., есть и еще. Тоесть если говорить проще монитор работает в цветовом пространстве RGB и никакое другое отображать не может а допустим тот же самый принтр может распечатать как и RGB так и CMYK а также в моем случае CMYKcm тоесть "С" это синии от 100 до 0 а "с" от 50 до 0. Качество возрастает в несколько раз но всеравно получается что махсимум на который способна печатающая техника на сагодняшьний день это 16 бит. Конечно в скором времени возможно уже сейчас существует технология выводящая изображение выше 16 битного образца. Но это точно уже не бумага :) Допустим полупрозрачние объекты не распечатываются полупрозрачными., тоесть распечатываются но это просто такой трюк который перед выводом изображения создается скрин полупрозрачного объекта чтобы сохранить видимость полупрозрачности. А также при работе над графикой всегда возникают проблемы с выводом на печать полупрозрачных объектов которая решается только фокусами ))))))) Короче говоря биты это глубина вложения и если монитор может изобразить 64 битный объект то такая платформа существует а если 128 бит на обычных LCD не отображается то и смысла пока в этом нет...
PS: Вобщем я сам во всем том что написал точно не уверен... Но одно я знаю точно что в этом понятии биты используются для вывода изображения и не для чего больше
PPS: для работы програмы достаточно и 16 бит согласен а для ракеты НАСА вобще 4 битного интерфейса вполне достаточно.
PPPS: извените что так много написанно))))))))))
[off]
получается что махсимум на который способна печатающая техника на сагодняшьний день это 16 бит.
Вам бы отправиться в эпоху 386/486 и порассуждать о необходимой разрядности процессоров с опорой на достижения печатной техники в то время :).
Поскольку задача обработки графики не является приоритетной задачей CPU, то разрядность CPU может плевать на возможности графического отображения :D.[/off]
[off]Костя (гость)
более забористого бреда за сегодня я еще не слышал... Вы еще порассуждайте об отсутствии необходимости 64-битных и 128-битных вычислений для криптографии - давайте, посмешите нас еще.[/off]
Разминка для ума.
Все процессоры нонче 64-битные. ОС - 64-битные. Излагаем причины - почему же 16-бит всё ещё присутствует и не отброшен как артефакт?
Не стесняемся. Аргументируем.
Тем более, что биосы-то пока не EFI поголовно :)
И, наконец, хит сезона. Статья прям-таки в продвинутый журнал. Порты: скорее живы? И мелким шрифтом подзаголовок: "Еще один аспект болезни Айнц-Геймера в пространстве портов".
Попытки отрекламировать новые многобитные возможности новых процессоров не было. Хотелось лишь засветить один тонкий момент с толстыми последствиями.
Можно долго рассуждать о "крутости" одних режимов работы процессора (а, соответственно и приложений для него) и отсталости других, однако все "крутые" режимы работы требуют Paging, который требует, собственно, памяти, которая в свою очередь требует инициализации и после RESET недоступна. В результате уже имеем прямую нужду в 16-битах, как единственного примитивно-простого режима доступа к оперативной памяти. Кроме того, для реализации таких примитивных вещей как 16-битный режим нужно минимум места на кристалле, потому глупо от этого отказываться.
Итого - это есть ответ "от обратного". Думаю, "загадку-разминку" можно считать закрытой. :)
64 бит - это не столько система команд, сколько архитектура.
А именно способ выполнения кода и в том числе расширенная шина(физика) и регистры(псевдо-виртуальная часть)!
16 битный код есть потому, что на данный момент еще не разработано ни одного высокоэффективного "Транслятора" кода.
А поскольку сама задача не такая уж и трудная - то лично я делаю вывод, что это связано каким-то образом с финансами, и вполне вероятно связанно как-то с промышленным сговором!
Если вдруг весь код со всех старых платформ начнуть "рекомпилировать" - этож даст фундамент не только рекомпиляции кода между совместимыми платфорамами, а вообще получится код "кросс-приложений"! А это такой удар по экономике многих организаций - что вполне вероятен сговор по этой самой причине.
А в ручную переписывать код - это долго и муторно, но всёже это происходит... Не стоит забывать, что с "математическими дискретами" - быстрее работает машина, а человек по жизни - машинка для медленного и "точного" взвешивания, хоть и годится для подобных рассчётов, но куда менее эффективна чем кремниевая система заточенная под дискретную логику!
Ну вот, вроде мысль выглядела как-то так :D
P.S.
Всё вышесказанное в основном относится к области высокопроизводительных систем, не касясь встраиваемых и тому подобных систем - там где собственно всё это не имеет большого значения, и часто может быть написано программистом не более чем за неделю, с нуля.
ДА, и многое вышесказанное - касается уже существующего кода.
Процессоры нынче (в принципе, смотря за какие идет речь) не сказал бы что полностью 64-битные(кроме итаниумов), они как были 32-х битные так и остались, ведь везде пишут, что это лишь ПОДДЕРЖКА, которая скорее всего обуславливает увеличение разрядности регистров и набор команд EM64T (ну и идентичный набор в процессорах от AMD) для возможности 64-битной адресации памяти объемом свыше 4 ГБ. К архитектуре IA-64 относятся только серверные камни.
Касательно ПО - тут неоднозначные выводы. х64 оси как новинка хороши, можно сравнить с операционками для смартов и кпк со своими разработками типа палма. Все красиво, быстро, НО... к примеру не очень интересно и удобно покупать платформу Symbian 9.2 или 9.3, когда сейчас только под 9.1 более менее достаточное количество прикладного ПО. Большинство пользователей настольных систем, которые кроме прослушивания музыки и набора текстов занимаются еще чем-то для своих интересов и бизнеса даже не покушаются на ту же 64-битную ХР, уже не говоря о Висте. Зная, что на новой платформе эмуляция в обратную сторону, т.е. лишь поддержка 32-битных приложений, и больше половины программ просто не запустятся или из-за несовпадения билдов осей, на которую их пытаться установить и под которую их писали, или из-за "неродных" методов обращения к памяти (за спеиализированные программы, которые могут быть популярны в узких кругах на территории России/Украины вообще молчу). А приложений, которые полным образом поддерживают 64 бита и/или двухъядерную архитектуру - можно сосчитать по пальцам, в первую очередь очень большие и очень дорогие пакеты для редактирования видео, графики и т.д. Потому нельзя сказать, что время подпадаемое под категорию х64 уже наступило...
Кардинально не согласен.
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-битным.
Да, и компиляторы не забудем, точнее, их особую одарённость. :)
Некоторое старое ПО все еще использует 16-ти битный режим, в основном это системные утилиты, написанные в 80-ых. В современных процессорах 16-ти битный режим оставили, видимо, как опцию - не мешает и ладно, а запас карман не тянет. Кроме того куча инженеров до сих пор сопровождает этот режим и пишут новые программки - не увольнят же их
Я недавно узнал, что существует 16 bit Protected Mode, и его поддержка потребовалась в сравнительно новом проекте Montevina.
Совместимость с более старыми наработками, изначально являвшаяся верным спутником IBM PC. Если убрать 16-разрядный режим, придется переписать очень много ПО, начиная от диагностического. А как же загрузочные секторы? Загрузчики операционных систем?
Бегло глянул NTLDR от XP32 SP2. 16-разрядный код, исполняемый в реальном режиме процессора (или режиме 8086). По-другому и быть не может - ведь спецификации на то, как осуществляется процесс загрузки ОС, не менялись. Я конечно понимаю, эмуляторы можно понаписать для софта и т.д. И плюнуть на таких, как я, у кого на Бартоне 2500@3200 стоит 98 ради ДОС... Но зачем? Как было правильно подмечено, места на кристалле много не требуется, на стоимость влияет не сильно...
P.S. Или я не уловил сути вопроса?
<font size="1">... для реализации таких примитивных вещей как 16-битный режим нужно минимум места на кристалле, потому глупо от этого отказываться</font>.
<font size="2">А еще очень глупо отказываться от уже сформировавшихся (а вернее сказать: сформированных) рынков и прибылей соответственно. Господа, в Intel-е и Мелкософте, ну не совсем же лохи работают.
P.S. А вообще оглядывась назад, складывается впечатление, что как-то изначально развитие вычислительной техники не тем путем пошло.</font>
PS: Вобщем я сам во всем том что написал точно не уверен... Но одно я знаю точно что в этом понятии биты используются для вывода изображения и не для чего больше
PPS: для работы програмы достаточно и 16 бит согласен а для ракеты НАСА вобще 4 битного интерфейса вполне достаточно.
PPPS: извените что так много написанно))))))))))
Поскольку задача обработки графики не является приоритетной задачей CPU, то разрядность CPU может плевать на возможности графического отображения :D.[/off]
более забористого бреда за сегодня я еще не слышал... Вы еще порассуждайте об отсутствии необходимости 64-битных и 128-битных вычислений для криптографии - давайте, посмешите нас еще.[/off]