Basil Hussain

Function attributes for format string validation give bogus warnings, disagree with actual capabilities of linked runtime library

Awesome, thanks!

Could at least this optimisation be done natively for t1sn.io and t0sn.io? I've been looking again at the instruction encoding tables on the Free-PDK website, and I see that mov.io always has the same number of address bits as t1sn.io and t0sn.io - 5 bits for pdk13, 6 for pdk14, 7 for pdk15. I do believe this would be a pretty significant improvement (especially so for code heavily performing GPIO pin testing), because as I commented on my recent mailing list post, in some situations peephole rules...

I suppose that makes sense. The assembler may be setting the current address according to the directive as far as it knows, but then at linking time the area offset is applied and screws things up. The current ASxxxx documentation claims that boundary specifications are preserved at linking time. But when looking at the ASxxxx changelog, I see the following note: Completed the functionality for propagating the boundary specifications .odd, .even, and .bndry processed during assembly to the linker....

Philipp was talking about the scenario of non-.io instructions. For pdk13 mov.io -> t?sn.io, the IO address is 5 bits for both (6 for pdk14, 7 for pdk15), so it would be perfectly feasible to do this optimisation at code generation time because both instructions can reference the same memory range. However, for non-IO (i.e. regular memory) case of mov -> t?sn, it can't be done because t?sn has fewer bits in the instruction to represent the memory address (only 4) than a mov(6 bits). To give a concrete...

I would like to add my support and encouragement for this feature. I am currently writing some code for PDK and am needing to use inline assembly with an stt16 instruction to load a value into the 16-bit timer counter (it's not accessible as a register, only by stt16 and ldt16 special instructions). I'm using a global uint16_t variable as the source value. static volatile uint16_t t16_reset_val = 1234; // must be word-aligned __asm__("stt16 _t16_reset_val\n"); However, the memory location the value...

I have devised a way of adding a compile-time check for the old function name to the Free-PDK headers, so I have submitted a pull request to them: https://github.com/free-pdk/pdk-includes/pull/14 That should help for the situation where new code is created using the old name, or where existing code is updated to use the latest Free-PDK headers, but is obviously not a complete solution.

you add a check to a single MACRO which is only related partially to the problem The PDK_SET_SYSCLOCK() macro is merely a convenient point at which to make the check, seeing as it is meant to be used within the startup function in question. The check is a compile-time check - the function's code doesn't actually have to run. also you check if the NEW version __sdcc_external_startup is defined You have mis-interpreted the code. It checks for the old function name. SDCC, when compiling C into assembly,...