diff options
| author | Jan Beulich <jbeulich@suse.com> | 2022-05-27 08:45:56 +0200 |
|---|---|---|
| committer | Jan Beulich <jbeulich@suse.com> | 2022-05-27 08:45:56 +0200 |
| commit | 811f61d4c453934b765c73bde78fc29ea22c0c7d (patch) | |
| tree | 2ce5662a5ae5fb9d95115aa71584087e274f8eaa /opcodes/rl78-decode.c | |
| parent | 2a2cb7cf2c7f0d380ee9cb9ef361223b8770c508 (diff) | |
| download | gdb-811f61d4c453934b765c73bde78fc29ea22c0c7d.zip gdb-811f61d4c453934b765c73bde78fc29ea22c0c7d.tar.gz gdb-811f61d4c453934b765c73bde78fc29ea22c0c7d.tar.bz2 | |
x86/Intel: adjust representation of embedded broadcast
MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Make the disassembler
follow this first, before also adjusting the assembler (such that it'll
be easy to see that the assembler change doesn't alter generated code).
For VFPCLASSP{S,D,H} and vector conversions with shrinking element sizes
the original {1to<n>} operand suffix is retained, to disambiguate
output. I have no insight (yet) into how MASM expects those to be
disambiguated.
Diffstat (limited to 'opcodes/rl78-decode.c')
0 files changed, 0 insertions, 0 deletions