??? 03/12/04 00:59 Read: times |
#66551 - RE: IAR Embedded Workbench Ver 6.10A Responding to: ???'s previous message |
An update on my new compiler:
After I succeeded in compiling my test program (code that compiled under the previous version and has been shipping for a number of years) it wouldn't link because of a missing library file. It turns out the compiler has so many options in terms of chip types, calling convention, constant storage etc., that they simply don't give all the library combinations. My IAR tech told me how to build the library for my project configuration; he had even built it himself and having found a problem with the library he also sent an updated library source. The required library built without problems. At the moment I'm fighting more linker errors, it seems that this compiler is a little more memory hungry than the previous one, and my project was tight on memory to begin with. I did examine the code it generated, and am not at all impressed. It is often recommended here that C programmers become familiar with the instruction set and assembler programming before writing C code. The same should be said of programmers that write code for the code generators. A teeny sample from some bit-bashing code: DI = 1; /* Set data into ADC to Start bit (=1) */ MOV A,0x9a SETB 0xE0 /* A */.6 MOV 0x9a,A Compared to the old compiler output: DI = 1; /* Set data into ADC to Start bit (=1) */ SETB P1.6 I was really confused about the 0x9a, until I found some code elsewhere where it became obvious that if the value had been 0x90 the code at least would have worked. Checking around I found in ioAT89S52.h (which I happened to use as being close to the AT89C52 that my project actually used) this bit of define: /* Port 1 */ __sfr __no_init volatile union { unsigned char P1; struct { unsigned char P1_0 : 1; unsigned char P1_1 : 1; unsigned char P1_2 : 1; unsigned char P1_3 : 1; unsigned char P1_4 : 1; unsigned char P1_5 : 1; unsigned char P1_6 : 1; unsigned char P1_7 : 1; } P1_bit; } @ 0x9A; A mistake in the header file, that 0x9A should have been 0x90. I guess I'll need to check each item in the header files to have any confidence it it. By adjusting the stack size smaller, I was able to get the project to link. With optimization turned off, it generated 5043 bytes of code, compared to 4852 bytes with the old compiler. However, with optimization turned on for full size optimizations, the new generated code was 3969 bytes...a significant improvement. Especially compared to the old compiler's full size optimization output of 4875 bytes (that's right, the size *increased*). Tomorrow I'll have to see if the code produced actually runs! Dennis |
Topic | Author | Date |
IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: Keil | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A | 01/01/70 00:00 | |
RE: IAR Embedded Workbench Ver 6.10A![]() | 01/01/70 00:00 |