Флаги процессора

Ну, пересылай через ecx и делай jecxz.

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

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

Слишком сложно получается, K.I.S.S.

Ничего не изменилось бы. Доказано примером ARM, где любая команда имеет возможность влиять на флаги.

О, хорошая идея. Пожалуй, если бы писал на x86 ассемблере, то использовал этот трюк. Но речь веду о ПЛИС и «доморощенном» ассемблере.

Итого получились следующие варианты:

1. Отказаться от идеи и оставить как есть.

2. Поменять семантику MOV, позволив ей рулить флагом/флагами.

3. Добавить новую форму инструкции MOV, которая будет менять флаги.

4.Добавить инструкцию, которая будет одновременно делать проверку на ноль и переход (по аналогии с JECXZ).

Но тут другая проблема - проверить число на ноль при выборке данных не стоит ничего, в то время как проверка и переход в один такт не поместятся, если нет конвейера и внеочередного исполнения.

Спасибо. Мне важен каждый ответ. Вариант условной установки флагов в зависимости от направления пересылки мне тоже не нравился

Кстати, как это реализовано в ARM? Т.е. инструкции могут менять или не менять флаги?

Да, в командном слове под это отведён специальный бит.

Но речь веду о ПЛИС и «доморощенном» ассемблере.

Если не секрет, зачем? Почему бы просто не взять Nios II или MicroBlaze?

ты свой свободный проц делаешь, чтобы собрать на нём доверенный компилятор?

1) частичное изменение флагов это плохо
2) сам факт изменения флагов - лишняя зависимость, т.е. нельзя спарить схожие инструкции

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

А в «чужом» решении сложно что-то менять. Отсутствие компилятора это огромное неудобство, но он компенсируется возможностью самому пройтись по всем граблям и, по возможности, переделать устройство.

Спасибо за замечание. Чаша перевесилась в пользу новой инструкции - аналогу MOV, которая управляет флагами нуля и переноса. Перенос установится если число отрицательное.

Круто! :) На каком HDL пишешь?
Задача - это поток/процесс или что-то типа Future?

Отсутствие компилятора это огромное неудобство

Ну тут есть два решения. Одно - покопаться в LLVM. Он модульный, есть кое-какая документация, так что можно просто написать только кодогенератор, а остальное будет уже готовое. Второе - написать интерпретатор какого-нибудь простого языка, хотя с другой стороны писать парсеры-лексеры на ассемблере - это слишком хардкорно :)

Пишу на Verilog, но при необходимости могу вставить в проект чужой код на VHDL. :)

В настоящее время - «Задача» это поток. В будущем может быть и потоком, и процессом. Но это в далёком будущем, когда появится поддержка адресных пространств и страничной памяти. Не совсем страничной, а на основе «универсальных страниц виртуальной памяти». Т.е. страницы памяти в традиционных архитектурах это лишь частный случай универсальных страниц.

Кстати, вопрос решил вот таким образом - http://everest.l4os.ru/0xd0_second_edition/