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

Полигон-2

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

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

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

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

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

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

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


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


Ссылка


Дата регистрации на форуме:
25 дек. 2007
Fe-Restorator написал:
[q]
Т.е. программы запускаются без всякой перекомпиляции?
[/q]
Преобразование выполняется кросс-ассемблером в автоматическом режиме (а не процессором на лету). Насколько я понимаю, ассемблер берет исполняемый (или по крайней мере объектный) файл для 8080 и автоматически делает его совместимым с 8088/86.

Спасибо, DrPass, за разъяснения!
DrPass
Advanced Member


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


Ссылка


Дата регистрации на форуме:
17 апр. 2005
User 0 написал:
[q]
Насколько я понимаю, ассемблер берет двоичный файл и автоматически делает его совместимым с 8086.
[/q]
Верно. У 8086 с 8080 отличаются коды команд, но есть их "смысловое" соответствие. Т.е. можно просто пройтись по коду программы и подменить инструкции 8080 на инструкции 8086, и оно заработает. Так на 8086 переносились, к примеру, WordStar, часть кода CP/M и т.д.
User 0
Junior Member


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


Ссылка


Дата регистрации на форуме:
25 дек. 2007
А можно ли узнать Ваше мнение, DrPass
(если вернуться назад, во времена, когда еще не существовало Java/.NET), в какой мере элегантность программной модели процессора и языка ассемблера влияют на эффективность программирования, качество компиляторов, быстродействие и компактность программ? Верно ли хотя бы отчасти предположение, что программисты по причине чрезмерного неудобства ассемблера x86 при всякой возможности отказываются от низкоуровневого кодирования, передавая эту задачу компиляторам ЯВУ, и является ли этот фактор значимым в общей сумме факторов, отрицательно сказывающихся на качестве ПО (таких, как слишком сжатые сроки)?
DrPass
Advanced Member


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


Ссылка


Дата регистрации на форуме:
17 апр. 2005
User 0 написал:
[q]
в какой мере элегантность программной модели процессора и языка ассемблера влияют на эффективность программирования, качество компиляторов, быстродействие и компактность программ?
[/q]
На эффективность низкоуровневого программирования влияют очень сильно. К примеру, PDP-11 имела простую систему команд и адресацию. Программист PDP-11 обучался ассемблеру намного быстрее и проще, и в общем-то мог читать даже машинный код.
На быстродействие влияет, но косвенно. К примеру, размер программы для RISC-процессора (да и даже для приснопамятного 8080) будет раза в два-три компактнее, чем аналогичной по функционалу программы для x86, благодаря более коротким машинным командам без монстроидальных суффиксов адресации. А это значит, в два-три раза сокращается количество обращений к кэшу и к ОЗУ.
Про качество компиляторов можно было говорить в 80-е годы, сейчас, учитывая, что современные оптимизирующие компиляторы (и не очень современные) знают все особенности архитектур х86, это уже не принципиально.


User 0 написал:
[q]
Верно ли хотя бы отчасти предположение, что программисты по причине чрезмерного неудобства ассемблера x86 при всякой возможности отказываются от низкоуровневого кодирования, передавая эту задачу компиляторам ЯВУ
[/q]
Я не скажу, что ассемблер х86 создавал какие-то неудобства. Возможно, если бы я на него пересел после ассемблера DEC или Motorola, меня бы он раздражал. Но начиная учиться на х86, я всё это воспринимал как должное :)
Просто каким бы удобным ассемблер не был, все равно программа на С или Паскале пишется в разы проще и быстрее. А результат не настолько уступает ассемблерному по производительности, чтобы жертвовать временем разработки ради некоторой оптимизации. Пока вы пишете одну программу на ассемблере, программист на ЯВУ выпустит несколько программ и продаст их вашим клиентам. Математика простая.
Другое дело, что сейчас оно вообще зашло до маразма, когда для считывания пары цифр из файла параметров программист применяет многомегабайтный парсер XML с DOM-моделью. "Золотая середина" между качеством кода и производительностью разработки была где-то пройдена в 90-е годы.
La Forge
Advanced Member
Lt. Cmdr.

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


Ссылка


Дата регистрации на форуме:
16 нояб. 2012
DrPass написал:
[q]
Просто каким бы удобным ассемблер не был, все равно программа на С или Паскале пишется в разы проще и быстрее. А результат не настолько уступает ассемблерному по производительности, чтобы жертвовать временем разработки ради некоторой оптимизации. Пока вы пишете одну программу на ассемблере, программист на ЯВУ выпустит несколько программ и продаст их вашим клиентам. Математика простая.
[/q]
Правильно сказано! А если нужно все оптимально на каком-то участке программы, то в BP была директива assеmbler, и часть кода можно писать на нём. Теоретически всю программу. Delphi это унаследовал и поддерживал по крайней мере до 7-й версии. Наскольно я в курсе, то же самое и в BC
Кстати насколько я в курсе, 1-й процом от Intel выполнявшим не X86, а результат их декодирования был отнюдь не 386 а Pentium Pro
User 0
Junior Member


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


Ссылка


Дата регистрации на форуме:
25 дек. 2007
DrPass написал:
[q]
"Золотая середина" между качеством кода и производительностью разработки была где-то пройдена в 90-е годы.
[/q]
Значит, качество программ и условия труда были объективно лучше, и это одно из объяснений тому, почему люди хотят хотя бы мысленно оказаться в том времени. :)
DOS Logic
Advanced Member
d(-_-)b

Откуда: Украина. Ивано-Франковск
Всего сообщений: 4778
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
1 июля 2006
Кстати сказать в тему, первым процом который выполнял быстрее 32-х разрядные проги, а не 16, был пень про.

А на счет ассемблера и особенно циклов, зачем использовать loop? сделайте без него, свой цикл который использует метку, команды сравнения и команды inc/add, на то он и ассемблер чтобы шевелить мозгами :biggrin: Но сейчас это никому не нужно, как говорили выше, ассемблер это слишком долго в первую очередь.
La Forge
Advanced Member
Lt. Cmdr.

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


Ссылка


Дата регистрации на форуме:
16 нояб. 2012
На асм-е я прогфессионально не программил, но из институтского курса припоминается, что в принципе регистры на деле можно использовать любые и не по-прямому назначению. Например для счётцика циклов насколько я помню, обычно используестя CX, но вподе бы пользовали любые и препод говорил, что назначение конкретного - просто дань традиции
Fe-Restorator
Гость

Ссылка

DrPass написал:
[q]
Про качество компиляторов можно было говорить в 80-е годы, сейчас, учитывая, что современные оптимизирующие компиляторы (и не очень современные) знают все особенности архитектур х86, это уже не принципиально.
[/q]
К сожалению, ВСЕМ этим компиляторам требуется настройка на генерацию кода именно для старых процов, порой, гораздо более тонкая, чем "подсунуть нужный файл-конфигуратор". Этим грешат даже ассемблерные компиляторы, ибо они, по-умолчанию, оптимизированы под современное жезезо. Про компиляторы с ЯВУ и говорить нечего, все, поголовно забыли прежнее программирование, и наперебой пыжатся гнать код под i7, а не под 486! Назови хоть один ЯВУ-компилятор, помнящий процедурное программирование. В отличие от объектно~ и сервиисно~ ориентированного, применяющегося в современности! Оттого и объектный код под старый проц будет разным у современных и старых компиляторов.

DrPass написал:
[q]
Другое дело, что сейчас оно вообще зашло до маразма, когда для считывания пары цифр из файла параметров программист применяет многомегабайтный парсер XML с DOM-моделью. "Золотая середина" между качеством кода и производительностью разработки была где-то пройдена в 90-е годы.
[/q]
+1. С точки зрения сего дня, такая ситуация - пролное дерьмо. В отношении старых процов - 100%-ое.
Сейчас на форуме
DrPass
Advanced Member


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


Ссылка


Дата регистрации на форуме:
17 апр. 2005
Fe-Restorator написал:
[q]
Назови хоть один ЯВУ-компилятор, помнящий процедурное программирование
[/q]
Ну чего? M$ Visual C++ еще годится для процедурного, и Embarcadero Delphi все еще в строю.
С работой на старых процах действительно есть нюанс. Если ассемблеры еще имеют опции для генерации кода, бинарно совместимого со старыми процами, то современные компиляторы ЯВУ обычно не имеют. Это не так плохо, т.к. они благодаря использованию современных инструкций делают более компактный и шустрый код, но всё-таки...
Кстати, вот DOS Logic привел интересный пример оптимизации. Программист на ассемблере обычно знает инструкцию LOOP и использует ее. А компилятор при компиляции циклов возьмет регистр-счетчик и будет его декрементировать инструкцией DEC. Почему? А потому что так на самом деле быстрее, чем LOOP :) Или тот же самый цикл, допустим, от 0 до 100. Программист возьмет переменную (или регистр, если на ассемблере), присвоит ей значение 0 и будет увеличивать, сравнивая со значением 100 на каждой итерации. Компилятор сначала проверит, насколько в цикле важен порядок его следования, и если не важен, возьмет регистр, запишет туда 100 и будет уменьшать до 0. Потому что сравнение с 0 также намного быстрее, чем сравнение с константой. Поэтому сейчас есть забавный факт: компиляторы умнее среднего ассемблерщика.


La Forge написал:
[q]
На асм-е я прогфессионально не программил, но из институтского курса припоминается, что в принципе регистры на деле можно использовать любые и не по-прямому назначению. Например для счётцика циклов насколько я помню, обычно используестя CX, но вподе бы пользовали любые и препод говорил, что назначение конкретного - просто дань традиции
[/q]
Не все регистры, а регистры общего назначения. Их можно произвольно использовать в операциях работы с памятью, арифметики, сравнения, но при этом своя узкая специализация в ряде инструкций у них все же есть. Например, CX автоматически используется как счетчик в упомянутой выше LOOP и в строковых операциях, DX - единственный регистр, который может указывать номер порта для ввода-вывода, а BX можно использовать для косвенной адресации внутри текущего сегмента.
<<Назад  Вперед>> Страницы: 1 2 * 3 4
Печать
Полигон-2 »   Технический флейм »   Самая большая legacy
RSS

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

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

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