Manipulating Arch specific code generator state

Hello all on the list,
I’m developing a backend for the 65816, however, I need a way to store some state, as processor flags can affect how instructions operate (including the length of some), as well as the calling convention. I need to track for each of these flags (x, m, and e) Set, Unset, Indeterminate. I was wondering if there was a nice way to store this with the MBB, so I can make sure everything does the right thing, and emit code to ensure the correct mode when necessary.

I am unfamiliar with that architecture and ISA, but quite a few architectures have a status register and flag setting/reading instructions. You can probably get inspiration from the X86, ARM or MIPS backends. Again, not entirely sure how your situation is different, but I guess you don’t want to store that in machineblocks because it is something that instructions produce/consume.

I am curious as to how keeping track of condition code values at compile time can be achieved when condition codes are only effected at execution time when real data is being processed. What possible changes can be made to the emitted code or printed asm when the actual condition code values aren’t known!!!

Its not a condition code (though its stored in the same register). There are three processor status flags, x and m. m is the machine data size and affects the size of the A register, values (including immediate values) loaded by the LDA instructions/stored by STA instructions, as well as the size of the value stored by the STZ instruction (simply stores zero), all between 1-byte when the flag is set, and 2-bytes when the flag is clear. The x flag is similar but affect the Y and X registers, and all load/store sizes (including immediate sizes for loads). There is also an emulation flag which switches into 6502 emulation mode (implying both flags), but would rarely be unknown or known to be set. There are two instruction that alters these flags (x and m), both with statically known values, and one (XCE) that can both check and alter the emulation flag to a statically known value after first explicitly setting or clearing the Carry Flag. The flags are never altered by any instruction except explicitly via SEP/REP or, in the case of the emulation flag, XCE).

The 65816 is generally a weird architecture doing weird stuff for backwards compatibility with the 6502.

I have seen this requirement come up before in other backend designs.

Secondly can you please let me know if this REPLY has gone to you directly or via the list. This list seems to operate a little differently to ones that I am use to and there doesn’t seem to be a reply option to go to the list.

It seems to have gone directly to myself and one other. I’ve manually corrected that