Объявление форума |
Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС. |
Полигон-2 » Технический флейм » Самая большая legacy |
<<Назад Вперед>> | Страницы: 1 2 3 4 | Печать |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 11:59 Сообщение отредактировано: 16 марта 2013 14:11
На мой взгляд, самая большая legacy — это неортогональная система команд x86. Почему, скажем, на PDP-11 почти любая команда может оперировать любым регистром, а на Intel — свои регистры для цикла, свои для умножения, свои для записи в порт и т. п.? При разработке процессора 8086 стояла задача обеспечить совместимость с предыдущим 8-разрядным процессором Intel путем автоматического преобразования двоичных программ. Отсюда и взялись ограничения — в коротких 8-битных командах, рассчитанных на 64-килобайтное ОЗУ, не было места для указания регистров, и те задавались неявно. Начиная с IBM PC компания IBM решила сделать архитектуру компьютера открытой (и тем самым обеспечила последующее глобальное доминирование США на рынках вычислительной техники и программных средств). Массовое распространение PC и прикладных программ на фоне вытеснения прогрессивных конкурирующих архитектур привели к тому, что и в самых современных 64-разрядных компьютерах применяется "унаследованная" система команд с принципами 8-битного процессора. |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 12:14 Сообщение отредактировано: 16 марта 2013 12:18
User 0 написал: Начнём с того, что i8086 никогда не был 8-ми битным! При разработке процессора 8086... ...применяется "унаследованная" система команд с принципами 8-битного процессора. Как ты упомянул. для "совместимости" с 8-битными процами того времени был спецом разработан i8088, самостоятельный процессор. А с 386-х камней всё более проявляется RISC-архитектура, вовсе не имеющая отношения к системе команд х86. |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 12:15 Сообщение отредактировано: 16 марта 2013 12:18
Я не говорил, что он был 8-битным. Я сказал, что в нем применены принципы 8-битного процессора. 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. |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 12:20
User 0 написал: Расшифруй, что это за принципы такие. Название твоё и непонятное и мутное. Я сказал, что в нем применены принципы 8-битного процессора |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 12:20 Сообщение отредактировано: 16 марта 2013 12:34 Не процессорами, а периферийными устройствами. У 8088 8-битная шина данных, а система команд та же, что и у 8086. Как ты упомянул. для "совместимости" с 8-битными процами того времени был спецом разработан i8088, самостоятельный процессор. Это в ядре, а программная модель как была, так и осталась, разве что расширилась немного. (То, что видит программист, пишущий на ассемблере.) А с 386-х камней всё более проявляется RISC-архитектура, вовсе не имеющая отношения к системе команд х86. Fe-Restorator написал: Команды, где регистр не указывается, а подразумевается. Расшифруй, что это за принципы такие. Пример: MUL и DIV (умножение и деление) в исходном варианте работает только с AX. OUT — только c DX и AX. LOOP — только c CX и так далее. В машинах прогрессивных архитектур можно указывать любые регистры. |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 12:34 Сообщение отредактировано: 16 марта 2013 12:39
User 0 написал: Ни разу! Минимальная правка исходного кода вручную - да. И обязательно - полная перекомпиляция под новый проц 8086. обеспечить совместимость с предыдущим 8-разрядным процессором Intel путем автоматического преобразования двоичных программ То-ж коснулось и аппаратной части камней - большинство узлов 8-битных процов было выброшено и взамен спроектированы новые, непохожие. Единственный камень, способный запускать 8-битные проги прежних процов без перекомпияции - NEC V30. И его 8-битный брателло V20. Оба - спецом заточены под такую задачу. С появлением RISC-части в камнях всякое программирование "по-старинке" потеряло смысл, ибо никогда не компилировалось в х86-код, сразу затачиваясь под возможности камня. Верхний уровень программирования оставался примерно похожим на прежний, ибо переучить 40-летнего человека неизмеримо труднее, чем процессор. Посему, пошли на подмену кода, скрыв оную от программиста, как минимум, от не очень требовательного программиста. |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Fe-Restorator написал: Я читал руководство программиста к относительно новым процессорам типа AMD64. Там нет никакого другого кода, кроме x86. Вы ведь не хотите сказать, что компилятор языка высокого уровня выдает объектный файл не с x86-кодом, а неким RISC-кодом? Или вы имеете в виду, что компилятор выдает x86-команды, оптимизированные для скрытого от программиста RISC-ядра? С появлением RISC-части в камнях всякое программирование "по-старинке" потеряло смысл, ибо никогда не компилировалось в х86-код, сразу затачиваясь под возможности камня. Верхний уровень программирования оставался примерно похожим на прежний, ибо переучить 40-летнего человека неизмеримо труднее, чем процессор. Посему, пошли на подмену кода, скрыв оную от программиста, как минимум, от не очень требовательного программиста. |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 13:01 Сообщение отредактировано: 16 марта 2013 13:25
"Совместимые с программистом" х86 команды разделяются компилятором на части, оптимальные для выполнения риск-архитектурой проца, второй вариант. Объектный код при этом не похож ни на чистый х86, ни на чистый "риск". И покажи-ка мне программиста, напрямую обращающегося к регистру АХ на проце i7!!! Вида MOV AX,xxx. И началось сие безобразие ещё с далёких 386-х. PS. По той-же причине программы под форточку на работали в чистом досе - отличался объектный код. Крупной проге, возможно, не хватало ресурсов подлинковать 100500 внешних библиотек, но даже простенький "Hello World!" отказывался работать! А сейчас уже ОС отказывается от досовского наследия, уже из-за заточенности под широкобитную шину. Постепенно пропадает класс "консольных приложений". |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 13:25 Сообщение отредактировано: 16 марта 2013 23:19
Вы хотите сказать, что если я ассемблерную программу реального режима для 86/486 скомпилирую современным компилятором, указав опцию "для нового процессора", код будет иным, чем если взять старый компилятор для 486-го процессора? Fe-Restorator написал: А разве не потому, что в расширенном режиме по-другому организованы работа с памятью и ввод-вывод — программа обращается к таким функциям операционной системы и по таким адресам, которых в "чистом DOS'е" не существует. По той-же причине программы под форточку на работали в чистом досе - отличался объектный код. Я бы не стал смешивать консольные приложения с DOS-приложениями. Консольный ввод очень удобен: сравните скорость изменения, скажем, даты/времени, или там управления службами через консоль/скрипт и через графический интерфейс. Постепенно пропадает класс "консольных приложений". |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 13:38 Сообщение отредактировано: 16 марта 2013 13:42
Если современным компилятором ты соорудишь объектный код для выполнения на 386/486 физическом камне, этот код будет отличаться от такового, созданного старым компилятором, порой достаточно сильно, чтобы не запуститься на 486. Оптимальным сей код точно не будет, и некие приёмы, допустимые в современных процах и оставшиеся в коде могут стать косяками и приведут к зависанию. Современные компиляторы не обязаны знать особенности старых процов, нужен некий "патч" для компилятора, где вся нужная инфа прописана в полном объёме. Однако, такой патч фактически превращает новый компилятор в старый, и разница с отдельно-взятым старым компилятором минимальна, хотя всё-ещё заметна. Кроме возможности работать на современной технике, обслуживая технику древнюю - этот путь ничего не даёт. Если на современном компиляторе создашь "досовский" код для выполнения на i7, хотя весь алгоритм останется неизменным, на 486-м его не запустишь. User 0 написал: Поменяй-ка дату/время через порт RS232 извне! Замерь скорость, если так интересно. И не путай окно консоли с консольной программой. Я бы не стал смешивать консольные приложения с DOS-приложениями. Консольный ввод очень удобен: сравните скорость изменения даты и времени/управления службами через консоль/скрипт и через графический интерфейс. |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 13:39 Сообщение отредактировано: 16 марта 2013 14:02 Это я бы проверил. Если на современном компиляторе создашь "досовский" код для выполнения на i7, хотя весь алгоритм останется неизменным, на 486-м его не запустишь. |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
Fe-Restorator написал: Код с 8-битного 8080 действительно легко переносится автоматическим кросс-ассемблером на 8086. Именно ради этого в 8086 адресное пространство не по-человечески линейное, а сегментированное, все операции переходов 8080 превращаются во внутрисегментные переходы 8086. Ни разу! Минимальная правка исходного кода вручную - да. И обязательно - полная перекомпиляция под новый проц 8086. |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 13:43 Сообщение отредактировано: 16 марта 2013 13:46
DrPass написал: Т.е. программы запускаются без всякой перекомпиляции? Что-т ни единого разу сие не срабатывало, сколь ни пробовал. Код с 8-битного 8080 действительно легко переносится автоматическим кросс-ассемблером на 8086. Именно ради этого в 8086 адресное пространство не по-человечески линейное, а сегментированное, все операции переходов 8080 превращаются во внутрисегментные переходы 8086. |
Сейчас на форуме |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
User 0 написал: Если речь идет об ассемблерной программе, то код будет таким же. Ассемблер никогда не занимается фантазиями на тему оптимизации, он всегда преобразует в машинный код указанные операции один к одному. Если речь идет о языке высокого уровня, то, конечно, код будет иным. Т. е., если я ассемблерную программу реального режима для 86/486 скомпилирую современным компилятором, указав опцию "для нового процессора", код будет иным, чем если взять старый компилятор для 486-го процессора? Fe-Restorator написал: Прочти еще раз мою фразу, и погугли незнакомые тебе слова Т.е. программы запускаются без всякой перекомпиляции? |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 13:51 Сообщение отредактировано: 16 марта 2013 13:53
Хамишь. Некрасиво с твоей стороны. Впрочем, бери сию тему в свои руки, раз уж проявил к ней интерес: инициатива наказуема. |
Сейчас на форуме |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 13:54 Сообщение отредактировано: 16 марта 2013 13:54
Fe-Restorator написал: Прошу прощения, обижать не хотел Просто болит голова и настроение плохое... Хамишь. Некрасиво с твоей стороны. |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 13:59 Сообщение отредактировано: 19 марта 2013 20:13
Fe-Restorator написал: Преобразование выполняется кросс-ассемблером в автоматическом режиме (а не процессором на лету). Насколько я понимаю, ассемблер берет исполняемый (или по крайней мере объектный) файл для 8080 и автоматически делает его совместимым с 8088/86. Т.е. программы запускаются без всякой перекомпиляции? Спасибо, DrPass, за разъяснения! |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 14:01 Сообщение отредактировано: 16 марта 2013 14:01
User 0 написал: Верно. У 8086 с 8080 отличаются коды команд, но есть их "смысловое" соответствие. Т.е. можно просто пройтись по коду программы и подменить инструкции 8080 на инструкции 8086, и оно заработает. Так на 8086 переносились, к примеру, WordStar, часть кода CP/M и т.д. Насколько я понимаю, ассемблер берет двоичный файл и автоматически делает его совместимым с 8086. |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 14:48 Сообщение отредактировано: 16 марта 2013 14:53
А можно ли узнать Ваше мнение, DrPass (если вернуться назад, во времена, когда еще не существовало Java/.NET), в какой мере элегантность программной модели процессора и языка ассемблера влияют на эффективность программирования, качество компиляторов, быстродействие и компактность программ? Верно ли хотя бы отчасти предположение, что программисты по причине чрезмерного неудобства ассемблера x86 при всякой возможности отказываются от низкоуровневого кодирования, передавая эту задачу компиляторам ЯВУ, и является ли этот фактор значимым в общей сумме факторов, отрицательно сказывающихся на качестве ПО (таких, как слишком сжатые сроки)? |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
User 0 написал: На эффективность низкоуровневого программирования влияют очень сильно. К примеру, PDP-11 имела простую систему команд и адресацию. Программист PDP-11 обучался ассемблеру намного быстрее и проще, и в общем-то мог читать даже машинный код. в какой мере элегантность программной модели процессора и языка ассемблера влияют на эффективность программирования, качество компиляторов, быстродействие и компактность программ? На быстродействие влияет, но косвенно. К примеру, размер программы для RISC-процессора (да и даже для приснопамятного 8080) будет раза в два-три компактнее, чем аналогичной по функционалу программы для x86, благодаря более коротким машинным командам без монстроидальных суффиксов адресации. А это значит, в два-три раза сокращается количество обращений к кэшу и к ОЗУ. Про качество компиляторов можно было говорить в 80-е годы, сейчас, учитывая, что современные оптимизирующие компиляторы (и не очень современные) знают все особенности архитектур х86, это уже не принципиально. User 0 написал: Я не скажу, что ассемблер х86 создавал какие-то неудобства. Возможно, если бы я на него пересел после ассемблера DEC или Motorola, меня бы он раздражал. Но начиная учиться на х86, я всё это воспринимал как должное Верно ли хотя бы отчасти предположение, что программисты по причине чрезмерного неудобства ассемблера x86 при всякой возможности отказываются от низкоуровневого кодирования, передавая эту задачу компиляторам ЯВУ Просто каким бы удобным ассемблер не был, все равно программа на С или Паскале пишется в разы проще и быстрее. А результат не настолько уступает ассемблерному по производительности, чтобы жертвовать временем разработки ради некоторой оптимизации. Пока вы пишете одну программу на ассемблере, программист на ЯВУ выпустит несколько программ и продаст их вашим клиентам. Математика простая. Другое дело, что сейчас оно вообще зашло до маразма, когда для считывания пары цифр из файла параметров программист применяет многомегабайтный парсер XML с DOM-моделью. "Золотая середина" между качеством кода и производительностью разработки была где-то пройдена в 90-е годы. |
La Forge
Advanced Member
Lt. Cmdr. Откуда: Рязань Всего сообщений: 3248 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 нояб. 2012 |
DrPass написал: Правильно сказано! А если нужно все оптимально на каком-то участке программы, то в BP была директива assеmbler, и часть кода можно писать на нём. Теоретически всю программу. Delphi это унаследовал и поддерживал по крайней мере до 7-й версии. Наскольно я в курсе, то же самое и в BC Просто каким бы удобным ассемблер не был, все равно программа на С или Паскале пишется в разы проще и быстрее. А результат не настолько уступает ассемблерному по производительности, чтобы жертвовать временем разработки ради некоторой оптимизации. Пока вы пишете одну программу на ассемблере, программист на ЯВУ выпустит несколько программ и продаст их вашим клиентам. Математика простая. Кстати насколько я в курсе, 1-й процом от Intel выполнявшим не X86, а результат их декодирования был отнюдь не 386 а Pentium Pro |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
DrPass написал: Значит, качество программ и условия труда были объективно лучше, и это одно из объяснений тому, почему люди хотят хотя бы мысленно оказаться в том времени. "Золотая середина" между качеством кода и производительностью разработки была где-то пройдена в 90-е годы. |
DOS Logic
Advanced Member
d(-_-)b Откуда: Украина. Ивано-Франковск Всего сообщений: 4778 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 1 июля 2006 |
Кстати сказать в тему, первым процом который выполнял быстрее 32-х разрядные проги, а не 16, был пень про. А на счет ассемблера и особенно циклов, зачем использовать loop? сделайте без него, свой цикл который использует метку, команды сравнения и команды inc/add, на то он и ассемблер чтобы шевелить мозгами Но сейчас это никому не нужно, как говорили выше, ассемблер это слишком долго в первую очередь. |
La Forge
Advanced Member
Lt. Cmdr. Откуда: Рязань Всего сообщений: 3248 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 нояб. 2012 |
На асм-е я прогфессионально не программил, но из институтского курса припоминается, что в принципе регистры на деле можно использовать любые и не по-прямому назначению. Например для счётцика циклов насколько я помню, обычно используестя CX, но вподе бы пользовали любые и препод говорил, что назначение конкретного - просто дань традиции |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 20:20 Сообщение отредактировано: 16 марта 2013 20:25
DrPass написал: К сожалению, ВСЕМ этим компиляторам требуется настройка на генерацию кода именно для старых процов, порой, гораздо более тонкая, чем "подсунуть нужный файл-конфигуратор". Этим грешат даже ассемблерные компиляторы, ибо они, по-умолчанию, оптимизированы под современное жезезо. Про компиляторы с ЯВУ и говорить нечего, все, поголовно забыли прежнее программирование, и наперебой пыжатся гнать код под i7, а не под 486! Назови хоть один ЯВУ-компилятор, помнящий процедурное программирование. В отличие от объектно~ и сервиисно~ ориентированного, применяющегося в современности! Оттого и объектный код под старый проц будет разным у современных и старых компиляторов. Про качество компиляторов можно было говорить в 80-е годы, сейчас, учитывая, что современные оптимизирующие компиляторы (и не очень современные) знают все особенности архитектур х86, это уже не принципиально. DrPass написал: +1. С точки зрения сего дня, такая ситуация - пролное дерьмо. В отношении старых процов - 100%-ое. Другое дело, что сейчас оно вообще зашло до маразма, когда для считывания пары цифр из файла параметров программист применяет многомегабайтный парсер XML с DOM-моделью. "Золотая середина" между качеством кода и производительностью разработки была где-то пройдена в 90-е годы. |
Сейчас на форуме |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 21:17 Сообщение отредактировано: 16 марта 2013 21:18
Fe-Restorator написал: Ну чего? M$ Visual C++ еще годится для процедурного, и Embarcadero Delphi все еще в строю. Назови хоть один ЯВУ-компилятор, помнящий процедурное программирование С работой на старых процах действительно есть нюанс. Если ассемблеры еще имеют опции для генерации кода, бинарно совместимого со старыми процами, то современные компиляторы ЯВУ обычно не имеют. Это не так плохо, т.к. они благодаря использованию современных инструкций делают более компактный и шустрый код, но всё-таки... Кстати, вот DOS Logic привел интересный пример оптимизации. Программист на ассемблере обычно знает инструкцию LOOP и использует ее. А компилятор при компиляции циклов возьмет регистр-счетчик и будет его декрементировать инструкцией DEC. Почему? А потому что так на самом деле быстрее, чем LOOP Или тот же самый цикл, допустим, от 0 до 100. Программист возьмет переменную (или регистр, если на ассемблере), присвоит ей значение 0 и будет увеличивать, сравнивая со значением 100 на каждой итерации. Компилятор сначала проверит, насколько в цикле важен порядок его следования, и если не важен, возьмет регистр, запишет туда 100 и будет уменьшать до 0. Потому что сравнение с 0 также намного быстрее, чем сравнение с константой. Поэтому сейчас есть забавный факт: компиляторы умнее среднего ассемблерщика. La Forge написал: Не все регистры, а регистры общего назначения. Их можно произвольно использовать в операциях работы с памятью, арифметики, сравнения, но при этом своя узкая специализация в ряде инструкций у них все же есть. Например, CX автоматически используется как счетчик в упомянутой выше LOOP и в строковых операциях, DX - единственный регистр, который может указывать номер порта для ввода-вывода, а BX можно использовать для косвенной адресации внутри текущего сегмента. На асм-е я прогфессионально не программил, но из институтского курса припоминается, что в принципе регистры на деле можно использовать любые и не по-прямому назначению. Например для счётцика циклов насколько я помню, обычно используестя CX, но вподе бы пользовали любые и препод говорил, что назначение конкретного - просто дань традиции |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 22:09 Сообщение отредактировано: 16 марта 2013 22:12
DrPass написал: Не настолько-уж они современные, не умеют одновременно с "чисто 486" особенностями программировать "множество потоков под ядра i7", например. Либо одно, либо другое. Более того, ассемблеры тож перестали содержать опции, генерирующие код под 386-486, и винить их за сей "промах" по меньшей мере - безосновательно. M$ Visual C++ еще годится для процедурного, и Embarcadero Delphi все еще в строю. DrPass написал: Снова вопрос об виртуозности программиста, а не об ТТХ проца/компилятора! Хороший программист изучил сию особенность архитектуры, и заранее "вывернул цикл наизнанку", в точности, как это делает компилятор, одновременно, выиграв десяток тактов/циклов у того-ж компилятора. Более того, компилятор создавался и оптимизировался именно на основе приёмов эффективного программирования квалифицированными людьми. Иначе - мгновенно получается Болген-ОС, или как её там зовут... Программист на ассемблере обычно знает инструкцию LOOP и использует ее. А компилятор при компиляции циклов возьмет регистр-счетчик и будет его декрементировать инструкцией DEC. Почему? А потому что так на самом деле быстрее, чем LOOP |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 22:20 Сообщение отредактировано: 17 марта 2013 23:24
DrPass написал: Когда я приобрел компьютер на базе Celeron 1,2 ГГц, мне стало интересно посчитать его производительность по старому принципу «сложение „регистр+регистр”». Я написал программу, где блок из 16384 команд целочисленного сложения множество раз вызывался из LOOP-цикла. И, по-моему, именно эта программа на Celeron выполнялась гораздо дольше, чем на AMD K6-166. Может, из-за особенностей устройства конвейера, не знаю точно. А потому что так на самом деле быстрее, чем LOOP |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 22:25 Сообщение отредактировано: 16 марта 2013 22:28
User 0 написал: Сферическая лошадь в вакууме. Текст программы где? И, по-моему, именно эта программа на Celeron выполнялась гораздо дольше, чем на AMD K6-166. Вот, селерон-800, заторможенный аппаратно до 200, выполняет ASM-проги медленнее, чем первопень 200. Зато, доступ к памяти за пределом мегабайта у щелерона выше, несмотря на искусственную заторможенность. Исчаз мене кето-то выскажет ценнейшую мыслю об фиксированности множителя щелеронов... |
Сейчас на форуме |
Fe-Restorator |
NEW! Сообщение отправлено: 16 марта 2013 22:46
Ну, в щелеронах регистры EAX, а не просто AX, как в твоей проге, и при вызове "полрегистра" всякий раз срабатывает автообнуление старших битов, что есмь опция/фича компилятора... А ежли не быто перекомпиляции под щелерон - то отбрасывание старших битов при вызове биос-функций, те-ж |
Сейчас на форуме |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 22:50 Сообщение отредактировано: 16 марта 2013 23:33
Fe-Restorator написал: Это не так. При обращении к AX в любом режиме старшее слово EAX остается неприкосновенным (как и старший байт AX при обращении к AL). и при вызове "полрегистра" всякий раз срабатывает автообнуление старших битов, что есмь опция/фича компилятора |
La Forge
Advanced Member
Lt. Cmdr. Откуда: Рязань Всего сообщений: 3248 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 нояб. 2012 |
Fe-Restorator учите матчась. Регистры EAX. EBX и т.д. появились в 386-м. И пень и селерон и вообще любой 32-х разрядный проц их содержит |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 23:33 Сообщение отредактировано: 17 марта 2013 8:59
La Forge, спорим, что не любой 32-разрядный . У меня есть ARM, но в нем нет EAX. По поводу матчасти: компьютеры и программы к ним стали настолько сложны, что невозможно быть компетентным во всех областях, как 30 лет назад. |
La Forge
Advanced Member
Lt. Cmdr. Откуда: Рязань Всего сообщений: 3248 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 нояб. 2012 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 16 марта 2013 23:51 Сообщение отредактировано: 16 марта 2013 23:54
АРМ это не процы, а так,выдри...ки. Паразитирующая архитектура живущая по принципу "у кого бы чего содрать?". И пусть сейчас их много...ну так жуков колорадских тоже много. И это временно. (я не про жуков ) Тут я только ЗА Только бы не смешивать в ходе диалога предположения и догадки с фактами |
Fe-Restorator |
NEW! Сообщение отправлено: 17 марта 2013 0:10 Сообщение отредактировано: 17 марта 2013 0:43
User 0 написал: Fe-Restorator написал: Это не так. При обращении к AX в любом режиме старшее слово EAX остается неприкосновенны Читай внимательнее: компилятора, а не проца! Проц тупой, автоматически почти ничего не умеет в плане подмены кода! Однако, на обнуление тратятся такты, например: XOR EAX,EAX, MOV EAX,1... Причём, сперва нужно привести конструкцию MOV AL,2 к виду MOV EAX,0002h!!! автообнуление старших битов, что есмь опция/фича компилятора... ЗЫ. Все мы, хором, отклонились от темы. ТС вопрошал, будет-ли код отличаться, и правильный ответ - будет, однозначно. Даже при оптимизации "под старый проц". Ибо по конструкции MOV EAX,0002h трудно определить, адресуется весь AX или только его половинка, AL/AH!!! Более того, компилятор уже заточен оперировать половинками EAX, т.е. целыми регистрами 8086, без деления на их половинки, и на 8088 такой код неоперабелен, на 60% минимум. Иными словами, у современных процов давно-уж нет "наследия 8086", в том виде, как сие утверждал ТС. Говорить, что i7 строго следует "архитектуре и принципам 8086" - неверно, принципиально! Современные процы поддерживают программирование "в стиле х8086", ценою потери 97% производительности всего компа. La Forge написал: Сделай сие смостоятельно, ОК? Листинг, приведённый ТС вообще EAX не содержит, об чём пляшет весь мой пост. Запроси его у ТС, зря он спрятал листинг под "требование через ЛС". Fe-Restorator учите матчась. И впредь, знай, где звон, прежде, чем его услышишь. |
Сейчас на форуме |
La Forge
Advanced Member
Lt. Cmdr. Откуда: Рязань Всего сообщений: 3248 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 нояб. 2012 |
Автор, текст проги в студию pls. Fe-Restorator, повежливее pls. |
DrPass
Advanced Member
Откуда: Донецк Всего сообщений: 3566 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 17 апр. 2005 |
Fe-Restorator написал: Компилятор ничего не обнуляет. А ассемблер - тем более. Если в тексте программы написано MOV AL, 2, процессору будет скормлено именно MOV AL, 2, а не MOV EAX,0002h. Процессор сам разберется, что с этим сделать. Читай внимательнее: компилятора, а не проца! Проц тупой, автоматически почти ничего не умеет в плане подмены кода! Однако, на обнуление тратятся такты, например: XOR EAX,EAX, MOV EAX,1... Причём, сперва нужно привести конструкцию MOV AL,2 к виду MOV EAX,0002h!!! Fe-Restorator написал: Операбелен на 100%. Код 8088 оперирует такими же 16-битными "половинками EAX", как и 8086. Он не зря вышел на год позже 8086, Интел этот год потратила на разработку контроллера шины 8088, который при обработке команд с 16-битными операндами делает два цикла обращения к памяти, вытаскивая оба байта и "склеивая" их в регистре в одно целое перед операцией, дабы программист не задумывался о том, что по факту работает с 8-битной машинкой. Более того, компилятор уже заточен оперировать половинками EAX, т.е. целыми регистрами 8086, без деления на их половинки, и на 8088 такой код неоперабелен, на 60% минимум Fe-Restorator написал: Чесслово, это ты тоже сам так домыслил, да? Или тогда уже напиши, где прочитал - я эту статью прокритикую Говорить, что i7 строго следует "архитектуре и принципам 8086" - неверно, принципиально! Современные процы поддерживают программирование "в стиле х8086", ценою потери 97% производительности всего компа. |
Tronix
Advanced Member
Откуда: Москва Всего сообщений: 1749 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 15 янв. 2008 |
Мне кажется, что Fe-Restorator чего-то не то курит. core i7 обычный представитель x86, и на нем спокойно запускается MS-DOS, потому что у него, как и у любого x86, есть Real Mode. И работает он в нем нативно, исполняя нативный 8086 код. Не спорю, вполне возможно в самом камне есть какие-то аппаратно-програмные прослойки, но это для нас не важно в принципе, так как он работает с нативным 8086 кодом на номинальной заявленной частоте. Вот если бы он выполнял 8086 код медленнее, чем его максимальная скорость - тогда да, можно было бы говорить что что-то здесь не так. А так - самый обычный x86. Что 386, что i7 - для real mode разницы нет ваще никакой. |
User 0
Junior Member
Откуда: Moscow Всего сообщений: 112 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 25 дек. 2007 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 17 марта 2013 9:19 Сообщение отредактировано: 17 марта 2013 23:20 Мы тут все время отклоняемся от темы. Программа лишь иллюстрировала разницу в скорости цикла на разных процессорах, это не имеет отношения к основному вопросу, который благодаря DrPass я считаю выясненным. |
La Forge
Advanced Member
Lt. Cmdr. Откуда: Рязань Всего сообщений: 3248 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 нояб. 2012 |
Ну насколько я помню ASM это обычная прога для 16-разрядного проца 8086-286. Но думаю она заработает и на I7 тоже |
<<Назад Вперед>> | Страницы: 1 2 3 4 | Печать |
Полигон-2 » Технический флейм » Самая большая legacy |
0 посетителей просмотрели эту тему за последние 15 минут |
В том числе: 0 гостей, 0 скрытых пользователей |
Последние | |
[Москва] LIQUID-Акция. Сливаются разъемы CF МС7004 и 7004А на AT и XT Пайка термотрубок Проммать s478 PEAK 715VL2-HT ( Full-Size SBC) Подскажите по 386 материке по джамперам. |
Самые активные 5 тем | |