vasm and word alignment

[Den]

Hello,

I wanted to set up a comfy toolset to try and code some Amiga asm, so I tried vasm.

I found a topaz scroller source, vasm ran without errors, resulting file worked fine in winUAE.

I changed the text a bit, vasm ran without errors, but resulting file crashed in winUAE.

Original code looked like this:

	DC.B	'this is the scrolling text    ',0,0
INTER:
	MOVEM.L	D0-D7/A0-A6,-(A7)	; Put registers on stack

I then tried to assemble the modified source with ASM-One in winUAE, and it failed with a "** Word at ODD address" error. I added an EVEN directive after the DC.B and everything ran fine again.

This might not be the best coding example in the world, I understand the second trailing zero after the text was meant to align the following instruction, and that an EVEN directive would have been a wiser choice.

Still I'm wondering why vasm didn't fail assembling that file. I tried with and without the -devpac option and found nothing (that made sense to me at least ) in the options list.

So I would like to know if there's a way to tell vasm to break (and warn) on this kind of errors.

for what it's worth, here's the command line I used to run vasm (with and without -devpac):

vasmm68k_mot -Fhunkexe -devpac -o exefilename -nosym source.s

Thanks for reading
Den

[Leffmann]

Instructions are auto aligned on 2 bytes by default, so the code ends up on the correct address, but if an instruction is auto aligned then vasm will resolve a label on the line above to a different address than if the label and instruction are on the same line, that could probably be the source of your error.

In these examples, "Label" will have different address values:

       move.l  #Label, d0
       dc.b    0
Label
       rts

----------------------

       move.l  #Label, d0
       dc.b    0
Label  rts

Now that I think of it this has to be unintentional, so I'll send Frank a bug report about it.

[Den]

Thanks for your answer, Leffmann.

You nailed it. I just tested again without the EVEN directive, with the label on the same line as the movem, both with X chars and X-1 chars in the preceding dc.b and it indeed worked in both cases

I agree this is not a "desired" behaviour and that the label should be updated when the instruction that immediately follows it is auto-aligned, be it on the same line, or even 10 (empty) lines below.

Also, I think it would be nice to be able to disable that auto-alignment feature and have vasm output an 'odd alignment' error so as to have the opportunity to see what has been overlooked and manually add an EVEN or an ALIGN directive where needed. Not a vital feature by any means though

And finally, if Frank (I guess it's phx?) reads these lines, thanks a lot for the work you put into vasm!

[phx]

Originally Posted by Den

I agree this is not a "desired" behaviour and that the label should be updated when the instruction that immediately follows it is auto-aligned, be it on the same line, or even 10 (empty) lines below.

I tend to disagree.

This behaviour is intended. You can never say whether an alone-standing label belongs to the source above or below it. Example:

strstart:
        dc.b    "abc"
strend:
        rts

The instruction is auto-aligned. But aligning strend would be fatal, because it is used to calculate the string length.

The behaviour of vasm in this respect is absolutely identical to Devpac and AsmOne/AsmPro. All these assemblers will only align labels which are following the aligned instruction or reside on the same line. So there is no reason to change it.

Also, I think it would be nice to be able to disable that auto-alignment feature and have vasm output an 'odd alignment' error so as to have the opportunity to see what has been overlooked

It makes no sense to assemble instructions at an odd address, but I agree that a warning about auto-aligned instructions could be helpful. I changed that (will be in tomorrows source snapshot).

So your example (with an odd string length) would look like this now:

vasm 1.6b (c) in 2002-2013 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 1.3d (c) 2002-2013 Frank Wille
vasm motorola syntax module 3.4 (c) 2002-2013 Frank Wille
vasm test output module 1.0 (c) 2002 Volker Barthelmann

warning 51 in line 3 of "source.s": instruction had been auto-aligned
>       MOVEM.L D0-D7/A0-A6,-(A7)       ; Put registers on stack

Hope this helps.
Warnings can be disabled as usual, with -w. Or specifically for this new warning: -nowarn=51.

[Den]

I can see the problem with labels used to calculate a length, which I had overlooked.
Oh well, I'll just learn to put labels were they need to be and use more tabs if I need to fit longer names

Originally Posted by phx

So your example (with an odd string length) would look like this now:

warning 51 in line 3 of "source.s": instruction had been auto-aligned
>       MOVEM.L D0-D7/A0-A6,-(A7)       ; Put registers on stack

Hope this helps.

If I may, I think "has been auto-aligned" would be even better
This is a perfect addition, it obviously makes no sense to assemble instructions at odd addresses and this warning gives all the necessary info if one wants to go and manually align stuff in the source

Thanks again!

[phx]

Originally Posted by Den

Oh well, I'll just learn to put labels were they need to be and use more tabs if I need to fit longer names

I would rather use proper alignment directives.

If I may, I think "has been auto-aligned" would be even better

Hmm.. we're both no native speakers, but you may be right. "had" sounds like it was aligned in the past, but now it is no longer?
Changed that.

[Den]

Just compiled latest source snapshot:

warning 51 in line 163 of "ScrollExample.S": instruction has been auto-aligned
>	MOVEM.L	D0-D7/A0-A6,-(A7)	; Put registers on stack

Works perfectly, thanks again

[Leffmann]

A warning message like this was probably the best solution. Thanks for a quick patch as always.

[xxxxx]

Hey, sorry to resurrect an old thread. I really like the warning idea, but I would have liked it to trigger in more cases. So I have (experimentally) moved it up so it triggers for anything that adds data (other than CNOP/ODD/EVEN/ALIGN), rather than just for type INSTRUCTION. I did this by
1. moving the error up above the "if (p->type == RORG&&rorg_pc == 0)"
2. adding an extra parameter to sblock named is_alignment, and have do_alignment pass TRUE while everything else allocating a space atom sets it to FALSE
3. changing the check to:
if (sec->pc != oldpc && (p->type != SPACE || p->content.sb->is_alignment == FALSE))
general_error(50); /* instruction had been auto-aligned */

Feel free to use this if you want. it seems to work well for me.

[phx]

In default vasm mode there is only auto-alignment for instructions. Maybe you are thinking about the Devpac-compatibility mode, where data would be auto-aligned too?

Yes, your modification could be useful in that case, but I would add another warning message, as "instruction has be auto-aligned" doesn't really fit for data.

It is also not necessary to add the is_alignment flag to sblock, because an unaligned sblock will always have align=1. So the change now looks like this:

+++ vasm.c      7 Feb 2014 10:22:22 -0000
@@ -258,6 +258,12 @@
       }
       if(p->changes>MAXSIZECHANGES)
         sec->flags|=RESOLVE_WARN;
+      if(sec->pc!=oldpc&&(p->type!=SPACE||p->align==1)){
+        if (p->type==INSTRUCTION)
+          general_error(50);  /* instruction has been auto-aligned */
+        else
+          general_error(57);  /* data has been auto-aligned */
+      }
       if(p->type==RORG&&rorg_pc==0){
         rorg_pc=*p->content.rorg;
         org_pc=sec->pc;
@@ -273,8 +279,6 @@
       }
       else if(p->type==INSTRUCTION){
         dblock *db;
-        if(sec->pc!=oldpc)
-          general_error(50);  /* instruction had been auto-aligned */
         cur_listing=p->list;
         db=eval_instruction(p->content.inst,sec,sec->pc);
         if(pic_check)

Commited that for the next version. Thanks for your contribution.