HOST_WIDE_INT

[Joseph S. Myers]

On Fri, 13 Jun 2003, Roberto Belloni wrote:

> Q: Why is HOST_WIDE_INT a 64 bit type?

Certain target types, including char, size_t and wchar_t, need to fit
inside a HOST_WIDE_INT for the compiler to work; if they couldn't fit
inside an simple integer type on the host, that would mean excessive
complexity in the compiler to manipulate them and excessive performance
cost for the common case where they can fit in HOST_WIDE_INT.  Thus
HOST_WIDE_INT is 64 bits when targetting a 64-bit system.

You have come across the problem that the support for targets with bytes
wider than 8 bits is quite flaky.  You can expect to need to do quite a
bit of work on the compiler to fix problems with this, as the few such
existing targets with this property (e.g. c4x) are rarely tested, and
especially as the existing ones do not have bytes wider than 32 bits.  
This includes cleaning up the specification of various internal interfaces
and datastructures which have never been clearly specified as to how they
store target bytes if wider than host bytes, if you want a fully working
port.

You can submit clean changes to accommodate such issues in core code
separately from your port.  Hopefully someone can send you the copyright
assignment forms, which will need to be got in first.

Here is an old list of some of the issues, composed from past messages of
mine on the subject:

* What is the format of STRING_CSTs representing narrow strings on systems
where target bytes are wider than host bytes?  The target bytes may be a
multiple of host bytes (e.g. C4X), or may not be (e.g. PDP10).  They must
represent all values of that type.  Several existing places in the
compiler, that presume them to be the same, must be adapted.  This
includes defining the interface of some target macros in terms of whether
they take a count of host bytes or of target bytes.

A past proposal of mine:

  So we still need to work out how GCC should store 32-bit target chars
  internally as part of target string constants (and then make GCC use 
  this representation consistently).  As no-one has said what this 
  representation should be, I'll suggest: each target byte (hardware byte 
  of BITS_PER_UNIT bits, if CHAR_TYPE_SIZE is bigger - though no-one has 
  said whether CHAR_TYPE_SIZE > BITS_PER_UNIT really works) is stored 
  big-endian in the minimal number of host bytes ((BITS_PER_UNIT + 
  CHAR_BIT - 1) / CHAR_BIT), with the first host byte padded with 0s if 
  necessary to fill an integer number of host bytes.

  Next question: should TREE_STRING_LENGTH store the number of host bytes,
  or the number of target bytes?  It is used in the compiler with both
  meanings at present.  I think target bytes are probably more 
  appropriate.

  What should the length parameter to ASM_OUTPUT_ASCII be?  I'd guess 
  target bytes as well.

* What is the format of wide STRING_CSTs in such cases?

  (I guess a sequence of target bytes encoded as described.)

* How wide a target byte need we support?  Can it be wider than 
HOST_WIDE_INT?  Can it be wider than HOST_WIDEST_INT?

* Likewise, for target wchar_t?  In both cases, GCC should fail to build 
if the types are too wide.

  (I believe we must declare that both types must fit in HOST_WIDE_INT.)

* As above, where the target hardware byte is smaller than the target C 
char (BITS_PER_UNIT smaller than CHAR_TYPE_SIZE).  There are no such 
systems currently in tree.  If we don't really support them, we should say 
so.

* Then, there should be common functions used throughout the tree for
accessing individual elements of both narrow and wide strings.

-- 
Joseph S. Myers
jsm28@cam.ac.uk