This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: m68k : why is bra an alias for braw, not jra
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Nick Clifton'" <nickc at redhat dot com>, "'Philippe De Muyter'" <phdm at macqel dot be>
- Cc: "'binutils mailing list'" <binutils at sources dot redhat dot com>
- Date: Fri, 7 Apr 2006 16:50:06 +0100
- Subject: RE: m68k : why is bra an alias for braw, not jra
On 07 April 2006 16:29, Nick Clifton wrote:
> Hi Philippe,
>
>> In the m68k assembler, I wonder why `bra' and friends are alias for their
>> `bxxw' counterparts.
>
>> And if one writes no size specification for a `bra' instruction the
>> assembler should be free to choose the most efficient way to generate it,
>> i.e.
>> a `brab' if possible of even a `bral' if needed.
Remembering back to my old amiga days, it would be because word-size was the
default. In motorola syntax[*] you had an appended size field, and you would
write one of
bra.b label
bra.w label
to indicate a byte- or word- sized operands. There was also a .l suffix for
those opcodes that could take 32-bit immediate operands. The default was
16-bits. The assembler was not allowed to make decisions on behalf of the
user; if you didn't specify a length suffix, that /explicitly/ meant you
intended to use the default 16-bit operand size, and things would go very
wrong if the assembler decided to adjust the sizes of operand fields in your
self-modifying code. Allowing the assembler to choose to shorten branches was
regarded as an 'optimisation' that had to be specifically switched on with a
command-line option, but regardless of that, "bra" was always *synonymous*
with specifying "bra.w", it never meant "bra.w or bra.b at your discretion" to
the assembler, and when you told it to optimise it would, equally, transform
"bra.w" with an explicit size specifier to a "bra.s".
So, the answer would be "For compatibility between binutils and the various
native assemblers of the day".
cheers,
DaveK
[*] - as opposed to MIT syntax, rather than to AT+T syntax for once!
--
Can't think of a witty .sigline today....