xas99 3.1.0 stuck in loop
MirrorPusher opened this issue · 7 comments
xas99 3.1.0 stuck in loop when trying to assemble a bigger project.
The project successfully assembles in xas99 v2.
Steps to reproduce:
$cd /tmp
$tar -xvf breaks_xas99.tar.gz
$mkdir bin list
$python3 <path_to_xdt99>/xas99.py -b .stevie_b1/stevie_b1.81698/stevie_b1.asm.81698 -o bin/stevie_b1.bin -L list/stevie_b1.lst.asm -D build_date=211009-81698
It loops in assemble_pass_1()
I think there is something going wrong in parser.resume()
Keeps on reprocessing the same file.
Thanks for reporting this issue.
Unfortunately, I cannot assemble your project, because it tries to include /storage/bitbucket/projects/ti994a/spectra2/src/runlib.asm. Could you perhaps include that file in the sources and adjust your COPY directive?
I have updated the tar file in the 1st post so that it now also includes the spectra2 subdirectory.
While preparing this I found out that the looping stops, if no path is given in the copy statement.
In other words; if all the files that belong to runlib are available in .stevie_b1/stevie_b1.81698/stevie_b1.asm.81698 it does not loop.
stevie_b1/stevie_b1.81698/stevie_b1.asm.81698
copy "/tmp/spectra2/src/runlib.asm"
; Hang v3 xas99.py
vs.
stevie_b1/stevie_b1.81698/stevie_b1.asm.81698
copy "runlib.asm"
; Terminates v3 xas99.py
Alright, I was able to locate SPECTRA2. With runlib.asm in place, I get several warnings and one error in cpu_constants.asm, as there is a ---- line which is not a comment. With that line fixed, I get
> basic_cpu_vdp.asm <2> 0496 - b @xpym2v ; Display string
***** Warning: Possible branch/jump optimization
> basic_cpu_vdp.asm <2> 0518 - b @putstr
***** Warning: Possible branch/jump optimization
> cpu_scrpad_paging.asm <2> 0086 - b @cpu.scrpad.restore ; Restore scratchpad memory
***** Warning: Possible branch/jump optimization
> timers_tmgr.asm <2> 0051 - b @kthread ; Run kernel thread
***** Warning: Possible branch/jump optimization
> timers_kthread.asm <2> 0045 - b @tmgr3 ; Exit
***** Warning: Possible branch/jump optimization
> stevie_b1.asm.81698 <2> 0058 - b @main.stevie ; Start editor
***** Warning: Possible branch/jump optimization
> edkey.fb.mov.topbot.asm <2> 0022 - b @ _edkey.goto.fb.toprow
***** Warning: Possible branch/jump optimization
> edkey.fb.mov.topbot.asm <2> 0051 - b @ _edkey.goto.fb.toprow
***** Warning: Possible branch/jump optimization
> edkey.fb.mov.goto.asm <2> 0067 - b @_edkey.goto.fb.toprow ; Position cursor and exit
***** Warning: Possible branch/jump optimization
> edkey.fb.ins.asm <2> 0092 - b @edkey.action.char.overwrite
***** Warning: Possible branch/jump optimization
> edkey.cmdb.mod.asm <2> 0031 - b @edkey.action.cmdb.home
***** Warning: Possible branch/jump optimization
> rom.stubs.bank1.asm <2> 0050 - b @dialog.unsaved ; Show dialog and exit
***** Warning: Possible branch/jump optimization
> rom.stubs.bank1.asm <2> 0122 - b @_trampoline.bank3 ; Show dialog
***** Warning: Possible branch/jump optimization
> rom.stubs.bank1.asm <2> 0133 - b @_trampoline.bank3 ; Show dialog
***** Warning: Possible branch/jump optimization
> *** <2> **** -
***** Warning: Unused constants: DSRLNK.$0008, MEM.SAMS.EXTERNAL, MEM.SAMS.TIBASIC, NOSPRITE, PANE.SHOW_HINT.VECTOR, PREFIX, SPCODE, TIBASIC.32X24, TIBASIC.32X30, TV.TABS.TABLE, TX4024, TX8024, TXT.KEYMARKER, TXT.RULER, TXT.VERTLINE, VEC.11, VEC.12, VEC.13, VEC.14, VEC.15, VEC.16, VEC.17, VEC.19, VEC.23, VEC.28, VEC.29, VEC.30, VEC.31, VEC.8, VEC.9
and a binary file of 8191 bytes.
Could you please check if you do get endless look with that source? Maybe retry with the latest SPECTRA2 file if you haven't done so already.
Sorry, same idea here. :-)
But glad you pinpointed the error, then I can analyze that. In my source, I did indeed removed the absolute path of SPECTRA2.
Interesting. There's indeed a difference in the size of the resulting binary file when using v3.1.0
v2.0.1 results in 8192 bytes
v3.1.0 results in 8191 byes
Somewhere 1 byte went missing. Will have to look into that.
Guess it's probably best to open another issue. Will do when I have some more details.
That's because I accidentally(?) changed the semantics of SAVE a little: Now, the upper bound is exclusive, so you should change your save to SAVE >6000,>8000. Sorry about that.
I also had to change to handling of banks, but from what I've seen, you're not using that.
Alright, I fixed the endless loop. There were actually two factors at play here: A bug and a negligence from my part.
What I didn't explain in enough detail is that I changed how the default include dir changed between v2 and v3. In v2, it was always the dir you started xas99 in. In v3, it starts there, but then changes to the dir of the current include file. So if you include /tmp/runlib.asm, and that file include vdp.asm, xas99 will actually look for file /tmp/vdp.asm, which doesn't exist.
The reasoning for the change was libraries. Imagine a library which includes itself, for example
lib/lib.asm
lib/utl/alloc.asm
lib/util/release.asm
If this library is designed to be placed anywhere, then lib.asm will have a statement like COPY "util/alloc.asm", which only works if the current include directory changes to lib once that lib/lib.asm has been included. Am I making sense?
Anyway, so with the absolute path, none of the COPYs in runlib.asm were actually included.
But because of a bug, that case wasn't correctly handled, and instead duplicated the code before the failed COPY, leading to an ever increasing source file that couldn't be assembled completely.
I pushed a fixed version to GitHub. Please just download xas99.py from there. I won't make a release out of that just now. And I realized I forgot to change python to python3, so I'll do that now. But you also need to make sure that your runlib.asm resides in the same directory as the other files, or you'll get errors.