Re: [PATCH] [PowerPC] VLE update

[Alexander Fedotov <alfedotov at gmail dot com>]

Ping on a patch :)

On Wed, Aug 30, 2017 at 7:03 PM, Alexander Fedotov <alfedotov@gmail.com> wrote:
>>> If you split off the part dealing with SEC_PPC_VLE that can be
>>> committed separately.
>
> Done. New patch attached.
>
>
>>> OK, but if there was a processor that could operate in both VLE and
>>> non-VLE mode (controlled by MAS2 bit VLE), would these instructions be
>>> available in both modes?  If only VLE, then SHF_PPC_VLE ought to be
>>> set for any section containing them.  See tc-ppc.c:3513.
>>>
>>> However, from the fact that the "Lightweight Signal Processing APU
>>> (LSP APU) Reference Manual" does not mention VLE, and the encoding of
>>> these instructions, my guess is that these instruction are not VLE and
>>> thus should not be in vle_opcodes.
>
> Yes, there could be e.g e200z759n core. But it has SPE, not LSP.
>
> On Tue, Aug 29, 2017 at 9:17 AM, Alan Modra <amodra@gmail.com> wrote:
>> On Mon, Aug 28, 2017 at 05:20:45PM +0300, Alexander Fedotov wrote:
>>> > You could reuse the SEC_MEP_VLIW bit, I guess.   The section flags
>>> > weren't really supposed to be used for target-specific purposes, but
>>> > it seems pointless trying to be a purist now.
>>>
>>> Okay, so I will set
>>> +#define SEC_PPC_VLE SEC_MEP_VLIW
>>
>> If you split off the part dealing with SEC_PPC_VLE that can be
>> committed separately.
>>
>>> > That doesn't look elegant at all.  So you are using R_PPC_PLTREL24 and
>>> > R_PPC_LOCAL24PC relocations in VLE code but giving them a new meaning.
>>> > Is that documented in the ABI?
>>> >
>>> > I think it would be better to define new R_PPC_VLE_PLTREL24 and
>>> > R_PPC_VLE_LOCAL24 relocs, and make the assembler generate them when
>>> > assembling VLE code.
>>>
>>> Nope, they are not defined by ABI at all. I agree it would be better
>>> to rework. I will remove it from current patch set.
>>
>> I should note that I'm not greatly concerned about adding relocations
>> that aren't described in an ABI document.  It's not ideal, but the
>> document can always be modified later.  I was more concerned that
>> someone may have already described R_PPC_PLTREL24 as behaving
>> differently for VLE, and the problem that causes for compatibility if
>> the GNU toolchain then goes off and implements something else.
>>
>>> > As I understand it, SHF_PPC_VLE and PF_PPC_VLE are set on sections or
>>> > segments containing instructions that can only be executed by a
>>> > processor in VLE mode.  PPC_OPCODE_VLE is set for such opcodes too.
>>> > So, do the LSP instructions only execute in VLE mode?  I suspect not,
>>> > from their encoding.
>>> >
>>> > Do you have the LSP instructions in the correct opcode table?
>>>
>>> I see that LSP instructions are available only on the cores with VLE ISA only.
>>
>> OK, but if there was a processor that could operate in both VLE and
>> non-VLE mode (controlled by MAS2 bit VLE), would these instructions be
>> available in both modes?  If only VLE, then SHF_PPC_VLE ought to be
>> set for any section containing them.  See tc-ppc.c:3513.
>>
>> However, from the fact that the "Lightweight Signal Processing APU
>> (LSP APU) Reference Manual" does not mention VLE, and the encoding of
>> these instructions, my guess is that these instruction are not VLE and
>> thus should not be in vle_opcodes.
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM
>
>
>
> --
> Best regards,
> AF



-- 
Best regards,
AF