Очевидной причиной моих проблем (а их было три) было то, что оптимизатор C вырезал код, потому что не знал, что код сборки оказал какое-либо влияние на определенные переменные.
(Мои примеры кода относятся кЭмулятор процессора 6809/6309)
Я кратко изложу три вопроса.
Кажется, что инструкция по сборке rcl НЕ устанавливает флаг переноса.
(Задокументировано в этом посте)
Код сборки будет работать в 100-1000 раз медленнее, когда код C был скомпилирован с оптимизацией.
(Пример невозможен)
Для того, чтобы код вообще работал, необходимо замаскировать определенный код.
Следующий код:
static void(*JmpVec1[256])(void) = { ... };
...
unsigned char memByte = MemRead8(PC_REG++);
JmpVec1[memByte](); // Execute instruction pointed to by byte @ PC_REG
CycleCounter += instcycl1[memByte]; // Add instruction cycles
Будет работать только в том случае, если будет использован следующий код:
static void(*JmpVec1[256])(void) = { ... };
...
unsigned char memByte = MemRead8(PC_REG++);
if (memByte == 0x34) // Just doesn't like instruction 0x34 Pushs register_list
{
JmpVec1[memByte](); // Execute instruction pointed to by PC_REG
}
else
{
JmpVec1[memByte](); // Execute instruction pointed to by PC_REG
}
CycleCounter += instcycl1[memByte]; // Add instruction cycles
Поскольку код C не имеет представления о том, что выполняет какая-либо из эмулированных инструкций 437 или какие последствия имеют эти инструкции, почему он выбрал инструкцию 0x34, чтобы прекратить работузагадка.
Что решило проблему и позволило мне удалить обфусцированный код и позволило снова включить оптимизацию C, сделало переменную CycleCounter (int) volatile.
Исправлены все мои проблемы !!!
Эта проблема была еще более усугублена, поскольку в vscode нет поддержки разборки, что делает отладку процедур сборки чрезвычайно трудной.
Если кто-то использует хорошую IDE C / Assembly в Linux, оставьте комментарий.