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.
Hi all, I try to use the simulator with a code that contains struct or union, but it doesn't seem to see members. Here is an example code: struct chuf { unsigned char hi; unsigned char lo; }; union { struct chuf chi; unsigned int both; } buf; void main(void) { buf.chi.hi =5; buf.chi.lo =1; buf.both =0x1122; while (buf.both) buf.both>>=1; } When I try to see something like buf.both, it shows error 10. By the way, where can one see the list of simulator errors? When I look for just buf, it shows the first byte of this union. At the same time, within the memory it seems to work right. Can anything be done about it? Thanks, Michael.
This doesn't sound like a bug to me. Here's why... If you create a C file and you compile it with the C compiler and generate an OBJ file, all line number information and symbolic information are stored in the OBJ file generated by the C compiler. If you create a C file and you compile it with the SRC option, the C compiler generates a .SRC file. The SRC file is an assembly source file. And, when you assemble the SRC file (with the assembler) you get an OBJ file generated by the assembler. Now, the OBJ file from the assembler references line numbers (from the SRC file -- NOT from the C file) and it references symbol information (again from the SRC file and NOT from the C file). The problem is that there is no assembler equivalent to the C structure. So, structure accesses in C that are compiled to a SRC file are REALLY accesses to the offset from the beginning of a symbol. And...that's why you only see 1 byte if you try to display a C struct that has been compiled to a SRC file and then assembled with the assembler. I guess one question is: Is this a bug? The answer is NO, because this is the way we designed it. The assembler is not supposed to generate symbol information and line number information that relate to the C source file. Jon
Jon, That's fair comment, but this is a commonly misunderstood area. I think Keil would do well to explain this thoroughly in the manual. After all, most people use #pragma ASM to just insert just a small snippet of assembler into a mainly-'C' source file (and this is the way it's presented in the manual). Perhaps it would help if the interleaved 'C'/Assembler listing were more accessible? How do other compilers cope with source-level debug for inline assembler?
Perhaps it would help if the interleaved 'C'/Assembler listing were more accessible? I'm not sure what you mean. The .SRC file includes both the C and generated assembly code interleaved. How do other compilers cope with source-level debug for inline assembler? This is really implementation-defined. However, I guess that other C compilers (that generate assembler output instead of .OBJ output) insert assembler directives that say to the linker, "Hey, the following lines of assembly refer to line number xxx in the C source file yyy.c" However, if you go start hacking on the assembler output, I would think that it's possible to introduce subtle synchronization errors between the assembler and C source. Jon
Andy: "Perhaps it would help if the interleaved 'C'/Assembler listing were more accessible?" Jon: "I'm not sure what you mean. The .SRC file includes both the C and generated assembly code interleaved" Sorry, I was thinking of the assembler listing produced by the CODE directive. Oops! However, I note that the .SRC file duplicates the assembler code between the ASM and ENDASM - once as a comment (representing the 'C' source) and again as "real" assembler; eg,
; #pragma ASM ; ; EXTRN CODE (m_main) EXTRN CODE (m_main) ; ; MOV A,#LOW( m_main ) ; MOV A,#LOW( m_main ) ; ; MOV wait_return_address_low,Acc ; MOV wait_return_address_low,Acc ; ; MOV A,#HIGH( m_main ) ; MOV A,#HIGH( m_main ) ;
You don't call it a bug, I do. You explain me the difference between .obj and .src files. But it is your interior problem and your virtual reality - it wasn't I who chose your implementation. What I see as a user is that writing code using both C and assembler in the same file is a common practice and your simulator doesn't provide a mean to see what is going on in the controller - that is why I call it a bug. Michael.
I found a bug in my Ford Explorer. It doesn't accelerate from 0 to 60 MPH in 4 seconds. :-) Jon
You explain me the difference between .obj and .src files. Actually, I explained why you can't see C structures when you compile the C file and generate assembly source. I guess I wasn't very clear on that point. Maybe this makes more sense. Rule 1. The Keil A51 Assembler does not have a struct data type. Therefore, structures in assembly must be implemented as an array of bytes. When you use the debugger to view these assembly structures, only the first byte will be displayed. This applies EVEN IF you start with a C file and compile it using the SRC directive. The output from the C compiler is an assembler source file (.SRC) which you must then assemble using the A51 Assembler. And, Rule 1 applies. The assembler works this way by design. Jon
"You don't call it a bug, I do." No, it's not a bug; it's a direct consequence of the way Keil have chosen to implement their support for inline assembler, as Jon has explained. You may consider this to be a bad implementation, but that's a different issue! BTW: Keil are not alone in choosing this implementation. BTW2: You see a similar effect if you #include executable code in a 'C' source file: the 'C' compiler only sees the resulting pre-processed file, so it can't generate line number debug information for the #included file! This is certainly not limited to just Keil.