Starting ASM coding on A1200. Which Assembler?

[NorthWay]

Originally Posted by meynaf

I don't think Barfly would assemble my 4MB HOMM2 source file

Why not?

I was betatesting Barfly and I put it through some pretty stupid shit that made laire roll his eyes. And he fixed it all.

[Thorham]

Originally Posted by meynaf

I don't think Barfly would assemble my 4MB HOMM2 source file

That's because you use Phxass specific functions Do you really need those?

[meynaf]

First I'm often writing :

 macro name

instead of :

name macro

which is supported by phxass but not by barfly (bad habit i know, but it would need many changes everywhere).

Requires cachefile.library or it will refuse to assemble (phxass does not need any lib).

I do *not* want to see that flooding the output when assembling my cpu test routines :
Warning 542: You use a supervisor command.
Warning 541: You should be aware of the Move16 problems.

 bra.s tc

Is rejected (under the fallacious pretext that "tc" is a mmu register).

Barfly does not support the EQURL directive. I don't think this is really PhxAss specific.

Of course it does not support the BASEREG directive, which is a must have for me (and no, offsets won't save me because i sometimes do var instead of var(a5) when a5 isn't available).

It also can't convert short branches into long branches when they don't fit (or at least it doesn't do this by default).

I don't know how to give it a config file like PHXOPTIONS does, which would tell it where to fetch my framework include files.

And finally the best one, enough by itself to throw the program in the bin :
Error 87: Demo limitation. If you like this product please registrate.

I got Barfly 2.00 from Aminet and checked my sources quite superficially to find this. More problems certainly exist...

[NorthWay]

Originally Posted by meynaf

Warning 542: You use a supervisor command.

"super"

Originally Posted by meynaf

Warning 541: You should be aware of the Move16 problems.

"opt wm-"

Originally Posted by meynaf

Barfly does not support the EQURL directive. I don't think this is really PhxAss specific.

Don't think I know this. What does it do? Alias for a list of registers?

Originally Posted by meynaf

Of course it does not support the BASEREG directive, which is a must have for me (and no, offsets won't save me because i sometimes do var instead of var(a5) when a5 isn't available).

Also unknown. What does it do?

Originally Posted by meynaf

It also can't convert short branches into long branches when they don't fit (or at least it doesn't do this by default).

Are you sure? Might be that it assumes you know what you do when you specify size, but it will easily do 13 passes over the source to try and optimize sizes.

Originally Posted by meynaf

I don't know how to give it a config file like PHXOPTIONS does, which would tell it where to fetch my framework include files.

I typically don't use anything like that but I know it has several options for setting/using options.

But I thought the Aminet version was unlimited? It seems my version is more recent as it is 2.17.

[meynaf]

Originally Posted by NorthWay

"super"

"opt wm-"

May i put that in some config file so that i don't have to use them in every source ?

Originally Posted by NorthWay

Don't think I know this. What does it do? Alias for a list of registers?

Your guess is right. I have adaptative (often included) code that may or may not trash a register, and so the reg-save list changes accordingly.

Originally Posted by NorthWay

Also unknown. What does it do?

Allows automatic register-relative access. Like this :

 basereg zbss,a5
 lea zbss,a5
 move.l var2(a5),d0

 bss
zbss
var1 ds.l 1
var2 ds.l 1
var3 ds.l 1

Asm-one also supports this directive.

Originally Posted by NorthWay

Are you sure? Might be that it assumes you know what you do when you specify size, but it will easily do 13 passes over the source to try and optimize sizes.

I sure am.
This :

 bra.s label
 ds.w $100
label

Gives :
Error 56: The Argumentvalue is larger than the operand width.

Originally Posted by NorthWay

I typically don't use anything like that but I know it has several options for setting/using options.

The doc mentions something in ENV: indeed. I have to check it more closely.

Originally Posted by NorthWay

But I thought the Aminet version was unlimited? It seems my version is more recent as it is 2.17.

Seems it's not. Basm says version 2.9. Where to fetch a more recent one ? Preferably the latest ?

[Thorham]

Originally Posted by meynaf

Requires cachefile.library or it will refuse to assemble (phxass does not need any lib).

Does that really matter? Isn't that library the program's own library? It's included in the package after all.

Anyway, I'm not trying to convert you. I just like Barfly because of it's speed.

[meynaf]

Originally Posted by Thorham

Does that really matter? Isn't that library the program's own library? It's included in the package after all.

If each program i use adds its own .library to libs: then my libs: will look like a windows directory...
Is this lib used for other programs beside barfly ? If not, i don't see the point in doing a .library.
It's not a big deal for a program that has its own dir and the lib can be just sitting here. But basm should be callable from everywhere and ideally sitting in C: (the amiga's regular command dir).

Originally Posted by Thorham

Anyway, I'm not trying to convert you. I just like Barfly because of it's speed.

Can't check because my large code won't assemble, but i wouldn't bet. It may be possible that phxass is indeed faster and then your choice loses its sole purpose...

[Thorham]

Originally Posted by meynaf

If each program i use adds its own .library to libs: then my libs: will look like a windows directory...

Indeed.

Originally Posted by meynaf

Is this lib used for other programs beside barfly ?

Probably not.

Originally Posted by meynaf

If not, i don't see the point in doing a .library.

I think it's part of the include cache mechanism. Of course, the program could just generate a library in memory.

Originally Posted by meynaf

It's not a big deal for a program that has its own dir and the lib can be just sitting here. But basm should be callable from everywhere and ideally sitting in C: (the amiga's regular command dir).

I use a setup script for that. That way I keep all files in the program directory. Having to type something like 'setupbarfly' isn't a problem for me.

Originally Posted by meynaf

It may be possible that phxass is indeed faster and then your choice loses its sole purpose...

Perhaps not. It has things like _MOVEMBYTES and _MOVEMREGS which represent the byte count and register mask of the last movem. These can be very nice to have.

I also like Barfly because it feels nicer than Phxass

[meynaf]

Originally Posted by Thorham

Perhaps not. It has things like _MOVEMBYTES and _MOVEMREGS which represent the byte count and register mask of the last movem. These can be very nice to have.

A lot of things are "nice". But among these things, not all are really useful. So i still have to see a use case for these.

Originally Posted by Thorham

I also like Barfly because it feels nicer than Phxass

For me it's the opposite.
But i am not especially attached to phxass. It's just that no other asm does the job (vasm is the only other asm that can assemble my code, but it is too slow and memory hungry for practical use).

[NorthWay]

Originally Posted by meynaf

Allows automatic register-relative access. Like this :

 basereg zbss,a5
 lea zbss,a5
 move.l var2(a5),d0

 bss
zbss
var1 ds.l 1
var2 ds.l 1
var3 ds.l 1

Asm-one also supports this directive.

Sounds a bit like "smalldata" directive.

Originally Posted by meynaf

 bra.s label
 ds.w $100
label

bopt wm-,O+,OG+,wo-

Originally Posted by meynaf

Seems it's not. Basm says version 2.9. Where to fetch a more recent one ? Preferably the latest ?

Sorry, don't know. I got mine from laire so I'm not gonna spread without knowing status.

[meynaf]

Originally Posted by NorthWay

Sounds a bit like "smalldata" directive.

Seems so. But basereg allows the starting point anywhere in the section.
I'm usually having two baseregs on the same register : one for the app, one for my included framework. Thus both can have access to 64k.

Originally Posted by NorthWay

Sorry, don't know. I got mine from laire so I'm not gonna spread without knowing status.

Yikes. For Phxass i even have the sources somewhere...
Can that guy be contacted ?


One day or another i'll write my own asm program. Unsure it will be for 68k, though.

[Thorham]

Originally Posted by meynaf

A lot of things are "nice". But among these things, not all are really useful.

That applies to some of what you list as well.

1. Basereg -> Define a structure.
2. Regsiter lists -> Define a macro.

Many things are just conveniences.

Originally Posted by meynaf

So i still have to see a use case for these.

_MOVEMBYTES is handy for passing parameters using the stack and _MOVEMREGS is useful if you used a register list as a macro parameter and want to use the same register list in another macro without having to specify it again.

Originally Posted by meynaf

For me it's the opposite.

Typical how that works

Originally Posted by meynaf

Seems it's not. Basm says version 2.9. Where to fetch a more recent one ? Preferably the latest ?

It seems the author released the registered version on Aminet at some point. You must've downloaded the shareware version before the registered version was released.

[meynaf]

Originally Posted by Thorham

1. Basereg -> Define a structure.

Can't do that. It wouldn't work for a direct access.
IOW, I'm pretty sure i have quite a few move.l label,a0 which would be converted without warning into things like move.l $8,a0.
Besides, a structure is defined prior to use, not at the end like the bss.

Originally Posted by Thorham

2. Register lists -> Define a macro.

Could be done.

Originally Posted by Thorham

Many things are just conveniences.

It's the little things that add together...

Originally Posted by Thorham

_MOVEMBYTES is handy for passing parameters using the stack and

Who does that in asm ?
Anyway if there is another MOVEM in the routine, you're in big trouble.

Originally Posted by Thorham

_MOVEMREGS is useful if you used a register list as a macro parameter and want to use the same register list in another macro without having to specify it again.

This is normally done with the EQURL directive

Originally Posted by Thorham

It seems the author released the registered version on Aminet at some point. You must've downloaded the shareware version before the registered version was released.

I got it today from http://aminet.net/package/dev/asm/BarflyDisk2_00


Another problem is this :
Error 43: You can't use this char combination in a symbol.

So barfly, too, rejects accentuated characters in symbols, which is a very big annoyance for a french coder like myself.
I bugged Frank Wille quite a lot to get support for that in Vasm, btw.

[Leffmann]

Originally Posted by meynaf

I don't think Barfly would assemble my 4MB HOMM2 source file

I doubt that's the case, but if it is then it's hardly something speaking against basm. A software consisting of 4 MB source code may be a merit, but 4 MB source code in a single file is just a case of "you're doing it wrong".

Anyway, I know of at least 1 bug in Basm 2.9 from Barfly 2.0, and there should be at least a Basm 2.16 available, and a Barfly 2.9 package, but I don't know if it's possible to find Ralph Schmidt to get hold of these.

[meynaf]

Originally Posted by Leffmann

I doubt that's the case, but if it is then it's hardly something speaking against basm. A software consisting of 4 MB source code may be a merit, but 4 MB source code in a single file is just a case of "you're doing it wrong".

Apparently you have never resourced a large program, huh ?

[Thorham]

Originally Posted by meynaf

Can't do that. It wouldn't work for a direct access.
IOW, I'm pretty sure i have quite a few move.l label,a0 which would be converted without warning into things like move.l $8,a0.
Besides, a structure is defined prior to use, not at the end like the bss.

With Barfly you can do this:

a
    lea     bssdat,a0
    move.l  #$12345678,var1(a0)
    rts

    section bss

            rsset   0
var1        rs.l    1
var2        rs.l    1
var3        rs.l    1
sizeOf_bss  rs.l    0

bssdat
    ds.b    sizeOf_bss

Originally Posted by meynaf

Could be done.

Not fabulously handy, but it should indeed work.

Originally Posted by meynaf

It's the little things that add together...

That's true. After all, we're not writing everything in hex anymore.

Originally Posted by meynaf

Who does that in asm ?

What's wrong with it?

Originally Posted by meynaf

Anyway if there is another MOVEM in the routine, you're in big trouble.

label set _MOVEMBYTES

Originally Posted by meynaf

I got it today from http://aminet.net/package/dev/asm/BarflyDisk2_00

That's not the registered version?

Originally Posted by meynaf

Another problem is this :
Error 43: You can't use this char combination in a symbol.

So barfly, too, rejects accentuated characters in symbols, which is a very big annoyance for a french coder like myself.
I bugged Frank Wille quite a lot to get support for that in Vasm, btw.

Yeah, that's a good one.

[meynaf]

Originally Posted by Thorham

With Barfly you can do this:

a
    lea     bssdat,a0
    move.l  #$12345678,var1(a0)
    rts

    section bss

            rsset   0
var1        rs.l    1
var2        rs.l    1
var3        rs.l    1
sizeOf_bss  rs.l    0

bssdat
    ds.b    sizeOf_bss

Which is not as practical as writing :

 basereg bssdat,a5

 lea bssdat,a5
 move.l #$12345678,var1(a5)
 rts
interrupt_routine
 addq.l #1,var1
 rte

 bss
var1 ds.l 1
var2 ds.l 1
var3 ds.l 1

Originally Posted by Thorham

What's wrong with it?

Depends on the case, but it's usually better to pass them in registers.

Originally Posted by Thorham

That's not the registered version?

Seems not, as it's that version which got the message.

[Thorham]

Originally Posted by meynaf

Which is not as practical as writing :

 basereg bssdat,a5

 lea bssdat,a5
 move.l #$12345678,var1(a5)
 rts
interrupt_routine
 addq.l #1,var1
 rte

 bss
var1 ds.l 1
var2 ds.l 1
var3 ds.l 1

True, you'd need extra labels.

Originally Posted by meynaf

Depends on the case, but it's usually better to pass them in registers.

Perhaps.

Originally Posted by meynaf

Seems not, as it's that version which got the message.

That's strange because I just tried it with a one megabyte test source in WinUae. I simply made a partition out of the Barfly directory and booted with that. Then copied that big source into the directory and assembled. Worked fine. Perhaps an older Barfly is still in C:? The version on Aminet really should be the registered version.

[meynaf]

Originally Posted by Thorham

That's strange because I just tried it with a one megabyte test source in WinUae. I simply made a partition out of the Barfly directory and booted with that. Then copied that big source into the directory and assembled. Worked fine. Perhaps an older Barfly is still in C:? The version on Aminet really should be the registered version.

Well, i just dearchived the lha to a temp directory and put both the command and the library it asks to ram:. Then any sufficiently big file ends up with the error message. But i found no keyfile in the archive. How does it know it is registered ?
Anyway, you probably have a more advanced version than the one on aminet, haven't you ?

[Thorham]

Originally Posted by meynaf

Well, i just dearchived the lha to a temp directory and put both the command and the library it asks to ram:.

Do what I did. Make a partition out of the Barfly directory and boot from that. Should work.

Originally Posted by meynaf

But i found no keyfile in the archive. How does it know it is registered ?

It doesn't need one.

Originally Posted by meynaf

Anyway, you probably have a more advanced version than the one on aminet, haven't you ?

Nope. The one on Aminet is the right version.

Something strange is happening for sure