On Fri, Aug 31, 2012 at 1:22 AM, Christof Petig <christof.pe...@arcor.de> wrote: > Hi Shalabh, > > Am Donnerstag, den 30.08.2012, 16:32 -0400 schrieb Shalabh Jain: >> > Use '-mmemory-model=large' instead of the underlying flags and your >> > code should work. (In fact, use -mmemory-model=medium unless you need >> > code in far memory: due to limitations in gcc that I've mentioned >> > before certain optimizations get disabled when sizeof(void*) != >> > sizeof((*)(void)), which only holds when -md20 != -ma20.) >> > >> > The memory model large does the correct placement and code generation. >> However, since it implicitly converts all the instructions to 20 bit >> variant, which causes significant overhead. I did some experiments and I >> see almost 15% increase in code size and 50% increase in runtime. This is >> quite critical for our application. > > The solution we determined to work around the "no usable far data > pointers outside large memory model" problem is: > > - use medium model throughout the program (no effect on code size, small > overhead due to higher stack usage for function calls) > - put as much code as possible into the high memory > - place read only data in the low memory region (easy access) > - use inline assembly as a fall back to access any data which does not > fit into the low memory > > Perhaps translating only the function which accesses the LUT with memory > model large can help you to avoid assembly at all. Because as far as I > can tell large and medium memory model are ABI compatible (if you avoid > passing a far pointer by using uint32 or uint20 instead).
Yes, I think that would work. You get a warning at link time when combining object files that were built with different CPUX target options, but it's just a warning. Avoid using uint32_t for 20-bit pointers as much as possible. uint20_t will be passed (and returned) in a single register, and translating between the 32-bit and 20-bit representations is extremely expensive. If all far pointers are typed as uint20_t instances while in code that does not recognize far pointers, there should be no issues. Peter > Christof > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
