Signed vs Natural/32-bits vs 31 bits

Signed vs Natural/32-bits vs 31 bits

[skidmarks]

I'm using gcc under Cygwin and gcc with Mingw and am getting the
following warning:

 476.       function D_Datum is new Unchecked_Conversion(Datum_Type,
AIL_List.Datum_Type);
            |
      >>> warning: types for unchecked conversion have different sizes
      >>> warning: size of "DATUM_TYPE" is 32, size of "DATUM_TYPE" is
31
      >>> warning: 1 trailing bits of source will be ignored

I understand what the message means but what is the operational
effect? What does 'ignored' mean in this context?

art

Re: Signed vs Natural/32-bits vs 31 bits

[Mark H Johnson]

skidmarks wrote:

> I'm using gcc under Cygwin and gcc with Mingw and am getting the
> following warning:
> 
>  476.       function D_Datum is new Unchecked_Conversion(Datum_Type,
> AIL_List.Datum_Type);
>             |
>       >>> warning: types for unchecked conversion have different sizes
>       >>> warning: size of "DATUM_TYPE" is 32, size of "DATUM_TYPE" is
> 31
>       >>> warning: 1 trailing bits of source will be ignored
> 
> I understand what the message means but what is the operational
> effect? What does 'ignored' mean in this context?

To answer the specific question, "ignored" means "ignored". I should 
really go look at my notes but if I recall, GNAT (or the newer GCC's) 
doing unchecked conversion will do something like...
  - ignore unused bits, value will be truncated
  - source value will be extended with unspecified bits
  - sign extend
  - zero extend
depending on the conditions when the number of source / destination bits 
do not match. These conditions basically are (in the same order...)
  - destination size < source size
  - destination size > source size & not a number
  - destination size > source size & a signed number
  - destination size > source size & an unsigned number
I generally consider a warning like this to be an error instead and fix 
the offending code.

Your subject (and not the body) makes me curious, why do you need an 
Unchecked_Conversion between signed and natural numbers? Is there 
something wrong with doing a type cast or is there something else involved?

   --Mark

Re: Signed vs Natural/32-bits vs 31 bits

[Jeffrey Carter]

If there both numeric types, you're far better off using a normal type 
conversion than Unchecked_Conversion.

If in fact you're using Natural, most likely objects are actually 32 
bits, and the message is meaningless. But I would check first to make 
sure this is so.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: Signed vs Natural/32-bits vs 31 bits

[skidmarks]

David Hoos in a private communication indicated that the least
significant bit was (indeed) deleted. What is confusing about this
dialog is that I thought that 'Unchecked_Conversion' meant that all
bits were used and the bits were converted to the 'new' type. Under
this impression, my thought was that I'd have a 32-bit Natural number.
What I seem to be told is that that is not accurate and that
'Unchecked_Conversion' takes less liberties than I'd hoped. Any idea
why?

Re: Signed vs Natural/32-bits vs 31 bits

[David C. Hoos]

Unchecked_Conversion only copies bits without any interpretation
or movement of bits.  When the two objects are of different sizes,
only the bits in the source object are copied.

For full details see RM95 13.9(1-5).

If you want a 32-bit natural number, you need to declare an object
of (say) type Interfaces.Unsigned_32;

Then, instead of using an instance of Unchecked_Conversion,
you do an explicit type conversion as described in  RM95 4.6

----- Original Message ----- 
From: "skidmarks" <aschwarz@acm.org>
Newsgroups: comp.lang.ada
To: <    >
Sent: Wednesday, October 27, 2004 10:35 AM
Subject: Re: Signed vs Natural/32-bits vs 31 bits


> David Hoos in a private communication indicated that the least
> significant bit was (indeed) deleted. What is confusing about this
> dialog is that I thought that 'Unchecked_Conversion' meant that all
> bits were used and the bits were converted to the 'new' type. Under
> this impression, my thought was that I'd have a 32-bit Natural number.
> What I seem to be told is that that is not accurate and that
> 'Unchecked_Conversion' takes less liberties than I'd hoped. Any idea
> why?
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> 

Re: Signed vs Natural/32-bits vs 31 bits

[Martin Krischik]

skidmarks wrote:

> David Hoos in a private communication indicated that the least
> significant bit was (indeed) deleted. What is confusing about this
> dialog is that I thought that 'Unchecked_Conversion' meant that all
> bits were used and the bits were converted to the 'new' type. Under
> this impression, my thought was that I'd have a 32-bit Natural number.
> What I seem to be told is that that is not accurate and that
> 'Unchecked_Conversion' takes less liberties than I'd hoped. Any idea
> why?

No. But the solution is clear:

type Natural is new Standart.Natural;
for Natural'Size use 32;

or

X : Natural := 0;
for X'Size use 32;

And you have 2 32 bit types. If you don't like confusion people then you can
use My_Natural as identifier ;-).

With Regards

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

Re: Signed vs Natural/32-bits vs 31 bits

[skidmarks]

> 
> type Natural is new Standart.Natural;
> for Natural'Size use 32;
> 
> or
> 
> X : Natural := 0;
> for X'Size use 32;
> 

This had already been tried with the effect that arithmetic operations
were no longer valid, to wit, X / 10, X mod 10. I don't know if this
is just a compiler issue or whether this is a more fundamental
problem. (If I remember correctly, the 'use' clause did not work
either).

David Hoos mentioned that: Interface.Unsigned_32 would be the way to
go. I haven't tried this yet.

art