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,
--
PMatos
