Activity for Jonathon Hall
-
Jonathon Hall posted a comment on ticket #472
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...
-
I dug in to learn the details of the pic16 stack model and got setjmp/longjmp implemented properly. The unexplained 3-byte offset was due to difference in temporary register allocation - setjmp was using 5 bytes (so saved 5 temp registers to the stack), longjmp was using 8 bytes (saved 8 temp registers to the stack). The 3 dummy bytes I pushed were the "missing" saved temp registers, which would then clobber those temp registers in the longjmp epilogue. It didn't have anything to do with the function...
-
I went through all the pic16 devices that said "ramsize 4096" and corrected them. Mostly used Microchip's product listings since the correct value is right there, in a few cases for products no longer listed I found datasheets and checked the data memory map. These two patches should be good now if they look good to you also. I still need to check out the reason for the extra byte offset in longjmp.
-
It looks like gputils does not emit symbols denoting region start/end like sdas does, so I can't zero statics/globals that way (without changing gputils as well, but I'd rather focus on getting the regression tests working). I can zero the device's actual SRAM range though. I can have sdcc emit a symbol (_sram_end, comparable to _stack_end) and use that in crt0iz.c. Looks like this works, and a few more tests pass for 18f452. However there are ~35 devices saying they have 4096 bytes of SRAM in pic16devices.txt,...
-
Thanks, added that change and rebased it dropping the prior patch that's no longer needed.
-
You're right, I don't think this is needed any more. I had been on Fedora 35 putting off release upgrades when I ran into those problems. Now I'm on Fedora 39 and I no longer need that change, looks like it was addressed in gpasm.
-
That's a good idea. I'm not sure if there are any devices with memory all the way up to 0xeff, but maybe crt0iz could just zero up to the limit of the largest-memory device, then we pick one of those devices in the simulator. I'll check it out.
-
pic16: Fixing regression tests
1