64-bit integers in Ada

64-bit integers in Ada

[David Rasmussen]

I understand that I can easily use an integer in Ada that has exactly 64 
bits. But are there any guarantees that such a type would be mapped to 
native integers on 64-bit machines or to a reasonable double 32-bit 
implementation on 32-bit machines? At least, are compilers ok at this in 
real life?

/David

Re: 64-bit integers in Ada

[Robert Dewar]

David Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote in message news:<3CE3978F.6070704@gmx.spam.egg.sausage.and.spam.net>...
> I understand that I can easily use an integer in Ada that has exactly 64 
> bits. But are there any guarantees that such a type would be mapped to 
> native integers on 64-bit machines or to a reasonable double 32-bit 
> implementation on 32-bit machines? At least, are compilers ok at this in 
> real life?
> 
> /David

You have to check the particular compiler. GNAT supports 64-bit arithmetic
on all targets, using whatever is appropriate efficient code to do so.

Re: 64-bit integers in Ada

[Mark Johnson]

David Rasmussen wrote:
> 
> I understand that I can easily use an integer in Ada that has exactly 64
> bits. But are there any guarantees that such a type would be mapped to
> native integers on 64-bit machines or to a reasonable double 32-bit
> implementation on 32-bit machines?
No. However...
> At least, are compilers ok at this in
> real life?
> 
Yes. Robert mentions GNAT, but you will have to review the technical
information for your compiler [or test it] to be sure. Generally, if the
compiler doesn't reject the construct, it will implement it correctly.
  --Mark

Re: 64-bit integers in Ada

[Victor Giddings]

David Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote 
in news:3CE3978F.6070704@gmx.spam.egg.sausage.and.spam.net:

> I understand that I can easily use an integer in Ada that has exactly 64 
> bits. But are there any guarantees that such a type would be mapped to 
> native integers on 64-bit machines or to a reasonable double 32-bit 
> implementation on 32-bit machines? At least, are compilers ok at this in 
> real life?
> 
> /David
> 

Try using (or deriving from) Interfaces.Integer_64 or Integer.Unsigned_64. 
Admittedly, this requires 2 steps on the part of the compiler developer. 1) 
actually support the 64-bit integer type. 2) to put it in Interfaces (as 
required by B.2(7)). However, we rely on this in our CORBA product 
implementation and have been making sure that the compiler vendors are 
adding these types when they are supported. 

As of now, I know of only one compiler that supports 64-bit integers and 
doesn't define Interface.Integer_64. That is to be remedied very soon.

-- 
Victor Giddings		mailto:victor.giddings@ois.com
Senior Product Engineer	+1 703 295 6500
Objective Interface Systems	Fax: +1 703 295 6501

Re: 64-bit integers in Ada

[Robert A Duff]

Victor Giddings <victor.giddings@ois.com> writes:

> David Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote 
> in news:3CE3978F.6070704@gmx.spam.egg.sausage.and.spam.net:
> 
> > I understand that I can easily use an integer in Ada that has exactly 64 
> > bits. But are there any guarantees that such a type would be mapped to 
> > native integers on 64-bit machines or to a reasonable double 32-bit 
> > implementation on 32-bit machines?

In the language standard, there is no "guarantee" of anything related to
efficiency.  I think that's true of pretty much all languages, and I
don't see how one could do better.

>... At least, are compilers ok at this in 
> > real life?

Yes.  Compiler writers don't deliberately go out of their way to harm
efficiency.

Note that the RM does not require support for 64-bit integers
(unfortunately, IMHO), and there are compilers that do not support
64-bit integers.  But if the compiler *does* support 64-bit integers,
I see no reason to suspect that it wouldn't do so in the obviously
efficient way (native 64-bit ints on a 64-bit machine, or a pair of
32-bit ints on a 32-bit machine).

> > /David
> 
> Try using (or deriving from) Interfaces.Integer_64 or Integer.Unsigned_64. 
> Admittedly, this requires 2 steps on the part of the compiler developer. 1) 
> actually support the 64-bit integer type. 2) to put it in Interfaces (as 
> required by B.2(7)). However, we rely on this in our CORBA product 
> implementation and have been making sure that the compiler vendors are 
> adding these types when they are supported. 

I don't see the point of this advice.  If you say "type T is range
-2**63..2**63-1;", I don't see any reason why T would be more or less
efficient than Interfaces.Integer_64.  In fact, I would think they would
have identical representation, and arithmetic ops would use identical
machine code.

> As of now, I know of only one compiler that supports 64-bit integers and 
> doesn't define Interface.Integer_64. That is to be remedied very soon.

- Bob

Re: 64-bit integers in Ada

[Richard Riehle]

Robert A Duff wrote:

> Note that the RM does not require support for 64-bit integers
> (unfortunately, IMHO), and there are compilers that do not support
> 64-bit integers.

Robert,

We still have quite a few embedded platforms for which 64 bit
integers are not supported.   We would like to be able to use
Ada 95 for them, so a requirement for a language feature that
is not supported would be meaningless.   Also, there has been
some discussion, in the past, about support for eight-bit
microcontrollers such as the I-8051 family.   I am sure some
compiler developer would find it very entertaining to design
an Ada compiler with 8051 64 bit integers, but also  quite
useless.

Richard Riehle

Re: 64-bit integers in Ada

[Robert A Duff]

Richard Riehle <richard@adaworks.com> writes:

> Robert A Duff wrote:
> 
> > Note that the RM does not require support for 64-bit integers
> > (unfortunately, IMHO), and there are compilers that do not support
> > 64-bit integers.
> 
> Robert,
> 
> We still have quite a few embedded platforms for which 64 bit
> integers are not supported.   We would like to be able to use
> Ada 95 for them, so a requirement for a language feature that
> is not supported would be meaningless.

All processors can easily support 64-bit arithmetic, or 640-bit
arithmetic.  It's not meaningless -- it just means that the
implementation has to provide software support.

I think I know how to design such a feature in accordance with the
"Bauer Principle", which Robert Dewar recently told us the name of.  So
if you have an 8-bit processor, maybe you don't want 64-bit integers, or
maybe you don't want 32- or even 16-bit integers, but I still think the
compiler should be required to provide them.  And more.

>...   Also, there has been
> some discussion, in the past, about support for eight-bit
> microcontrollers such as the I-8051 family.   I am sure some
> compiler developer would find it very entertaining to design
> an Ada compiler with 8051 64 bit integers, but also  quite
> useless.

Why?  What is the largest integer that a programmer might want, given
that the programmer has chosen an 8-bit processor?

Where do you draw the line?

To me 8-bit processor implies limited address space, but I don't see why
that *necessarily* implies small integers.

> Richard Riehle

- Bob

Re: 64-bit integers in Ada

[Robert Dewar]

Richard Riehle <richard@adaworks.com> wrote in message news:<3D46DC69.7C291297@adaworks.com>...
> Robert,
> 
> We still have quite a few embedded platforms for which 64 bit
> integers are not supported. 

There is no reason for hardware support here, even the ia32
does not have hardware support, but 64-bit integers are
very useful and must be supported, just as floating-point
MUST be supported even on processors with no floating-point.

>  We would like to be able to use
> Ada 95 for them, so a requirement for a language feature that
> is not supported would be meaningless.

gcc supports 64-bit integers on virtually all processors
including 8-bit microprocessors.

> Also, there has been
> some discussion, in the past, about support for eight-bit
> microcontrollers such as the I-8051 family.   I am sure 
> some compiler developer would find it very entertaining 
> to design an Ada compiler with 8051 64 bit integers,

Not so much entertaining, but rather quite straightforward.

> but also  quite useless.

Not at all! If your application requires 64-bit integers,
e.g. long durations measured in nanoseconds, then you have
to have this facility, and it is far better that it be
provided by the compiler, rather than having to cook up some half
baked software multiple precision support which
is likely to be FAR less efficient, and certainly far less
convenient.

Once again, in a language which requires all implementations to
provide floating-point, it seems a trivial additional effort to
provide 64-bit integer support.

Note that if anyone bothers to port GNAT to an 8-bit microprocessor
currently supported by GCC, then the 64-bit integer support will come
for free.

> Richard Riehle

Re: 64-bit integers in Ada

[Keith Thompson]

dewar@gnat.com (Robert Dewar) writes:
> Richard Riehle <richard@adaworks.com> wrote in message
> news:<3D46DC69.7C291297@adaworks.com>...
> > Robert,
> > 
> > We still have quite a few embedded platforms for which 64 bit
> > integers are not supported. 
> 
> There is no reason for hardware support here, even the ia32
> does not have hardware support, but 64-bit integers are
> very useful and must be supported, just as floating-point
> MUST be supported even on processors with no floating-point.

For certain values of "must".  I'm fairly sure that the Ada standard
does not require support for 64-bit integers, and I've worked with Ada
implementations that didn't support anything bigger than 32 bits
(System.Max_Int = 2**31-1).

If you want to argue that such an implementation is broken (even
though it's conforming), I won't disagree.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: 64-bit integers in Ada

[Larry Kilgallen]

In article <yeceldkpm34.fsf@king.cts.com>, Keith Thompson <kst@cts.com> writes:
> dewar@gnat.com (Robert Dewar) writes:
>> Richard Riehle <richard@adaworks.com> wrote in message
>> news:<3D46DC69.7C291297@adaworks.com>...
>> > Robert,
>> > 
>> > We still have quite a few embedded platforms for which 64 bit
>> > integers are not supported. 
>> 
>> There is no reason for hardware support here, even the ia32
>> does not have hardware support, but 64-bit integers are
>> very useful and must be supported, just as floating-point
>> MUST be supported even on processors with no floating-point.
> 
> For certain values of "must".  I'm fairly sure that the Ada standard
> does not require support for 64-bit integers, and I've worked with Ada
> implementations that didn't support anything bigger than 32 bits
> (System.Max_Int = 2**31-1).
> 
> If you want to argue that such an implementation is broken (even
> though it's conforming), I won't disagree.

Do you mean Ada has not defined its own counterintuitive meaning for
the term "broken" ?    :-)

Re: 64-bit integers in Ada

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> dewar@gnat.com (Robert Dewar) writes:
> > Richard Riehle <richard@adaworks.com> wrote in message
> > news:<3D46DC69.7C291297@adaworks.com>...
> > > Robert,
> > > 
> > > We still have quite a few embedded platforms for which 64 bit
> > > integers are not supported. 
> > 
> > There is no reason for hardware support here, even the ia32
> > does not have hardware support, but 64-bit integers are
> > very useful and must be supported, just as floating-point
> > MUST be supported even on processors with no floating-point.
> 
> For certain values of "must".  I'm fairly sure that the Ada standard
> does not require support for 64-bit integers, ...

Yes, and I'm pretty sure Robert is well aware of that.

Actually, Ada requires 16 bit integers (at minimum).
Robert has argued in the past that this is silly -- too small to be of
use, and better to let the market decide.  Probably true.

>... and I've worked with Ada
> implementations that didn't support anything bigger than 32 bits
> (System.Max_Int = 2**31-1).

I don't know of any Ada implementation that only supports 16 bits,
and only one that doesn't support at least 32 (it supports 24 bits).

> If you want to argue that such an implementation is broken (even
> though it's conforming), I won't disagree.

But why 64?  Why shouldn't we say 128?  Or 1000?

After all, Lisp implementations have been supporting more than that
for decades.

- Bob

Re: 64-bit integers in Ada

[Marin David Condic]

One advantage to insisting that the type Integer supports at least 16 bits
is that it gives the developer some minimal parameters on which to write
software that might rely on the standard type Integer. If you won't
guarantee that the type Integer has some minimal usefulness, then why bother
to have it at all? Most hardware will support 16 bits and even if it doesn't
you might find it difficult to write any useful programs if you can't count
up to at least 32767, so a software simulation is probably necessary.

Is there a case where, for example, it would make any sense at all for an
implementation to *not* give the user 16 bits? Would it ever make sense for
the type Integer to be 8 bits, for example? (Assuming that if I actually
want an 8-bit integer type I can still declare one of my own, that is...)
Would anyone ever really want to build an Ada implementation that had a
maximum integer of something less than 16 bits? If not, then the ARM
specifying support for at least 16 bits is a good thing in terms of giving
the developer a warm fuzzy feeling that he can depend on at least that much.

For what its worth, IIRC, the XD-Ada compiler for the Mil-Std-1750a had 16
bits for the standard type Integer. I don't remember if it allowed
declarations of integers larger than this, but my vague memory was that it
did not. Given the machine architecture and the intended usage, it would not
have been an unreasonable restriction.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc65ywhw3s.fsf@shell01.TheWorld.com...
>
> Actually, Ada requires 16 bit integers (at minimum).
> Robert has argued in the past that this is silly -- too small to be of
> use, and better to let the market decide.  Probably true.
>

Re: 64-bit integers in Ada

[Lutz Donnerhacke]

* Marin David Condic wrote:
>Is there a case where, for example, it would make any sense at all for an
>implementation to *not* give the user 16 bits? Would it ever make sense for
>the type Integer to be 8 bits, for example? (Assuming that if I actually
>want an 8-bit integer type I can still declare one of my own, that is...)

Integer ist expected to be the size of the maschine word. Now choose a 6502
or similar �P. If you need a certain range of countable numbers, define your
own type. But do not insist on types the maschine can not handle efficiently.
Ada requires native support for all native maschine types anyway.

Re: 64-bit integers in Ada

[Marin David Condic]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

Its been a while since I've seen a C compiler for a 6502, but my
recollection is that the last one I did look at had 16 bits for the type
int. Please correct me if I'm wrong here - have you seen C compilers for
this target using 8 bits for the type int? My thinking here is that even for
guys programming small computers, an int or Integer being required to
support at least 16 bits, is a useful constraint even if it has to be
simulated with software. Guys programming 6502's still need to frequently
count things well above +/-128 and int or Integer are the customary, handy
counter that you'd like to have some asurance will accommodate some useful
range.

That's why I wouldn't object to the standard requiring that an
implementation support at least 16 bits - even for small machines. People
expect it. Going the other direction (requiring support for 64 bits or 128
bits or unlimited bits) is a different situation in that this might become
an unreasonable burden on a compiler for a small target. (I'd certainly
consider it desirable that it be "permissable" - just not "required")

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnakhqa5.ok.lutz@taranis.iks-jena.de...
>
> Integer ist expected to be the size of the maschine word. Now choose a
6502
> or similar �P. If you need a certain range of countable numbers, define
your
> own type. But do not insist on types the maschine can not handle
efficiently.
> Ada requires native support for all native maschine types anyway.

Re: 64-bit integers in Ada

[Lutz Donnerhacke]

* Marin David Condic wrote:
>Its been a while since I've seen a C compiler for a 6502, but my
>recollection is that the last one I did look at had 16 bits for the type
>int. Please correct me if I'm wrong here - have you seen C compilers for
>this target using 8 bits for the type int?

The only C-Compiler for the C64 has a 16bit int, because it's required by
the language (at least now).

>My thinking here is that even for guys programming small computers, an int
>or Integer being required to support at least 16 bits, is a useful
>constraint even if it has to be simulated with software.

Ack for C, nack for Ada. Ada has the ability to specify the type ranges you
need. C hasn't.

>That's why I wouldn't object to the standard requiring that an
>implementation support at least 16 bits - even for small machines. People
>expect it.

No. Ada people expect to define there own types if they need certain ranges.
They expect efficient implementations for those types.

>Going the other direction (requiring support for 64 bits or 128
>bits or unlimited bits) is a different situation in that this might become
>an unreasonable burden on a compiler for a small target. (I'd certainly
>consider it desirable that it be "permissable" - just not "required")

It would be fine the have a minimum requirement for the user defined ranges.
"type uint64 is mod 2**64;" is still a portability problem.

Re: 64-bit integers in Ada

[Marin David Condic]

Maybe we're just talking at cross-purposes here. I certainly don't object to
support for user defined ranges/sizes that would be smaller than 16 bits.
The question at hand here had to do with the standard type Integer being
required to be at least 16 bits and therefore the standard mandating that an
implementation be able to support at least 16 bit integers in general.
Removing that requirement would mean that an implementation would be free to
say something like "The largest integer you can declare is 8 bits..." -
which seems like an unlikely thing to do, so having the requirement is not a
bad thing. Would most programmers find a language implementation useful if
you couldn't declare integers larger than (for example) 8 bits? Is an
implementation greatly inconvenienced by having the standard type Integer
required to be at least 16 bits? (Especially since they are free to create
Short_Integer and Long_Integer as 8 and 32 bits if they like. Seems like
they'd be free to create things that match most common hardware - even for
small machines.)

As for declaring one's own types, yes, I'm generally in favor of that. When
I care about specific sizes and ranges, I'll make my own types or subtypes.
Often, when all I care about is that I've got a variable big enough to
handle some chore, I'll use the standard Integer type. If you want to argue
that "All *competent* Ada programmers dutifully declare types to be sure
they are as big as they need." then that would imply the standard should
remove the types Integer, Float, Duration, etc. So long as these types
remain in the standard, I think it is a good thing that the standard
guarantees some minimal characteristics for the types so that a programmer
knows what he can count on.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnakkdbb.ou.lutz@taranis.iks-jena.de...
>
> Ack for C, nack for Ada. Ada has the ability to specify the type ranges
you
> need. C hasn't.
>
> >That's why I wouldn't object to the standard requiring that an
> >implementation support at least 16 bits - even for small machines. People
> >expect it.
>
> No. Ada people expect to define there own types if they need certain
ranges.
> They expect efficient implementations for those types.
>

Re: 64-bit integers in Ada

[Robert Dewar]

"Marin David Condic" 

> so having the requirement is not a
> bad thing. 

Here is why I think it *is* a bad requirement.

No implementation would possibly make Integer less than
16 bits. None ever has, and none ever would. Remember that
the only really critical role of integer is as an index
in the standard type String (it was a mistake to have string tied in
this way, but it's too late to fix this)

No one would make integer 8 bits and have strings limited
to 127 characters. 

If you are worried about implementors making deliberately
useless compilers, that's a silly worry, since there are
lots of ways of doing that (e.g. declaring that any
expression with more than one operator exceeds the capacity
of the compiler).

So why is the requirement harmful? Because it implies that
it is reasonable to limit integers to 16 bits, but in fact
any implementation on a modern architecture that chose 16 bits for
integer would be badly broken.

As for implementations for 8-bit micros, I would still make
Integer 32 bits on such a target. A choice of 16-bit integer (as for
example Alsys did on early on) would cause
giant problems in porting code. On the other hand, a choice
of 32-bit integers would make strings take a bit more room. I would
still choose 32-bits.

Anyway, I see no reason for the standard to essentially encourage
inappropriate choices for integer types by adding a requirement that
has no practical significance whatever.

This is an old old discussion. As is so often the case on
CLA, newcomers like to repeat old discussions :-)

This particular one can probably be tracked down from the
design discussions for Ada 9X.

Re: 64-bit integers in Ada

[Richard Riehle]

Robert Dewar wrote:

> As for implementations for 8-bit micros, I would still make
> Integer 32 bits on such a target.

I assume you are talking about Standard.Integer.   If so, this
would not correspond to the way software is so frequently
written for these machines.   In particular, for I-8051
platforms, it would introduce a potential inefficiency and
force the programmer to explicitly declare a shorter
integer (absent the availability of Standard.Short_Integer).

Since we often counsel designers to specify their own numeric
types anyway, this is probably not a hardship, but it could
be troublesome for an experienced I-8051 programmer who
expects 16 bit integers.   Consider, for example, that simply
pushing a 16 bit entity on the stack requires storing two
eight-bit stack entries.   To store a 32-bit integer would
take four stack entries.   The corresponding inefficiency
would be intolerable for most I-8051 applications.

One reason I like Ada is because we can define our own
numeric types.  Though there are few machines still extant
that use storage multiples of other than eight-bits,  they
do still exist.   I think the compiler for the Unisys 11xx
series has a word size of 36 bits.  Randy can correct me
on that if I am wrong.

> Anyway, I see no reason for the standard to essentially encourage
> inappropriate choices for integer types by adding a requirement that
> has no practical significance whatever.

I completely agree with you on this point.  The designer should make
the decision based on the architecture of the targeted platform and
the application requirements.  The language should be, as Ada is,
flexible enough to give the designer this level of support.

Don Reifer recently told me that one reason Ada was becoming
irrelevant, and his reason for recommending against its use for
new projects, was that it is not sufficiently flexible to support
the new kinds of architectures in the pipeline.   Though I disagree
with him on this assessment,  forcing the language to correspond
to a single word-size architecture (read 32 bits) would be
play into his flawed view of Ada's value for new software.

Richard Riehle

Re: 64-bit integers in Ada

[Chad R. Meiners]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3D4C2805.62563584@adaworks.com...
> with him on this assessment,  forcing the language to correspond
> to a single word-size architecture (read 32 bits) would be
> play into his flawed view of Ada's value for new software.

I don't think Dr. Dewar is arguing for forcing the language to correspond to
a single word-size architecture.

-CRM

Re: 64-bit integers in Ada

[Robert Dewar]

Richard Riehle <richard@adaworks.com> wrote in message news:<3D4C2805.62563584@adaworks.com>...
> I assume you are talking about Standard.Integer.   If so, > this
> would not correspond to the way software is so frequently
> written for these machines.   In particular, for I-8051
> platforms, it would introduce a potential inefficiency 
> and
> force the programmer to explicitly declare a shorter
> integer (absent the availability of
> Standard.Short_Integer).

First. I trust we all agree that new Ada code should
almost NEVER EVER use type Integer, except as the
index of the String type.

To talk of the programmer being "forced to declare a shorter integer"
is very peculiar, since this is nothing
more than good Ada style. If this approach helps persuade
incompetent programmers to adopt better style -- GOOD!

Second. In fact legacy code does tend to over use Integer.
So in practice when acquiring or porting legacy code, this
may be an issue, but this is *precisely* the case where
making Integer 32 bits can be appropriate, because most
of that badly written code that uses type Integer will
have assumed that integer is 32 bits.

However, the issue of unwanted overhead on the String
type is an issue (too bad these got intertwined in the
original design).
 
> Since we often counsel designers to specify their own
           ^^^^^
I trust this is a typo for *always*

> numeric types anyway, this is probably not a hardship, 
> but it could be troublesome for an experienced I-8051 
> programmer who expects 16 bit integers.

I don't understand, is this "experienced I-8051" programmer
an experienced Ada programmer. If so, he has no business
using Standard.Integer. If not, and he is writing Ada in
C style, then perhaps the choice of 32-bit integers will
help cure this bad practice.

> Consider, for example, that simply
> pushing a 16 bit entity on the stack requires storing two
> eight-bit stack entries.   To store a 32-bit integer
> would
> take four stack entries.   The corresponding inefficiency
> would be intolerable for most I-8051 applications.

Yes, but it is also intolerable for this experienced
I-8051 programmer to be using Standard.Integer explicitly.

 
> One reason I like Ada is because we can define our own
> numeric types.

Exactly, so what's the issue.

> Though there are few machines still 
> extant that use storage multiples of other than 
> eight-bits,  they
> do still exist.   I think the compiler for the Unisys 
> 11xx
> series has a word size of 36 bits.  Randy can correct me
> on that if I am wrong.

Yes, of course it's 36 bits (that was a port of Alsys
technology with which I am familiar).

 
> Don Reifer recently told me that one reason Ada was becoming
> irrelevant, and his reason for recommending against its use for
> new projects, was that it is not sufficiently flexible to support
> the new kinds of architectures in the pipeline.

This is complete and utter nonsense. Where on earth does
Reifer get these crazy ideas?

> Though I disagree
> with him on this assessment,  forcing the language to 
> correspond
> to a single word-size architecture (read 32 bits) would 
> be
> play into his flawed view of Ada's value for new 
> software.

I find this completely puzzling. Given that in Ada code
we always define the integer types we want, the standard
forces nothing.

Well we still have the tie in with Integer and String, 
and that is worthy of discussion, but this business of
claiming that Ada is flawed because incompetent programmers
misusing Standard.Integer might get an integer size they
do not expect is really not a sustainable argument.

Indeed a good argument can be made that the type Integer
should never have been introduced in the first place. It
is an unnecessary concession to C and Fortran programmers.

Re: 64-bit integers in Ada

[Richard Riehle]

Robert Dewar wrote:

> First. I trust we all agree that new Ada code should
> almost NEVER EVER use type Integer, except as the
> index of the String type.

Robert,

We are in full agreement on all of the points you made.

The only two uses of predefined type Integer are its
requirement in the predefined String, and for occasional
pedagogic purposes, and the latter use often leads to
more trouble than it is worth.

Richard Riehle

Re: 64-bit integers in Ada

[Simon Wright]

Richard Riehle <richard@adaworks.com> writes:

> Robert Dewar wrote:
> 
> > First. I trust we all agree that new Ada code should
> > almost NEVER EVER use type Integer, except as the
> > index of the String type.
> 
> Robert,
> 
> We are in full agreement on all of the points you made.
> 
> The only two uses of predefined type Integer are its
> requirement in the predefined String, and for occasional
> pedagogic purposes, and the latter use often leads to
> more trouble than it is worth.

Well, I think that when you are writing libraries you may find that
Integer, Natural and Positive have their uses. For example,

   package Tables is

      type Item_Array is array (Positive range <>) of Items.Item_Container;
      type Value_Array is array (Positive range <>) of Values.Value_Container;

      type Table (Number_Of_Buckets : Positive) is record
         Items : Item_Array (1 .. Number_Of_Buckets);
         Values : Value_Array (1 .. Number_Of_Buckets);
         Size : Natural := 0;
      end record;

.. it seems pointless to force the user to provide yet another
parameter to specify the type for Number_Of_Buckets.

I note also that GNAT.Dynamic_Tables has

   generic
      type Table_Component_Type is private;
      type Table_Index_Type     is range <>;

      Table_Low_Bound : Table_Index_Type;
      Table_Initial   : Positive;
      Table_Increment : Natural;

   package GNAT.Dynamic_Tables is

Re: 64-bit integers in Ada

[Randy Brukardt]

Robert Dewar wrote in message
<5ee5b646.0208040607.ebb6909@posting.google.com>...

>> Though there are few machines still
>> extant that use storage multiples of other than
>> eight-bits,  they do still exist.   I think the compiler for the
Unisys
>> 11xx series has a word size of 36 bits.  Randy can correct me
>> on that if I am wrong.
>
>Yes, of course it's 36 bits (that was a port of Alsys
>technology with which I am familiar).


That's the Ada 83 compiler. The Ada 95 compiler is a port of Janus/Ada.
And, yes it has a word size of 36-bits. (Although the compiler
internally considers it a machine with 9-bit storage units with strong
alignment requirements. This matched the code generator better (which
was created for C), and insured that strings were packed without
standing on ones head.)

               Randy.

Re: 64-bit integers in Ada

[Larry Kilgallen]

In article <5ee5b646.0208040607.ebb6909@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> Richard Riehle <richard@adaworks.com> wrote in message news:<3D4C2805.62563584@adaworks.com>...

>> Since we often counsel designers to specify their own
>            ^^^^^
> I trust this is a typo for *always*

I would expect no such counsel when:

	1. They are already doing so.
   or
	2. This consideration is vastly outweighed by a body of
	   more important items that deserve their intention.

>> numeric types anyway, this is probably not a hardship, 
>> but it could be troublesome for an experienced I-8051 
>> programmer who expects 16 bit integers.
> 
> I don't understand, is this "experienced I-8051" programmer
> an experienced Ada programmer. If so, he has no business
> using Standard.Integer. If not, and he is writing Ada in
> C style, then perhaps the choice of 32-bit integers will
> help cure this bad practice.

Let's cure _all_ such individuals, by standardizing on 4096 bits
as the size for Standard.Integer :-)

Re: 64-bit integers in Ada

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<PG2KS5+doDWm@eisner.encompasserve.org>...
> Let's cure _all_ such individuals, by standardizing on 
> 4096 bits as the size for Standard.Integer :-)

Actually I think the rule of avoiding using explicit
references to Integer is pretty well established. yes,
you see occasional shops that violate this rule, but not
many (in our experience of seeing code from hundreds of
serious projects using Ada).

Actually the above would almost warrant presentation without a smiley
(as a way of effectively removing the
injudicious Standard.Integer type from the language if
it were not for the darned cross contamination with
type String.

What I would have done for the Ada design is to have only
*one* predefined type which would be called something like

   type String_Index is range 1 .. Implementation_Defined;

and leave all other integer types out of standard. I think
that would have worked better, and people would not have
"misused" String_Index as they occasionally misuse Integer.

I feel differently about Float incidentally, I think it is
reasonable to have predefined Float and Long_Float types.
It is simply asking too much for all useful fpt library
packages to be generic since they can't easily speak to
one another if you do that.

Re: 64-bit integers in Ada

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<PG2KS5+doDWm@eisner.encompasserve.org>...
> 	2. This consideration is vastly outweighed by a 
>          body of more important items that deserve their
>          intention.
           ^^^^^^^^^
Nice typo, I assume you mean attention :-)

Actually, this kind of short range thinking (sorry I am too
busy to learn how to do things right, I have too much to
worry about) is really inappropriate to the Ada world and
the world of serious software engineering. I can't tell you
how many projects have a heck of a time porting legacy code
because programmers have not given attention to the issue of writing
portable code earlier on. Note that portable
code is code that is easily able to be ported. That does
NOT mean having stupid rules like "no use of unchecked
conversion". What it does mean is careful encapsulation
of dependencies, and avoidance of gratuitous non-portabilities (such
as using type Standard.Integer :-)

Re: 64-bit integers in Ada

[Marc A. Criley]

Robert Dewar wrote:
> 
> Actually, this kind of short range thinking (sorry I am too
> busy to learn how to do things right, I have too much to
> worry about) is really inappropriate to the Ada world and
> the world of serious software engineering. I can't tell you
> how many projects have a heck of a time porting legacy code
> because programmers have not given attention to the issue of writing
> portable code earlier on.

I can certainly vouch for the presence of this practice in the
industry.  I've done a few ports over the years, and so many times I
have to deal with problems that had the original developers spent just 5
minutes thinking about how to implement in an "Ada" way, rather than the
first approach that came into their head, would've eliminated the
porting problem and made the original code more straightforward and
readable.

The latest was the message buffer handling portion, wherein
Unchecked_Conversion, 'Address, and an Interfaced memcpy routine were
used to move the bits around from buffer to buffer, and to build and
unpack messages.  Variant records and assignment statements would've
worked just as well.

Although, software systems like these are really helpful for stress
testing source code analysis tools :-)

Marc A. Criley, Consultant
Quadrus Corporation
www.quadruscorp.com

Re: 64-bit integers in Ada

[Pat Rogers]

"Marc A. Criley" <mcq95@earthlink.net> wrote in message
news:3D4E652E.FDB4C1C@earthlink.net...
<snip>
> The latest was the message buffer handling portion, wherein
> Unchecked_Conversion, 'Address, and an Interfaced memcpy routine were
> used to move the bits around from buffer to buffer, and to build and
> unpack messages.  Variant records and assignment statements would've
> worked just as well.

I smell 1553 (or such).  OOP works even better for packing/unpacking,
although you do have to convince people that it is OK in the application
domain!

Re: 64-bit integers in Ada

[Richard Riehle]

Larry Kilgallen wrote:

> In article <5ee5b646.0208040607.ebb6909@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> > Richard Riehle <richard@adaworks.com> wrote in message news:<3D4C2805.62563584@adaworks.com>...
>
> >> Since we often counsel designers to specify their own
> >            ^^^^^
> > I trust this is a typo for *always*

I do have difficulty with words such as always and never.   Also, over
the years, especially when I was a day-to-day programmer, I found
myself suspicious of rigid rules for programming practice.  So, my
use of the word, often, though it might be a little to indecisive for
some tastes, it originates in the caution I use when giving advice
about programming style.  Perhaps I am just too wishy-washy about
this and need more backbone in my counsel.

Richard Riehle

Re: 64-bit integers in Ada

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> Well, I think that when you are writing libraries you may find that
> Integer, Natural and Positive have their uses. For example,
> 
>    package Tables is
> 
>       type Item_Array is array (Positive range <>) of Items.Item_Container;
>       type Value_Array is array (Positive range <>) of Values.Value_Container;

But using different index types for different unrelated arrays prevents
accidentally using an index for the wrong array.

- Bob

Re: 64-bit integers in Ada

[Randy Brukardt]

Robert Dewar wrote in message
<5ee5b646.0208030424.39703482@posting.google.com>...
>"Marin David Condic"
>
>> so having the requirement is not a
>> bad thing.
>
>Here is why I think it *is* a bad requirement.
>
>No implementation would possibly make Integer less than
>16 bits. None ever has, and none ever would. Remember that
>the only really critical role of integer is as an index
>in the standard type String (it was a mistake to have string tied in
>this way, but it's too late to fix this)
>
>No one would make integer 8 bits and have strings limited
>to 127 characters.
>
>If you are worried about implementors making deliberately
>useless compilers, that's a silly worry, since there are
>lots of ways of doing that (e.g. declaring that any
>expression with more than one operator exceeds the capacity
>of the compiler).


Right. The reason for the watered-down requirement was that certain
implementors wouldn't stand for a 32-bit requirement, which would break
all of their customer's code.

>So why is the requirement harmful? Because it implies that
>it is reasonable to limit integers to 16 bits, but in fact
>any implementation on a modern architecture that chose 16 bits for
>integer would be badly broken.

Here's where we disagree. Janus/Ada in fact still uses 16-bits for
Integer. This is simply because changing it breaks too much code (ours
and our customers); the compiler fully supports 32-bit integers and
32-bit strings. (I've tried it.) It would be trivial to change if
needed. (I've thought about putting in a compiler switch, but I haven't
had time or customer demand, and it is messy because of the way that
symbol table files are interrelated.) In any case, code that declares
their own types does not have a portability problem.

Indeed, I have occassionally declared my own string type to avoid this
dependence on Integer:

    type String_Count is range 0 .. 2**32-1;
    subtype String_Index is String_Count range 1 .. String_Count'Last;
    type My_String is array (String_Index range <>) of Character;

Ada's rules mean that this type can be used exactly like String. The
only time something extra need be done is when an item of type String is
actually required (such as for a file name). Then a simple type
conversion will do the trick (presuming that the string is short enough,
which better be true for file names).

     Ada.Text_IO.Open (File, String(My_Name), Ada.Text_IO.In_File);

>As for implementations for 8-bit micros, I would still make
>Integer 32 bits on such a target. A choice of 16-bit integer (as for
>example Alsys did on early on) would cause
>giant problems in porting code. On the other hand, a choice
>of 32-bit integers would make strings take a bit more room. I would
>still choose 32-bits.


It takes a lot more room, as the runtime has to carry support for doing
math on 32-bit items (multiply, divide, and so on are too large to put
in-line at the point of use). You're likely to pay for this support
always, because it is very likely that a String or Integer will occur in
the code (and use these operations). On (very) memory-limited targets,
that can be very bad. String descriptors, for loop data, and the like
also is twice as large -- which can matter.

The portability problem only occurs with code that is dubiously designed
in the first place (using predefined numeric types), and it probably is
too large for memory-limited targets anyway. So I strongly disagree with
this.

>Anyway, I see no reason for the standard to essentially encourage
>inappropriate choices for integer types by adding a requirement that
>has no practical significance whatever.
>
>This is an old old discussion. As is so often the case on
>CLA, newcomers like to repeat old discussions :-)
>
>This particular one can probably be tracked down from the
>design discussions for Ada 9X.

Sure, I remember this well. Randy wouldn't stand for a stronger
requirement (there was one at one point); he managed to get enough
support for his position, so we have the one we have now. Note that Ada
83 had no such requirement; the ACVC tests assumed 12-bit integers
maximum. It is useful for the ACVC/ACATS for there to be such a minimum
requirement. But I agree it probably isn't useful for anyone else.

               Randy.

Re: 64-bit integers in Ada

[AG]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:ulita886np1nd9@corp.supernews.com...

>     type String_Count is range 0 .. 2**32-1;
>     subtype String_Index is String_Count range 1 .. String_Count'Last;

To be consistent, should not it be:

subtype String_Index is String_Count range String_Count'First + 1 ..
String_Count'Last;

Otherwise you are assuming that counting starts from zero (or one).

Re: 64-bit integers in Ada

[Robert Dewar]

"AG" <ang@xtra.co.nz> wrote in message news:<UjC79.5960$hk3.1112693@news.xtra.co.nz>...

> To be consistent, should not it be:
> 
> subtype String_Index is String_Count range 
> String_Count'First + 1 .. String_Count'Last;
> 
> Otherwise you are assuming that counting starts from zero (or one).

Actually this seems a poor suggestion, your rewrite does
not emphasize that the lower bound of strings starts at 1.

Re: 64-bit integers in Ada

[Fraser Wilson]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Its been a while since I've seen a C compiler for a 6502, but my
> recollection is that the last one I did look at had 16 bits for the type
> int. Please correct me if I'm wrong here - have you seen C compilers for
> this target using 8 bits for the type int?

No, but Ada has a special problem on 8 bit targets -- the string type.
It's obvious that Integer should be 16 bits, but it's also obvious
that using a two byte string index is overkill; one unsigned byte is
plenty.  I'm vaguely planning some compiler trickery, but it feels
bad.  Is that the normal solution to this issue?  Indexing with two
bytes takes about ten times longer than one byte.

Actually, I don't know that a C compiler could do anything at all
about this, since there's no special string type for which index
finangling could be used.  It would be up to the programmer to address
with an int8.

Fraser.

Re: 64-bit integers in Ada

[Frank J. Lhota]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:aibbr8$4ie$1@nh.pace.co.uk...
> Its been a while since I've seen a C compiler for a 6502, but my
> recollection is that the last one I did look at had 16 bits for the type
> int. Please correct me if I'm wrong here - have you seen C compilers for
> this target using 8 bits for the type int?

The C standard requires that 'short int' must include all integers in the
range -32767 .. 32767, and that int includes all the values in 'short'. So
if there ever was a C compiler that implemented int with 8 bits, it was
clearly pre-ANSI.

Re: 64-bit integers in Ada

[Larry Kilgallen]

In article <ai8pf9$fip$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> One advantage to insisting that the type Integer supports at least 16 bits
> is that it gives the developer some minimal parameters on which to write
> software that might rely on the standard type Integer. If you won't
> guarantee that the type Integer has some minimal usefulness, then why bother
> to have it at all? Most hardware will support 16 bits and even if it doesn't
> you might find it difficult to write any useful programs if you can't count
> up to at least 32767, so a software simulation is probably necessary.

Certainly it is unlikely you would find it useful to be limited to
a maximum value of 127.

Re: 64-bit integers in Ada

[Ben Brosgol]

> Is there a case where, for example, it would make any sense at all for an
> implementation to *not* give the user 16 bits? Would it ever make sense
for
> the type Integer to be 8 bits, for example?

Not really.  E.g., remember that String's index subtype is Positive, so if
Integer were 8 bits then String objects would have a max size of 127.

Re: 64-bit integers in Ada

[Keith Thompson]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
[...]
> Is there a case where, for example, it would make any sense at all for an
> implementation to *not* give the user 16 bits? Would it ever make sense for
> the type Integer to be 8 bits, for example?

3.5.4(21) requires the range of Integer to include the range -2**15+1
.. 2**15-1 (i.e., Integer has to be at least 16 bits).

Even if that requirement weren't there, Ada.Calendar declares:

    subtype Year_Number is Integer range 1901 .. 2099;

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: 64-bit integers in Ada

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
[...]
> Actually, Ada requires 16 bit integers (at minimum).

You're right, I had forgotten that.

It also implicitly requires support for at least 24-bit fixed-point
(see the requirements for type Duration, 9.6(27)).

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: 64-bit integers in Ada

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> [...]
> > Actually, Ada requires 16 bit integers (at minimum).
> 
> You're right, I had forgotten that.
> 
> It also implicitly requires support for at least 24-bit fixed-point
> (see the requirements for type Duration, 9.6(27)).

...which is kind of silly.  Why would an implementation want to support
less for integers than for fixed?

- Bob

Re: 64-bit integers in Ada

[Robert Dewar]

Victor Giddings <victor.giddings@ois.com> wrote in message news:<Xns925A758E8FB6Avictorgiddingsoiscom@192.84.85.25>...
> 
> Try using (or deriving from) Interfaces.Integer_64 or Integer.Unsigned_64. 
> Admittedly, this requires 2 steps on the part of the compiler developer. 1) 
> actually support the 64-bit integer type. 2) to put it in Interfaces (as 
> required by B.2(7)). However, we rely on this in our CORBA product 
> implementation and have been making sure that the compiler vendors are 
> adding these types when they are supported. 
> 
> As of now, I know of only one compiler that supports 64-bit integers and 
> doesn't define Interface.Integer_64. That is to be remedied very soon.

I don't understand the point of this advice. What does this gain over just
declaring the type you want. Either construct will be rejected if the compiler
does not support 64 bit integers. 

Actually there is no requirement in the RM that a compiler that supports 64-bit
integers must have this declaration there. On a 36-bit machine like the PDP-10
you would expect to find Interfaces.Integer_72, but not Interfaces.Integer_64.

I would also argue that it is dubious to expect Interfaces.Integer_64 on a
32 bit machine. Are 64 bit integers "supported by the target architecture?"
Well it's arguable.

Far simpler to use

   type I64 is mod 2 ** 64;

if that's what you want!