On Mon, Jul 30, 2012 at 5:29 PM, Paulo J. Matos <pa...@matos-sorge.com> wrote: > On 26/07/12 15:04, Joseph S. Myers wrote: >> >> On Thu, 26 Jul 2012, Paulo J. Matos wrote: >> >>> My target has 16bit chars. >> >> >> As I explained before, support for such targets is extremely limited and >> bitrotten (this applies whether it is BITS_PER_UNIT, CHAR_TYPE_SIZE or >> both that are not 8) and a large amount of work, and global GCC expertise >> and vision for what internal interfaces should look like in the context of >> such bytes, will be required to remove assumptions about target bytes >> being 8 bits before such a port can work. It would not surprise me if a >> series of more (possibly much more) than 100 large patches to the >> target-independent compiler is needed to make such targets work properly. >> >> http://gcc.gnu.org/ml/gcc/2010-03/msg00445.html >> > > I understand we had this discussion before and much of my work in my current > company is to get GCC to support this exotic architecture. > > It is sometimes frustrating that GCC appears to be flexible enough to > support many different architectures (by allowing you to set CHAR_TYPE_SIZE > and BITS_PER_UNIT for example) but then making assumptions about these same > values throughout the code. > > >> It's not particular useful to raise questions about "why" something is >> broken in such a case, as it's simply generally not been a design >> consideration at all; rather, propose a clear definition of a relevant >> interface that is meaningful for such a case, with a complete patch making >> all the code follow that definition. And repeat 100 (possibly many more) >> times until all interfaces are properly defined for general target byte >> sizes. And keep a careful watch on all patches going through gcc-patches >> for anything hardcoding new assumptions about target byte size. >> > > Realistically I understand that since it seems I am the only one facing > these problems there's no reason not to make these assumption but why, then > not just assume these assumptions publicly and force BITS_PER_UNIT == 8 and > CHAR_TYPE_SIZE <= HOST_BITS_PER_CHAR for example for GCC? > > Also, as much as I would like to help in an effort to remove these > constraints, again I am the only one interested and the company I work for > prefers if I spend my time developing optimisations that improve code > density for client software than removing constraints from GCC just so we > can memset with a fill variable > 255. > > Thanks once again for your comments on this,
The issue is really that all this bitrots quickly if we do not have an in-tree port that is regularly tested and has an active maintainer that reports issues as they pop up. So yes, it would work for me to force BITS_PER_UNIT to 8 ;) Richard. > -- > PMatos >
