We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
i use keil arm rvct and have small problem RVCT have no #pragma pack(1) but when i got program from my friend i didnt see this program and RVCT didnt say warning about this command - and i have problem because this command destroy execute program for example
#pragma pack(1)
typedef struct { unsigned char command; unsigned long packets; unsigned char reserved[3];
} COMMAND2;
int main() { COMMAND2 cmd2; unsigned long Size;
cmd2.command = 0x01; cmd2.packets = 1000; Size = cmd2.packets; Size = cmd2.command; }
when run this program Size <> 1 at the end !!!
undetermine command #pragma pack(1) create error and compiler dont say warning about this command if correct program for RVTC
typedef __packed struct { unsigned char command; unsigned long packets; unsigned char reserved[3];
we will get ok result
"bla-bla-bla not supported by compiler #2, compiler #2 can silently ignore the pragma."
KEIL compiler not support bla-bla-bla but MOT IGNORE pragma - its generate crazy code !!! try my example and after it we may will say about it you dot undestand me - because didnt try my small example if you try example you will be suprise !!!
"its generate crazy code !!!"
You have not yet posted the crazy code it generated.
"you dot undestand me - because didnt try my small example"
Your example produces no output and you didn't explain how you observed this craziness and arrived at your conclusion, so there's nothing to check.
If you are so absolutely convinced there is a compiler bug, why are you posting here instead of contacting Keil Support?
"You have not yet posted the crazy code it generated" you may create and look code in your compiler source C is enough
"Your example produces no output and you didn't explain how you observed this craziness and arrived at your conclusion, so there's nothing to check."
program has 4 operators do you undestand this program? :-)))))))))) debug this programm in keil emulator - and look on variable Size !!! and you see bug
after it you may look assembler code
after it we may say something about problem :-) again
i all said ;-)
"you may create and look code in your compiler source C is enough"
No, my compiler may be a different version than yours and produce different code. My compile options may be different than yours and produce different code.
"after it we may say something about problem "
No we won't because I'm done with your profound ignorance regarding how to present a problem for discussion or solution.
www.catb.org/.../smart-questions.html
Have you tried to print the variable Size, or have you only tried to watch it in the emulator?
If your code doesn't use Size for anything, the compiler may decide that it isn't important to make the assign.
A lot of strange things can happen if a compiler can deduce that a variable or an assign is never used.
if we have #pragma pack(1) - which must ignore and compiler must work how have no pragma problem is what when write cmd2.packets = 1000; this command erase cmd2.command
if we have no #pragma - we will see all OK
"No, my compiler may be a different version than yours and produce different code. My compile options may be different than yours and produce different code." 1 if you wanted - you got evalution version from keil 2 i try on few version compiler rvtc from keil 3 you say very much words - but dont said word 4 try and look - and dont say what you lower man - and try faqs again
Note one thing very important:
Two compilers can support a specific pragma, but they may define it to mean something completely different.
My question is still: Have you tried to print the variable Size?
Maybe the compiler do support #pragma pack(1) to mean exactly what you want it to mean, but are ignoring all use of the Size variable, since you haven't shown the compiler that you are really going to use it...
We can try and compile your code. However:
1) If you are wrong - we just lost time chasing ghosts.
2) If you are correct - then we can't solve your problem anyway.
3) A lot of users (expectedly all?) here already have an installed Keil compiler. Will the licensed version behave identically to the free version? What other settings do we need to care about, since you are only talking about a couple of lines of code - not a complete project...
4) Not all users here are using the same architecture or processor, so even if we do use Keil compilers, we might not have to care about this problem because it may not be applicable to our projects.
5) If there really is an error that do affect us, then the correct solution is that you send a complete project that correctly reproduces the problem to Keil support.
.................... very many words .....
programm has 4(FORE) commands you may try or you have no KEIL COMPILER? why did you write here if you have no keil arm compiler(RVTC) which i wrote up? i repeat my question - YOU TRY CODE? your answer - many many words about may be yes may be no but program has 4(FORE) commands !!! if you dont use keil arm(RVTC) what do you want ? i wrote about my problem for user whith use keil arm compiler ;-) again question ;-) do you use keil arm compiler ? have you problem whith my code? have no problem - ok- i be glad for you ;-)
Conclusion: You are either not able to read (or count to four either) When seeing more than three words, you ignore it and just calls it "many words".
I don't have a problem.
Have you really verified that you have a problem?
The compiler does not need to generate a single instruction from your source code, unless you prove to it that you will use the data. What you see in the emulator may be random noise left in the processor registers...
Unless you can show that the compiler makes an incorrect conditional jump, or emits incorrect information, you don't have a case.
You have also not supplied any assembler listings showing incorrect code being generated.
"Have you really verified that you have a problem?"
Oh, he/she/it most assuredly has a problem -- the refusal to cut through all of the drivel and obfuscation by simply posting an assembly listing.
**************************************************** IDE-Version: µVision3 V3.50 Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2007
Tool Version Numbers: Toolchain Path: BIN30\ C Compiler: ARM/Thumb C/C++ Compiler, RVCT3.0 [Build 951] for uVision [Full] Assembler: ARM/Thumb Macro Assembler, RVCT3.0 [Build 951] for uVision [Full] Linker/Locator: ARM Linker, RVCT3.0 [Build 951] for uVision [Full] Librarian: ARM Archiver, RVCT3.0 [Build 951] for uVision Hex Converter: ARM FromELF, RVCT3.0 [Build 951] for uVision [Full] CPU DLL: SARM.DLL V3.04 Dialog DLL: DARMP.DLL V1.13 Target DLL: BIN\UL2ARM.DLL V1.26 Dialog DLL: TARMP.DLL V1.11f ******************************************************
would you like? please look at IMPORTANT 17 OPERATOR 17: cmd2.packets = 1000;
****************************************************
#pragma pack(1) 12: { 13: COMMAND2 cmd2; 14: unsigned long Size; 15: 0x000001B0 E24DD008 SUB R13,R13,#0x00000008 16: cmd2.command = 0x01; 0x000001B4 E3A00001 MOV R0,#0x00000001 0x000001B8 E5CD0000 STRB R0,[R13] 17: cmd2.packets = 1000; 0x000001BC E3A00FFA MOV R0,#0x000003E8 0x000001C0 E28DC001 ADD R12,R13,#0x00000001 0x000001C4 E58C0000 STR R0,[R12] 18: Size = cmd2.packets; 0x000001C8 E28DC001 ADD R12,R13,#0x00000001 0x000001CC E59C1000 LDR R1,[R12] 19: Size = cmd2.command; 20: 21: 0x000001D0 E5DD1000 LDRB R1,[R13] 22: } ***************************************************************** if typedef __packed struct { unsigned char command; unsigned long packets; unsigned char reserved[3]; } COMMAND2; 12: { 13: COMMAND2 cmd2; 14: unsigned long Size; 15: 0x000001B0 E92D401C STMDB R13!,{R2-R4,R14} 16: cmd2.command = 0x01; 0x000001B4 E3A00001 MOV R0,#0x00000001 0x000001B8 E5CD0000 STRB R0,[R13] 17: cmd2.packets = 1000; 0x000001BC E28D1001 ADD R1,R13,#0x00000001 0x000001C0 E3A00FFA MOV R0,#0x000003E8 0x000001C4 EB00000E BL 0x00000204 18: Size = cmd2.packets; 0x000001C8 E28D0001 ADD R0,R13,#0x00000001 0x000001CC EB000004 BL 0x000001E4 0x000001D0 E1A04000 MOV R4,R0 19: Size = cmd2.command; 20: 21: 0x000001D4 E5DD4000 LDRB R4,[R13] 22: } ************************************************************************ have no #pragma only for example what must be when compiler will be ignore #pragma 12: { 13: COMMAND2 cmd2; 14: unsigned long Size; 15: 0x000001B0 E24DD00C SUB R13,R13,#0x0000000C 16: cmd2.command = 0x01; 0x000001B4 E3A00001 MOV R0,#0x00000001 0x000001B8 E5CD0000 STRB R0,[R13] 17: cmd2.packets = 1000; 0x000001BC E3A00FFA MOV R0,#0x000003E8 0x000001C0 E58D0004 STR R0,[R13,#0x0004] 18: Size = cmd2.packets; 0x000001C4 E59D1004 LDR R1,[R13,#0x0004] 19: Size = cmd2.command; 20: 21: 0x000001C8 E5DD1000 LDRB R1,[R13] 22: }
if you want - you may add volatile for clear code
if you have no LICENSE - example for evalution version
IDE-Version: µVision3 V3.50 Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2007
Tool Version Numbers: Toolchain Path: BIN30\ C Compiler: ARM/Thumb C/C++ Compiler, RVCT3.0 [Build 951] for uVision [Evaluation] Assembler: ARM/Thumb Macro Assembler, RVCT3.0 [Build 951] for uVision [Evaluation] Linker/Locator: ARM Linker, RVCT3.0 [Build 951] for uVision [Evaluation] Librarian: ARM Archiver, RVCT3.0 [Build 951] for uVision Hex Converter: ARM FromELF, RVCT3.0 [Build 951] for uVision [Evaluation] CPU DLL: SARM.DLL V3.04 Dialog DLL: DARMP.DLL V1.13 Target DLL: BIN\UL2ARM.DLL V1.26 Dialog DLL: TARMP.DLL V1.11f
#pragma pack(1) 12: { 13: COMMAND2 cmd2; 14: volatile unsigned long Size; 15: 0x000001B0 E24DD008 SUB R13,R13,#0x00000008 16: cmd2.command = 0x01; 0x000001B4 E3A00001 MOV R0,#0x00000001 0x000001B8 E5CD0000 STRB R0,[R13] 17: cmd2.packets = 1000; 0x000001BC E3A00FFA MOV R0,#0x000003E8 0x000001C0 E28DC001 ADD R12,R13,#0x00000001 0x000001C4 E58C0000 STR R0,[R12] 18: Size = cmd2.packets; 0x000001C8 E28DC001 ADD R12,R13,#0x00000001 0x000001CC E59C1000 LDR R1,[R12] 19: Size = cmd2.command; 20: 21: 0x000001D0 E5DD1000 LDRB R1,[R13] 22: }
"look at IMPORTANT 17 OPERATOR 17: cmd2.packets = 1000;"
Ah, very good. That wasn't too hard, was it? You have finally shown what the problem is.
For whatever ARM you are using or simulating, read up on how it handles unaligned memory accesses.
"Ah, very good. That wasn't too hard, was it? You have finally shown what the problem is.
For whatever ARM you are using or simulating, read up on how it handles unaligned memory accesses "
are you top manager? who may see - will be see
i finished this topic good bye baby ;-)