[pypy-dev] PPC backend design questions

[Michael Hudson-Doyle]

(sorry, forgot reply to all on the first version of this)

I guess a useful thing to understand here is that the powerpc
assembler was mostly written by me on a whim many many years ago --
there never was a really strong design sense and if there was, I've
probably forgotten it :)

On 10 August 2011 01:04, David Edelsohn <dje.gcc at gmail.com> wrote:
> The nop mnemonic is defined twice in ppc_assmbler.py:
>
> In class PPCAssembler
>
>    # F.9 Recommended Simplified Mnemonics
>
>    nop = BA.ori(rS=0, rA=0, UIMM=0)
>
> and in class PPCBuilder
>
>    def nop(self):
>        self.ori(0, 0, 0)
>
> Which one should be removed?  I assume the one in PPCBuilder.

However, I do remember that there was a reason I did this, although
not what.  Take out the version in PPCBuilder and see if anything
breaks, I guess.

> Some PPC64 instructions have complicated encodings that split operands
> among multiple fields, such as shift immediate instructions, or
> truncates fields, such as load and store displacements.  I implemented
> the instructions exposing all of the fields, but that does not match
> the way instructions are written in assembly language.  These aren't
> simplified mnemonics.
>
> For example,
>
>    sradi 3, 4, 33
>
> splits the shift count of the third operand between two fields in the
> instruction representation.  Or
>
>    ld 3, 0x8000(9)
>
> does not place the displacement 0x8000 in the instruction, but shifts
> the value by 2 bits -- displacements always are word aligned.  The
> base address can be anything, so addresses themselves are not strictly
> aligned, but the displacement is word aligned.  However, the
> programmer does not write the shifted address.
>
> My inclination is to implement the instructions the way they are
> written by a programmer in PPCAssembler and change the names in
> BasicPPCAssembler.  Is that reasonable and is there a precedent I
> should use for the names?

There are already fields that behave in unusual ways -- see

https://bitbucket.org/pypy/pypy/src/f8c92c646275/pypy/jit/backend/ppc/ppcgen/ppc_field.py#cl-55

I think you should be able to add your fields in this fashion -- in
fact, the IField looks a teensy bit like how the displacement field
should be already.  The split encodings should be fairly easy too,
although there might be some paranoid code checking that fields don't
overlap that you need to change.

Cheers,
mwh