Prevalence of Compilers for Which Integer'Size < 32?

Prevalence of Compilers for Which Integer'Size < 32?

[Dave Marshall]

So here I am, looking at some old code while I wonder what I was
thinking when I wrote it.  Suddenly, I see something that will raise
Constraint_Error if a compiler's Integer'Size is less than 32.

So, how prevalent are such compilers?  Is it really something that one
ought to consider when implementing components that are candidates for
reuse?

I did try to find such information in the usual places; if it's there,
I don't know exactly where.

So now:

a) I don't know where to look.

b) I am neither industrious nor concerned enough to look any further.

c) Maybe someone will look for me.
-- 
Dave Marshall
dmarshal@netcom.com

Re: Prevalence of Compilers for Which Integer'Size < 32?

[steved]

Dave Marshall writes:
>So here I am, looking at some old code while I wonder what I was
>thinking when I wrote it.  Suddenly, I see something that will raise
>Constraint_Error if a compiler's Integer'Size is less than 32.
>
Sorry for not answering your question but...

In my experience I have found that if portablilty is a concern, then all
predefined types should be avoided.

Ada is one of the languages that lends itself the best to defining your own
types in a portable manner:

  type
    anInt32 is range -21474_83648 .. 21474_83647;

If you want to use a "vanilla" integer.

In many cases it is better to define a range that better describes your problem.

BTW: I've used the same type of definitions in 'C' ie:

typedef integer int32;

Steve Doiel

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Dave Marshall]

steved@pacifier.com@199.2.117.163  (Steve Doiel) writes:

>Dave Marshall writes:
>>So here I am, looking at some old code while I wonder what I was
>>thinking when I wrote it.  Suddenly, I see something that will raise
>>Constraint_Error if a compiler's Integer'Size is less than 32.
>>
>Sorry for not answering your question but...

>In my experience I have found that if portablilty is a concern, then all
>predefined types should be avoided.

It's impossible to disagree with this.  Indeed, I believe that
explicitly declaring one's types rather than using predefined types
adds to code's maintainability to an even greater degree.

However, the thrust of my question was more towards the available
values for integer types rather than any specific typing schemes.  I
apologize for not having been so unspecific.

My specific question revolves around something such as this example
that you'll find in a lot of time-handling packages.

type Seconds_In_A_Day is range 0 .. 86_400;

This is going to work fine for compilers for which Integer'Size is 32,
but it will fail for compilers for which Integer'Size = 16.  Of
course, this is because the above statement is equivalent to

type some_anonymous_integer_type is new Integer;
subtype Seconds_In_A_Day is some_anonymous_integer_type range 0 ..86400;

If Integer'Last is 65535, ka-bloowie.

Rather than make another entry in the predefined-types versus
user-defined-types battles, I thought I'd just get right to the matter
and try to get the information I was after.
-- 
Dave Marshall
dmarshal@netcom.com

Re: Prevalence of Compilers for Which Integer'Size < 32?

[steved]

Dave Marshall writes:
>My specific question revolves around something such as this example
>that you'll find in a lot of time-handling packages.
>
>type Seconds_In_A_Day is range 0 .. 86_400;
>
>This is going to work fine for compilers for which Integer'Size is 32,
>but it will fail for compilers for which Integer'Size = 16.  Of
>course, this is because the above statement is equivalent to
>
>type some_anonymous_integer_type is new Integer;
>subtype Seconds_In_A_Day is some_anonymous_integer_type range 0 ..86400;
>
>If Integer'Last is 65535, ka-bloowie.

I certainly do not expect this behaviour.  I expect the compiler to choose a
suitably sized integer representation (perhaps a long integer) to represent the
range given.  If no such representation exists then I expect some sort of a
"not supported by this implemetation" error.

Steve Doiel

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert A Duff]

In article <dmarshalDv8t9y.Bq8@netcom.com>,
Dave Marshall <dmarshal@netcom.com> wrote:
>type Seconds_In_A_Day is range 0 .. 86_400;
>
>This is going to work fine for compilers for which Integer'Size is 32,
>but it will fail for compilers for which Integer'Size = 16.  

No, that's not quite right.  The largest integer range supported has
nothing to do with the range of Integer.  A compiler could have:

    type Integer is range -2**15..2**15-1;

and still support:

    type Seconds_In_A_Day is range 0 .. 60*60*24;

(Why does everybody in this thread like literals so much?)

or:

    type Huge_Positive is range 1..10**100; -- unlikely, I admit

So the *real* question you want to ask is, "Do all compilers support at
least 32-bit integers?"  Well, I don't know for sure, but I certainly
assume that in the code I write.  I simply wouldn't buy a compiler that
didn't (even for a 16-bit machine).

I believe that all versions of GNAT support 64-bit integers.

- Bob

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert Dewar]

iBob asks:

    type Seconds_In_A_Day is range 0 .. 60*60*24;

(Why does everybody in this thread like literals so much?)

because it is much easier to see that 86_400 is bigger than 32767 than
it is to see that 60*60*24 is bigger than 2**15-1 :-)


P.S. Bob is right, all versions of GNAT support 64 bit integers, this is
true even if the architecture has limited support for such integers
(appropriate software routines are used if necessary).

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert A Duff]

In article <dewar.838610210@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>because it is much easier to see that 86_400 is bigger than 32767 than
>it is to see that 60*60*24 is bigger than 2**15-1 :-)

Good point.  But in another post in this thread, it would have been
pretty easy to see that 2**31-1 is bigger than 2**15-1.

I refuse to memorize the decimal value of 2**31 -- it's a waste a of
brain cells.  I just know that it's a little over 2 billion (for the
U.S. meaning of "billion"), and that's enough.

I've seen a lot of Ada code that uses giant literals, when a static
expression like 2**31-1 or whatever would have been more readable.  E.g.
I've seen:

    X: constant := 2_147_883_648; -- 2**31

Never use a comment when you can say it in the language proper.

I've also seen things like:

    X: Integer := 100000000; -- ten million

where the programmer apparently didn't realize that underscores are
allowed, and make things more readable.  And I've even seen bugs (as in
the above) because the number of zeros was miscounted.

- Bob

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert Dewar]

Dave Marshall says

"My specific question revolves around something such as this example
that you'll find in a lot of time-handling packages.

type Seconds_In_A_Day is range 0 .. 86_400;

This is going to work fine for compilers for which Integer'Size is 32,
but it will fail for compilers for which Integer'Size = 16.  Of
course, this is because the above statement is equivalent to

type some_anonymous_integer_type is new Integer;
subtype Seconds_In_A_Day is some_anonymous_integer_type range 0 ..86400;"


This is technically incorrect. There is no requirement that in the above
Seconds_In_A_Day be derived from Integer, it can be derived from any
available predefined type in Standard. Yes, in theory you can imagine
a compiler that would not accept this, but in practice absolutely
every compiler wlil accept the above declaration. The 16-bit PC
compilers where integer is 16 bits (from both RR and ALsys) both
provided a 32-bit long_integer suitable for the above derivation.
I believe the most restrictive compiler available is the Intermetrics
Patriot-2 compiler, where the largest integer size is 24 bits, but (a)
I might be wrong on this, (b) I doubt you are using this compiler :-)
and (c) anyway 86_400 fits in 24 bits.

As to never using type Integer, you often see this advice, but like
most absolute rules, if you follow this rule absolutely, you will be
in trouble. It would mean that you could not use the built in type
String, and consequently could not use any library packages depending
on string (including unbounded_strings, bounded_strings, all the I/O etc).

In addition, you could not use the exponentiation operation on real
values.

So in practice the rule is not to use Integer where it is easily avoided,
but use it where necessary for predefined stuff.

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert A Duff]

In article <4tdp24$5h1@news.pacifier.com>,
Steve Doiel <steved@pacifier.com> wrote:
>  type
>    anInt32 is range -21474_83648 .. 21474_83647;

What's wrong with:

    type anInt32 is range -2**31 .. 2**31-1;

?

Also, a useful technique is:

    type Dummy is range -1_000_000_000 .. 1_000_000_000;
    subtype My_Int is Dummy'Base;

or

    subtype My_Int is Dummy'Base range Dummy'Base'First..Dummy'Base'Last;

which will give you a reasonably efficient range that is at least minus
a billion to a billion.

- Bob

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Ken Garlington]

Robert A Duff wrote:
> 
> What's wrong with:
> 
>     type anInt32 is range -2**31 .. 2**31-1;

Because it's not:

      Bits_32 : constant := 32;
      type anInt32 is range -(2**(Bits_32-1)) .. 2**(Bits_32-1)-1;

Note the gratuitous parentheses in the first expression, to help those
who think "-2" is a literal and not an expression.

(Sorry, couldn't resist :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert Dewar]

Ken Garlington said (in partial jest, I realize)

Because it's not:

      Bits_32 : constant := 32;
      type anInt32 is range -(2**(Bits_32-1)) .. 2**(Bits_32-1)-1;


But in fact Bits_32 is a horrible name. I like named constants, but I
don't like junk names. The above would be reasonable if the name
Bits_32 were something like Word_Length_In_Bits.

Re: Prevalence of Compilers for Which Integer'Size < 32?

[steved]

Robert Dewar writes:
>Ken Garlington said (in partial jest, I realize)
>
>Because it's not:
>
>      Bits_32 : constant := 32;
>      type anInt32 is range -(2**(Bits_32-1)) .. 2**(Bits_32-1)-1;
>
>
>But in fact Bits_32 is a horrible name. I like named constants, but I
>don't like junk names. The above would be reasonable if the name
>Bits_32 were something like Word_Length_In_Bits.
>
Ya know, I find this discussion interesting.  At the Tri-Ada 95' opening
address a representative from Silicon Graphics (sorry I don't recall his name)
talked briefly about cognitive recognition.  He used the example of the
filesystem that was displayed briefly on Jurrasic Park, where the type and
size of files was shown with 3D images.  He explained that humans can
visually recognize thins very quickly based on visual queues.

I am sure this isn't news to many, and you may be wondering what it has to
do with this discussion but...

How code looks to you is directly dependent on what you are accustomed to.

For me the following:

   Bits_32 : constant := 32;
   type anInt32 is range -(2**(Bits_32-1)) .. 2**(Bits_32-1)-1;

Is actually less readable than:

   type anInt32 is range -(2**31) .. 2**31-1;

The extra identifier and definitions add clutter without gaining in readability.
In my own code I actually might use:

  TYPE
    anInt32 IS RANGE -(16#FFFF_FFFF#)..16#7FFF_FFFF#;

Since when I am defining a 32 bit integer, I probably plan to use it for
for something that is machine related, at which time I tend to thing in terms
of bytes and words in hex.

Also on the topic of recognition.  I find that consistant use of case and naming
adds to the speed of recognition.  I happen to like my keywords in upper case.
All of my type defintions start with "a" or "an" in lower case and are followed
by mixed case.  All procedure and function names begin with upper case
followed by mixed case.

I know that when I look at code that is formatted in the way that I am used to
I can get my bearings very quickly.  And when I find scattered bits that are
formatted differently, things become very hard to read.

Definitely more than you wanted to hear...

Steve Doiel

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Robert Dewar]

Ken said

"Considering I had to start with "anInt32", I didn't really worry about
the clarity of the named number name! Of course, Word_Length_In_Bits is
also horrible if (a) you're declaring multiple types with
different widths in the same package and/or (b) the software might
be used somewhere where the machine word wasn't 32 bits."


You missed my point, case (b) is *exactly* the case where the name
Word_Length_In_Bits might be appropriate if that is what you really
want. Of course if you use the software somewhere where the machine
word is not 32-bits, then you would have to modify this declaration.

Ada code can be made to be automatically portable most of the time, but
not necessarily all the time, since the predefined set of attributes is
not necessarily powerful enough to parametrize everything you want.
In this particular case, if you really wanted the machine word size
to govern the length of the type, you could probably use
System.Word_Size (or in GNAT Standard'Word_Size) and completely avoid
the dreaded 32, in the declaration as *well* as in the name.

Re: Prevalence of Compilers for Which Integer'Size < 32?

[Ken Garlington]

Robert Dewar wrote:
> 
> You missed my point, case (b) is *exactly* the case where the name
> Word_Length_In_Bits might be appropriate if that is what you really
> want. Of course if you use the software somewhere where the machine
> word is not 32-bits, then you would have to modify this declaration.

Perhaps I misunderstood. I thought the intent was to declare an integer
value that would always fit in 32 bits, regardless of machine word
size. If that's the case, wouldn't Word_Length_In_Bits always be 32,
for all machines, for the code I gave earlier? And, if that's the case, wouldn't 
a maintainer seeing this on a 16-bit machine say, "Wait a minute, word length 
isn't 32 on my machine, better change this to 16..." - and end up with anInt32 
being a 16-bit value?

> Ada code can be made to be automatically portable most of the time, but
> not necessarily all the time, since the predefined set of attributes is
> not necessarily powerful enough to parametrize everything you want.
> In this particular case, if you really wanted the machine word size
> to govern the length of the type, you could probably use
> System.Word_Size (or in GNAT Standard'Word_Size) and completely avoid
> the dreaded 32, in the declaration as *well* as in the name.

I think this is true if anInt32 was supposed to be anIntWord. If that was the
intent, I misunderstood. I thought the original thread was: How do I make
an integer that will always be 32 bits, even on a 16 bit machine? and the
answer was:

  Optimal_Name : constant := 32;
  type anInt32 is range -(2**(Optimal_Name-1)) .. 2**(Optimal_Name-1)-1;

or something to that effect?

-- 
LMTAS - "Our Brand Means Quality"

Re: Prevalence of Compilers for Which Integer'Size < 32?

[tmoran]

> Suddenly, I see something that will raise
> Constraint_Error if a compiler's Integer'Size is less than 32.
> So, how prevalent are such compilers?  Is it really something that one
> ought to consider when implementing components that are candidates for
> reuse?
   Is there any reason you must use Integer rather than a type ... is
range ... that fits the problem?
  The RR compiler I still use for bare 16 bit DOS targets has, not
surprisingly, a 16 bit Integer.  Don't know about other compilers
with that target.  (Are there any?)

Re: Prevalence of Compilers for Which Integer'Size < 32?

[John Herro]

tmoran@bix.com writes:
> The RR compiler I still use for bare 16 bit
> DOS targets has, not surprisingly, a 16 bit
> Integer.  Don't know about other compilers
> with that target.  (Are there any?)
     Surely.  Meridian Ada 83 for DOS and Open Ada 83 for DOS (which is a
newer version of the same compiler) both have a 16-bit Integer, with
Long_Integer available.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor