NEO SPECTRUMAN
05.04.2017, 20:53
Картинки кликабельны!!!
https://img-fotki.yandex.ru/get/196245/124968272.1/0_14ff9f_1eddc18a_XL.png (https://fotki.yandex.ru/next/users/speccyalist/album/534405/view/1376159?page=0)
https://img-fotki.yandex.ru/get/197923/124968272.1/0_14ffa0_b5468933_XL.png (https://fotki.yandex.ru/next/users/speccyalist/album/534405/view/1376160?page=0)
https://img-fotki.yandex.ru/get/244791/124968272.1/0_14ffa4_27a174d0_XL.jpg (https://fotki.yandex.ru/next/users/speccyalist/album/534405/view/1376164?page=0)
https://yadi.sk/i/v-_mBaN43Gh77U
https://yadi.sk/i/KrVZQs333Gh79Y
красным подписал количество тактов в правильности подсчета которых я не уверен
голубым помечены(и синим подписаны) те последние такты команд которые продолжают исполнятся во время выполнения уже следующих команд
и которые можно просто игнорировать... (см пункт 9 комментариев)
фиолетовым пометил все отсылки к комментариям
Разбирал таблицу и обнаружил некоторые неточности
judge condition и sp = sp - 1
занимают место 2-х тактов но не разделены по средине
если считать ее за 2
jp cc,addr должен выполнятся за 11 тактов
а не за 10 как во всех простых таблицах
Кто проверял на реальном железе?????
если посчитать за 1
то не будет совпадать время у
call cc,addr
ret cc
sp = sp - 1
тоже должен занимать 2 такта
для совпадения
call addr
rst x
push rp
halt расписан на 6 тактов
хотя по таблицам с простой растактовкой он 7
я так понимаю вся jp подобная группа
подменяет первые 2 такта следующей команды (они справа от 2-й таблицы)
тут есть свой t2 ???? которые может задетектить hold
получается условные jp\call-ы все равно читают адрес из памяти даже если условие не выполняется?
самое интересное что уже в самом 8080 появляются зачатки конвеерности
некоторые команды исполняются на самом деле на 2 такта дольше
а проц начинает читать следующую когда еще полностью не выполнилась предыдущая
вот по этому сложение и куча других операций быстрей чем простое копирование регистров...
https://img-fotki.yandex.ru/get/196245/124968272.1/0_14ff9f_1eddc18a_XL.png (https://fotki.yandex.ru/next/users/speccyalist/album/534405/view/1376159?page=0)
https://img-fotki.yandex.ru/get/197923/124968272.1/0_14ffa0_b5468933_XL.png (https://fotki.yandex.ru/next/users/speccyalist/album/534405/view/1376160?page=0)
https://img-fotki.yandex.ru/get/244791/124968272.1/0_14ffa4_27a174d0_XL.jpg (https://fotki.yandex.ru/next/users/speccyalist/album/534405/view/1376164?page=0)
https://yadi.sk/i/v-_mBaN43Gh77U
https://yadi.sk/i/KrVZQs333Gh79Y
красным подписал количество тактов в правильности подсчета которых я не уверен
голубым помечены(и синим подписаны) те последние такты команд которые продолжают исполнятся во время выполнения уже следующих команд
и которые можно просто игнорировать... (см пункт 9 комментариев)
фиолетовым пометил все отсылки к комментариям
Разбирал таблицу и обнаружил некоторые неточности
judge condition и sp = sp - 1
занимают место 2-х тактов но не разделены по средине
если считать ее за 2
jp cc,addr должен выполнятся за 11 тактов
а не за 10 как во всех простых таблицах
Кто проверял на реальном железе?????
если посчитать за 1
то не будет совпадать время у
call cc,addr
ret cc
sp = sp - 1
тоже должен занимать 2 такта
для совпадения
call addr
rst x
push rp
halt расписан на 6 тактов
хотя по таблицам с простой растактовкой он 7
я так понимаю вся jp подобная группа
подменяет первые 2 такта следующей команды (они справа от 2-й таблицы)
тут есть свой t2 ???? которые может задетектить hold
получается условные jp\call-ы все равно читают адрес из памяти даже если условие не выполняется?
самое интересное что уже в самом 8080 появляются зачатки конвеерности
некоторые команды исполняются на самом деле на 2 такта дольше
а проц начинает читать следующую когда еще полностью не выполнилась предыдущая
вот по этому сложение и куча других операций быстрей чем простое копирование регистров...