Re: Problem using Ada.Text_IO.Modular_IO

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

anon schrieb:
> When the CPU or FFU executes a single arithmetic instruction it uses the 
> build-in CPU Carry flag to detect a Overflow/Underflow condition for those 
> types that are define in the Standard/System packages.

It turns out that the CPU instructions for "mod 2**64" types
are the very same as the CPU instructions for Unsigned_64.
Assuming you get an advantage from using hardware overflow
flags, they will thus be had for either type.


>  Which is faster 
> than a set of routines that the compiler generates for a new user type.

Q: What routines does the compiler generate for Unsigned_64
    but not for "mod 2**64" and vice versa?
A: None.

Q: What routines does the compiler generate for mod 2**5?
A: None that have a jump to constraint error handlers.
    (Not surprisingly; and see below.)
    Some that do fast, efficient, modular operations
    in hardware.
    (Not surprisingly; see below.)
    None that could replaced with predefined ones because
    there is no predefined type with the same properties as
    "mod 2**5". Not on earth, at least, as far as I can tell.



>  Actually, in the case of 2**5 the arithmetic 
> function is done on the processor 8-bit word and then the result is 
> compared to see if the result is with the range of 2**5.  A lot of 
> instructions are generated instead of only three for build-in types:

What makes you think that 2**5 artithmetic is necessarily expensive?
It is modular arithmetic on a power of 2. Ada compilers will in many
cases do better than what you have outlined.

Code for a "mod 2**5" type:

    type M5 is mod 2**5;

    function Double_It(Item: M5) return M5 is
    begin
       return item + item;
    end Double_It;


$ gnatmake -gnatwa -gnato -O -fno-inline mod5.adb

0000000000000000 <mod5__double_it.912>:
    0:	01 ff                	add    %edi,%edi
    2:	89 f8                	mov    %edi,%eax
    4:	83 e0 1f             	and    $0x1f,%eax
    7:	c3                   	retq

%eax is a 32-bit word, and no 8-bit AL or AH register is mentioned.
ADD is safe because %edi is bound to contain values of type
"mod 2**5", so small that addition can never set a 32bit CPU's
unsigned overflow flag.
The rest ist just clearing the sequence of carried bits
because this is how "mod 2**5" works in binary hardware.

Again -gnato is used for turning checks on, in case you
had overlooked this when answering.

To repeat, I have _never_ seen different code produced for
the same algorithm using either Unsigned_N or mod 2**N.
Could you give one actual, compilable example so we could
convince ourselves that what you claim can be found to be
true, concerning the superiority of Unsigned_N over mod 2+*N?



--
Georg Bauhaus
Y A Time Drain  http://www.9toX.de