Activity for Chingson Chen
-
Chingson Chen posted a comment on ticket #3642
sdcc/src/SDCCopt.c line 3309: if (optimize.lospre && (TARGET_Z80_LIKE || TARGET_HC08_LIKE || TARGET_IS_STM8)) / For mcs51, we get a code size regression with lospre enabled, since the backend can't deal well with the added temporaries / If add back the optimization in this line for mcs51, the bug will be disappeared. I don't know why pdk15 has not that problem. I just don't understand the corresponding optimization procedure. Is there any more documents for the optimizations?
-
https://sourceforge.net/p/sdcc/bugs/3642/ Anyone help? Appreciated. Chingson
-
Missed complement operation after lrange optimization
-
As my experiences, SDCC that formerly designed for 8-bit targets is usually easier to optimize machine codes in 8-bit domain. For example, long foo(long k) { if(k&0x100) bar(); ... return 0; } The "k&0x100" operation in 8-bit domain sometimes can be done in a bit instruction. However, for LLVM/GCC developers .. such kind of optimization is really a headache. But for SDCC developers, such optimization is generally not so hard. Another point of view is that GCC/LLVM usually deals with large code size,...
-
Dear Sirs, I cannot build sdcpp from sdcpp.vcxproj (under win-10)after gcc patch merged. Any help?
-
PIC14 port does not update (volatile) global variable in some situations
-
Visual Studio has smart build and auto-multi-thread seems faster than single thread build under Linux (VM). Also switching between Release/Debug is easy. Today VSCODE+CPPDBG debugging SDCC under Linux (VM) is pretty comfortable. Using Linux to develop SDCC has a major benefit that it has "much" faster EXT4 than NTFS and fast console-IO. Also, usually Linux has /dev/shm can be used as RAM-DISK, which is even faster. My experience is that Linux VM can do the regression test many timers faster than...
-
I found the "st_link" type-chain used in "symtab.h" has reserved "v_enum" in "const_val" field of the specifier. But seems it is not assigned (yet) in current version SDCC. BTW, I can not find the trace of "typedef" statements in the back-end either. Without those information, the code output is still correct. But when debugging , the corresponding "ENUM" item is not shown, and show memory that "casting" to the type that "typedef" defined is not available. The features above seems not important for...
-
From the web-site we know after 2009, PIC18F series had extended the instructions of ADDFSR/PUSHL/ADDULNK, etc. New instructions seems good for C compiler/linker. However, from http://ww1.microchip.com/downloads/en/DeviceDoc/C18_UG__51288e.pdf, in section 3.2, we find for MPLAB C18, its C stack is still increasing the address when PUSH data, and it uses FSR2 as the FRAME pointer, FSR1 as the STACK pointer. Sadly, PUSHL instruction operates on FSR2, and decreasing, which means PUSHL cannot be used...
-
If only C code used, and not no need to connect the emulator/writer, some header definitions like #ifndef SDCC #define __data #define __xdata #endif can make vscode readable for most cases. The only annoying is sfr usually I use the macro like below: #ifndef __SDCC #define __SFRDEF(a,b) volatile unsigned char a; #else #define __SFRDEF(a,b) __sfr __at b a; #endif need to re-write the headers... by search replace should be OK. And, .. write your own Makefile, of course. Generally it is not an issue....
-
Sorry. After porting SDCC to other targets, I don't think SDCC translate C source line by line either. What I mean is that it needs some more optimizations to make the final assembly (more) compact and (more) beautiful. Those optimizations are hard if front-end don't initially support. Without those final optimzations, SDCC has done other tons of optimizations even we don't feel it. It is a good tool, especially its performance is very fast at STM8 port. People use compilers because it give us correct...
-
Yes. Commercial compilers are not promised to have better result. The ultimate option is to write the optimizer by ourselves. By the experiences of SDCC porting, I found the optimizations are generally not enough if peephole is used in low-level assembly only. At least 2 more optimization should be applied in assembly code (8-bit) level: 1. Dummy assignment removal. 2. Variable assignment parapagation/substitute. Such optimizations need trace the generated code for all its branches and all 8-bit...
-
As I know, because sdcc-icode (middle-interpretation of C code) is not 8-bit fixed, since processors like Z80 have 16-bit instructions and target has very different instruction sets, Its "icode" leaves the size to be processed by the back-end. And the optimizations have to be done by the back-end. For example, "clr (0x01, sp)" clears the ram (0x1,sp), which is not used in the following operations, should be optimized out easily. However, the front-end has only the live-range of the temp variables,...
-
Dear sirs, Does anyone browsing SDCC code on ..VSCODE or any IDE of Linux ? When using Windows, Visual Studio Community works pretty good, I am just not sure it is "legal" to use in a company (not licensed) to browse SDCC source code and build some special version. If anyone has a good settings for VSCODE, it will be great. Visual Studio Community is good. Or maybe it is possible to debug code through WSL ..However, I just feel it is a little too big comparing to VSCODE. Any advice will be appreciated....
-
Dear Sirs, I found the compiled i-code of pre-increase/decrease like .... main() { int i=0; while(++i) asm("NOP"); PT2=1; } will get i-code like testpredec.c(l7:s0:k3:d0:s0:b1) _whilecontinue_0($1) : testpredec.c(l7:s0:k4:d0:s0:b1) iTemp1 [k4 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed} = iTemp0 [k2 lr0:0 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{int fixed}{ sir@ _main_i_65536_1} + 0x1 {const-unsigned-char literal} testpredec.c(l7:s0:k5:d0:s0:b1) iTemp0 [k2 lr0:0 so:0]{ ia0 a2p0 re1 rm0 nos0...
-
It is about a new Instruction Set Architecture. (ISA) Generally 8/16-bit CPU instruction set architecture (ISA) has its trade-off of complexity, performance, addressing space, and code-density, etc. For example, 8051 can address to 64K BYTE of ROM (directly), but STM8 can use up to 16MB. But MSP430 share the 64K with code and data. And for 8051, the code density is really good with IAR/KEIL compilers for some smaller applications. If someone need to "design" a new CPU/MCU for special applications,...
-
As I know, currently SDCC seems mainly focus on STM8. For other ports, "correctness" will be maintained only. But for optimization quality, it is another story. Though https://www.microchip.com/mplab/mplab-x-ide with XC8 free version's optimization of PIC18 series is not perfect either, but XC8 has very advaced Linking Time Optimizer (LTO) and should be good for PIC14/PIC16 series. For example, SDCC needs declare code/data for pointer to RAM or ROM, but XC8 linker will check if the pointer used for...
-
the git repo I use is https://github.com/svn2github/sdcc I haven't tried "git svn clone", maybe it is a good idea. SVN to an origin git ripo. Thank you for your advice, I will try these days.
-
OK, this is not a purely SDCC problem. Recently, I have port SDCC to some special kinds of 8-bit CPU. Generally the SDCC front-end works well. The problem is that the official sdcc is still active, and the git updates several times per month. That is, I have to clone the sdcc repository, make my branch, and pull-commit-merge of my branch several times per month. The problem is that if I re-base my repo, seems I cannot pull from the official sdcc git anymore... However, if I cannot re-base my repo......
-
PIC series of MICROCHIP are good products. For the PIC16 series of 14-bit wide instruction set, the limits are annoying for a "regular" compiler: a) per register FILE (F) has only 128 byte directly. Other address need to switch bank. b) One hardware pointer for indirect access only. c) Use "skip" instructions that make bank-switching insertion in linker very hard. For example btfsc F1.2 ADCFW F2 if F1 and F2 are in different bank, Bank-switching must add between F1 and F2.. ... Like PIC16F526, sometimes...
-
Anyone can help to write a document about symbol/usl/spill? Seems most backend cannot deal with the spilled parameters yet..
-
In "_divuxxx", assignment of "c" is hard to be optimized. Also, in "__moduxxx", shift left (<<) is also hard to be optimized. Yes, we will get shorter code, at least for PIC series.
-
I see the library code seems mostly done in 1999. The code works, but it feels me a little dump after some checking. For example, the "_divuint" do { // reste: x <- 0; c = MSB_SET(x); x <<= 1; reste <<= 1; if (c) reste |= 1; if (reste >= y) { reste -= y; // x <- (result = 1) x |= 1; } } will it be equal to do { // reste: x <- 0; **reste <<= 1; if (MSB_SET(x)) reste |= 1; x<<=1;** if (reste >= y) { reste -= y; // x <- (result = 1) x |= 1; } } // which saves a variable and some lines of codes also...
-
I suggested 8-bit icode several months ago. However, sdcc supports many CPU has 16-bit operations, which will need a "instruction selection" stage and will be much more complex than it is today. Seems it is not a simple work. I've also suggest that the procedure required is "constant propagation and dead code elimination". For the PC 15~20 years ago and without 8-bit i-code, the job can be done in back-end side and iterated with peephole optimzation. However, it would made the compiler very slow....
-
I found in "gencmp" of gen.c, the signed compare with literal is convert to unsigned with 0x80/0x8000 add first, and result in C, and ,.. MSB first, I just wonder why not using OV flag. consider one byte compare if (a<-1) the sdcc generated code is add (lit) 0x80 then compare 0x7f with unsigned, and result is C. why not direcly add -127 to see if it overflows? Any considerations?
-
As I know, gcc is now competing msvc and other compilers in many ways. I am also very gad that SDCC is still active though 3.7.0 is not available after 1X months of 3.6.0. As I said, STM8 has many 16-bit operations that less constants need to be propagated. The difficult ones are the constants to propagate in PIC18/PIC16/MCS51 8-bit operations. I know STM8 is not expensive today, but STM8 hardware is .. not open-source...yet. PIC18/PIC16/MCS51 are still very popular MCU today. by https://www.youtube.com/watch?v=XAf0H1-ujzI...
-
As I know, gcc is now competing msvc and other compilers in many ways. I am also very gad that SDCC is still active though 3.7.0 is not available after 1X months of 3.6.0. As I said, STM8 has many 16-bit operations that less constants need to be propagated. The difficult ones are the constants to propagate in PIC18/PIC16/MCS51 8-bit operations. I know STM8 is not expensive today, but STM8 hardware is .. not open-source...yet. PIC18/PIC16/MCS51 are still very popular MCU today. by https://www.youtube.com/watch?v=XAf0H1-ujzI...
-
OK, I found it is the "constant propagation and dead-code elimination" stage. If 16-bit operations are used, possibility is lower to have full 16-bit constant dead code. But for 8-bit only operations, there are much higher possibilities to get 8-bit constant/dead code. For example, long x = (y&0x4000008)>>1; middle 2 bytes are zero-constants and can be propagated in 8-bit operations, but not in 16-bit operations. For 8-bit compiler, if the middle 2-byte constant of above operations is not propagated...
-
YES, 32 BIT to 16 bit is fine to code by human. The problem is 24bit to 16 bit. I have many applications need 24 bit data. Or some times we have '#define MASK 0xffff00' '#define SH 8' then unsigned long b = (kk&MASK)>>SH; Do you think sdcc can "optimize" its icode to (kk>>SH)&MASK when mask=0xffff00 and SH is 8?
-
My special CPU has no 16-bit operations like STM8, but I think I know what you means. I shall try a more smart peephole optimizer. Currently in my compiler, load/store operations and their dependencies are further checked by flow-optimizer to see if those operations can be replaced/reduced. I didn't find the method in the textbook so I tried by myself. Iterations with peephole optimizations can generate pretty good result. The cons is that it is slow for longer function because some load/store has...
-
I've been porting SDCC to special 8-bit CPU for a period of time. The sdcc-icode structure is generally good for most cases. However, in addition to peeph-hole optimization, I found some byte-code optimization costs CPU a lot if I really want to do the optimization in byte-level. For example, int foo(unsigned long kk) { unsigned long b = (kk&0xFFFF00)>>8; return (int)(b+1); } it is obviously that bytes0 and 3 of kk is not used at all. current (i)code method needs spead 4-bytes operations, then use...
1