search for: n1169

Hi, I don't think we should make bit casts between pointers with different address spaces illegal. Address spaces are not required to be disjoint. In the N1169 spec, it says A non-null pointer into an address space A can be cast to a pointer into another address space B, but such a cast is undefined if the source pointer does not point to a location in B. If the address spaces overlap, one should be able to bticast between them. -- Mon Ping On S...

I've been playing around with clang/LLVM looking at adding partial support for the draft technical report for embedded C extensions (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf), specifically named address spaces. Named address spaces need to be tracked in LLVM in essentially all the same places that alignment is tracked, which necessitates adding the information to the .bc format. Given the Apple has shipped .bc files I'm guessing that backwards compatib...

Should LLVM make bitcasts between pointers with different address spaces illegal? This will require a small clarification in the documentation and an assertion check added to the verifier, but I think this would be a good approach. The reason being is that in different address spaces, pointers are not always the same size. This could be limited to make it legal only if the size of the pointer

Mon Ping Wang wrote: > Hi, > > I don't think we should make bit casts between pointers with different > address spaces illegal. Address spaces are not required to be disjoint. > In the N1169 spec, it says > A non-null pointer into an address space A can be cast to a pointer into > another address space B, but such a cast is undefined if the source > pointer does not point to a location in B. Use a ptrtoint + inttoptr to implement the cast. > If the address spaces overlap,...

On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > I've been playing around with clang/LLVM looking at adding partial > support for the draft technical report for embedded C extensions > (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ > n1169.pdf), specifically named address spaces. > > Named address spaces need to be tracked in LLVM in essentially all > the same places that alignment is tracked, Others addressed the other questions, one (surprising?) thing I'd recommend: Unlike alignment and volatility, I think that...

...Lewycky<nicholas at mxc.ca> wrote: > >> Mon Ping Wang wrote: >>> Hi, >>> >>> I don't think we should make bit casts between pointers with different >>> address spaces illegal. Address spaces are not required to be disjoint. >>> In the N1169 spec, it says >>> A non-null pointer into an address space A can be cast to a pointer into >>> another address space B, but such a cast is undefined if the source >>> pointer does not point to a location in B. >> >> Use a ptrtoint + inttoptr to implement the c...

...7, 2012, at 11:10 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Mon Ping Wang wrote: >> Hi, >> >> I don't think we should make bit casts between pointers with different >> address spaces illegal. Address spaces are not required to be disjoint. >> In the N1169 spec, it says >> A non-null pointer into an address space A can be cast to a pointer into >> another address space B, but such a cast is undefined if the source >> pointer does not point to a location in B. > > Use a ptrtoint + inttoptr to implement the cast. > I find...

...gt; wrote: >> >>> Mon Ping Wang wrote: >>>> Hi, >>>> >>>> I don't think we should make bit casts between pointers with different >>>> address spaces illegal. Address spaces are not required to be disjoint. >>>> In the N1169 spec, it says >>>> A non-null pointer into an address space A can be cast to a pointer into >>>> another address space B, but such a cast is undefined if the source >>>> pointer does not point to a location in B. >>> >>> Use a ptrtoint + inttop...

...permail/llvmdev/2007-November/011385.html. >From there, it is pretty clear that addrspace was introduced specifically as a mechanism for implementing the 'named address space' extensions defined in the Embedded C standard (ISO/IEC TR 18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf). The Embedded C standard gives this overview of the 'named address space' extension: Many embedded processors have multiple distinct banks of memory and require that data be grouped in different banks to achieve maximum performance. Ensuring the simultaneous flow of data and...

On Thu, Jul 17, 2008 at 5:08 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Now, we are using a function which reads a value from one of these memories > and does some processing. Since we want to execute this function for multiple > memories, we make it accept a pointer in the generic address space (ie, no > address space attribute): > > void do_stuff(char*

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will d...

...> On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address spaces. >> >> Named address spaces need to be tracked in LLVM in essentially all >> the same places that alignment is tracked, > > Others addressed the other questions, one (surprising?) thing I'd > recommend: > > Unlike alig...

...> On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address spaces. >> >> Named address spaces need to be tracked in LLVM in essentially all >> the same places that alignment is tracked, > > Others addressed the other questions, one (surprising?) thing I'd > recommend: > > Unlike alig...

Hi all, I'm currently struggling a bit with some problems regarding address spaces and (implicit) casts. I'll explain some context first and then proceed to the actual question I'd like to have answered. In our target platform, we have a number of distinctly different memory banks. To access these from our C code, we declare a global array for each memory, with the address space

On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > The more I think about it, the more I become uncomfortable with the > concept of language-specific address spaces in LLVM.  These are the > main issues I see with language-specific address spaces: ... > Instead of language-specific address spaces, each target should > concentrate on

On Fri, Feb 25, 2011 at 02:55:33PM -0500, Ken Dyck wrote: > The address space mechanism is used by some code generators to > differentiate between physical memory spaces. The PIC16 code generator > uses address spaces 0 and 1 to select between its RAM and ROM spaces. > And X86 uses address space 256 for GS and 257 for FS. In the back end > for a dual-harvard DSP that I've been

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specifi...

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: --- 1) Syntax extension: In our existing compiler for 8-bit microcontrollers, we have introduced rom and ram qualifiers (with ram