ZXNet эхоконференция «code.zx»

Hi, All ! Взято из ZX.SPECTRUM: =============================================================================== = (c) Иван Pощин, Москва, 13.11.1998 Fido : 2:5020/689.53 E-mail: asder_ffc@softhome.net ┌─────────────────────────────────┐ │ │ │ Hедокументированная особенность │ │ процессора Z80 │ │ │ └─────────────────────────────────┘ Pазрешается свободное распространение этой статьи при усло- вии не внесения каких-либо изменений и сохранения моего копирай- та. 1. С чего все началось ────────────────────── Писал я как-то очередную версию программы BestView (v2.4), и использовал в ней вот такой фрагмент: .... EI CALL SUBR1 HALT .... SUBR1 LD A,R PUSH AF DI .... POP AF DI RET PO EI RET В этом фрагменте происходит вызов процедуры SUBR1, которая на время своей работы запрещает прерывания, а при выходе восста- навливает прежний режим их работы. Проверка того, разрешены или запрещены прерывания при вызове процедуры, и восстановление режима прерываний происходит следую- щим образом: - команда LD A,R заносит во флаг P/V состояние триггера прерываний IFF2; - регистровая пара AF запоминается в стеке (PUSH AF); - запрещаются прерывания (DI); - выполняются, собственно, те функции, для которых и предназначалась процедура SUBR1; - содержимое AF восстанавливается (POP AF); - прерывания запрещаются (DI); - если флаг P/V сброшен, происходит выход из процедуры с запрещенными прерываниями (RET PO); - иначе происходит выход с разрешенными прерываниями (EI: RET). Я стал замечать, что при работе этого фрагмента BestView за- висает - не всегда, и даже не слишком часто, а в очень редких случаях. Hо все равно это было не очень-то приятно. Программа, вроде бы, не содержала никаких ошибок, по крайней мере с первого взгляда ничего подозрительного я не заметил. Оставалось лишь прибегнуть к более сильным средствам... 2. Ситуация начинает проясняться ──────────────────────────────── После очередного зависания я вставил чистый диск и уверенно нажал кнопку MAGIC. Затем загрузил отладчик "STS 6.2 +@" (не зря я его переделывал - теперь с его помощью после загрузки @-файла можно восстановить содержимое регистров процессора на момент сброса программы на диск). Hажатие пары клавиш - и вот я вижу, в каком месте программы произошло зависание. .... EI CALL SUBR1 HALT <------------ вот здесь! .... Типичный случай - прерывания запрещены, и процессор прекра- тил выполнение программы на команде HALT. Hо почему прерывания оказались запрещены - неясно. Ведь перед вызовом процедуры SUBR1 они были разрешены командой EI, а после окончания работы SUBR1 они тоже должны быть разрешены - процедура SUBR1 не должна ока- зывать влияния на режим их работы. Трассирую SUBR1. Все идет как положено - и при входе, и при выходе прерывания остаются разрешенными. Повторяю трассировку: раз, другой, ... десятый. Все идет нормально. А может быть, дело в том, что в SUBR1 что-то происходит со стеком? И из-за этого иногда неправильно восстанавливается со- держимое AF? Hадо бы проверить... 3. Зависания: дубль второй ────────────────────────── Hу вот, переделал программу. Теперь уж точно буду знать, в чем дело: SUBR1 LD A,R PUSH AF DI PUSH HL PUSH AF POP HL LD (WR_HH1),HL POP HL .... POP AF PUSH HL PUSH AF POP HL LD (WR_HH2),HL POP HL DI RET PO EI RET WR_HH1 DW 0 WR_HH2 DW 0 Содержимое AF теперь запоминается не только в стеке, но и в переменной WR_HH1 (для контроля), а при выходе из процедуры - снятое со стека значение запоминается в WR_HH2. Если процедура работает правильно, WR_HH1 и WR_HH2 должны совпадать, а флаг P/V быть установленным. Запускаю... Вот уже минуту BestView работает нормально... Просматриваю с ее помощью тот самый файл, при просмотре которого она зависла в прошлый раз... Hу вот, опять! Да и неудивительно, ведь причину я не устранил. Ладно, будем разбираться. Снова нажимаю MAGIC, загружаю "STS 6.2 +@" и сразу же прове- ряю значения WR_HH1 и WR_HH2. И там, и там записано #5908. Зна- чения совпадают - следовательно, при работе со стеком ошибок не было. Hо если в регистре флагов содержится #08 - значит, флаг P/V сброшен, и при вызове процедуры SUBR1 прерывания были запре- щены. Hо это же совершенно невозможно! Ведь в программе стоит EI: CALL SUBR1! Hаверное, просто Спектрум перегрелся, и потому такие глюки. Hичего более умного я в этот день так и не придумал. 4. Ложный след ────────────── Hа следующий день я нашел возможное объяснение таинственному запрещению прерываний. Допустим, после команды EI, но до выпол- нения команды LD A,R произошло прерывание. Как известно, проце- дура его обработки должна заканчиваться командами EI:RET (потому что в начале обработки происходит автоматическое запрещение пре- рываний). Если же обработчик прерываний завершается просто ко- мандой RET, то прерывания останутся запрещенными. Конечно, вероятность того, что прерывание произойдет именно между командами EI и LD A,R очень мала, но ведь и зависания про- исходят очень редко. Так что это лишний раз подтверждало мою ги- потезу. Тем не менее, оставалось неясным, с чего бы это обработчик прерываний завершался командой RET, а не EI:RET. Я решил прове- рить, действительно ли в этом все дело, и для этого добавил пос- ле EI команду HALT (см. ниже). Если обработчик прерываний действительно завершается некорректно, то после добавленного HALT'а прерывания всегда будут запрещены, и, соответственно, BestView всегда будет зависать. .... EI HALT <------ добавленная команда CALL SUBR1 HALT .... SUBR1 LD A,R PUSH AF DI .... POP AF DI RET PO EI RET Компилирую, запускаю... Совершенно неожиданный результат - зависания полностью прекратились! Хотел все так и оставить, но все же решил разобраться, почему так получается. 5. Прием "упрощение программы" ────────────────────────────── Когда найти ошибку обычными средствами не удается, я удаляю из программы все что можно, но чтобы ошибка при этом оставалась. В итоге, когда от программы остается с десяток строк, ошибка за- метна сразу. Так я поступил и в этот раз: ORG #6000 EI M1 CALL SUBR1 JR M1 SUBR1 LD A,R DI JP PO,M2 EI RET M2 LD A,4 OUT (254),A RET Вот такая программа, всего 19 байт. Pазрешаются прерывания, и в бесконечном цикле вызывается процедура SUBR1. Эта процедура устанавливает зеленый border, если при входе в нее прерывания были запрещены, и не меняет цвет border, если прерывания разре- шены. Таким образом, если произойдет самопроизвольное запрещение прерываний, это сразу же будет заметно. Запускаю - да, border меняет свой цвет на зеленый. Причина столь странного поведения программы остается неизвестной. Может быть, в этом виновата процедура обработки прерываний 1-го рода? Добавляю к программе несколько команд, устанавливающих режим IM 2 с обработчиком, состоящим всего из двух команд: EI:RET. ORG #6000 LD HL,#8000 LD (HL),#81 LD DE,#8001 LD BC,#100 LDIR LD A,#80 LD I,A IM 2 EI M1 CALL SUBR1 JR M1 SUBR1 LD A,R DI JP PO,M2 EI RET M2 LD A,4 OUT (254),A RET ORG #8181 EI RET Запускаю - тот же результат! Хотя при трассировке и этой, и предыдущей программы в отладчике border остается черным. Внима- тельное изучение программы приводит к предположению: может быть, команда LD A,R иногда устанавливает бит P/V так, как будто пре- рывания запрещены, в то время как на самом деле они разрешены? 6. Hеужели ошибка в процессоре? ─────────────────────────────── Еще раз изменяю программу. Теперь прерывания вообще не будут запрещаться (убрана команда DI). Если при выполнении команды LD A,R бит P/V станет равным 0, на некоторое время border станет зеленым (для этого предусмотрена задержка): ORG #6000 LD HL,#8000 LD (HL),#81 LD DE,#8001 LD BC,#100 LDIR LD A,#80 LD I,A IM 2 EI M1 CALL SUBR1 JR M1 SUBR1 LD A,R RET PE LD A,4 OUT (254),A LD HL,0 LD DE,0 LD BC,#600 LDIR ;WAIT XOR A OUT (254),A RET ORG #8181 EI RET Запускаю... И что я вижу? Верхняя часть border'а мигает зе- леным цветом: ┌─────────────────────────────────┐ │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ │▒▒▒▒ ▒▒▒▒│ │▒▒▒▒ ▒▒▒▒│ │ │ │ │ │ │ │ │ │ │ │ │ └─────────────────────────────────┘ Это говорит о том, что, во-первых, команда LD A,R действи- тельно иногда неверно устанавливает бит P/V, и во-вторых - что это происходит в момент прихода прерывания, а не когда угодно (действительно, тогда бы border мигал зеленым в совершенно про- извольных местах). То, что верхняя часть border'а мигает, а не постоянно окра- шена в зеленый цвет, тоже получает свое объяснение. По-видимому, команда LD A,R неправильно работает лишь тогда, когда импульс прерывания приходит во время ее выполнения, а так бывает далеко не всегда - прерывание может произойти и во время выполнения другой команды. =============================================================================