OK… I'm pushing GCB hard.. sometimes it pushes back…
Version 0.9 10/9/2010, compiled for Linux. Stock other than the "FRA" assembly.bi fix from my last post.
When compiling code for the PIC18F2525 chip I'm using for my project, I ran into a case where it left in a RCALL that jumped just beyond the allowed range (tried to jump 1031 words, limit is -1023/+1024). Using the external gpasm caught the error, the internal assembler does not. I solved the issue at hand in my copy by reducing numbers under OptimiseCalls but that's probably not the real fix.
Another issue I ran into was with sub call parameters… the following structure did not work…
Sub somesubroutine(in parm1, optional out parm2)
Generated variable names line INPARM1 and OPTIONALOUTPARM2 and also instructions that had missing fields. The gpasm assembler caught it, the internal assembler didn't complain and generated code that misbehaved badly. Perhaps I'm specifying the parms incorrectly? Workaround for me for now is don't do that, just use plain sub parms and always use all of them.
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
assembly.bi does Not have similar code - it just assumes the relative branches are correct. With the OptimiseCalls code in gcbasic.bas hacked to limit relative use to (what it thinks is) +/- 50 locations, the internal assembler assembles the app just fine, it's running now. The real fix is probably in the CalcLineSize sub - need to make it so that it returns the correct size for dw lines.
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK… I'm pushing GCB hard.. sometimes it pushes back…
Version 0.9 10/9/2010, compiled for Linux. Stock other than the "FRA" assembly.bi fix from my last post.
When compiling code for the PIC18F2525 chip I'm using for my project, I ran into a case where it left in a RCALL that jumped just beyond the allowed range (tried to jump 1031 words, limit is -1023/+1024). Using the external gpasm caught the error, the internal assembler does not. I solved the issue at hand in my copy by reducing numbers under OptimiseCalls but that's probably not the real fix.
Another issue I ran into was with sub call parameters… the following structure did not work…
Sub somesubroutine(in parm1, optional out parm2)
Generated variable names line INPARM1 and OPTIONALOUTPARM2 and also instructions that had missing fields. The gpasm assembler caught it, the internal assembler didn't complain and generated code that misbehaved badly. Perhaps I'm specifying the parms incorrectly? Workaround for me for now is don't do that, just use plain sub parms and always use all of them.
Terry
Correction…
assembly.bi does Not have similar code - it just assumes the relative branches are correct. With the OptimiseCalls code in gcbasic.bas hacked to limit relative use to (what it thinks is) +/- 50 locations, the internal assembler assembles the app just fine, it's running now. The real fix is probably in the CalcLineSize sub - need to make it so that it returns the correct size for dw lines.
Terry