More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Chill doesn't generate ARRAY_REF for bit arrays/string.  Instead, it
>     generates PACKED_ARRAY_REF, which is defined in ch/ch-tree.def.
> 
> Hmm... I don't much like the idea of making a type in the
> language-independent code which only language-specific code can
> handle.  My feeling is that if the only things which can process a
> type are language-specific, then the type should be as well.

I agree and disagree.  The PACKED_ARRAY_REF should be subsumed by the
language-independent ARARY_REF, and the language-independent code
should handle packed arrays properly.  However, we didn't have the
time or expertise to do it properly, plus give that the Chill front-end
at that time was not part of the public sources we wanted to minimize
changes to the public sources.  (That is not the best approach, I agree.)
But even so, since the concept of a "packed array" is not language
specific, there is no point in *removing* that concept from the
language-independent code, even if the support is incomplete.
> 
> Also, why is a function call used in ch/expr.c?  Isn't it easy enough
> to open-code the one-bit case?

It gets a bit hairy when you have a dynamic bit index in a dynamically-sized
bit array, and also want to check for out-of-range.  Still, I agree the
best solution is to open-code the indexing.

> I don't follow here.  Please define "empty range" and give me an example.

An empty range is (for example) a string or array of length zero.
We had to go through various contortions dealing with (say) a
TYPE_MAX_VALUE of -1.  It's been a while since I worked on this,
so I'm rather rusty on the issues.  One problem I seem to remember 
is that we wanted:
  TREE_TYPE (TYPE_MIN_VALUE (T)) == T
  TREE_TYPE (TYPE_MAX_VALUE (T)) == T
This provided the necessary semantics, at least for Chill.
However, it doesn't really work for empty ranges, especially
when ranges can be dynamic.

Anyway, it's been so long I thought about this, I'm no longer
sure about it, and I doubt that I can convince anyone there is a
real problem *and* that it is worth fixing (especially when I'm
not even sure myself), so I'm going try to drop the issue.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/