Конечно, возможно. Не вы первый, кому эта идея пришла в голову. Я думал о подобной надстройке еще в 1995-96 годах где-то. Тогда еще ФПГА массово не использовались - думал делать логику на ЛА3 и РТ4.
Основной довод "против" уже высказал Jerri: сделать подобную аппаратную довеску несложно. Ну, месяц потрудишься - и получится в конце концов. Но проблема ведь не в аппаратуре. Проблема в софте, которого под эту конфигурацию нет. На создание софта уйдет значительно больше человеко-часов, чем на создание аппаратной части. У вас есть столько времени и желания писать софт? А если нет у вас лично - может кого-нибудь знаете, у кого есть?
С тем же успехом можно заменить Z80 каким-нибудь 32-битным процессором. И все, проблемы с адресацией уйдут. Почему никто этого не делает? А если кто и делает, то такие компы уже не назваются "Спектрумами"? В чем тут принципиальная разница - взять совершенно другой проц или оставить прежний, но приделать к нему кучу костылей? Для программистов-то между этими двумя вещами разницы нет. Старые программы не смогут поддерживать новые возможности.
Тогда уж лучше сделать аппаратный ускоритель блочной пересылки или, еще лучше, - блиттер, как на Амиге, который обрабатывает прямоугольные блоки. Ведь LDI и LDIR жутко медленные. Даже если составить последовательность чтения-записи памяти на шине Z80 из трехтактовых циклов, т.е. минимального времени, за которое Z80 может обратиться к памяти, то получится 6 тактов на пересылку байта - против 16 для LDI или 21 для LDIR.
Сочувствую. Я видел и хорошие примеры использования рекурсии, и сам ее иногда использовал с большой эффективностью.
Рекурсия иногда нужна. Как и любой другой инструмент, она занимает свое место в мастерской программиста. При использовании ее по назначению все прекрасно - и у программиста, и у компьютера. Стек не переполняется. А не по назначению - это как гвозди забивать микроскопом. Конечно, получается фиаско.
Почему это? Что ты предлагаешь делать, если нужен временный массив на 60 (или даже 6000) килобайт? malloc? Так это же неэффективно. Работа менеджера кучи сложнее, чем стека, и впоследствии возможна фрагментация памяти. Для подобных применений стек лучше.





Ответить с цитированием