AsmPro 1.19

[Photon]

Originally Posted by kamelito

@a/b
Set AsmOne to 68000
The code : move.w $bd.w, d0 should not be accepted an odd address error should be given instead.

The 68000 CPU supports this by opcode $303800BD. All 68000-only, and all 680x0 Assemblers must support this. This is the real reason, not that it's an odd address, or that you're reading instead of writing, or that you're moving directly instead of lea $bd.w,a0;move.w (a0),d0. If it warns you, it might (I say might) help you. If it doesn't finish Assembling a program with a valid opcode, I say it's not the Assembler you want.

[Bruce Abbott]

Originally Posted by Photon

If it doesn't finish Assembling a program with a valid opcode, I say it's not the Assembler you want.

Branch to an odd address is valid 68000 code too, but you wouldn't want the assembler to accept it.

In kamelito's example the coder made the mistake of forgetting to put a # in front of the number used in a dfb loop count. Their assembler (apparently) silently accepted this, resulting in a nasty bug in the executable.

The chances of wanting to load a word from an odd address on the 68000 is very small. The only valid reason for doing it is to induce an exception. IMO it is better for the assembler to treat it as an error.

On 68020+ it should warn, and have an option to error out (preferably set by default).

[phx]

I also spent some thoughts on this topic while developing vasm, and I'm with Photon. There should be no reason for the assembler to artificially restrict the developer, even if the code is probably stupid in most cases. As long as it is valid, you should be able to generate it.

In vasm I even allowed unaligned data and instructions, if you really want that (instructions only with an option). You may have a reason for it. And such errors with odd addressing are easily spotted with an Alignment Exception. They don't cause hard to find bugs.

Originally Posted by Bruce Abbott

Branch to an odd address is valid 68000 code too, but you wouldn't want the assembler to accept it.

That's probably a different case. It is unclear if branch-opcodes with bit 0 set are really defined. I know that the 68080 uses these patterns for new instructions.
Although I would allow them too. You can't check everything, anyway. For example when branching to an external symbol. An odd addend (label+1) may be legal, when the (unknown) destination label is also at an odd address.

The chances of wanting to load a word from an odd address on the 68000 is very small.

Even if the chance is one in a million, you will curse the assembler when you really need it. An optional warning is all I would consider.

Originally Posted by a/b

It will only check instruction and directive alignment (DC, DS, ...), and if 68020+ odd data is not enabled (asm prefs) it will error out.

I would turn that into a warning. There may be reasons for data at an odd address. Maybe you want to copy the data somewhere else, before using it, or it is a data structure in an external format you want to replicate. For example DWARF uses words at odd addresses.

[StingRay]

I agree with Photon and phx, any valid 680x0 opcodes have to be accepted by the assembler. If the assembler issues an error when it detects "stupid" opcodes, I'd immediately switch to another assembler. It's not the job of the assembler to decide if code is useful or not.

[Bruce Abbott]

Originally Posted by phx

Even if the chance is one in a million, you will curse the assembler when you really need it. An optional warning is all I would consider.

I'm already cursing my assemblers for not creating the opcodes I ask for, not allowing relocation etc. I put up with it because these particular assemblers are much faster.

I also curse compilers that generate code my assembler can't reproduce. What does vasm do with a 'negative' immediate byte value - does it extend it to a word or make the upper byte 0?

[phx]

Originally Posted by Bruce Abbott

What does vasm do with a 'negative' immediate byte value - does it extend it to a word or make the upper byte 0?

As far as I understand bits 8-15 of an 8-bit immediate operand word are undefined and reserved. Usually you would set such bits to 0, and this is what vasm does.

Which means

move.b #-1,d0

and

move.b #$ff,d0

will both be encoded as

$103c $00ff

.

I know there were a few assemblers which extended the sign into the undefined part of the word, and I added a compatibility flag in the IRA reassembler for those.

But this thread is about AsmPro and I hope it does the same.

[Photon]

Even if a sizecoder would like to use the high byte e.g. for 'storage', and would like only a warning if the immediate value doesn't fit in a byte, it wouldn't affect execution.

To code in Assembler is to care about every CPU instruction - if you structure you're code well and are not under pressure for speed or size - not every single one of them.

To use a higher-level language is to trust the compiler dev's knowledge of Assembler. (I hear some compilers are written in their own language as some kind of misguided test, but that obviously means the compiler generated unoptimized and generic code.)

My view is that since Assembler is what we use instead of direct opcodes, in theory all opcodes supported by the CPU (definition: does not trigger Illegal Instruction by the CPU) should be supported by the Assembler. Once that is covered, niceties can be added, but it's important to still avoid things we've seen like sub An->suba, dbf->dbra, "moveq.b" etc.

If it makes sense, I want to know that the price I pay and the reward for writing every CPU instruction is that what I write is translated exactly. Otherwise, there can be some confusion, and then you read the Disassembler output and trust moves to the Disassembler instead.

Now we're at a detailed level, and most coders will not be caught out or have the need for such precision. But I think that's still not a reason to not have it, it's a great bragging right! I'm sure all 68k Assemblers have flaws, including whatever GNU uses for 68k.

And this is understood and accepted. In those rare cases I can just declare the opcode.

If you want to make AsmPro more powerful, I have a few directive suggestions that I always wanted to see.

[oRBIT]

Any new version coming up soon?

[a/b]

Not on the horizon right now. Still haven't decided to fully dig into disassembler because I'd have to allocate a good chunk of time for that and there are too many things on the menu as is. v1.20 will primarily be just more bugfixes, you aren't missing much :P, but if you encounter any problems/bugs let me know and I'll release a new v1.19 build in the meanwhile.

[oRBIT]

Originally Posted by a/b

Not on the horizon right now. Still haven't decided to fully dig into disassembler because I'd have to allocate a good chunk of time for that and there are too many things on the menu as is. v1.20 will primarily be just more bugfixes, you aren't missing much :P, but if you encounter any problems/bugs let me know and I'll release a new v1.19 build in the meanwhile.

Can't get a macro to work that looks like this (illegal operand):
MyMacro:
MACRO
move.b d2,(a0,\1.l)
ENDM
It assembles in Asm-One... Is it my syntax?

[paraj]

Originally Posted by oRBIT

Can't get a macro to work that looks like this (illegal operand):
MyMacro:
MACRO
move.b d2,(a0,\1.l)
ENDM
It assembles in Asm-One... Is it my syntax?

Works for me if you don't have a newline between MyMacro and MACRO. I get (probably expected) "illegal operator" otherwise. How are you exactly defining/invoking it? Use sqaure-open-bracket([) CODE square-close-bracket (]) ... sqaure-open-bracket([) back-slash (/) CODE square-close-bracket (]) to inline some code here

[oRBIT]

Originally Posted by paraj

Works for me if you don't have a newline between MyMacro and MACRO. I get (probably expected) "illegal operator" otherwise. How are you exactly defining/invoking it? Use sqaure-open-bracket([) CODE square-close-bracket (]) ... sqaure-open-bracket([) back-slash (/) CODE square-close-bracket (]) to inline some code here

I attach a screenshot how I type it. Doesn't work that way anyway, running 1.19c..

[paraj]

Originally Posted by oRBIT

I attach a screenshot how I type it. Doesn't work that way anyway, running 1.19c..

Ahh, I thought \1 would be a register here. What addressing mode are you expecting to be generated?

[oRBIT]

Originally Posted by paraj

Ahh, I thought \1 would be a register here. What addressing mode are you expecting to be generated?

Not entirely sure of what you mean but Asm-One assembles this as:

move.b d2,(a0,$00000010.L)

[a/b]

I guess you want this: ($10,a0), or $10(a0) if using the old syntax? If so, the correct way is (\1,a0) or \1(a0). This implies (d16,ax) address reg 16-bit displacement indirect mode.
.L plus placing the offset after Ax implies 020+ full extension addressing. It's basically (d8,ax,ry*scale) but with a 32-bit displacement and supressed index ry.
It was implemented that way in order to differentiate between brief and full modes so you could have control what opcode will be generated because there is some overlap. To put it simple...
There might be bugs and complications/confusion with full extension addressing, because of all of that.

[oRBIT]

Originally Posted by a/b

I guess you want this: ($10,a0), or $10(a0) if using the old syntax? If so, the correct way is (\1,a0) or \1(a0). This implies (d16,ax) address reg 16-bit displacement indirect mode.
.L plus placing the offset after Ax implies 020+ full extension addressing. It's basically (d8,ax,ry*scale) but with a 32-bit displacement and supressed index ry.
It was implemented that way in order to differentiate between brief and full modes so you could have control what opcode will be generated because there is some overlap. To put it simple...
There might be bugs and complications/confusion with full extension addressing, because of all of that.

Interesting, it's (\1.l,a0) obviously I'm after, but after a bit of testing, that syntax seems to be limited to 16-bit offsets only (both AsmPro/AsmOne), as you obviously wrote above. The
syntax I mentioned earlier that doesn't work in AsmPro, supports 32-bit offsets in AsmOne.

[BraxtonDK]

I found this feature in AsmPro .. tested with v1.18 and v1.19c

$B03C0004 CMP.B #4,D0
$0C000004 CMPI.B #4,D0

When AsmPro assembles the Cmp.b, it get turned into Cmpi.b

now CMP.B #4,D0 is a leagal opcode.
so the quesation is should it be turned into Cmpi ?

When I assemble with vasm v1.9e .. it do not get changed.

ps: a/b thanks for updating AsmPro

[a/b]

Probably shouldn't but it gets away with it because it doesn't matter in 99.99% of situations. It does that not only with cmpi but many other "dual" opcodes, it's the way the parser is written. In this particular case if you write cmp it will ultimately end up using shared code for add/sub/cmp, so all the immediates get an "I".

[BraxtonDK]

Ahh right .. I just wanted to mention it, in case it was a problem.

[Photon]

Originally Posted by BraxtonDK

I found this feature in AsmPro .. tested with v1.18 and v1.19c

$B03C0004 CMP.B #4,D0
$0C000004 CMPI.B #4,D0

When AsmPro assembles the Cmp.b, it get turned into Cmpi.b

now CMP.B #4,D0 is a leagal opcode.
so the quesation is should it be turned into Cmpi ?

When I assemble with vasm v1.9e .. it do not get changed.

ps: a/b thanks for updating AsmPro

68000 PRM says,

CMPA is used when the destination is an address register. CMPI
is used when the source is immediate data. CMPM is used for
memory-to-memory compares. Most assemblers automatically
make the distinction.

The distinction here is that the first allows <ea>, and Imm is an ea. The second is a superfluous hard-coded immediate instruction that can have no other ea. Superfluous as in, there are no result or cycle differences (on 68000). It's probably this way because some other instructions that have no *I syntax share decoding circuitry with a list of ALU instructions of which CMP is a necessary one. Duplicate instructions simplifies the decoding circuit, and should (hopefully) be passed to the same execution circuit/microprogram.

Probably there are many instructions that work this way. I.e. cmp.b #4,a0 (or sub.b #4,a0) should have the same effect as the word size instruction, if you write an assembler that encodes the bit for .b.

But there might be some instruction word bits that are not ignored on the earlier CPUs, so that if the assembler would encode blindly and the CPU executes blindly could give some interesting side effects.