Вроде, все аппаратные прерывания должны в дизассемблере "отмечаться", но в целом - это единственное объяснение, как после RTI может не измениться SP.
Вид для печати
Вроде, все аппаратные прерывания должны в дизассемблере "отмечаться", но в целом - это единственное объяснение, как после RTI может не измениться SP.
К примеру такой вариант (просто с потолка) - при возврате из эмулятора в PSW выставился бит T, в 14 естественно 0 -> .EXIT/HRESETЦитата:
Сообщение от Patron
Продублирую еще раз, а то оказалось в конце предыдущей страницы.
Понял из-за чего это происходит. Взгляните на это кусок кода:
Сами два аргумента ложаться в стек, но не по SP, а по R2. Естественно возникающий TRAP10 ложит туда прерванный PC и PSW. Но п/п исполнения FIS естественно его благополучно затирает. Сами команды FIS стек не используют, а вот здесь получается вот так не очень хорошо.Код:013544 [000004]: MOV SP, R2 ; R6 :000772 -> R2
013546 [000000]: MOV #16384., -(R2) ; 013550:040000 -> 000770
013552 [000000]: CLR -(R2) ; 000766:013536
013554 [000004]: MOV #16384., -(R2) ; 013556:040000 -> 000764
013560 [000000]: CLR -(R2) ; 000762:010520
013562 [000004]: 075002 - Команда не опознана.
Это получается то для чего оно и предназначено - чтобы проверить что трап был. Тут не должно проблем быть - просто он все-равно должен бы обнаружить отсутствие FIS несмотря на эмулятор.Цитата:
Сообщение от Alex_K
---------- Post added at 03:40 ---------- Previous post was at 03:36 ----------
А нет. Все точно - эмулятор-то потрет именно стек :)
А вот проблемы и есть. Объясняю. Команды FIS в качестве указателя используют адрес двух смежных аргументов. Соответственно в стек по R2 ложаться аргументы A и B. Далее команда FIS вызывает прерывание и аргумент B затирается. Но ничего об этом не зная, программа эмуляции складывает два аргумента A и B и ложит результат на место аргумента B, где вообще то находится адрес возврата и затирает его. Вот что-то так.Цитата:
Сообщение от form
Уже написал выше. Правильная работа эмулятора честно трет стек :)Цитата:
Сообщение от Alex_K
---------- Post added at 03:41 ---------- Previous post was at 03:41 ----------
Нужно проверять в нем такой случай и отпускать на самотек.
Ну что поделать, не могли авторы предусмотреть такой случай. И главное ничего не поделаешь.Цитата:
Сообщение от form
Ну так теперь выяснили - можно поправить драйвер :)Цитата:
Сообщение от Alex_K
Сэмулировать наличие FIS тут уже не получится - остается сделать вид, что его нету (как оно и есть на самом деле).
Кто-то у нас явно гений..
Код:PC[127032] PSW[351] SP[000746] 0766[135656] : BIC #15., 18.(SP) ; 127034:000017 -> 000770:000772
PC[127040] PSW[341] SP[000746] 0766[135656] : BIS R5, 18.(SP) ; R5 :000010 -> 000770:000760
PC[127044] PSW[341] SP[000746] 0766[135656] : MOV (SP)+, 12.(SP) ; 000746:130232 -> 000762
PC[127050] PSW[351] SP[000750] 0766[135656] : MOV (SP)+, R0 ; 000750:004430 -> R0
PC[127052] PSW[341] SP[000752] 0766[135656] : MOV (SP)+, R1 ; 000752:000003 -> R1
PC[127054] PSW[341] SP[000754] 0766[135656] : MOV (SP)+, R2 ; 000754:000766 -> R2
PC[127056] PSW[341] SP[000756] 0766[135656] : MOV (SP)+, R3 ; 000756:105061 -> R3
PC[127060] PSW[351] SP[000760] 0766[135656] : MOV (SP)+, R4 ; 000760:010520 -> R4
PC[127062] PSW[341] SP[000762] 0766[135656] : MOV (SP)+, R5 ; 000762:135656 -> R5
PC[127064] PSW[351] SP[000764] 0766[135656] : RETURN ; 000764:130232 -> R7
PC[130232] PSW[351] SP[000766] 0766[135656] : RTI
#############
TrapTo(014)
#############
PC[000000] PSW[000] SP[000766] 0766[135656] : BIC R0, R0 ; R0 :004430 -> R0 :004430
Ну это побочное явление. Суть в том, что эмулятор честно вычисляет результат, но по условиям вызова, кладется он на место адреса возврата и PSW (а за счет порчи PSW и получается trap 14).Цитата:
Сообщение от Patron
---------- Post added at 03:47 ---------- Previous post was at 03:46 ----------
То есть надо в эмуляторе проверять что регистр конфликтует со стеком и в случае такого плевать на эмуляцию.