m68k : why is bra an alias for braw, not jra

m68k : why is bra an alias for braw, not jra

[Philippe De Muyter]

All,

In the m68k assembler, I wonder why `bra' and friends are alias for their
`bxxw' counterparts.

It seems to me that if someone needs a word-sized bra insn, (s)he will
use the braw variant.

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.

IIRC, that's also what the Motorola assembler did in Motorola's Unix System V.

It is also what `gcc/config/m68k/lb1sf68.asm' expects in gcc.  If you look
at this file, you'll see that it is full of `bra', `beq', `bge' etc., where
the intent is clearly to let the assembler decide.

I know that there exists a `jra' or `jbra' keyword, but that's not the
natural way of writing if you write assembler code using your Motorola
reference manual as base.

If no-one objects, I'll submit a patch

Philippe

Re: m68k : why is bra an alias for braw, not jra

[Nick Clifton]

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.

> If no-one objects, I'll submit a patch

Please feel free to submit such a patch.  I would recommend however that 
you control the new behaviour with a command line switch as I suspect 
that there will be assembler source files out there that rely upon the 
current behaviour.

Also, if you would like your patch to be accepted into the binutils 
sources you will need to have an FSF copyright assignment in place.

Cheers
   Nick

RE: m68k : why is bra an alias for braw, not jra

[Dave Korn]

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....

Re: m68k : why is bra an alias for braw, not jra

[Andreas Schwab]

Nick Clifton <nickc@redhat.com> writes:

> 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.
>
>> If no-one objects, I'll submit a patch
>
> Please feel free to submit such a patch.  I would recommend however that 
> you control the new behaviour with a command line switch as I suspect 
> that there will be assembler source files out there that rely upon the 
> current behaviour.

I've found this comment in the gas-2.x sources:

/* Define this so that jump tables with calculable offsets are possible.
   This option forces "bsr" and "bra" to always use 16-bit offsets, even
   if smaller ones work work.  Other pseudo-instructions are available for
   variable-sized offsets.  */
#define FIXED_SIZE_BRANCH

and later down:

#ifndef FIXED_SIZE_BRANCH
#define BRANCH "Bg"
#define BRANCH_MASK one(0xFF00)
#else
/* Fixed-size branches with 16-bit offsets */
#define BRANCH "BW"
#define BRANCH_MASK one(0xFFFF) /* 8-bit displacement must be 0 */
#endif

whereas gas 1.38.1 still made them variable sized.  This is the
corresponding change log:

Wed Nov  4 07:36:49 1992  Ken Raeburn  (raeburn@cygnus.com)

	* m68k.h: Define FIXED_SIZE_BRANCH, so bsr and bra instructions
	always use 16-bit offsets.  Makes calculated-size jump tables
	feasible.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."