From: Gabriel Paubert <paubert@iram.es>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Tom Rini <trini@kernel.crashing.org>,
ML linuxppc-embedded <linuxppc-embedded@ozlabs.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: ASM formatting rules?
Date: Tue, 29 Mar 2005 10:32:11 +0200 [thread overview]
Message-ID: <20050329083211.GA27952@iram.es> (raw)
In-Reply-To: <1112048510.5410.60.camel@gaston>
On Tue, Mar 29, 2005 at 08:21:50AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2005-03-28 at 10:44 -0600, Kumar Gala wrote:
> > Guys,
> >
> > While this is not overly important to me, I was wondering if we had any
> > rules related to formatting of assembly files. We seem to have code
> > formatted with and without spaces in the args.
> >
> > I'm assuming something like this (w/o spaces):
> >
> > <TAB>insn<TAB>argD,arg1,arg2
> >
> > is what we want? Just trying to get a rule documented going forward.
>
> I used to have argD, arg1, arg2 but since everything else was "compact",
> I now tend to adapt to everything else ;)
Assembly is not C! I don't like the space after the comma in
assembly, but can adapt to (almost) any style.
For the record, the biggest file of PPC assembly I wrote
(the real mode x86 emulator to initialize graphics board
through BIOS emulation) is really atypical:
1) it has two tabs before the opcode, because it must
accomodate really_long_labels and a single tab is not enough.
2) only a space between the opcode and the operands, but many
registers have fixed uses and have mnemonic names through #defines.
This helps a lot for readability and maintainability. See 4)
for the reason.
3) no space after the comma between operands.
4) Sometimes several instructions separated by a semicolon in
the same line, but only the first instruction may have a label.
That's because at the time I wanted to see as much as possible
on a small screen. But this does not mix well with putting
tabs between instruction and operands, hence 2).
I don't think these rules ar generally applicable to
assembly files, these were specific rules which matched
my needs for this file (5000 lines).
Gabriel
prev parent reply other threads:[~2005-03-29 8:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-28 16:44 ASM formatting rules? Kumar Gala
2005-03-28 16:56 ` Tom Rini
2005-03-28 17:11 ` Dan Malek
2005-03-28 17:22 ` Matt Porter
2005-03-28 21:37 ` Paul Mackerras
2005-03-28 23:07 ` Kumar Gala
2005-04-04 6:33 ` Paul Mackerras
2005-04-05 16:45 ` Dan Malek
2005-03-28 22:21 ` Benjamin Herrenschmidt
2005-03-29 8:32 ` Gabriel Paubert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050329083211.GA27952@iram.es \
--to=paubert@iram.es \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=paulus@samba.org \
--cc=trini@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.