Кодерский уголок

A.P.$lasH, без обид. И долго и много. Проще просто делать "как все, не выделываясь".

Но, если интересно, просто вспомни фактический механизм выполнения команды JMP по схеме. И всё сразу станет ясно.

 

Да какие обиды, я просто разницы не вижу. Если ты в курсе кардинальных отличий двух вариантов задержки, направь хотя бы в сторону подходящего параграфа в мануале. У меня открыто руководство по 386-му и я в упор не вижу, в чём отличия 15-тактового джампа от пяти 3-тактовых NOP'ов.

Фразу, которую ты цитируешь, я в сети тоже не вижу. Вероятно, не там ищу.

По какой схеме? Алгоритм в руководстве расписан, он у меня перед глазами. Всё равно не вижу большой разницы.

Где посмотреть и на что обратить внимание?

---------- Сообщение добавлено в 22:16 ---------- Предыдущее сообщение размещено в 21:45 ----------

http://computer-programming-forum.com/46-asm/d1e3fdd0cfb588d5.htm (по ссылке чуть больше подробностей)

http://computer-programming-forum.com/46-asm/3492a112e1590b0e.htm

Пока всё, что нашёл по теме

 

по схеме процессора, десу.

повторю: дело не в задержке и даже не в тактах.
Суть сводится к тому, что при джампе изменяются CS:IP со всеми вытекающими из этого нюансами, которые и решают.

"Agreement when programming in Assembly language". Входило в поставку оригинальных IBM.

Помнится кто то мне сказал, что не сотрудничает с Википедией...
Я не отвечаю за материалы, которые есть или которых нет в сети.

 

Понятно.

 

Ну например, при вводе/выводе в порты видеоадаптера никто и никогда не ставил никаких задержек. На любых процессорах.

 

В том числе и благодаря вашим ответам на мои глупые вопросы, у The Elder Scrolls: Arena только что появилась поддержка SID!

 

Вот и я так помню. Потому и стало интересно.

Всё, что удалось найти, говорит о том, что на редких системах (преимущественно, до 386) нужно было подождать несколько тактов, пока порт получит информацию и проблемы могли возникнуть, если запись идёт последовательно в один и тот же порт с очень маленькими интервалами.

Вон, у Geryon'a в примере, хоть и в один и тот же порт пишется, а всё равно минимум 15 тактов между отправкой.

Ну и раз такое дело, можно было хоть на константу поделить, всё равно достаточно бы времени прошло. Почему "дело не в задержке и не в тактах", я не понимаю, но поищу. Жаль, что это так сложно объяснить.

 

Не можешь. Порты разные, но устройство-то одно и то же и ему всё равно надо успеть всё обработать.

Таки нет. На ЕМНИП до 486-го JMP срывает конвейеризацию (а чем выше проц, тем длиннее у него конвейер и, сответственно, тем больше будет задержка - и не в тактах проца, а в циклах памяти). А NOP'ы пролетают со свистом по нескольку штук за такт.
А вот предсказание ветвления может всю эту малину изгадить. :-( Поэтому я в таих случаях делаю работу с портами отдельной функцией - насколько я в курсе, процы ещё не умеют предсказывать ветвление на CALL-RET.

---------- Сообщение добавлено в 12:51 ---------- Предыдущее сообщение размещено в 12:46 ----------

В конвейеризации. JMP/CALL/RET заставляет проц сбросить уже нащёлканный конвейер и начать его заново с нового места - начитать с ОЗУ в кэш, с кэша в конвейер... в общем, не скоро ещё у проца дойдут руки до 15-тактового JMP'а. :-)

---------- Сообщение добавлено в 12:55 ---------- Предыдущее сообщение размещено в 12:51 ----------

А не один фиг? Устройство получило свой байт команды и пошло обрабатывать, проц тем временем делает свою работу... Или имеешь в виду, что проц может успеть изгадить байт в AL после OUT'а раньше, чем байт уйдёт в порт, т.е. байт уйдёт уже изгаженным? Не знал про такое.

 

Рыжий Тигра, ну тоже не только это... но вот зачем рассказал ? Испортил человеку часть удовольствия заценить всё самому.

С Call чуток всё сложнее из-за стека. Зато можно очень прикольные вещи делать !

теперь знаешь Ну, ладно - почти бинго. Теперь осталось только догадаться почему такое может случиться и как именно.

Но там возможны весчи и почуднее. А если ещё и устройство спроектировано оригинально...

 

Не думаю. :-) Вот если б отсутствие JMP $+2 гарантированно приводило к глюку, тогда да. А поскольку оно таки вероятностно (тем более под dosbox'ом с его игрищами типа динамической компиляции), то вылезать будет слишком редко и в слишком разных местах, чтобы доставить удовольствие возможностью покопаться; более того, может подвигнуть на ИМХО наихудший вид правок - шаманство (типа "а если выйти и снова войти? а если покрасить в синий цвет?").

---------- Сообщение добавлено в 13:02 ---------- Предыдущее сообщение размещено в 13:01 ----------

В смысле - предсказание ветвлений уже и до CALL'а добралось? :-(

---------- Сообщение добавлено в 13:09 ---------- Предыдущее сообщение размещено в 13:02 ----------

А-аа, ключевым был не OUT, а IN. Тогда всё просто: на спроектированном левой ногой устройстве, вместо выставлять сигнал готовности операции ввода-вывода после фактического завершения приёма/передачи, этот сигнал тупо запаян в положение "всегда готов". :-( Видел такую фигню на самопальном PCIE-FPGA-устройстве: разработчик пожадничал купить у Xilinx'а готовую мегафункцию и разработал сам, а в описание стандарта не вчитался. А я как раз к этому девайсу лабал драйвер. С месяц разбирались - что за хрень, почему вместо одного прерывания приходит всегда два...

 

Рыжий Тигра, да вот кривизна DB и всплыла... впрочем и других эмулей тоже, видимо. Всё что разработано в них - работает только в них. На реальных железках может быть и так и этак.

Ненене ! Я пока что не буду подсказывать. Самое интересное ещё впереди. Хотя всё, что бы его найти простым размышлением уже сказано. Надо просто вспомнить всё, что умеет процессор.

отлично ! Это один из вариантов с внешними устройствами. Теперь поглядим внутрь компа.

 

Вот! Наконец-то программист пришёл. Спасибо.

Этот момент я вчера изучал. Что интересно, в официальной доке от Intel прямым текстом сказано, что начиная с 486-го jmp $+2 в этом качестве работать не будет. Но в обсуждении нарисовался человек, который пытается доказать, что это не так, что и в 486-м всё примерно так и работает.

http://computer-programming-forum.com/46-asm/515da73f8afa6d74.htm

Доказывает он это таким кодом (я перевёл в MASM, исходник выглядит чуть иначе

Код:

        mov cx,040
        clc
        ;mov b[>L1+3],6
        ;jmp $+2

        L1:
        db 0f,0ba,0e1,0

        exit:           ;set break point here.
        mov ax,04c00
        int 021

):

Код:

        .radix  16
        .model  tiny

        .data

msg     db      "OK!", 0d, 0a, '$'

        .code
        org     100
start:
        mov     cx, 040
        clc
        mov     byte ptr [L1+3], 6
        jmp     $ + 2

L1:
        db      0f, 0ba, 0e1, 0
        jnc     exit

        mov     dx, offset msg
        mov     ah, 9
        int     21

exit:                                   ; set break point here
        mov     ax, 4c00
        int     21
        end     start

Он пишет, что без jmp $ + 2 BT по-прежнему проверяет нулевой бит, а не шестой и, само собой, флаг переноса не устанавливается. А вот с ней происходит обновление очереди. Собственно, для того её в самомодифицирующемся коде и используют. У меня это не работает (проверяется 6-й, хоть с джампом, хоть без), но я и не на 486-м запускаю, проверить негде

И потом, я ведь специально уточнил - "видимо, можно было и просто поделить, раз дело лишь в величине задержки". Из твоих слов следует, что сброс очереди предпочтительнее из-за длительности, я правильно понимаю?

К сожалению, Bato-San изъясняется образами и подмигиваниями.

Наконец, вот:

 

Ага, дошло. В пентюхах и выше конвейер сам чистится при модификации уже всосанного в конвейер, в более ранних - нет. Т.е. не работают основанные на измерениях длины конвейера методы определения типа проца, ну да хрен с ними - есть и ещё методы; но самое паскудное: летят к чёрту основанные на том же принципе защиты от отладки, а они как раз в играх под 286 и 386 были весьма популярны, - механизм защиты блокирует работу игры. Вот заразы! :-(

Хм? Не уловил - не будет работать что именно? Это ты про вот это?

Ну дык правильной работы OUT'а со стороны проца - мало. Надо, чтобы ещё и устройство, которому пнули байт, до следующего IN'а или OUT'а успело среагировать на предыдущий, а пока не - чтобы блокировало следующую операцию (или хотя бы позволяло выяснить его состояние, чтобы блокировать программно). Например, знаменитый креативовский SB16 ничего не блокировал и не сигналил, потому и приходилось тянуть резину через JMP +2, а то и несколько подряд. :-(

Конечно.

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

"Я знаю." (L) Ж.-Б.-Э. Зорг :-(

---------- Сообщение добавлено в 17:52 ---------- Предыдущее сообщение размещено в 17:39 ----------

Таки да. Динамическая, мать её, компиляция. :-( А всё потому, что intel'овские процы нарушают критерий Попека-Гольдберга, т.е. железно правильно сымитировать интеловский проц на интеловском проце можно только программной эмуляцией каждой команды, т.е. с замедлением на несколько порядков.
(хихикает) Между прочим, я переехал на процы от интела прямо с ЕСовского Ряда-3,который Попеку-Гольдбергу таки соответствует, - лично лет 25 назад под СВМ ЕС на виртуальной машине запускал вторичный СВМ и под ним на "вторичной" ВМ генерировал резидентный том. А несколько раз даже с него и грузился, получая таим манером уже "третичные" виртуальные машины, - идея была именно замедлить работу (не помню уже на кой), но фиг там - больше десятка процентов тормозухи выжать так и не удалось. :-(

Достал. :-( Не хочешь делиться - держи язык за зубами, не можешь держать - делись! "По-моему, так!" (L)

 

Джамп. Вот, всё из того же источника:

i486 Microprocessor Data Sheet
6.3.1 WRITE BUFFERS AND I/O CYCLES

Хотя в теме товарищ доказывает, что и на 486 джамп всё ещё нужен (тем самым исходником, который я выше приводил).

Я тогда понять не могу, как же оно проверяет, что "I/O write actually completes on the external bus". До какого момента тогда "internal execution stops" на 486-м (и, судя по всему, выше).

 

Если я правильно понял, речь про то, что код уже во внутреннем кэше и заново вычитываться процом из ОЗУ не будет, т.е. резина потянется JMP'ом недостаточно для полноценной задержки.

Ну дык там другой случай - надо не резину потянуть, а конвейер перечитать, а из ОЗУ или из кэша - не один ли фиг.

До получения готовности от адресата. Шина приняла байт от проца, передала в ус-во, подождала с него сигнал готовности, выставила готовность процу и проц побежал дальше.
А про то, что сигнал готовности с устройства - фальшивый (тупо запаян на "да-да, я всегда готов"), ни шина, ни проц не знают. Разработчик устройства схалтурил - логично рассудил, что пока проц отелится передать что-то ещё, устройство всяко успеет прожевать ранее переданное. Но оказался морально не готов к тому, что за десяток лет скорострельность процов выросла на три порядка. :-(

 

A.P.$lasH, Ну, у Тигры, ладно, нетерпение взыграло, судя по воплям странным, хотя мог бы уже и сам сказать всё - просто "за деревьями леса не видит".

А вот ты уже вплотную подобрался к решению загадки, задал правильный вопрос в конце (на который сейчас неправильно ответит Тигра), но слегка неправильно понимаешь цитату про 386 и 486 проц. Там не совсем то имели ввиду.

ЗЫ. С праздником Победы вас, ребята !

 

Ты помнишь, как в "Гостье из будущего" пираты планировали захват дома Юли Грибковой? Что там Весельчак ответил по поводу институтов?

https://www.youtube.com/watch?v=gTMkiOp2Qrc#t=3266

 

A.P.$lasH, а спорим - в самый интересный момент, когда мы дружно скажем "Сдаёмсууу!", Bato-San сделает вид что потерял интерес к теме и больше никогда не заикнётся? :-)

 

Рыжий Тигра, не пытайся купить победу так дёшево ! Но, чувствуя, что у вас уже терпение на исходе - подскажу. Вот когда ты про конвейер говоришь ты забываешь о чистом 8086 и о том, что там это как то было некритично. Но, что то там такое могло произойти, что следующий OUT мог и не выполниться вовремя или вообще.

Предположим, что есть устройство с одним портом, которое жрёт команду, а следом данные. Притом, если данные не прилетают после команды через определённое время, устройство начинает трактовать следующую запись, как команду.

 

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