From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31612 invoked by alias); 7 Apr 2006 15:50:12 -0000 Received: (qmail 31601 invoked by uid 22791); 7 Apr 2006 15:50:12 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (217.40.213.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Apr 2006 15:50:10 +0000 Received: from mail.artimi.com ([192.168.1.3]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 16:50:07 +0100 Received: from rainbow ([192.168.1.165]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 16:50:07 +0100 From: "Dave Korn" To: "'Nick Clifton'" , "'Philippe De Muyter'" Cc: "'binutils mailing list'" Subject: RE: m68k : why is bra an alias for braw, not jra Date: Fri, 07 Apr 2006 15:53:00 -0000 Message-ID: <000101c65a5a$f162ac50$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <4436852E.1020707@redhat.com> Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00125.txt.bz2 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....