[vasmm68k] what are these optimizations ?

Hello,

As you know, the assembler vasmm68k is doing some automatic optimizations when it finds token which could be translated in a quicker opcode.

I've understand some of them, but other are quite a mystery for me.

As i'd like get rid of them (too much warning means difficult vasm output to read), perhaps someone could explain to me what i could write instead.
The problem is what i've written in my source is what is generated (i've checked it with fs-uae debugger).

Here is a sample of what i get:

message 2050 in line 41 of "print.s": operand optimized: abs.l->abs.w
>  clr.w 0x100 ; fs-uae: w 0 100 2

not much to say to this one, nothing has changed after compilation:
4278 0100 CLR.W $00000100

message 2050 in line 45 of "print.s": operand optimized: abs.l->abs.w
>  move.l execbase, %a6

Same message than above.
«execbase» is just an equ defined like this:
.equ execbase,4

and it gives:

2c78 0004 MOVEA.L $00000004,A6

I still don't see what has been optimized.


Well, i got some others, like this one:

message 2050 in line 91 of "print.s": operand optimized: label->(d16,PC)
>  lea hexatable,%a1

message 2050 in line 92 of "print.s": operand optimized: label->(d16,PC)
>  lea hexares,%a2

these «lea» refer to data chunk, just after the rts of the subroutine:
(it's my own hex to ascii translation routine, if you say it's ugly, tell me how to improve it )

print_d0:
  movem.l %d0-%d2/%a1-%a2,-(%sp)
  rol.l #4,%d0
  move.l %d0,%d1
  lea hexatable,%a1
  lea hexares,%a2
  moveq #7,%d2
loop_ph:
  and.l #0xf,%d0
  move.b (%a1,%d0),(%a2)+
  rol.l #4,%d1
  move.l %d1,%d0
  dbra %d2,loop_ph
  movem.l (%sp)+,%d0-%d2/%a1-%a2
  print hexares,10
  rts
  hexatable: .ascii "0123456789ABCDEF"
  hexares: .rept 8
           .byte 0
           .endr
           .ascii "\r\n"

Thank you.

[Mrs Beanbag]

it has indeed optimised the first two examples. It is using short addressing.

4278 0100 instead of 4279 0000 0100

and
2C78 0004 instead of 2C79 0000 0004

the LEAs have been converted to PC-relative addressing. Do instead, for instance:
lea hexares(%pc),a2

one could in fact dispense with a1 entirely and just do:
move.b hexatable(%pc,%d0),(%a2)+

I didn't knew what short form was.
That's why i hadn't understood what the compiler said to me. I was focused on the length of the clr. For example, i tried clr.w, but now i understand the difference.

for the move with my .equ, fortunately, the compiler accepts this form:

move.l (register).w,%a6

(i tried the same syntax that the one used when dereferencing address registers and it worked).


Thank you.

(the road is straight but the slope is hard )

[matthey]

Are you using -devpac mode of vasm? Optimizations are not shown by default unless using -devpac mode (turned on with -devpac option from the CLI). The optimization messages can be turned off with OPT OW- or on with OPT OW+ in your assembler source. Normal error messages and warnings are displayed with optimization messages off. The vasm manual (English only) is very good and can be found here:

http://sun.hasenbraten.de/vasm/

I let vasm do some of the optimizations as it saves time. It's important to be aware of what optimizations are being performed but there is nothing wrong with letting vasm do optimizations for you, especially while you are learning. I leave branches unsized because vasm can optimize them completely unlike most other assemblers.

Originally Posted by pixel

for the move with my .equ, fortunately, the compiler accepts this form:

move.l (register).w,%a6

This should actually be:

move.l (address).w,%a6

It would more commonly be written:

move.l (xxx).w,a6

Vasm doesn't need the % sign for registers by the way. You would save yourself some time if you didn't use them and it may be more readable without them.

Matthey, i use those options in my makefile

$(exe): $(obj)
        vlink -bamigahunk -s $^ -o $(exe)

%.o: %.s
        vasmm68k_std -m68020 -elfregs -showopt -Fhunk -o $@ $<

So, no -devpac mode, i think.

But i'm interested in seeing (and more important, understanding) the optimizations made. So, i wouldn't turn off optimization report.

I've made a mistake with my
move.l (register).w,%a6

Why did i write register instead of execbase, i don't know!

So, the correct thing is of course, as you pointed:

.equ execbase , 0x4
move.l (execbase).w,%d6

I use % for prefixing register, because i've compiled vasm in «std» mode. It uses the AT&T assembler syntax (like the GNU assembler from their binutils).

In fact, i'd rather like using GAS (GNU Assembler) than another assembler at the beginning. They support virtually every CPU that had existed since the beginning. And the advantage is to get a very good support, a well-tried codebase (depends of course of the popularity of the CPU) and always the same syntax, from z80 to 680x0.

When i began with the AT&T syntax, i found it rather clumsy. But i'm now accustomed to it, and i prefer to put % before registers. In this way, they are differentiated from variables. Even if in assembly languages, you don't have the problems you get with «soft-typed» languages, where every keystroke fault gives you a new variable

I finally decide to use vasm/vlink when i saw the documentation (it shows the product is seriously written), and couldn't manage to compile GNU binutils with Amiga support (lot of patch to apply, and i'd rather like not rewrite a BFD myself for getting the correct backend). But i'm happy, vasm is nice