vasm and comments

[xxxxx]

hey everyone,

I have a suggestion for an option for how vasm could deal with comments. The current comment functionality is very eager to turn things into comments that at first glance doesn't seem like comments. There is something that has bitten me a few times recently.

To quote the vasm manual: "Comments are introduced by the comment character ; or *. The rest of the line will be ignored. Also everything following the operand field, separated by a whitespace, will be regarded as comment."


I mostly do c programming professionally, and have learned to put in spaces into my expressions. So I would like to suggest a "strict comment" option that would warn of potential problems. It could maybe work like this:
1. not turn whitespaces into comments, but instead warn if there is a whitespace character that *would* have been a comment, followed by any non-whitespace character other then semicolon.
2. not turn * into comments except if it is the first non-whitespace character on a line, but instead warn.
Maybe with a text like "line Y has a comment starting with a whitespace (or *) - was that the intention?"

The cases I am worried about are things like
if someexpression=1 || someexpression=2
move.w #$1234, someregister + 3 * 2
if someexpression = 5 * $1024

In all of these cases, it should warn that the whitespace (and the *).

What do you think?

Cheers

[BigFan]

What about using -spaces in command line to ignore whitespace in operand fields as suggested by the manual ?

[Lonewolf10]

Originally Posted by xxxxx

The cases I am worried about are things like
if someexpression=1 || someexpression=2
move.w #$1234, someregister + 3 * 2
if someexpression = 5 * $1024

I have never used VASM, but the line above (that I have bolded) isn't the correct syntax for assembler and I'm pretty sure it would be illegal in VASM too - though I think the others are valid.

Comments usually start with an asterisk/star (*) or semi-colon (;) for assemblers, and apostrophe (') for Visual Basic and AMOS Pro (and probably other languages too).
The * is supposed to be only used at the start of a line to indicate the whole line is a comment, whereas the ; can be used anywhere.

[xxxxx]

@Bigfan: Yes, that is a good option if I am only to write assembler code that is never shared or ported. But I hate the idea that people with other assemblers (or even the same assembler with different parameters) may get a different compiled output. I would rather the assembler warned about things that could potentially be wrong.

@Lonewolf10: that was a typo by me - I meant "move.w #$1234, somelabel + 3 * 2". Yes, I agree that comments should be marked with * at start of line or ; anywhere. But some assemblers are more forgiving than others.

[Lonewolf10]

Originally Posted by xxxxx

But I hate the idea that people with other assemblers (or even the same assembler with different parameters) may get a different compiled output.

That is why assemblers (certainly DevPac, as I don't use any others right now) allow you to include options in the code aswell. I have a bunch of options at the start of my code that should make it compilable (and run!) on other peopls setup's.

Originally Posted by xxxxx

@Lonewolf10: that was a typo by me - I meant "move.w #$1234, somelabel + 3 * 2".

Hehe, that's more like it.

Personally, I don't like spaces in calculations in code, but I agree they should have an option to allow/disallow spaces. (One more option among many isn't going to hurt anyone - except maybe the person/people that have to implement the new option)

[xxxxx]

The problem is that then I would have to know how every single assembler needs the options specified. If instead there was a way for me to verify that there was no ambiguous code, it would be safer.

But yeah, it could easily be messy to implement. I have only played a little with the vasm code, and this seems like it could be tricky to get right.

I will live with -spaces for now, though.

[phx]

You're right, I see the problem. You can never be sure that you were missing a blank somewhere, which started an unwanted comment in the operand field.

The asterisk should be no problem, as it is only regarded as a comment in an operand when using PhxAss compatibility mode.

I have implemented a new option for the mot-syntax module, called -warncomm. It will warn you about any line with blanks in the operand field, which are followed by non-blank characters.

Example:

frank@sun cat checkcomm.s 
        move.w  d0,lab + 2
        rts     

lab:    dc.w    2 * 3
frank@sun ../../vasmm68k_mot -warncomm checkcomm.s 

  Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
vasm 1.7c (c) in 2002-2015 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.0f (c) 2002-2015 Frank Wille
vasm motorola syntax module 3.6e (c) 2002-2015 Frank Wille
vasm test output module 1.0 (c) 2002 Volker Barthelmann

warning 1019 in line 1 of "checkcomm.s": check comment
>       move.w  d0,lab + 2

warning 1019 in line 4 of "checkcomm.s": check comment
>lab:   dc.w    2 * 3

CODE(acrx2):              10 bytes

Ok?

[Lonewolf10]

Originally Posted by phx

Ok?

That was quick phx!

Seems ok to me.

[xxxxx]

That is exactly what I was hoping for. Thank you!

[Thorham]

Originally Posted by xxxxx

The problem is that then I would have to know how every single assembler needs the options specified. If instead there was a way for me to verify that there was no ambiguous code, it would be safer.

You could just make a particular assembler a hard requirement, and specify why. Trying to make your source code compatible with all assemblers is actually a terrible idea, because that way you limit the features you can use to the assemblers that are the worst, like Seka, for example. If your source doesn't assemble with Seka, who cares? Let them use a proper assembler.

Make your source code work with one or two good assemblers like Barfly, PhxAss and VASM. It's not hard to get any of those, and if someone doesn't want to use one of these assemblers, then too bad for them.

Don't make things hard for yourself and require that people use the right tool.

[phx]

Ok. Tomorrow's source snapshot will include the new option.