different compilers: different standard types?????

different compilers: different standard types?????

[Riccardo]

Thanks !

My problem was of course not to define new types but to use the same type
(with the same source files!) on both the consoles (a Sun Spark and an Alpha
Digital ).

So in defining new types I have to be sure that I don't have to manage
different source codes.

I'm looking for a sort of pragma that should help me to share the needs of
the two implementations (as the "conditional compilation" in C).

I saw that the pragma System is a deprecated one.

Is there something useful that allows the operation?

Re: different compilers: different standard types?????

[Martin Dowie]

"Riccardo" <kk@kk.com> wrote in message
news:c3e7qn$2oe$1@e3k.asi.ansaldo.it...
> My problem was of course not to define new types but to use the same type
> (with the same source files!) on both the consoles (a Sun Spark and an
Alpha
> Digital ).
>
> So in defining new types I have to be sure that I don't have to manage
> different source codes.
>
> I'm looking for a sort of pragma that should help me to share the needs of
> the two implementations (as the "conditional compilation" in C).
>
> I saw that the pragma System is a deprecated one.
>
> Is there something useful that allows the operation?

But surely the solution to your problem is to simply not use predefined
types? Define your own with the range you require or use the type in package
Interfaces.

Portable types

[Stephen Leake]

"Riccardo" <kk@kk.com> writes:

> Thanks !
> 
> My problem was of course not to define new types but to use the same type
> (with the same source files!) on both the consoles (a Sun Spark and an Alpha
> Digital ).
> 
> So in defining new types I have to be sure that I don't have to manage
> different source codes.
> 
> I'm looking for a sort of pragma that should help me to share the needs of
> the two implementations (as the "conditional compilation" in C).
> 
> I saw that the pragma System is a deprecated one.
> 
> Is there something useful that allows the operation?

I'm not clear what you are asking. 

Apparently you want to write some source code that is portable between
a Sun Spark (running what OS?) and Compaq Alpha (Digital was bought by
Compaq; I don't think they make Alphas anymore) (running what OS?).

Ada is very good for writing portable code. But to give you specific
help, I need to see the source that you want to be portable.

-- 
-- Stephe

Re: Portable types

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: 
: Compaq Alpha (Digital was bought by
: Compaq; I don't think they make Alphas anymore)

You can still buy them though, e.g. 
http://h18002.www1.hp.com/alphaserver/

different compilers: different standard types?????

[Riccardo]

Hello everybody!

I've got a problem.
Using an old program that now my Firm wants to make running on different
kind of consoles simoultaneously I see that my compilers (I have two of
them) are different ones depending on the fact that the word lenght is
different (32 vs 64 bit).

Specifically:  I noticed that the type long_long_integer, that is used on
the first one, is not present at all on the second one.

I'm looking for a solution that should permit me to compile the software on
both the environments making, obviously, the least changes on the current
version.

The same product, in the end, should be compiled on both the consoles
without making changes! (it is possible!?!??!!??!)

Is there someone who has any kind of easy solution for that problem??

Thanks in advice,


Riccardo

Re: different compilers: different standard types?????

[Martin Krischik]

Riccardo wrote:

> Hello everybody!
> 
> I've got a problem.
> Using an old program that now my Firm wants to make running on different
> kind of consoles simoultaneously I see that my compilers (I have two of
> them) are different ones depending on the fact that the word lenght is
> different (32 vs 64 bit).
> 
> Specifically:  I noticed that the type long_long_integer, that is used on
> the first one, is not present at all on the second one.

Well define your own types. 

> I'm looking for a solution that should permit me to compile the software
> on both the environments making, obviously, the least changes on the
> current version.
> 
> The same product, in the end, should be compiled on both the consoles
> without making changes! (it is possible!?!??!!??!)

If both compilers support the same types: yes.

> Is there someone who has any kind of easy solution for that problem??

I take it you are pretty new to Ada - otherwise you would know the solution.

In Ada you can define your own integer types. i.E.:

type Month is range 1 .. 31;

The compiler will choose the bits needed which is good for most programms.
If you need a special size you can say:

for Month'Size use 8; -- bit!

or even

for Month'Size use 5;

Performace for a 5 bit type will be abysmal but if you want it the compiler
will give it to you.

If you need long_long_integer and the compiler does not provide one use:

type long_long_integer is range -2**63 .. +2**63 - 1;
for long_long_integer'Size use 64;

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: different compilers: different standard types?????

[Steve]

In my opinion the best approach would be to either find or write an
automated tool to modify the existing sources such that they do not use
standard types that vary in size depending on implementation.

For integral values define types in terms of ranges, for floating point
values define types in terms of precision requirements.  You could use the
types defined in the Interfaces package, but would be better to use your own
types based on your application.

You can probably find someone to convert your sources by searching the Web.
If you choose to do the work yourself, you may want to have a look at ASIS.

I hope this helps,

Steve
(The Duck)


"Riccardo" <kk@kk.com> wrote in message
news:c391gu$5c3$1@e3k.asi.ansaldo.it...
> Hello everybody!
>
> I've got a problem.
> Using an old program that now my Firm wants to make running on different
> kind of consoles simoultaneously I see that my compilers (I have two of
> them) are different ones depending on the fact that the word lenght is
> different (32 vs 64 bit).
>
> Specifically:  I noticed that the type long_long_integer, that is used on
> the first one, is not present at all on the second one.
>
> I'm looking for a solution that should permit me to compile the software
on
> both the environments making, obviously, the least changes on the current
> version.
>
> The same product, in the end, should be compiled on both the consoles
> without making changes! (it is possible!?!??!!??!)
>
> Is there someone who has any kind of easy solution for that problem??
>
> Thanks in advice,
>
>
> Riccardo
>
>
>

Re: different compilers: different standard types?????

[Jean-Pierre Rosen]

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


"Steve" <nospam_steved94@comcast.net> a �crit dans le message de news:mZ86c.30434$JL2.362994@attbi_s03...
> In my opinion the best approach would be to either find or write an
> automated tool to modify the existing sources such that they do not use
> standard types that vary in size depending on implementation.
>
Jumping on the opportunity for a shameless plug...

This tool is already available. Look at Adasubst at http://www.adalog.fr/compo2.htm

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: different compilers: different standard types?????

[Dmitry A. Kazakov]

On Thu, 18 Mar 2004 11:37:52 +0100, "Jean-Pierre Rosen"
<rosen@adalog.fr> wrote:

>
>"Steve" <nospam_steved94@comcast.net> a �crit dans le message de news:mZ86c.30434$JL2.362994@attbi_s03...
>> In my opinion the best approach would be to either find or write an
>> automated tool to modify the existing sources such that they do not use
>> standard types that vary in size depending on implementation.
>>
>Jumping on the opportunity for a shameless plug...
>
>This tool is already available. Look at Adasubst at http://www.adalog.fr/compo2.htm

Great!

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: different compilers: different standard types?????

[Marius Amado Alves]

I have a related problem, at least with GNAT 3.15p, the compiler of all us 
poor academics.

The standard requires that "the range of Integer should be no wider than that 
of Long_Integer" 3.5.4 (25). (I'm not sure this is an intelligent limitation, 
but never mind.) GNAT defines Integer and Long_Integer for 32-bit, and 
Long_Long_Integer for 64-bit.

So if you want to define an integral type with a greater range than (the 
associated with) 32 bits, you have to use Long_Long_Integer as a base. But 
then you hinder portability, because Long_Long_Integer is not standard.

So I guess my question is: Why does not GNAT define Integer (and Long_Integer) 
for 64-bits? AFAICS the standard does not impose a upper limit on Integer. 
And don't tell me the answer is: Because then Short_Integer would have 
32-bits, and that is not what the C world calls short.

Thanks.

Re: different compilers: different standard types?????

[Ludovic Brenta]

Marius Amado Alves <maa@liacc.up.pt> writes:

> I have a related problem, at least with GNAT 3.15p, the compiler of
> all us poor academics.
> 
> The standard requires that "the range of Integer should be no wider
> than that of Long_Integer" 3.5.4 (25). (I'm not sure this is an
> intelligent limitation, but never mind.)

Basically, this means that by definition, Long_Integer is at least as
long as Integer.  It's not really a limitation, but a definition of
terms.

> GNAT defines Integer and Long_Integer for 32-bit, and
> Long_Long_Integer for 64-bit.
> 
> So if you want to define an integral type with a greater range than
> (the associated with) 32 bits, you have to use Long_Long_Integer as
> a base. But then you hinder portability, because Long_Long_Integer
> is not standard.
> 
> So I guess my question is: Why does not GNAT define Integer (and
> Long_Integer) for 64-bits? AFAICS the standard does not impose a
> upper limit on Integer.  And don't tell me the answer is: Because
> then Short_Integer would have 32-bits, and that is not what the C
> world calls short.

It's not because of C, it's because in your case, GNAT targets a
32-bit processor.  This means that, if you recompile GNAT to target a
64-bit machine, Integer and Long_Integer should become 64 bits wide.

You may also want to try -gnatdm, debug.adb says this forces
Long_Integer to be 64 bits wide on all targets, but it also warns that
this flag may cause other problems.

-- 
Ludovic Brenta.

Re: different compilers: different standard types?????

[Georg Bauhaus]

Marius Amado Alves <maa@liacc.up.pt> wrote:
: So if you want to define an integral type with a greater range than (the 
: associated with) 32 bits, you have to use Long_Long_Integer as a base. But 
: then you hinder portability, because Long_Long_Integer is not standard.

would this work:

procedure l is

   type LI is range 0 .. 2**40 - 1;

   x: LI;

begin
   x := 2 ** 34;
end l;


-- Georg

Re: different compilers: different standard types?????

[Marius Amado Alves]

>    type LI is range 0 .. 2**40 - 1;

I was temporarilly insane. Thanks for the slap on the face. Of course this is 
the right way to define 'long' integer types. I was fixated on forms with a 
base/parent type:

  subtype ST is Long_Integer range ...
  type T is new Long_Integer range ...

/* My only excuse is that my brain is not naturally equiped to intuitively 
grasp and store these differences. Were there many more like me and this 
could be a message to language designers. But I'm probably the odd one. So 
it's a message to me: start looking for a smaller language, as definitely the 
ARM does not fit in your (my) head entirely. */

Re: different compilers: different standard types?????

[Martin Krischik]

Georg Bauhaus wrote:

> Marius Amado Alves <maa@liacc.up.pt> wrote:
> : So if you want to define an integral type with a greater range than (the
> : associated with) 32 bits, you have to use Long_Long_Integer as a base.
> : But then you hinder portability, because Long_Long_Integer is not
> : standard.
> 
> would this work:
> 
> procedure l is
> 
>    type LI is range 0 .. 2**40 - 1;
> 
>    x: LI;
> 
> begin
>    x := 2 ** 34;
> end l;

I don't know about your compiler but GNAT will accept anything up to
2**64-1.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: different compilers: different standard types?????

[Jeffrey Carter]

Marius Amado Alves wrote:
> 
> So if you want to define an integral type with a greater range than (the 
> associated with) 32 bits, you have to use Long_Long_Integer as a base. But 
> then you hinder portability, because Long_Long_Integer is not standard.

ARM 3.5.4 says, "An implementation may provide additional predefined 
signed integer types, declared in the visible part of Standard, whose 
first subtypes have names of the form Short_Integer, Long_Integer, 
Short_Short_Integer, Long_Long_Integer, etc."

The operative word is "may". Integer is the only predefined integer type 
required (in Standard). Long_Integer is just as non-standard as 
Long_Long_Integer.

You don't have to use [Long_]Long_Integer as a base. You should declare 
your numeric types based on your application's requirements:

type T is range <application-defined>;

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: different compilers: different standard types?????

[Duncan Sands]

Hi Marius,

> So I guess my question is: Why does not GNAT define Integer (and
> Long_Integer) for 64-bits? AFAICS the standard does not impose a upper
> limit on Integer. And don't tell me the answer is: Because then
> Short_Integer would have 32-bits, and that is not what the C world calls
> short.

I guess you mean "why doesn't GNAT define Integer to have 64 bits"?
I've heard it said that GNAT (in fact gcc) defines Integer to be the most
efficient integer type for the processor.  For example, on a 32 bit processor
64 bit integer arithmetic is slower than 32 bit integer arithmetic.  I expect
that Integer is 64 bits on 64 bit processors...

Ciao,

Duncan.

Re: different compilers: different standard types?????

[Stephen Leake]

Marius Amado Alves <maa@liacc.up.pt> writes:

> The standard requires that "the range of Integer should be no wider
> than that of Long_Integer" 3.5.4 (25). (I'm not sure this is an
> intelligent limitation, but never mind.) 

What would you like it to say instead?

> GNAT defines Integer and Long_Integer for 32-bit, and
> Long_Long_Integer for 64-bit.
> 
> So if you want to define an integral type with a greater range than
> (the associated with) 32 bits, you have to use Long_Long_Integer as
> a base. 

Hmm. Let's declare a type:

type My_Long_Int is range -2**50 .. 2**50 -1;

You don't _specify_ Long_Long_Integer, but the compiler does use a 64
bit integer as the base type. Just to be picky :).

> But then you hinder portability, because Long_Long_Integer is not
> standard.

The problem is not that Long_Long_Integer is not standard; the problem
is that 64 bits is not standard. Neither, for that matter, is 32 bits;
the standard only requires 16 bit integers.

> So I guess my question is: Why does not GNAT define Integer (and
> Long_Integer) for 64-bits? 

How would that improve portability? As long as other compilers don't
support 64 bit integers, using them will be none-portable.

Integer is used for the index of String; it probably does not make
sense for that to be 64 bits. Why waste space?

It might make sense for Long_Integer to be 64 bits. 

But none of this really matters; you should _never_ use an integer
type declared in Standard (except Integer for String indices, or when
you really don't care about size).

> AFAICS the standard does not impose a upper limit on Integer.

True.

> And don't tell me the answer is: Because then Short_Integer would
> have 32-bits, and that is not what the C world calls short.

That is certainly not the answer; C types are in Interfaces.C, not
Standard.

-- 
-- Stephe

Re: different compilers: different standard types?????

[Marius Amado Alves]

> I guess you mean "why doesn't GNAT define Integer to have 64 bits"?
> I've heard it said that GNAT (in fact gcc) defines Integer to be the most
> efficient integer type for the processor....

Yes. I was temporarily amnesic of the fact that the proper way to define an
integer of any size is

  type IT is range ...

I was fixated on forms

  subtype ST is Long_Integer range ...
  type T is new Long_Integer range ...

(I posted this before but seemingly it didn't reach the list.)

Anyway, I now understand that the proper way to define an integer type with
the maximum range possible is

  type MI is range System.Min_Int .. System.Max_Int;

/* My natural expectation of Integer was that it would be this type. To a
layman, 3.5.4 (11) seems to support that. But I guess no. I think Ada is too
much complicated here. As in other places. Too many integers (root,
universal, etc.) And so little time. */

Re: different compilers: different standard types?????

[Steve]

One other note: I am aware of at least one commercial compiler that doesn't
support integer types larger than 32 bits (ObjectAda V7.2.2 - Intel).

System.Min_Int:-2147483648
System.Max_Int: 2147483647

Steve
(The Duck)

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.110.1079654853.327.comp.lang.ada@ada-france.org...
> > I guess you mean "why doesn't GNAT define Integer to have 64 bits"?
> > I've heard it said that GNAT (in fact gcc) defines Integer to be the
most
> > efficient integer type for the processor....
>
> Yes. I was temporarily amnesic of the fact that the proper way to define
an
> integer of any size is
>
>   type IT is range ...
>
> I was fixated on forms
>
>   subtype ST is Long_Integer range ...
>   type T is new Long_Integer range ...
>
> (I posted this before but seemingly it didn't reach the list.)
>
> Anyway, I now understand that the proper way to define an integer type
with
> the maximum range possible is
>
>   type MI is range System.Min_Int .. System.Max_Int;
>
> /* My natural expectation of Integer was that it would be this type. To a
> layman, 3.5.4 (11) seems to support that. But I guess no. I think Ada is
too
> much complicated here. As in other places. Too many integers (root,
> universal, etc.) And so little time. */
>

Re: different compilers: different standard types?????

[Marius Amado Alves]

> One other note: I am aware of at least one commercial compiler that
doesn't
> support integer types larger than 32 bits (ObjectAda V7.2.2 - Intel).
>
> System.Min_Int:-2147483648
> System.Max_Int: 2147483647

The famous 2G limit. Now you got me nervously looking for the file position
type. The standard is silent, so is GNAT's documentation, so it's a long
journey in the sources: Direct_IO.Count, System.Direct_IO.Count,
Interfaces.C_Streams.long, System.Parameters.long_bits, and finally
Long_Integer'Size, which is... also 32-bit! (Inspecting Count'Size confirms
that.) Oh, well...

(Just for those who might be thinking that 2G is large enough let me tell
you I have hit that wall on several real world applications.)

Re: different compilers: different standard types?????

[Marius Amado Alves]

> The famous 2G limit.

And of course System.Address is also 32-bit. I guess we'll be hiting that
wall in year or two...

Re: different compilers: different standard types?????

[Stephen Leake]

"Marius Amado Alves" <amado.alves@netcabo.pt> writes:

> > > The standard requires that "the range of Integer should be no wider
> > > than that of Long_Integer" 3.5.4 (25). (I'm not sure this is an
> > > intelligent limitation, but never mind.)
> >
> > What would you like it to say instead?
> 
> I guess have a named type (Integer) for the largest base available. Then no
> need for System constants Max/Min_Int. Use 'First, 'Last instead. Also
> what's the use of Short_ and Short_Short_ if you have representation clauses
> for 'Size? The optimal size for a given target would be given in the
> documentation for that target.

I think most people agree that having any integer types in Standard
was a mistake. Hence the advice to never use them.

> Yes. As I said before I had forgotten that the integer base type is
> nameless. You can stop bashing now ;-)

I only bashed once :). One problem with newsgroups is lots of people
think they are the first responder; so you get bashed a lot :).

-- 
-- Stephe

Re: different compilers: different standard types?????

[Marius Amado Alves]

> > The standard requires that "the range of Integer should be no wider
> > than that of Long_Integer" 3.5.4 (25). (I'm not sure this is an
> > intelligent limitation, but never mind.)
>
> What would you like it to say instead?

I guess have a named type (Integer) for the largest base available. Then no
need for System constants Max/Min_Int. Use 'First, 'Last instead. Also
what's the use of Short_ and Short_Short_ if you have representation clauses
for 'Size? The optimal size for a given target would be given in the
documentation for that target.

> > GNAT defines Integer and Long_Integer for 32-bit, and
> > Long_Long_Integer for 64-bit.
> >
> > So if you want to define an integral type with a greater range than
> > (the associated with) 32 bits, you have to use Long_Long_Integer as
> > a base.
>
> Hmm. Let's declare a type:
>
> type My_Long_Int is range -2**50 .. 2**50 -1;
>
> You don't _specify_ Long_Long_Integer, but the compiler does use a 64
> bit integer as the base type. Just to be picky :).

Yes. As I said before I had forgotten that the integer base type is
nameless. You can stop bashing now ;-)

> Integer is used for the index of String; it probably does not make
> sense for that to be 64 bits. Why waste space?

String is another slightly disturbing thing. I'd rather have an Ada.Arrays
generic on the types of index and element. Talk small. And then the same
"create your own integers" argument would apply here. Create your own
Strings. But this is designing a new language. (No, not C.)

Re: different compilers: different standard types?????

[Jean-Pierre Rosen]

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


"Marius Amado Alves" <amado.alves@netcabo.pt> a �crit dans le message de
news:mailman.112.1079678230.327.comp.lang.ada@ada-france.org...
> String is another slightly disturbing thing. I'd rather have an Ada.Arrays
> generic on the types of index and element. Talk small. And then the same
> "create your own integers" argument would apply here. Create your own
> Strings. But this is designing a new language. (No, not C.)
>
But you can define your own string type:
   type My_String is array (whatever range <>) of characters;

It will have all the features of String, including concatenation, slices and literals.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: different compilers: different standard types?????

[Jeffrey Carter]

Marius Amado Alves wrote:

> String is another slightly disturbing thing. I'd rather have an Ada.Arrays
> generic on the types of index and element. Talk small. And then the same
> "create your own integers" argument would apply here. Create your own
> Strings. But this is designing a new language. (No, not C.)

This is called a one-dimensional type declaration. For example, type 
String is defined as

type String is array (Positive range <>) of Character;
pragma Pack (String);

What you want can be done in exactly the same way:

type Ada_Array_Instantiation is array (Index [range <>]) of Element;

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
02

Re: different compilers: different standard types?????

[Marius Amado Alves]

> > String is another slightly disturbing thing. I'd rather have an
Ada.Arrays
> > generic on the types of index and element. Talk small. And then the same
> > "create your own integers" argument would apply here. Create your own
> > Strings. But this is designing a new language. (No, not C.)
>
> This is called a one-dimensional type declaration. For example, type
> String is defined as
>
> type String is array (Positive range <>) of Character;
> pragma Pack (String);
>
> What you want can be done in exactly the same way:
>
> type Ada_Array_Instantiation is array (Index [range <>]) of Element;

I know, and this is why I questioned the purpose of String (or Integer, or
Float). But I also meant a generic *package* Ada.Arrays. To have more
functionality for arrays than that provided by the language. Like
Ada.Strings, but for any element type.