On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com> wrote:> > > On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com> wrote: >> >> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com> wrote: >> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com> wrote: >> > >> > Take a look at how debuggers have migrated through the years. They too >> >> >> >> used to have their own script format. Now most (all?) popular >> >> debuggers >> >> do scripting through embedding an actual programming language. This >> >> could be a better way forward for linkers as well -- embed Python in >> >> the >> >> linker, define a Python API for linkable item placement, entry point, >> >> symbol operations, etc..., and then you also have the rest of Python at >> >> your fingertips. >> > >> > >> > I mostly care about specifying address where specific symbols will be >> > placed >> > and specifying the memory layout of the platform. I normally use >> > __attribute__((section(""))) to place the symbols in their own sections >> > and >> > then use the linker script to place the sections at the required >> > addresses. >> > How would this be accomplished without linker scripts? >> > >> > >> > I’d prefer to use an "__attribute__((address(0x1234)))” myself. That >> > way >> > you can control platform specifics with #ifdefs. >> >> But that way you have to do layout by hand in C. Generally you won't >> know the size of the preceding code or data so you won't know what >> address to put things at at the granularity of a single C level >> object/function. Better to say "put this in the ROM section" and set >> the address of the ROM section once in a linker script and let the >> linker do the layout. > > > The real use case is on platforms, like ARM, where control registers are > mapped to a specific address range. Then it is useful to put an object that > deals with the control registers at a specific address. > __attribute__((address(0x1234))) can be replaced with a platform specific > linker script. Which is better? I don't know, I haven't spent any time > comparing them.Why would you want to put an object at the address of some registers? You would just want a cast would you not? e.g. regs = (struct MyRegBlock *)0x1234
On Wed, May 6, 2015 at 9:34 AM, Will Newton <will.newton at gmail.com> wrote:> On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com> wrote: > > > > > > On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com> > wrote: > >> > >> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com> > wrote: > >> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com> wrote: > >> > > >> > Take a look at how debuggers have migrated through the years. They > too > >> >> > >> >> used to have their own script format. Now most (all?) popular > >> >> debuggers > >> >> do scripting through embedding an actual programming language. This > >> >> could be a better way forward for linkers as well -- embed Python in > >> >> the > >> >> linker, define a Python API for linkable item placement, entry point, > >> >> symbol operations, etc..., and then you also have the rest of Python > at > >> >> your fingertips. > >> > > >> > > >> > I mostly care about specifying address where specific symbols will be > >> > placed > >> > and specifying the memory layout of the platform. I normally use > >> > __attribute__((section(""))) to place the symbols in their own > sections > >> > and > >> > then use the linker script to place the sections at the required > >> > addresses. > >> > How would this be accomplished without linker scripts? > >> > > >> > > >> > I’d prefer to use an "__attribute__((address(0x1234)))” myself. That > >> > way > >> > you can control platform specifics with #ifdefs. > >> > >> But that way you have to do layout by hand in C. Generally you won't > >> know the size of the preceding code or data so you won't know what > >> address to put things at at the granularity of a single C level > >> object/function. Better to say "put this in the ROM section" and set > >> the address of the ROM section once in a linker script and let the > >> linker do the layout. > > > > > > The real use case is on platforms, like ARM, where control registers are > > mapped to a specific address range. Then it is useful to put an object > that > > deals with the control registers at a specific address. > > __attribute__((address(0x1234))) can be replaced with a platform specific > > linker script. Which is better? I don't know, I haven't spent any time > > comparing them. > > Why would you want to put an object at the address of some registers? > You would just want a cast would you not? > > e.g. regs = (struct MyRegBlock *)0x1234 >This causes you to have to be constantly dereferencing, which can result in a huge amount of syntactic overhead. CMSIS does this really consistently and do a good job at it: http://www.keil.com/pack/doc/CMSIS/Core/html/group__peripheral__gr.html But it's sort of an all-or-nothing thing to organize the peripheral headers like that, and many platforms don't (MSP430, AVR, smaller PIC's), instead preferring to have e.g. `volatile uint8_t Foo;` for each hardware register instead of putting things in structs. -- Sean Silva> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/a40d5295/attachment.html>
> On May 6, 2015, at 13:34 , Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, May 6, 2015 at 9:34 AM, Will Newton <will.newton at gmail.com> wrote: > > Why would you want to put an object at the address of some registers? > You would just want a cast would you not? > > e.g. regs = (struct MyRegBlock *)0x1234 > > This causes you to have to be constantly dereferencing, which can result in a huge amount of syntactic overhead. CMSIS does this really consistently and do a good job at it: http://www.keil.com/pack/doc/CMSIS/Core/html/group__peripheral__gr.html > But it's sort of an all-or-nothing thing to organize the peripheral headers like that, and many platforms don't (MSP430, AVR, smaller PIC's), instead preferring to have e.g. `volatile uint8_t Foo;` for each hardware register instead of putting things in structs. > > -- Sean SilvaHaving worked with both forms (struct vs. individual symbols), I really prefer the struct mechanism. Especially in more recent processors, the hardware register layout is very consistent from one peripheral to the next, and when using the struct, it can dramatically reduce the number of symbols one has to deal with. So, my $0.02 (having only a cursory understanding of this thread) is to hopefully allow the struct mechanism. -- Rick Mann rmann at latencyzero.com
While slightly off topic of LLD improvement, volatile uint8_t __attribute__((address(0x1234))) foo; is slightly nicer than (*(volatile uint8_t *)0x1234) because the latter ends up often being done in a header file as a macro, usually as something like: #define foo (*(volatile uint8_t *)0x1234) The former behaves with all the language scoping rules, so a foo within a function or as a parameter has the expected behavior. The latter has all the downsides that macro usage can come with. On topic – Sean – I think that is a great document on linker scripts and their usage and meaning. Kevin Smith From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva Sent: Wednesday, May 06, 2015 1:34 PM To: Will Newton Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] LLD improvement plan On Wed, May 6, 2015 at 9:34 AM, Will Newton <will.newton at gmail.com<mailto:will.newton at gmail.com>> wrote: On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com<mailto:diltsman at gmail.com>> wrote:> > > On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com<mailto:will.newton at gmail.com>> wrote: >> >> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com<mailto:clattner at apple.com>> wrote: >> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com<mailto:diltsman at gmail.com>> wrote: >> > >> > Take a look at how debuggers have migrated through the years. They too >> >> >> >> used to have their own script format. Now most (all?) popular >> >> debuggers >> >> do scripting through embedding an actual programming language. This >> >> could be a better way forward for linkers as well -- embed Python in >> >> the >> >> linker, define a Python API for linkable item placement, entry point, >> >> symbol operations, etc..., and then you also have the rest of Python at >> >> your fingertips. >> > >> > >> > I mostly care about specifying address where specific symbols will be >> > placed >> > and specifying the memory layout of the platform. I normally use >> > __attribute__((section(""))) to place the symbols in their own sections >> > and >> > then use the linker script to place the sections at the required >> > addresses. >> > How would this be accomplished without linker scripts? >> > >> > >> > I’d prefer to use an "__attribute__((address(0x1234)))” myself. That >> > way >> > you can control platform specifics with #ifdefs. >> >> But that way you have to do layout by hand in C. Generally you won't >> know the size of the preceding code or data so you won't know what >> address to put things at at the granularity of a single C level >> object/function. Better to say "put this in the ROM section" and set >> the address of the ROM section once in a linker script and let the >> linker do the layout. > > > The real use case is on platforms, like ARM, where control registers are > mapped to a specific address range. Then it is useful to put an object that > deals with the control registers at a specific address. > __attribute__((address(0x1234))) can be replaced with a platform specific > linker script. Which is better? I don't know, I haven't spent any time > comparing them.Why would you want to put an object at the address of some registers? You would just want a cast would you not? e.g. regs = (struct MyRegBlock *)0x1234 This causes you to have to be constantly dereferencing, which can result in a huge amount of syntactic overhead. CMSIS does this really consistently and do a good job at it: http://www.keil.com/pack/doc/CMSIS/Core/html/group__peripheral__gr.html But it's sort of an all-or-nothing thing to organize the peripheral headers like that, and many platforms don't (MSP430, AVR, smaller PIC's), instead preferring to have e.g. `volatile uint8_t Foo;` for each hardware register instead of putting things in structs. -- Sean Silva _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/9c382e4d/attachment.html>