vasm 1.5 RFC

[phx]

Soon I would like to bump the version of vasm (http://sun.hasenbraten.de/vasm/) to V1.5 and I would like to do my best to make it as stable and useful as possible.
So when anybody has a problem with V1.4f or the daily source snapshot, please tell me now. I'm also open for new features, as long as their complexity doesn't destabilize the current version.

[Cosmos]

Two new mnemonics :

bra2.b Label+2 => for $0C40

bra4.b Label+4 => for $51FA


Please Frank, we don't like some 'dc.w $0C40' in the sources...

[SyX]

Originally Posted by Cosmos

Two new mnemonics :

bra2.b Label+2 => for $0C40

bra4.b Label+4 => for $51FA


Please Frank, we don't like some 'dc.w $0C40' in the sources...

In this case, i think that it would better to use a pair of macros or i don't understand at Cosmos.

[Cosmos]

>macros

Too much complicated !

[phx]

I have to agree with Lionheart that it doesn't make much sense. It just makes your source incompatible with any other assembler.

But if you really want that, you can insert the following line into cpus/m68k/opcodes.h:

  "bra2",     {0},          {{0},              {0x0c40,0},1|UNS|S_NONE,m68000up|mcf},

The name is also bad. I think something like "skip" would be better. And the label field is not really required.

[StingRay]

Originally Posted by Cosmos

>macros

Too much complicated !

bra2	MACRO
	dc.w    $0c40 ; cmp.w #xx,d0
        ENDM

What's complicated about that?

[Leffmann]

Just cosmetic details, but some flexibility in the if-directives would be nice, so you could f.ex eliminate the .size in:

       cnop   0, 4
Start  ...
       ...
       rts

.size  = *-Start 
       if     .size > 256
        fail  "code will not fit in cache"
       endif

Also, complementing the comment directive with a comments-endcomments pair for multiple lines would be great.

[phx]

Originally Posted by Leffmann

Just cosmetic details, but some flexibility in the if-directives would be nice, so you could f.ex eliminate the .size in:

       cnop   0, 4
Start  ...
       ...
       rts

.size  = *-Start 
       if     .size > 256
        fail  "code will not fit in cache"
       endif

Ok, done. That was a bug. There must be no difference between .size and *-Start.
Be aware that such kind of code is dangerous. Directives for conditional assembly have to evaluate in the first pass and changes in further passes will not be recognized (e.g. through optimizations).

Also, complementing the comment directive with a comments-endcomments pair for multiple lines would be great.

That would need more than a minute to implement, but could be done. Should I use the REM and EREM directives from AsmOne?

[Leffmann]

Originally Posted by phx

Be aware that such kind of code is dangerous. Directives for conditional assembly have to evaluate in the first pass and changes in further passes will not be recognized (e.g. through optimizations).

Yeah I see now how ASM-One's if2 directive is useful for these things.

Any keywords for multiple comments would be fine, up to you, but I think it's important that they're available at all times, so you don't have to set f.ex an ASM-One compatibility mode.

[phx]

Originally Posted by Leffmann

Any keywords for multiple comments would be fine, up to you, but I think it's important that they're available at all times, so you don't have to set f.ex an ASM-One compatibility mode.

Ok, done. I used REM and EREM.

BTW, the same effect can be reached by using REPT 0, which might be more portable. But I didn't test if all assemblers accept a 0 counter.

[Leffmann]

Another cosmetic detail, I noticed that f.ex blk.l 10, label is not valid, and you have to use a larger rept-dc.l-endr construct to work around it.

[StingRay]

Originally Posted by Leffmann

Another cosmetic detail, I noticed that f.ex blk.l 10, label is not valid, and you have to use a larger rept-dc.l-endr construct to work around it.

I don't use vasm but, did you try dcb.l instead of blk (which is, as far as I know, Seka (and Asm1 for obvious reasons) only)?

[phx]

Originally Posted by Leffmann

Another cosmetic detail, I noticed that f.ex blk.l 10, label is not valid, and you have to use a larger rept-dc.l-endr construct to work around it.

DCB and BLK belong to the same family as DS. They reserve memory space and optionally fill it with a pattern. Internally they are represented by a "space"-atom, which was not meant to carry relocations.

Is that really needed? Ok. I enhanced the space atom to support relocations.

[Leffmann]

Originally Posted by phx

Is that really needed? Ok. I enhanced the space atom to support relocations.

Maybe not needed but the reason I use vasm is that it's the most powerful, flexible and convenient to use assembler, so I'll usually suggest these things if I think they can make vasm even better, and I think it's great that you're so accommodating.

[SyX]

Originally Posted by Leffmann

Maybe not needed but the reason I use vasm is that it's the most powerful, flexible and convenient to use assembler, so I'll usually suggest these things if I think they can make vasm even better, and I think it's great that you're so accommodating.

Totally Agreed!!! Besides, Frank is a GREAT GUY!!!

[Cosmos]

Other very usefull idea :

hunk organisation = begin with the first... and the last

Let's user choose with an option, like -hunkorder...

[meynaf]

VAsm v1.3c does not support such constructions even in phxass compatibility mode :

 basereg mybss,a5

 lea myvar(a5),a0

 bss
mybss
myvar ds.l 1

PhxAss did support that. On vasm (1.3c, did not test 1.4) it requires mybss to be declared prior to the basereg and it is very bad for me.

[phx]

BASEREG and ENDB were not supported before V1.4. So I don't know how you got it to accept basereg at all with 1.3c?

When there are no more bug reports in the following days I will probably release V1.5 soon. The daily snapshot can always be tested from: http://sun.hasenbraten.de/vasm/index.php?view=source

[Leffmann]

Not sure if this is a bug or a user error, but whenever I use -devpac to turn all optimizations off and specify opt o1+ to enable branch optimizations only, it also optimizes move #0 to clr, and add to addq.

What I want is to disable all optimizations except branches without explicit size. Is this possible?

[phx]

Originally Posted by Leffmann

Not sure if this is a bug or a user error, but whenever I use -devpac to turn all optimizations off and specify opt o1+ to enable branch optimizations only, it also optimizes move #0 to clr, and add to addq.

That's because vasm has no optimization flags for most 'safe' optimizations. They are always enabled as soon as the no-opt flag is cleared.

move #0 to clr is not a safe optimization for the 68000, BTW. So I assume you were generating code for 68010+?

What I want is to disable all optimizations except branches without explicit size. Is this possible?

Not with pre-1.5 versions. I'm currently working on a solution and notify this thread when it is available. The massive changes require some more testing though, which will delay the release...