Внимание! Это временный неофициальный архив старой версии форума Полигон Призраков, созданный сочувствующим форуму участником. Этот сайт просуществует лишь до тех пор, пока администрация Полигона не сдержит своё обещание и не откроет официальный архив по адресу old.sannata.org.

Полигон-2

Форум о старых компьютерах

Объявление форума

Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС.

Полигон-2 »   Технический флейм »   Самая большая legacy
RSS

Самая большая legacy

Система команд x86

<<Назад  Вперед>> Страницы: 1 2 3 4
Печать
 
User 0
Junior Member


Откуда: Moscow
Всего сообщений: 112
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
25 дек. 2007
На мой взгляд, самая большая legacy — это неортогональная система команд x86. Почему, скажем, на PDP-11 почти любая команда может оперировать любым регистром, а на Intel — свои регистры для цикла, свои для умножения, свои для записи в порт и т. п.?
При разработке процессора 8086 стояла задача обеспечить совместимость с предыдущим 8-разрядным процессором Intel путем автоматического преобразования двоичных программ. Отсюда и взялись ограничения — в коротких 8-битных командах, рассчитанных на 64-килобайтное ОЗУ, не было места для указания регистров, и те задавались неявно.
Начиная с IBM PC компания IBM решила сделать архитектуру компьютера открытой (и тем самым обеспечила последующее глобальное доминирование США на рынках вычислительной техники и программных средств). Массовое распространение PC и прикладных программ на фоне вытеснения прогрессивных конкурирующих архитектур привели к тому, что и в самых современных 64-разрядных компьютерах применяется "унаследованная" система команд с принципами 8-битного процессора.
Fe-Restorator
Гость

Ссылка

User 0 написал:
[q]
При разработке процессора 8086... ...применяется "унаследованная" система команд с принципами 8-битного процессора.
[/q]
Начнём с того, что i8086 никогда не был 8-ми битным!
Как ты упомянул. для "совместимости" с 8-битными процами того времени был спецом разработан i8088, самостоятельный процессор. А с 386-х камней всё более проявляется RISC-архитектура, вовсе не имеющая отношения к системе команд х86.
Сейчас на форуме
User 0
Junior Member


Откуда: Moscow
Всего сообщений: 112
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
25 дек. 2007
Я не говорил, что он был 8-битным. Я сказал, что в нем применены принципы 8-битного процессора.
[q]
Marketed as source compatible, the 8086 was designed to allow assembly language for the 8008, 8080, or 8085 to be automatically converted into equivalent (sub-optimal) 8086 source code, with little or no hand-editing. The programming model and instruction set was (loosely) based on the 8080 in order to make this possible.
[/q]
Fe-Restorator
Гость

Ссылка

User 0 написал:
[q]
Я сказал, что в нем применены принципы 8-битного процессора
[/q]
Расшифруй, что это за принципы такие. Название твоё и непонятное и мутное.
Сейчас на форуме
User 0
Junior Member


Откуда: Moscow
Всего сообщений: 112
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
25 дек. 2007
[q]
Как ты упомянул. для "совместимости" с 8-битными процами того времени был спецом разработан i8088, самостоятельный процессор.
[/q]
Не процессорами, а периферийными устройствами. У 8088 8-битная шина данных, а система команд та же, что и у 8086.
[q]
А с 386-х камней всё более проявляется RISC-архитектура, вовсе не имеющая отношения к системе команд х86.
[/q]
Это в ядре, а программная модель как была, так и осталась, разве что расширилась немного. (То, что видит программист, пишущий на ассемблере.)

Fe-Restorator написал:
[q]
Расшифруй, что это за принципы такие.
[/q]
Команды, где регистр не указывается, а подразумевается.
Пример: MUL и DIV (умножение и деление) в исходном варианте работает только с AX.
OUT — только c DX и AX.
LOOP — только c CX и так далее.
В машинах прогрессивных архитектур можно указывать любые регистры.
Fe-Restorator
Гость

Ссылка

User 0 написал:
[q]
обеспечить совместимость с предыдущим 8-разрядным процессором Intel путем автоматического преобразования двоичных программ
[/q]
Ни разу! Минимальная правка исходного кода вручную - да. И обязательно - полная перекомпиляция под новый проц 8086.
То-ж коснулось и аппаратной части камней - большинство узлов 8-битных процов было выброшено и взамен спроектированы новые, непохожие. Единственный камень, способный запускать 8-битные проги прежних процов без перекомпияции - NEC V30. И его 8-битный брателло V20. Оба - спецом заточены под такую задачу.
С появлением RISC-части в камнях всякое программирование "по-старинке" потеряло смысл, ибо никогда не компилировалось в х86-код, сразу затачиваясь под возможности камня. Верхний уровень программирования оставался примерно похожим на прежний, ибо переучить 40-летнего человека неизмеримо труднее, чем процессор. Посему, пошли на подмену кода, скрыв оную от программиста, как минимум, от не очень требовательного программиста.
Сейчас на форуме
User 0
Junior Member


Откуда: Moscow
Всего сообщений: 112
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
25 дек. 2007
Fe-Restorator написал:
[q]
С появлением RISC-части в камнях всякое программирование "по-старинке" потеряло смысл, ибо никогда не компилировалось в х86-код, сразу затачиваясь под возможности камня. Верхний уровень программирования оставался примерно похожим на прежний, ибо переучить 40-летнего человека неизмеримо труднее, чем процессор. Посему, пошли на подмену кода, скрыв оную от программиста, как минимум, от не очень требовательного программиста.
[/q]
Я читал руководство программиста к относительно новым процессорам типа AMD64. Там нет никакого другого кода, кроме x86. Вы ведь не хотите сказать, что компилятор языка высокого уровня выдает объектный файл не с x86-кодом, а неким RISC-кодом? Или вы имеете в виду, что компилятор выдает x86-команды, оптимизированные для скрытого от программиста RISC-ядра?
Fe-Restorator
Гость

Ссылка

"Совместимые с программистом" х86 команды разделяются компилятором на части, оптимальные для выполнения риск-архитектурой проца, второй вариант. Объектный код при этом не похож ни на чистый х86, ни на чистый "риск".
И покажи-ка мне программиста, напрямую обращающегося к регистру АХ на проце i7!!! Вида MOV AX,xxx. ;) И началось сие безобразие ещё с далёких 386-х.

PS. По той-же причине программы под форточку на работали в чистом досе - отличался объектный код. Крупной проге, возможно, не хватало ресурсов подлинковать 100500 внешних библиотек, но даже простенький "Hello World!" отказывался работать! А сейчас уже ОС отказывается от досовского наследия, уже из-за заточенности под широкобитную шину. Постепенно пропадает класс "консольных приложений".
Сейчас на форуме
User 0
Junior Member


Откуда: Moscow
Всего сообщений: 112
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
25 дек. 2007
Вы хотите сказать, что если я ассемблерную программу реального режима для 86/486 скомпилирую современным компилятором, указав опцию "для нового процессора", код будет иным, чем если взять старый компилятор для 486-го процессора?


Fe-Restorator написал:
[q]
По той-же причине программы под форточку на работали в чистом досе - отличался объектный код.
[/q]
А разве не потому, что в расширенном режиме по-другому организованы работа с памятью и ввод-вывод — программа обращается к таким функциям операционной системы и по таким адресам, которых в "чистом DOS'е" не существует.
[q]
Постепенно пропадает класс "консольных приложений".
[/q]
Я бы не стал смешивать консольные приложения с DOS-приложениями. Консольный ввод очень удобен: сравните скорость изменения, скажем, даты/времени, или там управления службами через консоль/скрипт и через графический интерфейс.
Fe-Restorator
Гость

Ссылка

Если современным компилятором ты соорудишь объектный код для выполнения на 386/486 физическом камне, этот код будет отличаться от такового, созданного старым компилятором, порой достаточно сильно, чтобы не запуститься на 486. Оптимальным сей код точно не будет, и некие приёмы, допустимые в современных процах и оставшиеся в коде могут стать косяками и приведут к зависанию. Современные компиляторы не обязаны знать особенности старых процов, нужен некий "патч" для компилятора, где вся нужная инфа прописана в полном объёме. Однако, такой патч фактически превращает новый компилятор в старый, и разница с отдельно-взятым старым компилятором минимальна, хотя всё-ещё заметна. Кроме возможности работать на современной технике, обслуживая технику древнюю - этот путь ничего не даёт.
Если на современном компиляторе создашь "досовский" код для выполнения на i7, хотя весь алгоритм останется неизменным, на 486-м его не запустишь.

User 0 написал:
[q]
Я бы не стал смешивать консольные приложения с DOS-приложениями. Консольный ввод очень удобен: сравните скорость изменения даты и времени/управления службами через консоль/скрипт и через графический интерфейс.
[/q]
Поменяй-ка дату/время через порт RS232 извне! Замерь скорость, если так интересно. И не путай окно консоли с консольной программой.
Сейчас на форуме
<<Назад  Вперед>> Страницы: 1 2 3 4
Печать
Полигон-2 »   Технический флейм »   Самая большая legacy
RSS

1 посетитель просмотрел эту тему за последние 15 минут
В том числе: 1 гость, 0 скрытых пользователей

Последние RSS
[Москва] LIQUID-Акция. Сливаются разъемы CF
МС7004 и 7004А на AT и XT
Пайка термотрубок
Проммать s478 PEAK 715VL2-HT ( Full-Size SBC)
Подскажите по 386 материке по джамперам.

Самые активные 5 тем RSS