OSDev.org

Hey! I'm learning assembly (using nasm) and I was wondering if
anyone here has some strong opinions concerning the different
assembly styles, in terms of indenting, comments etc.

Would be interesting to hear from someone who has some experience
with large projects in assembly.

I don't think there is really any standard, but I normally comment each function using something like:
Just treat it how you want unless you are working with others or expect others to use your source, at that time you would just comment every thing well and indent as normal (as if it were C or something with brackets). I just adapted my style from C. I must be missing something, is that all you wanted?

Thanks! That's all I was looking for. Don't want to run into any
awkward problems a few thousand lines into a project. I also don't
like tabs, so I'll prolly replace those with spaces, but other than
that, I like your style... and it's pretty much what I had in mind.

You might want to think about setting your editor to use 4 or 8 spaces instead of tabs.

Different editor environments tend to do different things with tabs, and you can end up with a hodgepodge of various space and tab indents by some auto-conversions faster than you can say "uncle". In my experience, only forbidding tabulators anywhere but in Makefiles (ideally by having a script check for them upon repository checkin) is the only "safe" way.

I find that just leads to different people using different numbers of spaces for indents. At least with tabs you can use the editor to change how it looks.

In the end, the important thing is not what the standard is... as long as there is one.

Solar wrote:You might want to think about setting your editor to use 4 or 8 spaces instead of tabs.

Different editor environments tend to do different things with tabs, and you can end up with a hodgepodge of various space and tab indents by some auto-conversions faster than you can say "uncle". In my experience, only forbidding tabulators anywhere but in Makefiles (ideally by having a script check for them upon repository checkin) is the only "safe" way.

I totally agree with that. I have Emacs set to using 4 spaces and no tabs at all.
It is often argued that it's better to use tabs, because that way people can configure
things the way they like. Well, there are some environments, such as in browsers,
where tabs look horrible. I cannot predict all the environments people want to read
my sourcecode from, so I just make it simple with spaces.

I agree with JackScott, use tabs, adjust your editor for visual appearance.

I prefer tabs as well, and I consider it to be the most pointless discussion ever. Just stop discussing it. Take an editor that auto-formats incoming files and that auto-formats what you type, then set every bit of code to what you like.

The important thing in assembler is to be able to look at the entrypoint for a function call, and be able to immediately tell

1) what the function is supposed to to
2) which other functions/processes are supposed to be able to call it
3) which registers hold which input values
4) which "output" registers hold which "return" values
5) which registers are "trashed" during the process of running the function

Beyond that, you want to be able to instantly see, by eye, what is a label, what is a comment, what is a mnemonic, and where the dividing line is between one function and the next.
In your comments, you only need to really say the things that you won't be able to remember about your algorithm/coding method in 6 months. Some of it is obvious. For the rest of it, you often have to wait 6 months, figure out how the code works again, see what you forgot, and THEN write your comments.

Personally, I also prefer my ASM code to be fairly compact. Lots of lines of actual code per screenful -- because each line doesn't do much, and it's easier to debug if you can see most of a routine all at once.

Candy wrote:I prefer tabs as well, and I consider it to be the most pointless discussion ever. Just stop discussing it.

As long as we don't get heated about it, I don't think it's pointless.

For the second time in my career now, I am facing a project of 100.000+ source lines which has been edited by many people in many environments. Some used tabs, some used spaces, and as everyone has a different setting for what a tab looks like, what looks good for one looks terrible for the other.

That's why I was suggesting the use of spaces - "wrong" settings are either immediately visible or trivially detected automatically.

But I agree with the sentiment "the standard doesn't matter as long as there is one" - I can live with that.

Solar wrote:...

That's why I was suggesting the use of spaces - "wrong" settings are either immediately visible or trivially detected automatically.

But I agree with the sentiment "the standard doesn't matter as long as there is one" - I can live with that.

My computer is strong enough to render me a virtual world with realistic plants and water. I'm pretty sure it can auto-format it for my preference for editing and then auto-format it for the company preference for committing.

In your 3D virtuality, one or two polygons that are a bit off-ish don't really matter...

If you happen to know a free, reliable, and correct (in the CS sense of the word) reformatter for C++ source, I'd be very interested to hear about it.

(I have to have a look at astyle again - Jim Pattee has done a number of releases since 1.15.3, but I know what he started with, and I wouldn't let that version anywhere near my code...)

Solar wrote:If you happen to know a free, reliable, and correct (in the CS sense of the word) reformatter for C++ source, I'd be very interested to hear about it.

Have you tried Uncrustify?

Solar wrote:In your 3D virtuality, one or two polygons that are a bit off-ish don't really matter...

If you happen to know a free, reliable, and correct (in the CS sense of the word) reformatter for C++ source, I'd be very interested to hear about it.

(I have to have a look at astyle again - Jim Pattee has done a number of releases since 1.15.3, but I know what he started with, and I wouldn't let that version anywhere near my code...)

Sadly, no. That's why we're having this discussion in the first place, right?

I would start with Vera++ as it's apparently very good and parses the full tree to pass to apply arbitrary transformations and checks to. You could just take the tree and dump it to a file instead.

I don't use these for my personal projects as I'm usually using such bleeding-edge c++ that gcc can't parse it properly (bug 36460 f.ex.). If the compiler builders don't get it, I really don't expect anybody else to do better.