connor horman via llvm-dev
2020-Mar-09 12:31 UTC
[llvm-dev] 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200309/736a0e49/attachment.html>
Sjoerd Meijer via llvm-dev
2020-Mar-09 21:18 UTC
[llvm-dev] Manipulating Arch specific code generator state
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. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of connor horman via llvm-dev <llvm-dev at lists.llvm.org> Sent: 09 March 2020 12:31 To: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: [llvm-dev] 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200309/fe0861b3/attachment.html>
connor horman via llvm-dev
2020-Mar-12 13:15 UTC
[llvm-dev] Manipulating Arch specific code generator state
On Thu, Mar 12, 2020 at 03:49 Walter Zambotti <zambotti at iinet.net.au> wrote:> 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> > > Regards > > > > Walter ZAMBOTTI > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Sjoerd > Meijer via llvm-dev > *Sent:* Tuesday, 10 March 2020 5:19 AM > *To:* llvm-dev at lists.llvm.org; connor horman <chorman64 at gmail.com> > *Subject:* Re: [llvm-dev] Manipulating Arch specific code generator state > > > > 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. > ------------------------------ > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of connor > horman via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* 09 March 2020 12:31 > *To:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> > *Subject:* [llvm-dev] 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. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200312/9ed6ffae/attachment.html>