Frank Heckenbach wrote:
However, in GPC that's not exactly the same as `Integer (16)'. A subrange would still be a type of the same size as `Integer' (usually 32 bits) which is generally preferable for performance reasons, while strict BP compatibility sometimes requires a 16 bit type because some BP code relies on record layout etc.
While there is nothing wrong with that practice, I was always under the impression that the system was allowed to reduce the storage requirements for a subrange to whatever was needed. Without range checking the result is extremely dangerous, of course.
Sure it's allowed to. But GPC choses not to do so for normal subranges. I think in most cases that's preferable since often subranges are not declared to reduce storage (at the cost of performance), but to declare proper array indices etc.
It is very debatable: AFAIKS gpc have no way to reduce storage requirements of standard-compliant code except if packing is used. Since packing involves breaking alignment rules it usually have big impact on performance. Reducing storage for subranges usually have very moderate impact on runtime and in realictic programs reduced memory usage may fully compensate for extensions and truncation (many benchmarks run in very small memory so they prefer bigger size). Promoting subranges to full size when handling expressions and temporaries (hard to do to full potential in current gpc) may give optimal performance, and I think such promotion should be done even if a subrange is packed
J. David Bryan wrote:
Is there a semantic difference between:
type Int16 = Integer (16);
and:
type Int16 = packed -32768..32767;
That is, can the packed subrange form replace the specified-size form in all cases?
In normal Pascal there should be no overflow, so compiler my better optimize the code ommiting truncation of intermediate expressions - IMHO the compiler is not doing it now, but I think it shoud have the right to optimize.
Frank Heckenbach wrote:
This could be changeg, e.g., to:
TypeOfSize (Integer, n)
I think better syntax would be:
type foo = Integer attribute(Size(n),...);
differences are: 1) attribute suggest much more general use (I think it could work for general extensions) 2) IMHO at the end of type it need to be only contextually reserved so someting like:
type attribute = Integer attribute(Size(5)); foo = attribute attribute(Volatile);
would work.