Jonathon Hall

I looked over the PIR1 and TXSTA registers across all pic18 devices by checking the headers in sdcc, with a script. Bottom line, all of them do have PIR1.TXIF in the same bit position. Some headers don't have all the bits labeled for some reason, but I checked datasheets for some of those and they are there. PIR1.TXIF was missing in the 18F2331 family (8 devices), those are all covered by the same datasheet. For some reason the bit is labeled TBIF in the header, and the other bits' labels are missing....

16F819 is a 14-bit instruction set device, so that would need the pic14 backend. I've only been working on the pic16 backend (16-bit instructions for PIC18 devices). The naming is kind of confusing.

Thanks for having a look danielt3. Sorry for the silence, kept thinking I would be able to get back to this but just haven't been able to carve out any time. I believe PIR1 is the same on all devices but I will look over that more thoroughly, that's a good thought. Did you look over patch #4? That one is pretty important to ensure that it doesn't discard needed register writes thinking they are unneeded.

Thanks for the suggestion @roybaer! I sent a message to the mailing list and it awaits moderator approval :) Hope we get some feedback!

Thanks for applying those @spth! How would you suggest we proceed for the remaining patches? My impression is that nobody else is active in the project any more that is familiar with PICs to review them. Unit test improvements are helpful but not perfect. I could go back through the history of those files and poke a few people here if you think we might get a response.

pic16: more long long impl, start moving to common stdlib

pic16: long long support

You're right @spth, I forgot the volatile. That fixes everything except mcs51 without --stack-auto. Attached a new patch for the unit test, but if you have another idea to capture this I'm open to suggestions. Removed the extra STACK_PTR_SIZE from setjmp.c, thanks for pointing that out @maartenbrock. The header has to define one since it is needed to know the size of jmp_buf, so I just used that one again in setjmp.c, didn't realize I had added that twice. @maartenbrock Does the mcs51 issue still...