Activity for Small Device C Compiler (SDCC)
-
sverx posted a comment on ticket #3976
So far I had never before seen them appearing when there was actually no conditional flow change, and I wonder what flow change had been applied here in the k=n/32 expression. But yes, technically that's not a bug, but I felt I wanted you to know about this anyway and the bug tracker is probably the better place for such issues anyway.
-
Philipp Klaus Krause posted a comment on ticket #3972
While the bug should be fixed in trunk now, unfortunately, a system affected by it will still need some manual fix, as posted on the sdcc-user list. I'll repeat it here in case anyone not on the list sees this bug report: If you did build and "make install" sdcc (from trunk or source snapshots tarball) between the beginning of March, and today, this issue most likely affects you. During my work on merging current upstream binutils into thr SDCC fork, I introduced a bug (https://sourceforge.net/p/sdcc/bugs/3972/)....
-
Since [bugs:#3972] is fixed now, could you please check if this works for you? Unfortunately, you will have to do teh manual fix of your system I posted to the sdcc-user list, which I'll repeat here in case anyone not on the list comes across this bug report: If you did build and "make install" sdcc (from trunk or source snapshots tarball) between the beginning of March, and today, this issue most likely affects you. During my work on merging current upstream binutils into thr SDCC fork, I introduced...
-
Small Device C Compiler (SDCC) released /snapshot_builds/sdcc-src/sdcc-src-20260408-16451.tar.bz2
-
-
-
-
Not sure if this is really a bug. Though I wonder if those EVELYN warnings are really worth it; IMO they give too many warnings for cases where optimizing conditional flow is totally fine.
-
-
Miguel Angel Perez Martinez posted a comment on discussion Open Discussion
This is becoming an actual bottleneck in my project. Having to wait minutes for a change in one file is killing productivity and tracking/finding which functions might be responsible is not easy and time consuming. In cseAllBlocks a loop calls cseBBlock for every block. Do you think this calls could be done in different threads at the same time? (I'm willing to try at least for a local patch to speed things up).
-
unexpected warning "conditional flow changed by optimizer: so said EVELYN the modified DOG"
-
-
"make uninstall" not removing sdar, sdnm, sdobjcopy, sdranlib
-
-
-
-
Can't install sdcc from current trunk
-
This should be fixed in [r16451].
-
Fixes for binutils merge in early March (bug #3972).
-
Can't install sdcc from current trunk
-
Looks like my binutils update broke this in a quit4 bad way that can also affect "make install" for programs other than sdcc. It looks like SDCC "make install" installs some binutils in /usr/local/bin without the correct sd prefix. This means that a user then might have e.g. a "strip" program in the path that has no support for the host architecture, just support for SDCC targest. This "strip" program will fail with an error message when used on a host binary, and that is apparently what happens...
-
This might be a duplicate of [bugs:#3972].
-
Daniel Drotos created ticket #3974
Linker files are not installed
-
Gabriele Gorla committed [r16450] on Code (SVN)
Reverse order of genCopy if saves a load.
-
-
-
-
Optimize loading/storing bitfiels when size is multiple of 8 bits.
-
-
-
Oleg Endo modified a comment on ticket #466
@spth I've looked at your change once more I looked into rules 112.c, 108.f and 108.g. While they were useful, I think I came up with a more general solution that requires fewer rules in [r15431]. Please have a look. Interestingly, it misses some cases like: my original patterns (do ljmp -> sjmp after conditional jumps) mov dptr,#(_g_state + 0x0001) movx a,@dptr anl a,#0x03 jz 00219$ ... ... 00219$: ret ----------------------------- your patterns (do ljmp -> sjmp first) mov dptr,#(_g_state + 0x0001)...
-
-
mcs51: add banked jump
-
Use simif to stop the simulation as in other ports
-
Apply patch #497 by Oleg Endo to emit __sdcc_program_exit label
-
[ucsim] Intro -m option to return main() value
-
[ucsim-s51] Turn off feature by #497 as it breaks regtests
-
-
-
-
-
-
What about using a label on the seljump which is after main? Please see the attached patch.
-
-
As it turns out, my idea to use something like #((___str_0 >> 16) + 0x80) for the high byte doesn't work. Although it compiles and assembles and links fine, it silently outputs #0x00 in the final code. This is should be probably also fixed in the assembler/linker. Funnily, turning around the expression seems to work fine #((___str_0 + 0x800000) >> 16) . So use that for now. Updated patch
-
-
-
What about using a label on the seljump which is after main? uCsim can get address of the label from the cdb (or map) file and automatically break at that address and pass out return value produced by sim_stop_result(). Yes, that sounds good!
-
Thanks!
-
[r16444]
-
[ucsim] Apply v2 of #497
-
[ucsim] Doc check command
-
What about using a label on the seljump which is after main? __sdcc_program_startup: lcall _main ; return from main will lock up __magic_point_after_main_to_stop_on: sjmp . uCsim can get address of the label from the cdb (or map) file and automatically break at that address and pass out return value produced by sim_stop_result().
-
Thanks for looking into it. I've been trying to update my SDCC from 4.2 to 4.5 and had this patch has been sitting in my tree. Apparently using selfjump was the old way of doing it. In fact, it's even still described in the 4.5 manual: (main.asm) .area GSFINAL (CODE) ljmp __sdcc_program_startup ;-------------------------------------------------------- ; Home ;-------------------------------------------------------- .area HOME (CODE) .area CSEG (CODE) __sdcc_program_startup: lcall _main ; return from...
-
-
-
-
-
-
-
-
-
-
-
I've applied uCsim part only! Code generator is not touched. I think that selfjump after the main is not a good solution, as selfjump detection is not used in mcs51 regtests, becouse it is valid in normal code.
-
[ucsim] Remove code analyzer; Add EOL converter for all uarts; Intro input file parameters; Doc updates
-
mcs51 usim: pass return value of simulated main function to host
-
[r16441]
-
[ucsim] Apply patch #497
-
[ucsim-pblaze] remove obsolete files
-
@spth I've looked at your change once more I looked into rules 112.c, 108.f and 108.g. While they were useful, I think I came up with a more general solution that requires fewer rules in [r15431]. Please have a look. Interestingly, it misses some cases like: my original patterns (do ljmp -> sjmp after conditional jumps) mov dptr,#(_g_state + 0x0001) movx a,@dptr anl a,#0x03 jz 00219$ ... ... 00219$: ret ----------------------------- your patterns (do ljmp -> sjmp first) mov dptr,#(_g_state + 0x0001)...
-
mcs51/gen.c: extract function emit_add_dptr,emit inline sequence if beneficial
-
implement area overlap checking (for banked code)
-
add support for .lk input files
-
mcs51 usim: pass return value of simulated main function to host
-
See also https://sourceforge.net/p/sdcc/feature-requests/870/ https://sourceforge.net/p/sdcc/feature-requests/969/
-
Generic optimization based on generalized constant propagation, I'd say. In the front-end, we need that int, since too many things break otherwise. But later, we should narrow it (e.g. after checking that the operands are in the 0 to 255 range, and that the backend does have an unsigned 8x8->16 multiplication). Interestingly, for your example we do get okayish code for z180, but currently not mcs51 and stm8.
-
Automatically narrow constants/literals types
-
The option to disable atomics has also been mentioned in the original atomics issue https://sourceforge.net/p/sdcc/feature-requests/624/
-
see also https://sourceforge.net/p/sdcc/feature-requests/1015/
-
Another pragmatic solution: add an option to disable the rewindable sequences, but still allow for native atomics in __data / __idata using the xch insn.
-
Another idea how to reduce the penalty of ljmp sdcc_atomic_maybe_rollback: atomic_sequence: setb psw.5 movx a,@dptr mov r3,a mov a,r2 movx @dptr,a clr psw.5 isr_epilogue: jb psw.5,do_rewind reti do_rewind: ljmp sdcc_atomic_maybe_rollback The main idea here is to use a bit variable to improve the hot path of the rewind check. AFAIR it has been mentioned in some of the rewindable-sequence papers that the probability of actually getting a race and thus a sequence rewind is rather low. Hence try to optimize...
-
As of svn r16432 the implementation of sdcc_atomic_maybe_rollback can cause data corruption of R0. It's assuming that ar0 = 0, i.e. register bank 0 is selected in psw. This is not necessarily true. For example with nested interrupt handlers that switch register banks. At the time when reti / ljmp sdcc_atomic_maybe_rollback is executed psw has the register bank of the interrupted context selected. So before using r0 in the code, it must change psw to register bank 0. The attached patch should fix...
-
Since it is sometimes difficult for the compiler to prove that an ISR does not use atomics and thus adds the still expensive ISR epilogue for the possible rollback, it might be worthwhile to prevent the compiler from generating atomic support. The same goes for the atomic support routines. I've been looking into updating my SDCC version and ran into this problem. One of my ISRs gets the sdcc_atomic_maybe_rollback treatment unexpectedly. Thus, for now I'd like to turn off the atomics stuff for my...
-
Since it is sometimes difficult for the compiler to prove that an ISR does not use atomics and thus adds the still expensive ISR epilogue for the possible rollback, it might be worthwhile to prevent the compiler from generating atomic support. The same goes for the atomic support routines. I've been looking into updating my SDCC version and ran into this problem. One of my ISRs gets the sdcc_atomic_maybe_rollback treatment unexpectedly. Thus, for now I'd like to turn off the atomics stuff for my...
-
-
-
Disable multiplication part of far arithmtic test for pdk targets, which don't have enough memory.
-
NGI0-Commons-SDCC
-
NGI0-Commons-SDCC
-
NGI0-Commons-SDCC
-
-
rtrack currently cannot track symbols. It will never be able to track global symbols as these are not placed yet by the linker at this stage. It doesn't necessarily have to get the absolute addresses. For example extern __xdata char some_data[]; int test_00 (void) { return some_data[1] + some_data[2]; } produces: mov dptr,#(_some_data + 0x0001) (*1) movx a,@dptr mov r7,a mov r6,#0x00 mov dptr,#(_some_data + 0x0002) (*2) movx a,@dptr mov r4,#0x00 Here rtrack could replace the dptr load at (*2) with...
-
It's strange why the "inc DPTR" is not used? Because it's emitting code to access individual memory locations at dptr + offset. And at each instruction it "forgets" the previous value of the address pointer. Similar thing happens when initializing/accessing an array on the stack (using --stack-auto) void main_01(void) { char str[]="1233"; } produces: _main_01: mov a,sp add a,#0x05 ; bug.c:61: char str[]="1233"; mov sp,a add a,#0xfc mov r1,a mov @r1,#0x31 mov a,r1 inc a mov r0,a mov @r0,#0x32 mov...
-
-
-
Another thing, I see is that you've changed the code to use emitcode ("push", "ar0"); I think this will not work properly when the register bank is other than 0. Hence I avoided that in my original code. I was wrong. Firstly, the register bank is set before function entry. Secondly, the corresponding ar0 ... ar7 aliases have been already output into the asm code when it reaches this point. So it's save to use r0 and ar0. I'm attaching my updated patch that applies to svn r16432 Perhaps it's better...
-
Where one can see the redundancy of the first instruction, mov a,_ACC This was one of the things which I tried to address in issue 466, https://sourceforge.net/p/sdcc/patches/466/attachment/0009-add-isSpecialRegister-peephole-condition-function-al.patch My patched-up SDCC produces the following: __sfr __at(0xE0) ACC; __sfr __at(0x82) DPL; __sfr __at(0x90) OTHER_SFR; void test_10 (void) { if (ACC & 0x01) ACC = 0; if (DPL & 0x01) DPL = 0; if (OTHER_SFR & 0x01) OTHER_SFR = 0; } _test_10: ; if (ACC &...
-
Note: The output in the original description above has been obtained with this patch applied https://sourceforge.net/p/sdcc/feature-requests/_discuss/thread/20d0835c81/6ce1/attachment/0001-issue-892-preserve-high-byte-of-gptr.patch Without the patch it will output: _my_data2: .byte __str_0, (__str_0 >> 8),#0x80 ; generic printIvalPtr .byte #0xe0,#0x46,#0x16 .byte #0xe0, #0x46, #0x16, #0x10 ; 269895392
-
I have tried to look into this issue again. Attached is my current WIP patch to tackle the issue and some test cases that I've been using. The main issue here is, the mcs51 code gen assumes that a pointer in the code address space is always 16-bit and hence sets the address byte 2 to a fixed 0x80 value to synthesize a 3-byte gptr. This is correct for non-banked, but makes banked code tedious to write, as it prohibits passing code/rodata references across different banks impossible. This happens basically...
