SwapSet

[Dart Alver]

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

Частенько перегруженная чем-либо "ненаивная" непрямолинейная реализация кода становится непонятна ни программисту, ни процессору. ))

А я и не утверждал того что мой метод прыгнул выше головы, и о каких то его преимуществах перед обычным ассемблером. Да это ассемблер, но это еще и API для расширенных операций, отсутствующих в стандартной архитектуре z80.

API для расширенных операций звучит конечно гордо, но по факту это будет обычный вызов подпрограммы либо встраивание куска кода через макрос. Необходимость менять весь сет регистров здесь прослеживается скорее почти никогда, да и подстановка push/pop макросом тоже вполне себе работает.

Я исследую, может ли такой подход упростить разработку больших проектов на Z80.
Если у вас есть идеи, как его улучшить или где он мог бы быть действительно полезен — буду благодарен за советы!

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

1. Изолированные функции
Каждая функция получает свой собственный контекст.
Это как «песочница» — туда кладём аргументы через сеттеры, переключаемся SwitchContext, выполняем код, возвращаемся, забираем результат через геттеры.
никаких push/pop, чистый вызов
функция не портит caller

Вытягивать все процедуры ассемблера в песочницу нерационально, падение производительности на вызовах колоссальное, плюс лишняя забивка памяти сетами и оболочками вызовов . Максимум несколько действительно нужных функций со своими наборами регистров, и даже в них будут появляться промежуточные результаты которые придётся либо кидать на стек, либо на ячейки памяти. Кроме того при работе с включенными прерываниями нужно следить чтоб свапинг не словил прерывание. Проще всего это делать, если вызывать свапинг после халта, либо использовать иные методы тайминга, например как Alone предлагал. А без прерываний... счас если что и пишется, то игрушки или изредка демки, где без AY совсем грустно ))

2. Многозадачность
Если в сет добавить ещё PC и SP, он превращается в полноценный TCB (Task Control Block).
Тогда SwitchContext становится ядром планировщика.
можно реализовать кооперативную или вытесняющую многозадачность
любая задача живёт в своём сете

Подвижки в принципе возможны, но тут первый вопрос а что многозадачить ? Когда на него отвечаем, то второй опять с обработкой прерываний. ))

3. Объекты и структуры
Сет можно рассматривать как объект, где есть «поля» (ячейки под регистры) и «методы» (геттеры/сеттеры, макросы).
геттеры/сеттеры заменяют push/pop и позволяют адресовать регистры произвольно а не LIFO.
Тут необязательно даже переключаться в контекст. Можно работать с чужим объектом напрямую,
считывать и записывать значения другого сета.

Правильнее сказать что адресация по структуре данных объекта через (ix+n) позволяет адресоваться к ячейкам памяти произвольно, а уж как работает с ними объект- загружает как сет регистров или вытягивает по одной как переменную (и далеко не факт что сетом регистров эффективнее будет), это вопрос уже конкретных условий реализации.