<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 03:49 Walter Zambotti <<a href="mailto:zambotti@iinet.net.au">zambotti@iinet.net.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div class="m_-7540310773856861691WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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!!!</span></p></div></div></blockquote><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">The 65816 is generally a weird architecture doing weird stuff for backwards compatibility with the 6502.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div class="m_-7540310773856861691WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I have seen this requirement come up before in other backend designs.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.</span></p></div></div></blockquote><div dir="auto">It seems to have gone directly to myself and one other. I’ve manually corrected that</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div class="m_-7540310773856861691WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regards</span></p></div></div><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div class="m_-7540310773856861691WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Walter ZAMBOTTI<u></u><u></u></span></p><p class="MsoNormal"><a name="m_-7540310773856861691__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] <b>On Behalf Of </b>Sjoerd Meijer via llvm-dev<br><b>Sent:</b> Tuesday, 10 March 2020 5:19 AM<br><b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; connor horman <<a href="mailto:chorman64@gmail.com" target="_blank">chorman64@gmail.com</a>><br><b>Subject:</b> Re: [llvm-dev] Manipulating Arch specific code generator state<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black">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. <u></u><u></u></span></p></div><div class="MsoNormal" align="center" style="text-align:center"><hr size="3" width="98%" align="center"></div><div id="m_-7540310773856861691divRplyFwdMsg"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of connor horman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>Sent:</b> 09 March 2020 12:31<br><b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>Subject:</b> [llvm-dev] Manipulating Arch specific code generator state</span> <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">Hello all on the list,<u></u><u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div></div></div></div></blockquote></div></div>