From: Borja F. <bor...@gm...> - 2010-11-04 14:52:12
|
Heh i knew this part was going to bring in some debate. Kevin thanks for the link to the C spec pdf file, i think we should try this approach now that we have the opportunity of doing things from scratch to improve what GCC offers. The PROGMEM attribute is a good workaround, but supporting this natively would bring around more benefits like pushing optimizations further avoiding many function calls and having some alias ptr analysis. As far as i know LLVM has address space identifiers in its IR so in theory it's possible to do it, however i havent looked yet how to implement this in the backend. Another thing, i havent checked if clang supports named address spaces, i know gcc does, but at the end we should end up using only clang as the frontend? Can somebody clarify me if GCC has support for 24 bit ptrs for largest devices and 8 bit ptrs for the smallests? i'm only used to 16 bit ptrs so i dont what gcc does outside this case. Implementing 24bit ptrs should be possible, same for 8bit. Deciding what ptr to use is not trivial, i took a fast read to gcc's code and i think there was a function that decided which reg pair had to be used, i could be wrong though. I did some tests and for example the Y ptr is favored against X if there's no frame ptr in the function, so this has to be taken into account. I need to look how ARM does this, they have 5 or 6 different addressing modes in their .td file. These decisions have to be taken after knowing what type of operations are done in the ptr itself, so for example if we have one ptr access that doesnt need doing ptr+<offs> X can be used otherwise use Z or Y, but as i said this needs doing a previous analysis, imagine functions with lots of traffic between arrays, there has to be some logic behind. |