[llvm-dev] Manipulating Arch specific code generator state

[connor horman via llvm-dev]

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>