From: Kustaa N. <Kus...@pl...> - 2014-06-18 08:35:38
|
Hi I noticed one of projects has (for some historical reason) a few definitions like this: typedef struct _BDT { unsigned char STAT; unsigned char CNT; unsigned int ADDR; } BDT; volatile BDT __at (0x0400+0*8) ep0_o; ...etc... (These define a USB end points at the given addresses). Now this won't work if I include this header in several places in my project, so I'm planning to change this definition into declaration volatile BDT ep0_o; and move the definition to .c file of its own. Now my questions is if this is going to change the generated code, especially if it incurs performance or code size penalty as I'm running on the edge on both. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Maarten B. <sou...@ds...> - 2014-06-18 11:48:49
|
Hello Kusti, Though I have no problem with your proposed change, it's probably not exactly as you expect here. Like the manual says, when a variable has an absolute location but no initializer it is not allocated by the compiler/linker. This is due to backward compatibility. I haven't checked for the pic code, but this how SDCC works in general and I assume the pic target to be no different. Maarten > Hi > > I noticed one of projects has (for some historical reason) a few > definitions > like this: > > > typedef struct _BDT > { > unsigned char STAT; > unsigned char CNT; > unsigned int ADDR; > } BDT; > > > volatile BDT __at (0x0400+0*8) ep0_o; > ...etc... > > > > (These define a USB end points at the given addresses). > > Now this won't work if I include this header in several places in my > project, > so I'm planning to change this definition into declaration > > volatile BDT ep0_o; > > and move the definition to .c file of its own. > > Now my questions is if this is going to change the generated code, > especially > if it incurs performance or code size penalty as I'm running on the edge > on both. > > br Kusti |
From: Kustaa N. <Kus...@pl...> - 2014-06-18 12:00:41
|
On 18/06/2014 14:48, "Maarten Brock" <sou...@ds...> wrote: >Hello Kusti, > >Though I have no problem with your proposed change, it's probably not >exactly as you expect here. That's why I asked ;) > Like the manual says, when a variable has an >absolute location but no initializer it is not allocated by the >compiler/linker. Hmm....can you elaborate a bit...as this is just a hardware register I do not want it to be allocated...but that of course depends on what allocated means here. My worry is that the access to it might be slower if the compiler/assembler does not see the full definition. >This is due to backward compatibility. I haven't checked >for the pic code, but this how SDCC works in general and I assume the pic >target to be no different. Thank you for answering! br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Maarten B. <sou...@ds...> - 2014-06-18 12:16:37
|
Hi again, >> Like the manual says, when a variable has an >>absolute location but no initializer it is not allocated by the >>compiler/linker. > > Hmm....can you elaborate a bit...as this is just a hardware register > I do not want it to be allocated...but that of course depends on what > allocated means here. My worry is that the access to it might be slower > if the compiler/assembler does not see the full definition. Allocated means that you nor the linker can place any other variable at that address. It is marked occupied and if it is global then it must be zeroed unless initialized before reaching main as specified by the C spec. When you use __at without initializer however, SDCC does not allocate and you can define another variable (with __at) at the same address. It will also not zero the variable at startup. This is probably exactly what you need for a hardware register. Maarten |
From: Kustaa N. <Kus...@pl...> - 2014-06-18 12:53:53
|
On 18/06/2014 15:16, "Maarten Brock" <sou...@ds...> wrote: > >When you use __at without initializer however, SDCC does not allocate and >you can define another variable (with __at) at the same address. It will >also not zero the variable at startup. This is probably exactly what you >need for a hardware register. Exactly, thanks. But what about access efficiency? If I just declare the variable in the header and define it (with __at) in the c file, is the code generated to to read/write the variable different from if I just define it in the header? br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Maarten B. <sou...@ds...> - 2014-06-18 13:41:19
|
> On 18/06/2014 15:16, "Maarten Brock" <sou...@ds...> wrote: >> >>When you use __at without initializer however, SDCC does not allocate and >>you can define another variable (with __at) at the same address. It will >>also not zero the variable at startup. This is probably exactly what you >>need for a hardware register. > > Exactly, thanks. But what about access efficiency? If I just declare > the variable in the header and define it (with __at) in the c file, > is the code generated to to read/write the variable different from > if I just define it in the header? I don't know. I don't work on the pic backend. But try it and you'll find out soon enough I guess by looking at the generated asm. |
From: Kustaa N. <Kus...@pl...> - 2014-06-21 20:33:58
|
On 18/06/2014 16:41, "Maarten Brock" <sou...@ds...> wrote: > >I don't know. I don't work on the pic backend. But try it and you'll find >out soon enough I guess by looking at the generated asm. Maybe I should have tried this first... In the .h I put: extern volatile BDT ep0_o; In the .c that includes above I put: volatile BDT __at (0x0400+0*8) ep0_o; and the compiler says: usb_pic_defs.c:9: error 91: extern definition for 'ep0_o' mismatches with declaration. usb_pic_defs.h:70: error 177: previously defined here So...maybe I'm too tired but I can't figure out how I can put a variable at a given address and declare it in the .h file and define it in the .c file. If I define it at the .h file then I get into trouble with linker if I include the .h file in multiple .c files...not god. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Joel D. <jr...@pr...> - 2014-06-21 20:44:05
|
On Sat, 21 Jun 2014, it would appear that Kustaa Nyholm wrote: > On 18/06/2014 16:41, "Maarten Brock" <sou...@ds...> wrote: >> >> I don't know. I don't work on the pic backend. But try it and you'll find >> out soon enough I guess by looking at the generated asm. > > Maybe I should have tried this first... > > > In the .h I put: > > extern volatile BDT ep0_o; > > > In the .c that includes above I put: > > volatile BDT __at (0x0400+0*8) ep0_o; > > and the compiler says: > > usb_pic_defs.c:9: error 91: extern definition for 'ep0_o' mismatches with > declaration. > usb_pic_defs.h:70: error 177: previously defined here > > > So...maybe I'm too tired but I can't figure out how I can put a > variable at a given address and declare it in the .h file > and define it in the .c file. If I define it at the .h file > then I get into trouble with linker if I include the .h file > in multiple .c files...not god. > > br Kusti Why not put: #ifndef __VARDEF volatile BDT __at (0x0400+0*8) ep0_o; #define __VARDEF #endif ...other defines in your .h? Joel -- Joel Davidson Austin, TX |
From: Raphael N. <rn...@we...> - 2014-06-21 20:45:59
|
Hi, why not do as the libraries declare and define SFRs? In the header use extern __at(0x0400) volatile BDT ep0_o; In one .c file use __at(0x0400) volatile BDT ep0_o; The relative order of __at() and the other keywords is somewhat flexible, the above scheme is used in the device libraries and headers. Hope that helps, Raphael On Jun 21, 2014 10:35 PM, "Kustaa Nyholm" <Kus...@pl...> wrote: > On 18/06/2014 16:41, "Maarten Brock" <sou...@ds...> wrote: > > > >I don't know. I don't work on the pic backend. But try it and you'll find > >out soon enough I guess by looking at the generated asm. > > Maybe I should have tried this first... > > > In the .h I put: > > extern volatile BDT ep0_o; > > > In the .c that includes above I put: > > volatile BDT __at (0x0400+0*8) ep0_o; > > and the compiler says: > > usb_pic_defs.c:9: error 91: extern definition for 'ep0_o' mismatches with > declaration. > usb_pic_defs.h:70: error 177: previously defined here > > > So...maybe I'm too tired but I can't figure out how I can put a > variable at a given address and declare it in the .h file > and define it in the .c file. If I define it at the .h file > then I get into trouble with linker if I include the .h file > in multiple .c files...not god. > > br Kusti > > > > > > > > This e-mail may contain confidential or privileged information. If you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. We will not be liable for direct, indirect, special or > consequential damages arising from alteration of the contents of this > message by a third party or as a result of any virus being passed on or as > of transmission of this e-mail in general. > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Kustaa N. <Kus...@pl...> - 2014-06-21 20:59:45
|
>why not do as the libraries declare and define SFRs? >In the header use >extern __at(0x0400) volatile BDT ep0_o; Ah, of course, I should have looked at the headers thanks, that is exactly what I was looking for! Hmm, spoke too soon, now the linker complains: error: missing definition for symbol "_ep0_o", required by "../obj/usb_hid.o" and if try to define it in the .c file I again get: volatile BDT ep0_o; br Kusti ________________________________ This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Raphael N. <rn...@we...> - 2014-06-21 21:04:30
|
Hi, your definition (in the. c file) is missing the __at() keyword including the address argument. The only difference between header and implementation file is the extern keyword (and optionally the initializer, do not use them here, though). Good luck, Raphael On Jun 21, 2014 11:00 PM, "Kustaa Nyholm" <Kus...@pl...> wrote: > >why not do as the libraries declare and define SFRs? > >In the header use > >extern __at(0x0400) volatile BDT ep0_o; > > > Ah, of course, I should have looked at the headers thanks, that is > exactly what I was looking for! > > Hmm, spoke too soon, now the linker complains: > > error: missing definition for symbol "_ep0_o", required by > "../obj/usb_hid.o" > > and if try to define it in the .c file I again get: > > volatile BDT ep0_o; > > > br Kusti > > > ------------------------------ > This e-mail may contain confidential or privileged information. If you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. We will not be liable for direct, indirect, special or > consequential damages arising from alteration of the contents of this > message by a third party or as a result of any virus being passed on or as > of transmission of this e-mail in general. > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Kustaa N. <Kus...@pl...> - 2014-06-21 21:16:42
|
>your definition (in the. c file) is missing the __at() keyword including >the address argument. The only difference between > header and implementation file is the extern keyword (and optionally the >initializer, do not use them here, though). Of course, getting late here, time to get some sleep. That solved the problem, rather elementary, I think what steered me off the track was that I presumed I would not have to repeat the address...repeating it both in .h and .c is not very cool OTH looks like it really is no maintenance problem as the compiler complains if the addresses do not match...could of course use a define for the address but that's more boiler plate defines to write and name. Thanks and good night from Finland where it is still quite light and the sun rises in a few hours, length of day 18 hours, 55 minutes... br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. |
From: Raphael N. <rn...@we...> - 2014-06-21 20:52:00
|
Hi, while ok in this case (with variables being pinned to fixed locations), please never put variable definitions into header files, even if guarded by such defines. Sooner or later you will end up getting linker errors, which someone could then try to resolve by making the variables static, which leads to duplication of the variables and interesting errors at runtime. For variable declarations in header files, you need to use the extern keyword! Best regards, Raphael On Jun 21, 2014 10:45 PM, "Joel Davidson" <jr...@pr...> wrote: > On Sat, 21 Jun 2014, it would appear that Kustaa Nyholm wrote: > > > On 18/06/2014 16:41, "Maarten Brock" <sou...@ds...> wrote: > >> > >> I don't know. I don't work on the pic backend. But try it and you'll > find > >> out soon enough I guess by looking at the generated asm. > > > > Maybe I should have tried this first... > > > > > > In the .h I put: > > > > extern volatile BDT ep0_o; > > > > > > In the .c that includes above I put: > > > > volatile BDT __at (0x0400+0*8) ep0_o; > > > > and the compiler says: > > > > usb_pic_defs.c:9: error 91: extern definition for 'ep0_o' mismatches with > > declaration. > > usb_pic_defs.h:70: error 177: previously defined here > > > > > > So...maybe I'm too tired but I can't figure out how I can put a > > variable at a given address and declare it in the .h file > > and define it in the .c file. If I define it at the .h file > > then I get into trouble with linker if I include the .h file > > in multiple .c files...not god. > > > > br Kusti > > Why not put: > > #ifndef __VARDEF > volatile BDT __at (0x0400+0*8) ep0_o; > #define __VARDEF > #endif > ...other defines > > in your .h? > > Joel > -- > Joel Davidson > Austin, TX > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Joel D. <jr...@pr...> - 2014-06-21 21:46:47
|
Ah, good point. I learn something all the time on this list. Thanks Raphael. On Sat, 21 Jun 2014, it would appear that Raphael Neider wrote: > Hi, > > while ok in this case (with variables being pinned to fixed locations), > please never put variable definitions into header files, even if guarded by > such defines. Sooner or later you will end up getting linker errors, which > someone could then try to resolve by making the variables static, which > leads to duplication of the variables and interesting errors at runtime. > > For variable declarations in header files, you need to use the extern > keyword! > > Best regards, > Raphael > On Jun 21, 2014 10:45 PM, "Joel Davidson" <jr...@pr...> wrote: > >> On Sat, 21 Jun 2014, it would appear that Kustaa Nyholm wrote: >> >>> On 18/06/2014 16:41, "Maarten Brock" <sou...@ds...> wrote: >>>> >>>> I don't know. I don't work on the pic backend. But try it and you'll >> find >>>> out soon enough I guess by looking at the generated asm. >>> >>> Maybe I should have tried this first... >>> >>> >>> In the .h I put: >>> >>> extern volatile BDT ep0_o; >>> >>> >>> In the .c that includes above I put: >>> >>> volatile BDT __at (0x0400+0*8) ep0_o; >>> >>> and the compiler says: >>> >>> usb_pic_defs.c:9: error 91: extern definition for 'ep0_o' mismatches with >>> declaration. >>> usb_pic_defs.h:70: error 177: previously defined here >>> >>> >>> So...maybe I'm too tired but I can't figure out how I can put a >>> variable at a given address and declare it in the .h file >>> and define it in the .c file. If I define it at the .h file >>> then I get into trouble with linker if I include the .h file >>> in multiple .c files...not god. >>> >>> br Kusti >> >> Why not put: >> >> #ifndef __VARDEF >> volatile BDT __at (0x0400+0*8) ep0_o; >> #define __VARDEF >> #endif >> ...other defines >> >> in your .h? >> >> Joel >> -- >> Joel Davidson >> Austin, TX |