nesdev.com
http://forums.nesdev.com/

DISASM6 v1.5 - Nes oriented disassembler producing asm6 code
http://forums.nesdev.com/viewtopic.php?f=2&t=7466
Page 6 of 8

Author:  tokumaru [ Fri Feb 25, 2011 8:47 pm ]
Post subject: 

Do any assemblers allow you to manually specify the relative displacement after a branch instruction? To me, it seems just logical that "$XX" is interpreted like an address, as that is the case with any other instruction, so I don't think ASM6 is doing anything wrong here. "BCC #$7F" may look weird, but looks to me like a more logical way to explicitly represent the displacement...

I mean, if someone doesn't want to use labels for whatever reason they are allowed to use addresses as arguments to branch instructions, right? With every other instruction, if I use "$XX" that number is interpreted as an address, so why would it be any different with the Bxx instructions? IMO, "BCC $7F" should mean "branch to address $7F" and "BCC #$7F" should mean "branch to the location 127 bytes ahead".

Author:  frantik [ Fri Feb 25, 2011 9:16 pm ]
Post subject: 

tokumaru wrote:
IMO, "BCC $7F" should mean "branch to address $7F" and "BCC #$7F" should mean "branch to the location 127 bytes ahead".



i tend to agree, though BCC #$7F is treated just like BCC $7F in asm6.. i think BCC #$7F should throw a proper error message at least

Author:  koitsu [ Sat Feb 26, 2011 2:14 am ]
Post subject: 

tokumaru wrote:
Do any assemblers allow you to manually specify the relative displacement after a branch instruction?


Yes, I'm pretty certain Merlin 8/16 and ORCA/M both behave this way, and I know the Apple IIGS mini-assembler behaves this way as well. There's absolutely no reason an assembler should not honour what the programmer says when they type "BCC $7F". The result should be $90 7F. If the assembler prefers to treat $7F as an address instead of an offset, there should at least be a way to honour literal offsets (possibly something like "BCC =$7F".

As for disassemblers: some disassemblers show the displacement in a human-friendly form, e.g. "90 7F" disassembles into "BCC $7F ; +128" or if the disassembler supports labelling then "BCC <nearlabel>" with "<nearlabel> <some code>" further down in the disassembly. For negative offsets, it would show -XXX.

I've also seen disassemblers which would output "BCC $7F {+128}" or "BCC $7F {nearlabel}, which is basically the same as the above but with the label and human-friendly offset written in literal braces ({}).

Author:  loopy [ Sat Feb 26, 2011 3:06 am ]
Post subject: 

asm6 is not supposed to be parsing BCC #$xx. It's a bug and I'll look into it.

On BCC $address, I am 100% in agreement with tokumaru. I started another post arguing with you, but realized I was repeating what he already wrote so I deleted it. You can reread his post instead :P

Author:  byuu [ Sat Feb 26, 2011 3:08 am ]
Post subject: 

tokumaru wrote:
Do any assemblers allow you to manually specify the relative displacement after a branch instruction?


I allow that with xkas, although it's a 65816 assembler, it's compatible except for the 'illegal' opcodes with the 6502.

It's quite handy when you are writing hundreds of small inline patches and don't want to break it down into individual labeled lines.

org $8214; sta $2180; dex; bne $fa //easier to do the math in your head

Author:  frantik [ Sat Feb 26, 2011 6:07 am ]
Post subject: 

koitsu wrote:
if the disassembler supports labelling then "BCC <nearlabel>" with "<nearlabel> <some code>" further down in the disassembly. For negative offsets, it would show -XXX.


I considered doing that but then there is the potential for up to 3 labels for 1 memory location. There isn't much difference between -_C010 and __C010 anyways, and if you use non-unique labels then you have to keep track of them to ensure it is ok to use it in that context.

you can however use relative labels in the user provided label list

Author:  tepples [ Sat Feb 26, 2011 8:35 am ]
Post subject: 

koitsu wrote:
There's absolutely no reason an assembler should not honour what the programmer says when they type "BCC $7F".

What the programmer is saying is BCC $007F. Consider the case of code copied to zero page.

Quote:
The result should be $90 7F. If the assembler prefers to treat $7F as an address instead of an offset, there should at least be a way to honour literal offsets (possibly something like "BCC =$7F".

How about something close to BCC *+$7F, where * represents a program counter?

Author:  Dwedit [ Sat Feb 26, 2011 8:53 am ]
Post subject: 

I think BCC #xx should be an error. If you want to specify the relative branch yourself, use BCC $+2+offset.

Author:  frantik [ Sat Feb 26, 2011 10:13 am ]
Post subject: 

Dwedit wrote:
I think BCC #xx should be an error. If you want to specify the relative branch yourself, use BCC $+2+offset.


why? because it implies an addressing mode which doesn't exist?

from a readability standpoint, I much prefer BCC #offset vs BCC $+2+offset.. and regardless of addressing mode, it makes sense. i mean LDA #$7F will always put a 7F after the opcode, so BCC #$7F should as well

Author:  koitsu [ Sat Feb 26, 2011 12:48 pm ]
Post subject: 

tepples wrote:
How about something close to BCC *+$7F, where * represents a program counter?


Works for me. Honestly anything works, as long as it's documented in the manual that comes with the assembler. Sub-par assembler documentation is unacceptable. :D

frantik wrote:
Dwedit wrote:
I think BCC #xx should be an error. If you want to specify the relative branch yourself, use BCC $+2+offset.


why? because it implies an addressing mode which doesn't exist?


Yes. # indicates immediate.

Author:  frantik [ Sat Feb 26, 2011 4:41 pm ]
Post subject: 

koitsu wrote:
Yes. # indicates
immediate.


then just put ut in the manual: "for branches, # acts similarly to immediate, but it's not technically the same thing." :D

conceptually, # means "a number which isn't a memory address" to me.

it's obviously up to loopy though.. and it's not even an issue really since i doubt many people will ever use the feature.. i'm not even quite sure why my code was generating BCC #$7F style output, and it's not now

Author:  frantik [ Sat Feb 26, 2011 11:41 pm ]
Post subject: 

Dwedit wrote:
Mapper writes confuse the disassembler, for example, it thinks that A000 is data because there are writes pointing there. Also looks like FCEUX thought it was data too, because it was marked as both data and code in the CDL file. Maybe "code" should always trump "data".


I added an option to disable creating labels in the PRG area (is that the right name? $8000 - $FFFF) when using STA/X/Y

working on a good way to be able to name them (right now when you make any label it will be placed into the program code unless it has a + or - in the text (but doesnt start with +/-))

Author:  tokumaru [ Sun Feb 27, 2011 7:57 pm ]
Post subject: 

koitsu wrote:
There's absolutely no reason an assembler should not honour what the programmer says when they type "BCC $7F". The result should be $90 7F.

But what if I don't want to use labels and still want the assembler to calculate the relative displacement for me? What do I do if I really want to branch to address $7F but don't want to have a label marking that position?

Author:  koitsu [ Mon Feb 28, 2011 3:16 am ]
Post subject: 

tokumaru wrote:
koitsu wrote:
There's absolutely no reason an assembler should not honour what the programmer says when they type "BCC $7F". The result should be $90 7F.

But what if I don't want to use labels and still want the assembler to calculate the relative displacement for me? What do I do if I really want to branch to address $7F but don't want to have a label marking that position?

I don't have an answer to this question. :-) I think overall the best approach is to implement both methods and document in the assembler documenation whichever one requires a quirk (e.g. BCC =$7F).

Tepple's example of using *+$7F is ideal, but to minimise support requests, I would recommend changing the branch-too-far error message to indicate the boundaries explicitly (-128 to +127 or -126 to +129, depending on if the author wants to take into consideration the branch being from the end of the instruction or the opcode, respectively. Let's not get too OCD about this one though; if I had to vote on which to output, it would be the former).

Author:  doppelganger [ Mon Feb 28, 2011 5:19 am ]
Post subject: 

koitsu wrote:
I don't have an answer to this question. :-) I think overall the best approach is to implement both methods and document in the assembler documenation whichever one requires a quirk (e.g. BCC =$7F).

Tepple's example of using *+$7F is ideal, but to minimise support requests, I would recommend changing the branch-too-far error message to indicate the boundaries explicitly (-128 to +127 or -126 to +129, depending on if the author wants to take into consideration the branch being from the end of the instruction or the opcode, respectively. Let's not get too OCD about this one though; if I had to vote on which to output, it would be the former).


You just helped me understand why the Z80 programmer's manual specified -126 to +129 for its relative jump operand range. :-)

Page 6 of 8 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/