VLE load/store multiple instructions

[Alexander Fedotov]

Updated patch: added ChangeLogs and fixed newline warning.

> I'll note that having fixed offsets in your file will make adding or
> removing lines "harder" later, in that you'll have to update the offsets
> for every line after the one you add or delete.  Also, is it possible
> one can use VLE in either Big Endian or Little Endian mode?
I suspect that it will never be updated ;)
VLE is Big Endian only.

> If e_lmvgprw is the more common usage over e_ldmvgprw, which your
> comment above seems to imply, then you'll want to add it above
> e_ldmvgprw, rather than after it.
I don't want to change default behavior because somebody might have
existing external tests.


Anyway, Peter, thank you for your comments :)

Alex


On Sat, Sep 30, 2017 at 12:26 AM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On 9/29/17 3:46 PM, Alexander Fedotov wrote:
>> +00000000 <prolog>:
>> +   0:        18 81 11 00     e_stmvsrrw 0\(r1\)
>> +   4:        18 22 11 04     e_stmvsprw 4\(r2\)
>> +   8:        18 03 11 08     e_stmvgprw 8\(r3\)
>> +   c:        18 a4 11 0c     e_stmvcsrrw 12\(r4\)
>> +  10:        18 c5 11 10     e_stmvdsrrw 16\(r5\)
>> +00000014 <epilog>:
>> +  14:        18 26 10 14     e_ldmvsprw 20\(r6\)
>> +  18:        18 07 10 18     e_ldmvgprw 24\(r7\)
>> +  1c:        18 88 10 1c     e_ldmvsrrw 28\(r8\)
>> +  20:        18 a9 10 20     e_ldmvcsrrw 32\(r9\)
>> +  24:        18 ca 10 24     e_ldmvdsrrw 36\(r10\)
>> +00000028 <epilog_alt>:
>> +  28:        18 2b 10 28     e_ldmvsprw 40\(r11\)
>> +  2c:        18 0c 10 2c     e_ldmvgprw 44\(r12\)
>> +  30:        18 8d 10 30     e_ldmvsrrw 48\(r13\)
>> +  34:        18 ae 10 34     e_ldmvcsrrw 52\(r14\)
>> +  38:        18 cf 10 38     e_ldmvdsrrw 56\(r15\)
>> \ No newline at end of file
>
> I'll note that having fixed offsets in your file will make adding or
> removing lines "harder" later, in that you'll have to update the offsets
> for every line after the one you add or delete.  Also, is it possible
> one can use VLE in either Big Endian or Little Endian mode?  If so, your
> fixed instruction hex values will only match one of them.  If you look
> at what we do in power9.d, you'll see we match offsets with ".*" and
> we allow matching with either BE or LE instruction encodings, so our
> tests work on both BE and LE.  For example:
>
> .*:     (7d a3 04 74|74 04 a3 7d)       cnttzd  r3,r13
> .*:     (7d c4 04 75|75 04 c4 7d)       cnttzd\. r4,r14
> .*:     (7d e5 04 34|34 04 e5 7d)       cnttzw  r5,r15
> .*:     (7e 06 04 35|35 04 06 7e)       cnttzw\. r6,r16
> .*:     (7d 54 ae 12|12 ae 54 7d)       modsd   r10,r20,r21
> .*:     (7d 75 b6 16|16 b6 75 7d)       modsw   r11,r21,r22
>
> Just a friendly suggestion, so take or ignore it. :-)
>
>
>>>> In current PPC opcodes we have only e_ldm*. But it seems that a lot of
>>>> developers uses e_lm* in their software and it fails with GAS. Other
>>>> compilers also recognizes only e_lm*.
>
> ...
>
>>  {"e_ldmvgprw",       OPVUPRT(6,16,0),OPVUPRT_MASK,   PPCVLE, 0,              {D8, RA0}},
>> +{"e_lmvgprw",        OPVUPRT(6,16,0),OPVUPRT_MASK,   PPCVLE, 0,              {D8, RA0}},
>
> If e_lmvgprw is the more common usage over e_ldmvgprw, which your
> comment above seems to imply, then you'll want to add it above
> e_ldmvgprw, rather than after it.  That way, objdump will disassemble
> the instruction to e_lmvgprw rather than e_ldmvgprw.
>
>
> Peter
>



-- 
Best regards,
AF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-aliases-VLE-load-multiple-instructions.patch
Type: text/x-patch
Size: 5910 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170929/4e9c4301/attachment.bin>