| |
Higgie
Registered: Apr 2002
Posts: 127 |
Branch too far in 64TASS
hiho!
what does 'Branch too far' mean?
the readme of 64tass says: 'can't relative branch that far'
i understand that sentence but what is the limit then?
and how to deal with the limitation?
sorry for coming up with stupid stuff already known to most of the decent coders here.... ;)
thanx in advance! |
|
| |
Scout
Registered: Dec 2002
Posts: 1570 |
If you jump using branches (beq, bne, bcc...) you can only jump 128 bytes back and forth.
You can solve this using a combination of branches and jmps.
You can also this in the 64tass manual:
Quote:
To avoid branch too long errors the assembler also supports long branches, it can automatically convert conditional relative branches to it's opposite and a JMP. This have to be enabled on the command line using the "--long-branch" option.
bcc veryfar ;compiled as "bcc veryfar" or
; bcs sk
; jmp veryfar
;sk
|
| |
Higgie
Registered: Apr 2002
Posts: 127 |
wow! thanx, scout!
i see, there are a lot of small things to keep in mind when coding assembler.
it's too easy to forget about such things if you have done java for some years. ;)
so if i understand this properly i can switch on that commandline option and my branches will get converted. sounds easy! :) |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote:
so if i understand this properly i can switch on that commandline option and my branches will get converted. sounds easy! :)
Yup! :-)
Keep in mind it's not the most elegant way especially when you're optimizing (speed)code.
Besides that, you're losing control over the compiled code. That could be a pain when debugging. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
What Scout says. Under normal circumstances (demo or game coding) you wouldn't want the compiler to automatically generate long branches for you. |
| |
Higgie
Registered: Apr 2002
Posts: 127 |
well, i don't see it being 'normal circumstances' when i'm coding assembler. ;)
'premature optimization is the root of all evil' (Donald E. Knuth) ... i know!
but as long as the assembler gives me a warning i think it's ok. so i can come back to that branch later to rework my code, if necessary. atm i'm quite happy that i don't have to deal with all those little obstacles myself. your help and the little help from 64tass are well appreciated. :)
i will keep in mind that there could occur some implicit behaviour depending on the assembler options i use. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@higgie: just do it manually. :D I mean, if the compiler complains, simply invert your branch and add a jmp. It's really not that hard.
F.e.
beq farAwayThatComplains
Invert it and make it branch past the jmp:
bne *+3
jmp farAwayThatComplains ; won't complain anymore
Simple as that!
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Agree with Scout et al, this long branch feature sounds risky. Any coder will learn how to make long branches as one of the first things. At least it should be a pseudo command, e.g. "lbcc".
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
If I was writing an assembler, I would also go for "lbcc" and pseudo-ops like that, to keep the distinction clear. |
| |
Higgie
Registered: Apr 2002
Posts: 127 |
@jackasser: you see me convinced. :)
@cruzer: yeah! such a pseudo command would definitly be superior over any configuration based behaviour. |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
I guess you can make, using Cruzers example, a macro for it in 64tass:
lbeq .macro
bne *+3
jmp \1
.endm
Something like that. |
... 3 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
