| |
ready.
Registered: Feb 2003
Posts: 441 |
64tass v1.45 bug
Using 64tass v1.45 or earlier by Breeze and Singular (64TASS V1.45), I can't compile the illegal op code ANC. I need:
....
lda ($2e),y
anc #$ff
ror
....
I have managed 64tass to compile the ANC op code in this way:
....
lda ($2e),y
.byte $0b, $ff
ror
....
In this way it works fine. Hope this can be helpful for a new version of 64tass.
BR,
Ready. |
|
... 17 posts hidden. Click here to view all posts....
|
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote:Now I have just fixed it thanks to Scout's hint. I did not use .align $0100, but he made me think about some branch problem.
Nice!
Maybe reading the manual might be an option because:
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
:D
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Quote:Now I have just fixed it thanks to Scout's hint. I did not use .align $0100, but he made me think about some branch problem.
Nice!
Maybe reading the manual might be an option because:
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
:D
this is not really the bug that Ready is experiencing.
Too many passes error is a weird bug, and sometimes you can get rid of it by some simple things :
like swapping
LDA #$xx
LDX #$xx
to
LDX #$xx
LDA #$xx
which should make no difference, but still it can get rid of the bug.
In short, there's something wrong with 64tass v1.45. |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: this is not really the bug that Ready is experiencing.
Too many passes error is a weird bug, and sometimes you can get rid of it by some simple things :
like swapping
LDA #$xx
LDX #$xx
to
LDX #$xx
LDA #$xx
which should make no difference, but still it can get rid of the bug.
In short, there's something wrong with 64tass v1.45.
True, it is still a bug.
I forgot to mention that in my response to make that clear.
I was just pointing to the long branches commandline option.
I found also a small bug.
Not a nasty one because it only gives a warning (thank <fill in your entity of choice>);
if you have data/code that ends at $ffff, the compiler warns that the top of memory has exceeded (or something like that).
Like i said, not a real bug but i guess some internal tweaking has to be done inside the compilercode.
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: True, it is still a bug.
I forgot to mention that in my response to make that clear.
I was just pointing to the long branches commandline option.
I found also a small bug.
Not a nasty one because it only gives a warning (thank <fill in your entity of choice>);
if you have data/code that ends at $ffff, the compiler warns that the top of memory has exceeded (or something like that).
Like i said, not a real bug but i guess some internal tweaking has to be done inside the compilercode.
/me has code ending at $ffff too ;D |
| |
Hermit
Registered: May 2008
Posts: 208 |
Now I can confirm that this ´OOOPS, Too Many Passes´ is really coming from something related to branches.
At least this time I had to change an address of a BNE.
After playing around for nearly half an hour to get this solved.
As I´m working on a bigger project (SID tracker), I faced this message many times. Usually writing something randomly or continuing the code solved the situation most of the times, but now I couldn´t go forward without modifying the BNE address.
I assume that this message comes when there´s a branching somewhere near the $7f..$80 boundaries. But as it didn´t compile I couldn´t exactly check how much bytes the branch wanted to jump.
I hope this helps some of you to get rid of this annoying bug.
hermit |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Maybe you can send a non-compiling source to Soci? Everytime i stumbled upon that bug I just swapped some opcodes and continued, before thinking about saving the source and submitting it to soci so he could have a look at it and trace what's going wrong. (I will next time ;)) |
| |
Hermit
Registered: May 2008
Posts: 208 |
I found this error message in 64tass source code:
The extract from (ver1.46) 64tass.c line 2020:
....
do {
if (pass++20) {fprintf(stderr,"Ooops! Too many passes...\n");exit(1);}
set_cpumode(arguments.cpumode);
address=l_address=databank=dpage=longaccu=longindex=0;low_mem=full_mem;top_mem= 0;encoding=0;
current_provides=0xffffffff;current_requires=0;current_conflicts=0;macrecursion= 0;
fixeddig=1;waitfor[waitforp=0]=0;skipit[0]=1;sline=0;procname[0]=0;conderrors=wa rnings=0;freeerrorlist(0);
/* listing=1;flist=stderr;*/
enterfile(arguments.input,0);
sline=0;
compile(arguments.input,0,0,"",-1,NULL);
exitfile();
if (errors) {status();return 1;}
if (conderrors && !arguments.list && pass==1) fixeddig=0;
} while (!fixeddig || (pass==1 && !arguments.list));
....
I wonder what causes the do while loop run more than 20 times increasing 'pass' variable.
|
| |
Hermit
Registered: May 2008
Posts: 208 |
Regarding source code that causes 'Oops, too many passes.'
I played around with branching to prove my assumption. Here is a code which recalls the bug, wherever you place it in memory:
loop beq jploop
.rept $80
NOP
.next
jploop jmp loop
As you can see, this would be a 'branch too far' normally, but the 2 byte bne xx isn't taken into account. That's why, writing .rept $81 of NOPs also causes the 'Oops', while .rept $82 and more calls 'branch too far'. The latter should be the case with $80 and $81 too. .rept $7f of NOPs and below is the safe area, where no error message at all.
Maybe I'll find in 64tass source where this can be fixed. At least we catched this bug, time to destroy it ;)
-I didn't experience this bug with backward-branching, because there 2 byte of BNE xx doesn't count into amount of max. jumping.
|
| |
Hermit
Registered: May 2008
Posts: 208 |
Here's an extract from 64tass.c 1.46 row 1767. It seems to calculate relative address by subtracting logical address (l_address) from absolute address value (val). And it substracts that 2 too (the 2 byte that bne/beq allocates). The problem must be in this if-else structure, because $80 and $81 branching both goes to the point where the normal (below $80) branches go. I restructured lookout of this code a bit to better see the hierarchy...
if (cnmemonic[ADR_REL]!=____)
{
if (d)
{
if (fixeddig && (l_address >> 16)!=(((unsigned)val) >> 16)) {err_msg(ERROR_BRANCH_TOOFAR,NULL); break;}
val=(val-l_address-2) & 0xffff; //hermit: maybe this '2' should be handled in other way
if (val<0xFF80 && val>0x007F) // hermit: checks BNE boundaries here.
{
if (arguments.longbranch && (cnmemonic[ADR_ADDR]==____) && ((cnmemonic[ADR_REL] & 0x1f)==0x10))
{//branch
longbranch=0x20;val=0x4C03+(((val+l_address+2) & 0xffff) << 16);
if (fixeddig) err_msg(ERROR___LONG_BRANCH,NULL);
}
else
{
if (cnmemonic[ADR_ADDR]!=____)
{
val=(val+l_address+2) & 0xffff;
opr=ADR_ADDR;w=1;ln=2;goto brancb;
}
else if (cnmemonic[ADR_REL_L]!=____)
{//gra
val=(val-1) & 0xffff;
opr=ADR_REL_L;w=1;ln=2;goto brancb;
}
else if (fixeddig) {err_msg(ERROR_BRANCH_TOOFAR,NULL); break;}
}
}
opr=ADR_REL;w=0;// bne -hermit: bne with safe 00..$7f jump comes here ------BUT WHY $80 and $81 too?
} else fixeddig=0; if (longbranch) ln=4; else ln=1;
}
|
| |
soci
Registered: Sep 2003
Posts: 480 |
Should work now.
svn co https://tass64.svn.sourceforge.net/svnroot/tass64/trunk tass64 |
| Previous - 1 | 2 | 3 - Next |
