Идеология стандартизации развития принципов Z80 в HDL [Архив] - Speccy

ZEK

29.09.2008, 03:08

Вот думаю про сабж.

Из того что надумал. Вводим в процессор режим SMI (system managment interrupt) типа того что есть в x86 процах, ток немного с другим акцентом, скажем как режим супервизра в M86000.

Суть режима в следующем - в процессор вводится дополнительный контекст со своим набором регистров, вход в режим только аппаратно. В режиме юзера процессор 100% Z80, в режиме супервизора появляется 2 дополнительных регистра (верней по другому интерпретируются I,R) через которые можно читать и модифицировать все регистры юзерского режима + вводятся дополнительные регистры для отладки (адрес бряки, тип срабатывания и т.д. ).

В режиме супервизора останавливается счет инкремент регистра R и принудительно устанавливается режим IM1. А регистры I и R имтерпертируются как индекст для доступа к новым регистам и соответсвенно данные (как в AY).

Вход в режим супервизора будет всегда по адресу NMI, туда же будут срабатывать исключения от отладочных регистров.
Выход из режима SMI будет во инструкции RETN по адресу 64h

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

Зачем это все нужно?. Сложны вопрос :). Вообще в принципе что бы не юзать в FPGAшных проектах отдельные корки процов/mcu для реализации сервисных возможностей. К примеру там работа с FATxx, связь про USB с компом, "настоящий" аппаратный отладчик. И т.д.

С расширениями адресации проца добавкой разных там умножений/делений или расширением регистров пока не замарачивался так как не вижу смысла (в смысле не поддерживается никакими инструментальными средсвами), а то что выше изложенно можно с чистой совестью юзать скажем из под SDCC, да и что угодно в принципе.

NovaStorm

29.09.2008, 10:49

Если корка будет все равно в FPGA, то зачем там z80? Можно небось и получше что найти... И не под sdcc, а под gcc. Ересь, да? =)

ZEK

29.09.2008, 11:13

Да не, это для спектрума. Да и нафик нада ARM на 3МГц или что то в таком духе

Addison

29.09.2008, 14:56

Идеология стандартизации развития принципов Z80 в HDL
И ты туда же?:rolleyes:
Давай лучше придумаем, как какую-нибудь железку спаять;)

ZEK

29.09.2008, 16:07

Давай лучше придумаем, как какую-нибудь железку спаять
нафик паять. девборда наш президент

NovaStorm

29.09.2008, 16:08

>>как какую-нибудь железку спаять
Тупым, раскалённым...
>>Да не, это для спектрума
А для чего спеку проц, не совместимый на 100% с Z80? Отдельным MCU будет и проще и эффективнее, поскольку в нём уже всё есть.

ZEK

29.09.2008, 16:12

А для чего спеку проц, не совместимый на 100% с Z80? Отдельным MCU будет и проще и эффективнее, поскольку в нём уже всё есть.
Че не совместимый? просто процы все что больше Z80 пихать в FGPA неправильно.
В режиме юзера проц 100% (насколько позволяет корка) Z80, повторюс в SMI режим можно войти только аппаратно. Польза есть к примеру для отладчика непосредственно на железяке

Mad Killer/PG

06.10.2008, 20:40

В чём плюс напиши на человеческом(аля доступном) языке;-)

ZEK

06.10.2008, 20:53

Дебагер/загрузчик/ось/связь с писюком -невидимые для ZX софта (если нет необходимости в обратном) в изолированом адресном пространстве, к примеру TR-DOS работающая прозрачно для софта (не стучащегося напрямую к портам ВГ93) c файловой системой FAT на SD карте.

Barmaley_m

10.10.2008, 03:48

Я когда-то тоже думал на эту тему... Навесить на Z80 аппаратуру, которая позволяла бы реализовать на нем "защищенный режим".

При обращении к запрещенным областям памяти и в других исключительных ситуациях генерировалось бы NMI. При этом адрес возврата, который Z80 пытается сохранить в память, перехватывается аппаратурой и сохраняется "в надежном месте". Одновременно сохраняется содержимое регистров выбора страниц/сегментов памяти, принудительно включаются страницы/сегменты ядра ОСи и разрешается работа с привилегированной аппаратурой (которая во время работы "пользовательских приложений" запрещена).

Далее программа, размещенная по адресу 066H делает все остальное.

Возврат - аналогичным методом. Увидев, что процессор собирается исполнить инструкцию RETN, аппаратура включала бы нужные страницы памяти и подставляла вместо "содержимого стека" адрес возврата.

Компенсация регистра R легко осуществляется программно, поэтому тут ничего особо городить не надо. Принудительное включение IM 1 - аналогично - не нужно. На начальном этапе работы супервизора (ядра ОСи) прерывания все равно запрещены, а позже ядро может выяснить текущий режим IM, сохранить его, и программно включить нужный режим (если для работы ядра вообще требуются маскируемые прерывания).

Вызов супервизора в неисключительных ситуациях может осуществляться похожим образом, без NMI, но чтобы аппаратура следила за командой, которую выполняет проц. И при вызове RST 0, например, аналогично происходила бы замена страниц и разблокировка привилегированных портов.

Для реализации вышеописанной концепции не нужно менять существующий Z80, то есть все решается только довесом внешней аппаратуры (скорее всего, разумеется, FPGA).

ZEK

10.10.2008, 08:52

Я тож думал над таким вариантом. (и не только я, Conan к примеру тож излогал подобные мысли) Так что идея популярна :)

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

Но из плюсов что можно привентить к жлезному процу в реальном спектруме, но раз приходится юзать FPGA то можно и весь проц туда засунуть ;)

Регистры отладки при обвешивании проца снаружи тож создает проблеммы, некоторые решаемы и только посфактум, а некоторые - тока скальпелем по TV80.

К примеру нелься сделать внешними методами протейшую опрерацию в любом отладчике - останов и переход в процедуру обработки бряки. Когда видно адрес выборки и что идет непосредсвенно сама выборка, уже позно кидать NMI он обработается ток на следующей инструкции. Можно конечно что то программно-аппаратное в духе подзаточить STS но к примеру я не потяну, а другим оно нафик не нужно.

Barmaley_m

10.10.2008, 14:38

Засовывать весь проц в FPGA имеет смысл в случае, если в FPGA места вагон, и засунуть туда проц компактнее, чем ставить его отдельно. Ну или если он на FPGA быстрее будет работать, чем оригинал.

Почему ты считаешь, что не удастся восстановить полностью контекст процессора после NMI? Ты имеешь в виду флаги "IFF1" и "IFF2"? Это будет критично только для той программы, которая пользуется NMI для своей нормальной работы, а в стандартных схемах спека NMI не используется, следовательно никакая программа и не заметит ничего.

Я когда-то делал сам монитор-отладчик на "Орель БК-08", который пользовался NMI. Без внешней аппаратуры мне удалось добиться полного восстановления контекста, за исключением 4 байт на вершине стека. И огромная практика пользования этим монитором показала, что очень-очень редко не удавалось восстановить контекст. Ну то есть сбоя легко добиться, разместив стек на адресах ПЗУ например, но очень редко какая программа так работала. Потому что без стека скучно :)

Когда видно адрес выборки, то можно вместо той команды, которая должна была быть выбранной, подставить другую ("RST" - для непосредственного вызова отладчика, или NOP, а потом NMI). Потом скомпенсировать побочные эффекты программно (откатить на 1 PC и регистр R).

Какие еще существуют нерешаемые проблемы?

Я, конечно, не собираюсь все это реализовывать (надо, главным образом, много софта писать) - просто принципиальная возможность это сделать меня интересует :)

ZEK

10.10.2008, 15:56

Ты имеешь в виду флаги "IFF1" и "IFF2"? Это будет критично только для той программы, которая пользуется NMI для своей нормальной работы, а в стандартных схемах спека NMI не используется
Ну NMI используется где то больше геде то меньше. Есть 2 неиспользуемых бита в регистре флагов в которые попадает огрызки из внутренних буферных регистов. Целесообразность настолько сохранять контекст для меня в приципе тож загадка, но скажем потеря совместимости присуствовать будет.

Засовывать весь проц в FPGA имеет смысл в случае, если в FPGA места вагон, и засунуть туда проц компактнее, чем ставить его отдельно. Ну или если он на FPGA быстрее будет работать, чем оригинал.
Ну я изночально за проц в FPGA веду речь. Тоесть в какую сторону расширять его возможности, из тех которые могут быть полезными.

Когда видно адрес выборки, то можно вместо той команды, которая должна была быть выбранной, подставить другую ("RST" - для непосредственного вызова отладчика, или NOP, а потом NMI).
Согласен. Если заниматься отключение проца от шины принципе можно стопать и обращения к памяти). Но например останов по значению регистра уже будет некоторую проблемму составлять.

Но это все огород необходимый для железного проца, для HDL корки можно боле простыми путями пойти. Я пытаюсь расматривать сабж именно со стороны что оно изначально будет жить в FPGA достаточной емкости. И я в принципе вижу основное требование - сохранение совместимости на том уровне на котором она щас.

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

Barmaley_m

10.10.2008, 18:40

Ну NMI используется где то больше геде то меньше. Есть 2 неиспользуемых бита в регистре флагов в которые попадает огрызки из внутренних буферных регистов. Целесообразность настолько сохранять контекст для меня в приципе тож загадка, но скажем потеря совместимости присуствовать будет.

По-моему эти два бита проблемы для NMI не представляют. Первые команды обработчика:
LD (save_sp),SP
LD SP,isr_sp
PUSH AF
...
Насколько я знаю, такое сохранение контекста не портит никаких флагов, в том числе двух "огрызков". Или я ошибаюсь?

Согласен. Если заниматься отключение проца от шины принципе можно стопать и обращения к памяти). Но например останов по значению регистра уже будет некоторую проблемму составлять.

Это да. Однако останов по обращению к памяти, по записи в память определенного числа по определ. адресу; по выборке определенной команды и тому подобные вещи делаются легко. На этом фоне мне кажется, что останов по регистру не может радикально улучшить положение.

Повторяю: даже на простом NMI без аппаратных наворотов, вроде тех, что мы обсуждаем, я виртуозно ломал чужие проги и налаживал свои. Загвоздка сегодня именно в желании писать проги на Z80 (включая чудо-отладчик), а не в чем-либо другом.

Но это все огород необходимый для железного проца, для HDL корки можно боле простыми путями пойти. Я пытаюсь расматривать сабж именно со стороны что оно изначально будет жить в FPGA достаточной емкости. И я в принципе вижу основное требование - сохранение совместимости на том уровне на котором она щас.

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

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

А вообще - почему бы не назвать твой проект "внутрисхемный эмулятор Z80"?

Скромно и со вкусом :)

ZEK

10.10.2008, 19:19

Насколько я знаю, такое сохранение контекста не портит никаких флагов, в том числе двух "огрызков". Или я ошибаюсь?
Интересный вопрос, учитывая что туда попадают огрызки внутреннего регистра адреса параметов. Вот и будет что потестить.

Повторяю: даже на простом NMI без аппаратных наворотов, вроде тех, что мы обсуждаем, я виртуозно ломал чужие проги и налаживал свои.
Я понял и идея мне предельно ясна.

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

Создал тему как раз для упорядовачивания своего потока мыслей (в смысле что бы попинали те кто видит недостатки), а так навыдуманное не обязательно будет правильно, и я могу просто из за ограниченых знаний не учесть или не знать каких то важных моментов.

Цели приследуемая при модификации корки следующие:
- возможность ставить трапы в области прошивок (к прмеру чтене сектора в TR-DOS)
- возможность выгружать спековскую програму остановленную в любой момент на карту с возможностью потом востанавливать (снапшоты фактически)
- отзываться на jtag, сюда входит ответная часть отладчика, загрузка чтение снапов.
- должно быть что то в духе бивиса управляющие конфигурацие девайса (к примеру выводить на экран спековской раскладки клавы по нажатию на F1 :) ).
- еще что то непомню (значит неважно)

В принципе все пункты реализовать по предложеной тобой варианту с NMI. На так как изначально HDL то можно писать "внутрисхемный эмулятор Z80". Но с обязательным условием не теряя совместимость ниже имеющейся.

Black_Cat

10.10.2008, 23:37

Я думаю, лучше сразу забыть про возможности какой-либо стандартизации. Ты и я - слишком мелкие фигуры, чтобы именно по нашим рекомендациям кто-то принял стандарт. Если кто-то еще захочет сделать нечто подобное - он вряд ли будет стремиться достичь совместимости с нашей поделкой. Потому что от этого не будет большой выгоды.Насамделе стандарт - эт не обязательно верх оптимальности, скорее уж верх компромиссности решений :) , к тому-же есть сугубо исторически сложившиеся стандарты, которые вообще говоря отбалдывозникшие :) . Дык что не боги горшки лепят, как слепите - так и будет стандарт :) .
..конечно лепить нужно с умом и по возможности по науке :) , тоды мож и насамделе "стандарт" в высоком понимании получится :)

А вообще - почему бы не назвать твой проект "внутрисхемный эмулятор Z80"?

Скромно и со вкусом:) насчёт "Идеологии стандартизации бла-бла-бла" эт heroy простебался, типо спародировал меня :) . Хотя насамделе ни про идеологию, ни про стандартизацию у него ничего сказано небыло. Но вот по этому поводу было-бы тож очень интересно услышать ваши мысли :) . То использование, что изначально предложил heroy - это разумное, но весьма частное решение на уровне концепции, в котором собсно идеология как направление развития z80 просматривается весьма туманно.

Цели приследуемая при модификации корки следующие:
- возможность ставить трапы в области прошивок (к прмеру чтене сектора в TR-DOS)
- возможность выгружать спековскую програму остановленную в любой момент на карту с возможностью потом востанавливать (снапшоты фактически)
- отзываться на jtag, сюда входит ответная часть отладчика, загрузка чтение снапов.
- должно быть что то в духе бивиса управляющие конфигурацие девайса (к примеру выводить на экран спековской раскладки клавы по нажатию на F1
Тут уже более чётко видно какие есть идеи по направлению развития, хотя и фрагментарно. heroy, мож ты бы поделился в более-менее формализованном виде идеями, как по твоему должен развиваться z80, чтоб можно было в комплексе представить себе задачу?

ZEK

11.10.2008, 00:35

насчёт "Идеологии стандартизации бла-бла-бла" эт heroy простебался, типо спародировал меня
Над Клон. :)

heroy, мож ты бы поделился в более-менее формализованном виде идеями, как по твоему должен развиваться z80
Z80 это тока часть головоломки (но чуть ли не самая главная). Это просто результат декомпозиции задачи (возможно неверный).

Я хачю так - запустил CodeBlocks нажал откомпилить Сишный код (sdcc), сделал джобик маленький что бы после компиляции консольная тулса залила результат в плату где типа вертится спектрум, на стороне спека ответная часть умеет пережевывать запросы и команды со стороны песюка. Понаставил бряк и они срабатывают, поколупался в переменных (которые могут в момент бряка быть как в регистре так и в памяти, это уже головная боль gdb), понял где я протормозил и т.д.

Или как альтернатива сижу в программулине, нажал на клаве ESC и попал в дебагер как в анриле. Что проще будет это уже когда конкретно дойду до моментов реализации видно будет, или может кто то посоветует.

Скромненько со вкусом, сомневаюсь что даже половину осилю :) Поэтому пытаюсь заюзать по максимуму готовое (sdcc, gdb, CodeBlocks, корки).

Хорошо что есть в природе люди которым тож такой экстрим подуше и они помогают.

Barmaley_m

13.10.2008, 20:44

Все ясно, дорогие товарищи.

Говоря о "внутрисхемном эмуляторе Z80", я имел в виду не столько название, сколько назначение, функциональность данного прибора. То есть по техническим требованиям, высказанных Heroy (аппаратные точки останова, JTAG и т.п.) виден классический набор требований к внутрисхемному эмулятору (ICE - In-circuit emulator - http://en.wikipedia.org/wiki/In-circuit_emulator)

Внутрисхемные эмуляторы не преследуют цели "развить" архитектуру процессора, который эмулируют. Вместо этого они всего лишь предоставляют РАЗРАБОТЧИКУ (не пользователю) ПО для данной архитектуры возможности отладки.

И если сформулировать главную задачу таким образом - не РАЗВИВАТЬ Z80, а сделать для Z80 внутрисхемный эмулятор (который представляет собой Z80 + отладочные регистры и т.д.) - то это будет правильнее. Для внутрисхемных эмуляторов не существует конкретных стандартов. Как сделаешь - так и будет. Лишь бы была совместимость отладочного харда и софта, которая в конечном счете позволяла бы разработчику эффективно вести наладку своих программ.

ZEK

13.10.2008, 21:06

GdbServer местами работает. Короче маленька консольная утилитка которая выполняет роль посредника между USB-JTAG и TCP стеком (удаленная отладка). Пишется не так что бы сложно

Начала копать с отсюда http://crossplatform.ru/?q=node/129#SEC110 и до победной

alexfreed

17.10.2008, 13:00

Меня всегда мало интересовала идеология и концепции, по крайней мере в электронике, а интересовали практические решения. Но раз уже зашел разговор в этой теме о том о чем я сейчас задумался, то надо тут и обсуждать.

Как я написал я почти довел до ума Спек на DE1 с поддрежкой ResiDOS.
К моему удивлению большого интереса не вызвало, но наверное у всех у кого есть DE1 есть и возможность грузить программы.
Так или иначе загрузка 128К SNA не работает и хочется понять почему, даже если никому не надо. Поскольку нет даже нормального монитора, я задумался о добавлении ICE к своей игрушке. Прикрутил JTAG для чтения/записи памяти и отладочных регистров. А теперь надо все это соединять с (soft) Z80.
Пока я обдумываю как лучше это сделать. Уверен что многие на этом форуме имеют намного больше опыта отладки на Спеке, поскольку у меня такого опыта нет совсем. Но зато я знаю как удобно отлаживать через (JTAG) debug interface программы на процессорах которые такой интерфейс имеют. Например AVR.

Остановить CPU по заданному условию очень легко. Сделать один шаг тоже. Но надо уметь читать регистры. Можно конечно в лоб подключиться ко всем регистрам железными средствами, но это громоздко. Поэтому думаю так:
при срабатывании break-point на шину выдается FF. Адрес пишется в стек и z80 прыгает на 38h. В это время нижний банк заменяется на BRAM - встроенную память в FPGA. Там код который сохраняет все регистры в тот же блок памяти (его легко читать через JTAG) и ждет команды продолжить. Соответственно выполняется RETN с одновременным возвратом банка памяти. Можно проверять что SP показывает куда надо
до форсирования RST38, но это почти всегда будет так.
Еще полезно последние n адресов, данных и т.д. писать в кольцевой буффер.
Есть лучше предложения? Кто нибуть хочет поучаствовать?

ZEK

17.10.2008, 15:44

Всеравно нада будет доделывать некоторые залипухи в TV80 к примеру что бы по чтению операнда из памяти останавливаться (можно сделать залипуху что бы до конца не выполнялся машинный цикл и не происходила перезапись внутренних регистров)

поучаствовать готов естественно :)

Barmaley_m

05.11.2008, 21:54

Alexfreed - есть еще такая вещь, как "In-circuit debugger", который и реализуется отчасти программно. У фирмы Microchip такие есть - почитай про него, может почерпнешь ряд полезных идей.

Я недавно пользовался их MPLAB ICD 2 для отладки своих прог. В принципе работает, но довольно тормозно: когда делаешь программе 1 шаг, то на это требуется секунд 10 реального времени, чтобы отладчик прочитал все данные из памяти отлаживаемого проца. Пошаговое выполнение в таких условиях имеет мало практического смысла; я почти исключительно пользуюсь только точками останова. Однако такие вещи поддаются оптимизации. И вообще полезны!

alexfreed

06.11.2008, 01:42

Alexfreed - есть еще такая вещь, как "In-circuit debugger", который и реализуется отчасти программно. У фирмы Microchip такие есть - почитай про него, может почерпнешь ряд полезных идей.

Да, есть такие вещи. Кроме MPLAB есть еще ATmel AVR Studio. И много других. И есть настоящие ICE (In-Circuit Emulator). Там вместо настоящего процессора вставляется специальный с дополнительным каналом связи с хостом и т.д.
Я с ними со всеми работал с начала 90х, так что с концепцией знаком.

Надо 2 части - железо и программа на хосте. Железо я делать люблю, а программы писать - не очень. А поскольку похоже никому это не надо, то наверное и делать не стану.

Mick

19.04.2009, 12:12

Кстати, а почему собственно не рассматривается вопрос о расширении самого ядра Z80 на 16 битную разрядность данных. Скажем оставим совместимость работы в 8 битном режиме и еще добавить некоторые команды для работы с 16 битными данными. Ведь по сути - это будет очередной виток в развитии Спека. Проц можно реалаизовать на ПЛИС, чтобы идеология компа не нарушалась. Зато графика сразу может прыгнуть на новый уровень и т.д.
Какие мысли по поводу.

Black_Cat

19.04.2009, 12:36

добавить некоторые команды для работы с 16 битными данными. Ведь по сути - это будет очередной виток в развитии Спека.имхо потому и не рассматривается, что нет смысла. Это будет ни с чем не совместимое нечто, к которому надо с нуля писать весь софт.. А смысл? Если проще взять любую существующую 16/32.. etc платформу уже с кучей софта.. и это будет ни чуть не хуже написания с нуля всего софта для несуществующего процессора.. а перезагрузка в FPGA новой платформы занимает пару секунд..

В Z80 можно, и даже нужно влезть внутрь, но отнюдь не для того чтоб изобретать новый процессор..

Mick

19.04.2009, 14:52

имхо потому и не рассматривается, что нет смысла. Это будет ни с чем не совместимое нечто, к которому надо с нуля писать весь софт.. А смысл? Если проще взять любую существующую 16/32.. etc платформу уже с кучей софта.. и это будет ни чуть не хуже написания с нуля всего софта для несуществующего процессора.. а перезагрузка в FPGA новой платформы занимает пару секунд..

В Z80 можно, и даже нужно влезть внутрь, но отнюдь не для того чтоб изобретать новый процессор..

Я не говорил о новом проце, если ты читал внимательно - то вопрос стоял о расширении существующего. И программы не надо переделывать.
Для примера у 8086 был собрат с 8 битной шиной 8088. Ведь софт никто не переделывал. А тут собственно наоборот - есть z80 с 8 битами, вот немного архитектуру его изменить - упс и 16 битный. Для того чтобы воспользоваться преимуществами полноценных 16 бит ввести новые команды которые этип преимущества подчеркивали. Так что старые проги не надо переделывать. Но появится возможность для полноценных Си и Паскаль компиляторов, потому как многим сейчас на асме лень программить.

Black_Cat

19.04.2009, 16:09

у 8086 был собрат с 8 битной шиной 8088. Ведь софт никто не переделывалвообще-то это один и тот же процессор, только с мультиплексированной шиной данных :)
А тут собственно наоборот - есть z80 с 8 битами, вот немного архитектуру его изменить - упс и 16 битныйв том-то и дело, что разница между 8ми битным и 16ти битным, это разница между 8080 и 8086/88, а не между 8086/88! А это уже совсем другой процессор. Имхо проще и грамотней использовать например 8086/88 в качестве сопроцессора, чем изобретать весь софт с нуля для несуществующего процессора. Но опять же - а зачем это нужно в рамках Спековской архитектуры?

Totem

25.12.2016, 01:00

AzAtom

27.12.2016, 12:58

Да, было бы неплохо заиметь z80 с дополнительными командами для 16 и 32 битной обработки, с 32 битной шиной данных и частотой 66-266 МГц. Тогда все старые программы будут работать со старыми командами, только быстрее, а новые могут использовать новые команды.
Ещё можно добавить команды умножения/деления. Это будет огромный шаг вперёд.
Вот только проблему с 16 битной адресацией так легко не решить.

bigral

30.12.2016, 05:10

Предлагаю эту тему признать ересью раз и навсегда, потому как проц в fpga это вообще никакой не ZX уже, а то что снаружи проца можно налепить в виде какого-нибудь КР1802ВР2 то уже не проц а аксель. Уже давно есть Z80 на 20mhz который перекрывает по скорости все чипы что в ZX клонах когда-либо применялись, его должно хватить всем.

AzAtom

30.12.2016, 09:36

Этот путь IBM уже прошла, результат не фонтан: Куча режимов для совместимости со старыми программами с кучей лишних элементов, зато всё равно совместимость крайне ограничена - максимум на 1-2 поколение назад.

Выход только один. Делать новый комп с новым процессором с новыми возможностями: 24-32-48 разрядная шина адреса, 16-32-64 разрядная шина данных и такие же команды, улучшенные аппаратные копиры (как LDIR, но без повторного чтения команды каждый раз), аппаратные блоки умножения, деления, тригонометрических функций.

Совместимость с оригинальным (старым) ZX Spectrum можно обеспечить банальным эмулятором, встроенным в ядро новой ОС.

Error404

30.12.2016, 12:59

Я не говорил о новом проце, если ты читал внимательно - то вопрос стоял о расширении существующего. И программы не надо переделывать.
Для примера у 8086 был собрат с 8 битной шиной 8088. Ведь софт никто не переделывал. А тут собственно наоборот - есть z80 с 8 битами, вот немного архитектуру его изменить - упс и 16 битный. Для того чтобы воспользоваться преимуществами полноценных 16 бит ввести новые команды которые этип преимущества подчеркивали. Так что старые проги не надо переделывать. Но появится возможность для полноценных Си и Паскаль компиляторов, потому как многим сейчас на асме лень программить.

Зерно истины тут есть - Z80 дичайше не хватает математики высокой разрядности, хотя бы целочисленной 32bit (сгруппировав регистры по аналогии с 16-битными регистровыми парами) , математики функционально полной - с сложением, умножением и всеми флагами сравнения (а не как у 8080/Z80 с его 16битными мат. возможностями, где для половины флагов в тех операциях нет обработки и надо городить проверки на 8-битных половинках), опционально в качестве приятных излишеств добавить ММU, но не такой бесполезный как у Z180, а позволяющий городить что-то многозадачное с защитой. При этом менять разрядность ШД проца (с 8 до более бит) или прямо адресуемой адресной шины (т.е. ранее ММU) до более 16 бит, стало бы уже не так важно, ибо компактность кода компиляторов (хоть асм, хоть С/Паскаля) и так уже стала бы лучше в разы, а скорость работы программ возросла в разы т.к. отпала бы надобность "городить огород" в коде при обработке int и long.

Сравните на досуге насколько просто выглядит компилированный С-код где используется только 8-битная математика, и как быстро он работает. Точно также стала бы работать и 16/32-битная на новых командах, и, к примеру, FatFS стала бы компилироваться не в 20килобайт, а в 5кб, и работать в десятеро быстрее чем как сейчас на подпрограммах. А ведь таких библиотек под портирование с "больших машин" - море разливанное, бери и используй (тот же TCP/IP, нормальные реализации которого не лезут в убогую 8-битную математику 8080/Z80).

Эти очевидные вещи почему-то не очевидны для разработчиков ЦПУ той поры. Их бы в порядке порки заставлять под свои поделия писать код посерьезнее моргания светодиодом, вот тогда бы и мысли развивались в рациональном направлении, а не с потолка. :)

- - - Добавлено - - -

Предлагаю эту тему признать ересью раз и навсегда, потому как проц в fpga это вообще никакой не ZX уже, а то что снаружи проца можно налепить в виде какого-нибудь КР1802ВР2 то уже не проц а аксель. Уже давно есть Z80 на 20mhz который перекрывает по скорости все чипы что в ZX клонах когда-либо применялись, его должно хватить всем.

хоть 20 хоть 120 Мгц-овые процы Z80 не могут выполнить 65кб сплошного кода из-за того что если код реально сложен математически, то он получается очень рыхлым, фактически весь с разложением на 8-битных регистрах многоитеративными циклами. Элементарный awk 1979 года, даже странслированный без float (только int) самым эффективным C-компилером Z80 получается на выходе в 80кб. Повышение компактности кода важнее всех прочих доработок проца: накой мне супербыстрый проц если на нем ничего сложнее супертетриса не запустишь?

Hacker VBI

30.12.2016, 13:34

"процы Z80 не могут выполнить 65кб сплошного кода. "
?
могут

SaNchez

30.12.2016, 14:18

Нда... Не могу понять, вот нафига z80 математика нужна, что за блажь?... Сделайте 120Mhz классический Z80, будет всем счастье;)

- - - Добавлено - - -

Нафига на z80 вообще Си нужен? z80 мнемоники уже по сути Си.

bigral

30.12.2016, 15:17

Элементарный awk 1979 года, даже странслированный без float (только int) самым эффективным C-компилером Z80 получается на выходе в 80кб. Повышение компактности кода важнее всех прочих доработок проца: накой мне супербыстрый проц если на нем ничего сложнее супертетриса не запустишь?

Ну это ж неконструктивный разговор вообще пошел. Тут тема о чуде юде трехголовом и трехватном в современной fpga, который занимал бы места стоко же скоко и NIOS2\MicroBlaze. Т.е. карикатура на Z80.

То что не компилится awk это проблема отсутствия linker-loader-а с поддержкой оверлеев, на том же pdp11 и unix7 он был написан? (который 28kW адресного пространства использует) .

Error404

30.12.2016, 17:46

"процы Z80 не могут выполнить 65кб сплошного кода. "
?
могут

невладение предметом? лишь бы поспорить?

- - - Добавлено - - -

Ну это ж неконструктивный разговор вообще пошел. Тут тема о чуде юде трехголовом и трехватном в современной fpga, который занимал бы места стоко же скоко и NIOS2\MicroBlaze. Т.е. карикатура на Z80.

То что не компилится awk это проблема отсутствия linker-loader-а с поддержкой оверлеев, на том же pdp11 и unix7 он был написан? (который 28kW адресного пространства использует) .

да, тот самый awk с Юникса V7. Оверлеи явно не добавят скорости, я полдюжины команд арифметики добавят, как и убавят размер кода. Хотя безусловно, тот поезд уже ушел, и предлагаемый тут непрограммирующими гражданами ФПГА-технопрон приводить в чувство смысла нет.

SaNchez

30.12.2016, 17:48

невладение предметом? лишь бы поспорить?

Чиво? :v2_jawdr:

SaNchez

01.01.2017, 14:18

хоть 20 хоть 120 Мгц-овые процы Z80 не могут выполнить 65кб сплошного кода из-за того что если код реально сложен математически, то он получается очень рыхлым, фактически весь с разложением на 8-битных регистрах многоитеративными циклами.

Как говорит Ступа:
http://cs4.pikabu.ru/images/previews_comm/2015-05_3/14315411053282.jpg

Error404

01.01.2017, 23:09

уймись уже, пионэр. Накатил чтоле? :)

Hacker VBI

02.01.2017, 12:20

Error404, смотри. ты всё это знаешь, я уверен.

максимальное адресное пространство памяти - 65535 байта.
каждый байт для процессора выглядит как.. 8 бит.
проц достал значение, засунул в себя и перемолол, обработал, выполнил что-то, неважно что.
а учитывая то что память закольцована, то проц выполняет бесконечное количество инструкций.
понятно ли я говорю?

рыхлость, сложность, итерации и прочее - это отмазки "программистов" :)

AzAtom

02.01.2017, 12:46

Для начала расскажите начинающему, что значит "сплошной код" и почему процессор не может его выполнить, если он весь будет доступен? Предвижу вычитание АП ПЗУ и АП той же видеопамяти, но это же не значит, что процессор не может?

SaNchez

02.01.2017, 16:18

Боюсь, что тебе этого никто не расскажет;) Это из разряда единорогов и прочего астрала:D

- - - Добавлено - - -

Хотя, кажется, я понял. Наверняка имелся ввиду исходник на каком-нибудь Си.

- - - Добавлено - - -

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

AzAtom

02.01.2017, 16:44

Программа на Си это не код процессора, поэтому, рассматривать такой исходник просто нет смысла, Ассемблер тоже.

SaNchez

02.01.2017, 16:49

И я про то-же.

Hacker VBI

02.01.2017, 18:59

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

короче. 65535 нопов - это нормально для нашего процессора. он не останавливается и будет выполнять.
еррор) это 404 ;)
рыхлый код, пухлый, овальный, *****-код, другой код - это уровень программиста, а не особенность именно этого процессора :)

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

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