ASM formatting rules?

ASM formatting rules?

[Kumar Gala]

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.

- kumar

Re: ASM formatting rules?

[Tom Rini]

On Mon, Mar 28, 2005 at 10:44:17AM -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.

My preference is for spaces after each , just because it makes it
visually clearer (and I don't always have instant mental insn->#args
mental mapping :)).

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: ASM formatting rules?

[Dan Malek]

On Mar 28, 2005, at 11:56 AM, Tom Rini wrote:

> My preference is for spaces after each , just because it makes it

Me, too.

Thanks.

	-- Dan

Re: ASM formatting rules?

[Matt Porter]

On Mon, Mar 28, 2005 at 09:56:11AM -0700, Tom Rini wrote:
> On Mon, Mar 28, 2005 at 10:44:17AM -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.
> 
> My preference is for spaces after each , just because it makes it
> visually clearer (and I don't always have instant mental insn->#args
> mental mapping :)).

As long as there is <TAG>insn<TAB>, I don't have strong feelings
about the arg spacing.  I feel that spaces between args really
don't enhance readability (why I have none between args in
head_44x.S) but I can live with them.

I think this is a good idea to get some consistency throughout
ppc32 asm.

-Matt

Re: ASM formatting rules?

[Paul Mackerras]

Kumar Gala writes:

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

Yep, that's the style we use.

Paul.

Re: ASM formatting rules?

[Kumar Gala]

Great, if my counting is correct (which may not be, since I grow up in=20=

Florida)

2 - for no space (Paul, BenH)
2 - for spaces (Tom, Dan)
2 - dont cares (Kumar, Matt)

Well, does Paul have authoritative rule here as ppc maintainer? :)

- kumar

On Mar 28, 2005, at 3:37 PM, Paul Mackerras wrote:

> Kumar Gala writes:
>
> > I'm assuming something like this (w/o spaces):
>  >
> > <TAB>insn<TAB>argD,arg1,arg2
> >
> > is what we want?=A0 Just trying to get a rule documented going =
forward.
>
> Yep, that's the style we use.
>
> Paul.

Re: ASM formatting rules?

[Paul Mackerras]

Kumar Gala writes:

> Great, if my counting is correct (which may not be, since I grow up in 
> Florida)
> 
> 2 - for no space (Paul, BenH)
> 2 - for spaces (Tom, Dan)
> 2 - dont cares (Kumar, Matt)
> 
> Well, does Paul have authoritative rule here as ppc maintainer? :)

I would take a similar attitude to Linus and say that if there is
someone who has taken on the role of maintaining a file or subsystem,
they get a fair bit of latitude in saying what the style should be
there.  So if Dan and Tom want to do "insn<TAB>op, op, op" in
head_8xx.S, I'm not going to go in and remove all the excess spaces.

However, apart from that - i.e. for code that is used on all PPC
platforms, or if people are asking what the style should be - then the
style is no spaces between the operands.

Paul.

Re: ASM formatting rules?

[Dan Malek]

On Apr 4, 2005, at 2:33 AM, Paul Mackerras wrote:

> However, apart from that - i.e. for code that is used on all PPC
> platforms, or if people are asking what the style should be - then the
> style is no spaces between the operands.

OK ....  I'll try to change my old habits :-)


	-- Dan

Re: ASM formatting rules?

[Benjamin Herrenschmidt]

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 ;)

Ben.

Re: ASM formatting rules?

[Gabriel Paubert]

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