Четене на 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 tag wiki за това как се прави.

Това вероятно няма да се компилира до много бърз код, особено флага за паритет. Имате ли нужда 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.

Очаквам, че можете да спечелите много производителност, като напишете части от емулацията в 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. Благодаря на всички, които се отзоваха, беше много полезно. Също така, ако някой може да забележи грешки в моя код, ще бъда оценен.