<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I don't think that's what the original poster needed (32-bit offset in<br>
a 64bit segment).<br></blockquote><div><br></div><div>let me make a correction. Indeed it is about a 32 bit (or less) offset inside a 32 bit (or less) addressable segment. Address would be always calculated as 64 bit pointer + 32 bit offset. </div><div><br></div><div>Indeed, as I stated in my prev, email __ptr32 would not make too much sense...<br></div><div><br></div><div>I further worked on this concept and almost came to the conclusion that implementation of special class of pointers would become too complicated (both clang and llvm). Would be though interesting to "teach" the compiler to allow arithmetics like</div><div><br></div><div>shortptr = longptr; //(where shortptro = longptr-base)</div><div>//or</div><div>longptr = shortptr; //where longptr = shortpr + base), where base would be a task (thread) specific value</div><div><br></div><div>The framework or the "extension" should make sure that such values are allocated in the correct adress space. </div><div><br></div><div>I will probably go for an "eco pointer template" solution</div><div><br></div><div><div>template<class T></div><div>class ecoPtr {</div><div> private:</div><div> static void * operator new(std::size_t); //forbid allocation on heap</div><div> static void * operator new[](std::size_t);</div><div> private:</div><div> uint32_t ptr; //this is the real pointer compressed to 32 bit</div><div> public:</div><div> template<typename... Args><br></div><div> inline eco(Args... args) __attribute__((always_inline)) { /* custom allocate T and return the offset */ }</div><div> T* operator->() {}</div><div>};</div></div><div><br></div><div>This would also implement later a ref counting, but ref count would be held inside T</div></div></div></div>