DISASM6 v1.5 - Nes oriented disassembler producing asm6 code
Moderator: Moderators
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".
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".
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".tokumaru wrote:Do any assemblers allow you to manually specify the relative displacement after a branch instruction?
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 ({}).
I allow that with xkas, although it's a 65816 assembler, it's compatible except for the 'illegal' opcodes with the 6502.tokumaru wrote:Do any assemblers allow you to manually specify the relative displacement after a branch instruction?
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
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.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.
you can however use relative labels in the user provided label list
What the programmer is saying is BCC $007F. Consider the case of code copied to zero page.koitsu wrote:There's absolutely no reason an assembler should not honour what the programmer says when they type "BCC $7F".
How about something close to BCC *+$7F, where * represents a program counter?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".
why? because it implies an addressing mode which doesn't exist?Dwedit wrote:I think BCC #xx should be an error. If you want to specify the relative branch yourself, use BCC $+2+offset.
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
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. :Dtepples wrote:How about something close to BCC *+$7F, where * represents a program counter?
Yes. # indicates immediate.frantik wrote:why? because it implies an addressing mode which doesn't exist?Dwedit wrote:I think BCC #xx should be an error. If you want to specify the relative branch yourself, use BCC $+2+offset.
then just put ut in the manual: "for branches, # acts similarly to immediate, but it's not technically the same thing."koitsu wrote:Yes. # indicates
immediate.
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
I added an option to disable creating labels in the PRG area (is that the right name? $8000 - $FFFF) when using STA/X/YDwedit 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".
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 +/-))
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?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.
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).tokumaru wrote: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?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.
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).
-
- Posts: 183
- Joined: Tue Apr 05, 2005 7:30 pm
You just helped me understand why the Z80 programmer's manual specified -126 to +129 for its relative jump operand range. :-)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).
Be whatever the situation demands.