[PATCH] opcodes: Fix BMASKI disassembly for immediate 32 on M*Core

[Jan Beulich]

On 20.01.2026 12:33, Michal Sobon wrote:
> On Tue, Jan 20, 2026 at 11:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>> Can you please provide a link to permit double checking of what you say? It all
>> sounds plausible and is consistent with what the assembler looks to be doing,
>> but still.
> 
> Sure. The doc is available here: https://archive.org/details/MCORERM
> The relevant information is on page 83.
> 
>>>       * gas/mcore/allinsn.d: Regenerate.
>>
>> This last entry doesn't read quite right. "Regenerate" generally means
>> something that is generated by a script or program. I don't think that's the
>> case here?
> 
> It was generated using objdump -drz and then manually modified to use
> regular expressions.

As I expected. That's not "regenerate" but e.g. "update expectations".

>> As you had to touch all these addresses, did you wonder whether that should
>> actually be necessary? The next time someone adds an insn form in the middle,
>> the same would be necessary again. Are these addresses relevant for the test?
>> I don't think so, and if they aren't, I'd suggest that if already (almost)
>> everything needs touching, perhaps these should be abstracted away by using
>> e.g. [0-9a-f]+[02468ace] on the lines with labels (keeping the label names
>> properly spelled out). Ideally such would be done in a separate, prereq
>> change, but I wouldn't insist on that.
> 
> I thought of adding the new instruction at the very end of the .s file, this way
> there wouldn't be a need to align these addresses. However, I see that
> instructions
> in this file are ordered alphabetically. Are you ok with adding the
> BMASKI r3, 32 at
> the end of this file? I believe this would make the patch cleaner.

I wouldn't mind that, in the interest of reducing patch size. (I would
prefer what I did outline, but I may as well do so myself after your
change has gone in.)

>>> -     clrc                    // These two instructions pad the object file
>>> -     clrc                    // out to a 16 byte boundary.
>>> -
>>
>> This change is unexplained. From the .d file prior to the change it looks as
>> if the comment was stale already anyway. That's okay to correct here, but
>> wants mentioning in the description as a secondary change.
> 
> After adding the new instruction the whole file is 4 bytes longer,

Which is part of what struck me as odd, seeing that you only add a 2-byte
insn. But apparently .literal has this kind of effect.

Jan

> so
> I believe the padding
> is no longer necessary (not sure it was necessary prior to my change anyway).
> I will add the explanation.
> 
> Michal