Any suggestions for command-line tools or editors that will auto-indent 6502 assembly? Code originally written for native assemblers on the C64 usually isn't indented very nicely and I'd like to clean it up to make it more readable when I look at it on my PC. I'd like to have the labels in the first column, mnemonics and operands in the second, and comments in a third. I could probably write something pretty easily but I'd rather spend time on more interesting things if one already exists. I did try to find something on my own before asking but I haven't found the magic combination of search terms apparently.

scotws was just talking about this in the Tinkerer topic: viewtopic.php?f=2&t=3548&p=50265#p50265

Thanks! I'll check it out.

It's here to be exact: https://github.com/scotws/tinkasm/tree/master/tinkfmt . Let me know if anything in the code is unclear.

Cudos go to the Go (golang) people behind the gofmt tool, who decided that they'd had it once and for all with endless formatting discussions. They decided on rules, set them down in the tool, and now every single (serious) Go program on the planet is formatted in the exact same way. The feeling seems to be that everybody hates the format, but loves the formatter. It certainly made a difference learning the language, because your brain seems to expect stuff in certain places after a while, and it is quicker to type, because you just hack it in and let the machine move everything around when you save the file (on vim, at least).

Tinkfmt now is very simple. Whitespace lines and full-comment lines are trivial; all directives start with a dot and come before their arguments; all mnemonics are known; everything else should be a label. Then, labels start at the beginning of the line, directives are indented by one tab worth of spaces (in other words, eight), mnemonics by two. What this means is that everything usually gets its own line (except for in-line comments), though the Tinkasm assembler itself will tolerate stuff on one line (and break it up internally). The only slightly complicated detail is that some things like .equ have their parameters justified.

Put differently, I cheated by creating my own notation where the directive comes before its parameters. You'll probably have to go to a bit more effort if you're using another notation where the directives are "infix". What I haven't done yet - next step - is to create a vim plug-in based on this so I can use tinkfmt just like gofmt is used, while you type.

You've re-used a really good idea there!

I utterly and completely detest the format standard chosen by the Go language tool. It is unreadable and I am glad that I will be unlikely to ever program in that language again. I can't say enough bad things about how horrible it is.

Note that if you read my comments in the forum I am generally a positive person. But it bothers me like nails on a chalkboard or lemon juice in a paper cut.

Update: Rather than just rant I say what pushed me over the edge. Every time I type "} else {" I die a little inside.

I am old enough to remember the era before C hit the big time. When C started catching on I and many other people's reaction was interesting language, but it digs deep into the oddball characters on the keyboard. Many keyboards didn't even have { }, so it was a bit of culture shock. Their placement for touch typing on most keyboards isn't ideal, and when you add in ( ) [ ] characters typing gets award.

Python greatly reduced the use of curly braces and typing it was a bit of a relief. But Go just makes you type those two extra awkward characters and do it in the ugliest way possible.

(It might be interesting, if you can take the time, if you'd paste an example paragraph of official format and your preferred format. Your wording is so strong I can't quite think how different they'd need to be! If we compare with C, I wouldn't much like having to deal all the time with GNU style but I'm sure we all have our own preferences.)

Edit: relevant story I read earlier today.

@BigEd, my update and you question collided. I suppose GNU style is a bit more tolerable because you type the curly braces coupled with the return key, so I shift my right hand over to the right and do it in one motion. The } else { means I keep my hand on the home row and use my pinky which is fatiguing.

Ultimately I think I would prefer the depreciation of curly braces as they are hard to type.

Thanks for the update.

I have to say, I'm in favour of the way Python does it - no braces, indentation is meaningful so no possibility of misleading indentation, which can be a real problem.

I'm not a touch typist so I don't have quite the trouble you do. I have a different kind of trouble!

The attached ZIP contains the C# code for a reformatter I wrote five years ago to convert BDD's monitor source (which uses lots of macros for opcodes) into standard 65C816 assembler source. One side affect of this conversion is that it retabulates the code.

There is a free community version of C# for Windows or Mono for Linux if you want to rebuild it.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

scotws: I tried running tinkfmt on my sources and it choked on a label assignment:



I haven't really looked at the exact format it's expecting yet (Typists Assembler?), but it doesn't seem to like the 64tass format. I've attached the source I was trying to format... it's Andre Fachat's @mon source which I converted to ASCII and cleaned up a bit.

Another example of the type of sources I'd like to reindent are the Supermon64 sources I converted to 64tass (although I've already reindented that one manually).

BitWise: I'll take a look at your reformatter when I get a chance.

This is me.



Indention is used to indicate structure, but relies on delimiters.

Ah yea, we used to call VAX Basic BASCALTRAN back in the day. When I used it, pre-TPU, we used EDT, which was pretty powerful, we had to rely on line numbers for error handling. We couldn't (or I didn't know how) get file operation status information, we had to rely on ON ERROR GOTO and then it would capture the line number that the error happened on, and then we would resume back to a line. If we didn't have to do that, we wouldn't have had to use any line numbers. The mix was kind of messy, but we made do.

I don't want to step on any toes since I'm the newbie here, but I thought I'd point out that arguing over C indentation style is pretty OT in a thread I started to find tools for indenting *assembly* sources. And besides, arguing about indentation style is like arguing about politics or religion. Nobody can prove they're right and it has a non-zero chance of starting a war.

It's OK, we usually don't get flame wars here. We don't worry too much about short off-topic excursions either. The important thing is to be discussing, not arguing!

Scott's tool and go's tool and the myriad conventions in C are all part of the same problem space.

As penance for my Go vent. The Emacs editor has an assembly mode and can automatically format text. Most parameters such as indentation are controlled via parameters in your .Emacs file. Emacs is also free, so the price is right. See this reference:

https://www.emacswiki.org/emacs/AsmMode

Of course editor wars are even more dangerous than coding standards wars, so apologies in advance.