Alireza.Moshtaghi at microchip.com
2007-Sep-13 20:51 UTC
[LLVMdev] PointerTypes with AddressSpace
Thank you Chris and Christopher, I agree... the Embedded C Language Extensions report provides a good foundation to build on, and what it proposes as far as Address Space is probably a super set of what we have in our existing compiler (and probably would like to keep) so no conflict there. I also agree that regardless of how we would like to deal with pointers, the same extensions must be applied to LLVM. I think it all boils down to whether you think it is time to incorporate these extensions into LLVM IR and how long do you think it will take to do so? Regards Ali. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Wednesday, September 12, 2007 11:07 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] PointerTypes with AddressSpace On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote:> Chris, > Extending LLVM IR to support PointerTypes that take an address > space is > what I was hoping to avoid. However, if we want to do things right, > that > is probably the way to go. Now that we got here, let me write some > of my > thoughts on this and solicit your input:Okay, I agree that it's the right way to go. Also, being able to eventually the Embedded C specification as Christopher points out seems very useful :).> --- 1) Syntax extension: > In our existing compiler for 8-bit microcontrollers, we have > introduced > rom and ram qualifiers (with ram being the default one) that can be > applied to any type for example: > rom int a; //integer in program memory > rom int *a; //ram pointer to integer in rom > int * rom a; //rom pointer to integer in ram > rom int * rom a; //rom pointer to integer in rom > Is something similar to the above what you also envision?As far as C syntax goes, I have no preference. I think that following Embedded C makes the most sense.> --- 2) Automatic pointers: > This is what we don't have in our existing compiler, but many > people are > asking for it. Would it be possible in LLVM to treat pointers as > general > all the way to code generation, and then decide its Address Space > based > on the following criteria? (we should be able to do so in an LLVM pass > because at code generation time we have the full view of the program) > -- a) Address Space of the pointer is the Address Space of the > variable > eg: ptr = &var; //AddSp of ptr becomes AddSp of var > -- b) Address Space of the pointer is the address Space of the pointer > eg: ptr1 = ptr2; //AddSp of ptr1 becomes AddSp of ptr2 > -- c) Conflicts inside functions are not resolvable and should > generate > diagnostic. > eg: > void f(void){ > generalPtr = romPtr; > //some code > generalPtr = ramPtr; // non resolvable conflict > }This basically amounts to type inference. If you want this, it would have to be implemented in the front-end, not in at the LLVM level (you lose too much to give useful error reports etc). Type inference is very nice, but it is not in the spirit of C at all. C is very explicit (to a fault perhaps).> -- d) Conflicts at the function interface will spawn a new function > eg: > void inc(int *a){ > (*a)++; > } > void g(void){ > inc(romPointer); // this will spawn an f with rom pointer > inc(ramPointer); // this will spawn an f with ram pointer > } > > In the case of (2) we still need rom and ram qualifiers to declare > variables in the intended Address Space, however the impact on the > front > end will probably be reduced. > A combination of (1) and (2) would probably be ideal.This again is a front-end issue. It sounds like you want generic functions ala C++ templates. If you go down this path, you are basically designing your own c-like language, you're not doing a simple C extension (which is what Embedded C is). Regardless of whether you choose to make your own language or use Embedded C, the LLVM support should be the same though. -Chris _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, 13 Sep 2007 Alireza.Moshtaghi at microchip.com wrote:> I think it all boils down to whether you think it is time to incorporate > these extensions into LLVM IR and how long do you think it will take to > do so?Sure, any time is good. The reason we don't have this now is primarily because noone has stepped up to contribute it. If you're like to start this, I'd be happy to help with the design issues. -Chris> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chris Lattner > Sent: Wednesday, September 12, 2007 11:07 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] PointerTypes with AddressSpace > > > On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com> > <Alireza.Moshtaghi at microchip.com> wrote: > >> Chris, >> Extending LLVM IR to support PointerTypes that take an address >> space is >> what I was hoping to avoid. However, if we want to do things right, >> that >> is probably the way to go. Now that we got here, let me write some >> of my >> thoughts on this and solicit your input: > > Okay, I agree that it's the right way to go. Also, being able to > eventually the Embedded C specification as Christopher points out > seems very useful :). > >> --- 1) Syntax extension: >> In our existing compiler for 8-bit microcontrollers, we have >> introduced >> rom and ram qualifiers (with ram being the default one) that can be >> applied to any type for example: >> rom int a; //integer in program memory >> rom int *a; //ram pointer to integer in rom >> int * rom a; //rom pointer to integer in ram >> rom int * rom a; //rom pointer to integer in rom >> Is something similar to the above what you also envision? > > As far as C syntax goes, I have no preference. I think that > following Embedded C makes the most sense. > >> --- 2) Automatic pointers: >> This is what we don't have in our existing compiler, but many >> people are >> asking for it. Would it be possible in LLVM to treat pointers as >> general >> all the way to code generation, and then decide its Address Space >> based >> on the following criteria? (we should be able to do so in an LLVM pass >> because at code generation time we have the full view of the program) >> -- a) Address Space of the pointer is the Address Space of the >> variable >> eg: ptr = &var; //AddSp of ptr becomes AddSp of var >> -- b) Address Space of the pointer is the address Space of the pointer >> eg: ptr1 = ptr2; //AddSp of ptr1 becomes AddSp of ptr2 >> -- c) Conflicts inside functions are not resolvable and should >> generate >> diagnostic. >> eg: >> void f(void){ >> generalPtr = romPtr; >> //some code >> generalPtr = ramPtr; // non resolvable conflict >> } > > This basically amounts to type inference. If you want this, it would > have to be implemented in the front-end, not in at the LLVM level > (you lose too much to give useful error reports etc). > > Type inference is very nice, but it is not in the spirit of C at > all. C is very explicit (to a fault perhaps). > >> -- d) Conflicts at the function interface will spawn a new function >> eg: >> void inc(int *a){ >> (*a)++; >> } >> void g(void){ >> inc(romPointer); // this will spawn an f with rom pointer >> inc(ramPointer); // this will spawn an f with ram pointer >> } >> >> In the case of (2) we still need rom and ram qualifiers to declare >> variables in the intended Address Space, however the impact on the >> front >> end will probably be reduced. >> A combination of (1) and (2) would probably be ideal. > > This again is a front-end issue. It sounds like you want generic > functions ala C++ templates. If you go down this path, you are > basically designing your own c-like language, you're not doing a > simple C extension (which is what Embedded C is). > > Regardless of whether you choose to make your own language or use > Embedded C, the LLVM support should be the same though. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/
Alireza.Moshtaghi at microchip.com
2007-Sep-14 00:22 UTC
[LLVMdev] Embedded C Language Extensions
Cool, Let me list the things that I can think of for now : (Please feel free to add/modify/eliminate/prioritize/etc) 1) I am still reading the LLVM docs, could you give me pointers to stuff that is more relevant to this discussion so I get faster start. 2) As far as the Embedded C language extensions, for now, I am more interested in the address space, and after that work on the Fixed point and I/O registers. 3) As far as things related to the Address Space, the ISO report leaves some stuff to the implementation; we have to decide what we want to do about them: Eg: --how many Address Spaces do we want to support in the LLVM IR --what address space names do we want to add to the front-end --how best to model nested address spaces (if we want to support this in IR) --do we want to provide some kind of support (type inference stuff) for things like Automatic pointers that I mentioned earlier (in case some one wants to use them). I agree that this is against C language fundamentals, however, people are asking for them more and more and some compilers are actually trying to support them in weird ways, I think we can handle them in LLVM much better than how others do. But again, this is probably at the bottom of our list anyways! A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Thursday, September 13, 2007 3:46 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] PointerTypes with AddressSpace On Thu, 13 Sep 2007 Alireza.Moshtaghi at microchip.com wrote:> I think it all boils down to whether you think it is time toincorporate> these extensions into LLVM IR and how long do you think it will taketo> do so?Sure, any time is good. The reason we don't have this now is primarily because noone has stepped up to contribute it. If you're like to start this, I'd be happy to help with the design issues. -Chris> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Chris Lattner > Sent: Wednesday, September 12, 2007 11:07 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] PointerTypes with AddressSpace > > > On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com> > <Alireza.Moshtaghi at microchip.com> wrote: > >> Chris, >> Extending LLVM IR to support PointerTypes that take an address >> space is >> what I was hoping to avoid. However, if we want to do things right, >> that >> is probably the way to go. Now that we got here, let me write some >> of my >> thoughts on this and solicit your input: > > Okay, I agree that it's the right way to go. Also, being able to > eventually the Embedded C specification as Christopher points out > seems very useful :). > >> --- 1) Syntax extension: >> In our existing compiler for 8-bit microcontrollers, we have >> introduced >> rom and ram qualifiers (with ram being the default one) that can be >> applied to any type for example: >> rom int a; //integer in program memory >> rom int *a; //ram pointer to integer in rom >> int * rom a; //rom pointer to integer in ram >> rom int * rom a; //rom pointer to integer in rom >> Is something similar to the above what you also envision? > > As far as C syntax goes, I have no preference. I think that > following Embedded C makes the most sense. > >> --- 2) Automatic pointers: >> This is what we don't have in our existing compiler, but many >> people are >> asking for it. Would it be possible in LLVM to treat pointers as >> general >> all the way to code generation, and then decide its Address Space >> based >> on the following criteria? (we should be able to do so in an LLVMpass>> because at code generation time we have the full view of the program) >> -- a) Address Space of the pointer is the Address Space of the >> variable >> eg: ptr = &var; //AddSp of ptr becomes AddSp of var >> -- b) Address Space of the pointer is the address Space of thepointer>> eg: ptr1 = ptr2; //AddSp of ptr1 becomes AddSp of ptr2 >> -- c) Conflicts inside functions are not resolvable and should >> generate >> diagnostic. >> eg: >> void f(void){ >> generalPtr = romPtr; >> //some code >> generalPtr = ramPtr; // non resolvable conflict >> } > > This basically amounts to type inference. If you want this, it would > have to be implemented in the front-end, not in at the LLVM level > (you lose too much to give useful error reports etc). > > Type inference is very nice, but it is not in the spirit of C at > all. C is very explicit (to a fault perhaps). > >> -- d) Conflicts at the function interface will spawn a new function >> eg: >> void inc(int *a){ >> (*a)++; >> } >> void g(void){ >> inc(romPointer); // this will spawn an f with rom pointer >> inc(ramPointer); // this will spawn an f with ram pointer >> } >> >> In the case of (2) we still need rom and ram qualifiers to declare >> variables in the intended Address Space, however the impact on the >> front >> end will probably be reduced. >> A combination of (1) and (2) would probably be ideal. > > This again is a front-end issue. It sounds like you want generic > functions ala C++ templates. If you go down this path, you are > basically designing your own c-like language, you're not doing a > simple C extension (which is what Embedded C is). > > Regardless of whether you choose to make your own language or use > Embedded C, the LLVM support should be the same though. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev