Чтение CF, PF, ZF, SF, OF

TL:DR: используйте ленивую оценку флага, см. ниже.

input - странное имя. Большинство ISA обновляют флаги на основе результата операции, а не входных данных. Вы смотрите на 16-битный результат 8-битной операции, что является интересным подходом. В C вы должны просто использовать unsigned int, что гарантированно будет как минимум uint16_t. Он будет компилироваться в лучший код на x86, где unsigned — 32-битный. 16-битные операции требуют дополнительного префикса и могут привести к замедлению частичного регистра.

Это может помочь с проблемой 8bx8b->16b mul, которую вы отметили, в зависимости от того, как вы хотите определить обновление флага для инструкции mul в архитектуре, которую вы эмулируете.

Я не думаю, что ваше обнаружение переполнения является правильным. См. это руководство по ссылке из x86 отметить вики, чтобы узнать, как это делается.

Это, вероятно, не будет компилироваться в очень быстрый код, особенно флаг четности. Нужна ли вам ISA, которую вы эмулируете/разрабатываете, с флагом четности? Вы никогда не говорили, что эмулируете x86, поэтому я предполагаю, что это какая-то игрушечная архитектура, которую вы разрабатываете сами.

Эффективный эмулятор (особенно тот, который должен поддерживать флаг четности), вероятно, много выиграет от некоторой отложенной оценки флага. Сохраните значение, из которого вы можете вычислить флаги, если это необходимо, но на самом деле ничего не вычисляйте, пока не дойдете до инструкции, которая считывает флаги. Большинство инструкций только записывают флаги, не читая их, и они просто сохраняют результат uint16_t в ваше архитектурное состояние. Инструкции по чтению флагов могут либо вычислить только тот флаг, который им нужен, из сохраненного uint16_t, либо вычислить их все и каким-то образом сохранить.

Предполагая, что вы не можете заставить компилятор фактически прочитать PF из результата, вы можете попробовать _mm_popcnt_u32((uint8_t)x) & 1. Или горизонтально XOR всех битов вместе:

x  = (x&0b00001111) ^ (x>>4)
x  = (x&0b00000011) ^ (x>>2)
PF = (x&0b00000001) ^ (x>>1)   // tweaking this to produce better asm is probably possible

Я сомневаюсь, что какой-либо из основных компиляторов может оптимизировать кучу проверок результата в LAHF + SETO al или PUSHF. Компиляторы могут быть введены в использование условия флага для обнаружения целочисленного переполнения, например, для реализации сложения с насыщением. Но понять, что вам нужны все флаги, и фактически использовать LAHF вместо серии инструкций setcc, вероятно, невозможно. Компилятору понадобится распознаватель шаблонов, когда он сможет использовать LAHF, и, вероятно, никто не реализовал его, потому что варианты использования исчезающе редки.

В C/C++ нет способа прямого доступа к результатам операции флага, что делает C плохим выбором для реализации чего-то подобного. IDK, если какие-либо другие языки имеют результаты флага, кроме asm.

Я ожидаю, что вы могли бы значительно повысить производительность, написав части эмуляции на ассемблере, но это будет зависеть от платформы. Что еще более важно, это намного больше работы.

Кажется, я решил проблему, разделив аргументы для обновления флагов на неподписанный и подписанный результат следующим образом:

void update_flags(int16_t unsigned_result, int16_t signed_result)
{
    Registers::flags.zero = unsigned_result == 0;
    Registers::flags.sign = signed_result < 0;
    Registers::flags.carry = unsigned_result < 0 || unsigned_result > UINT8_MAX;
    Registers::flags.overflow = signed_result < INT8_MIN || signed_result > INT8_MAX
}

Для добавления (которое должно давать правильный результат как для подписанных, так и для неподписанных входов) я бы сделал следующее:

int8_t a, b;
int16_t signed_result = int16_t(a) + int16_t(b);
int16_t unsigned_result = int16_t(uint8_t(a)) + int16_t(uint8_t(b));
update_flags(unsigned_result, signed_result);
int8_t c = a + b;

И знаковое умножение я бы сделал следующее:

int8_t a, b;
int16_t result = int16_t(a) * int16_t(b);
update_flags(result, result);
int8_t c = a * b;

И так далее для других операций, обновляющих флаги.

Примечание. Я предполагаю, что здесь расширяется знак int16_t(a), а расширяется ноль int16_t(uint8_t(a)).

Я также отказался от флага четности, мое решение _mm_popcnt_u32 должно работать, если я передумаю позже.

P.S. Спасибо всем, кто откликнулся, было очень полезно. Также, если кто-то может обнаружить какие-либо ошибки в моем коде, это будет оценено.