Possible bug in supplied assembler

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible bug in supplied assembler

dansan
In testing my assembler, I've found a weird behavior with the supplied assembler. If you assemble a file, and then save it, it does the right thing. But, if you do the compare file, it does not generate the same assembly code. Actually, it generates flawed code.

To reproduce:

* Open Assembler
* Load Rect.asm
* Do fast assemble
* Save to Rect-ref.hack
* Rewind
* Load Rect-ref.hack for comparison
* Do fast assemble

Somehow, when doing the comparison, the second symbol defined (@address) is getting an address of 16, instead of the 17 it should have, and which it actually computed correctly on the non-compare pass.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in supplied assembler

cadet1620
Administrator
Very strange.

I can't reproduce this bug. Sounds like an uninitialized variable problem. I hate those; they can be tricky to reproduce and to find.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in supplied assembler

dansan
I just tried this in a different environment, and I can't reproduce either. Oh well.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in supplied assembler

fitcat
I confirmed this bug.
After restarting the assembler, it works fine.
It seems to be an initialization bug.