differences between ada95 using O32 and N32 on SGI's

differences between ada95 using O32 and N32 on SGI's

[Vladimir Bednikov]

Hi all,

I have a program written in ada95 on an SGI (irix 6.2). The
program ran in real-time when I was using the old O32 version
of the compiler. Since installing the new version (N32) of the
compiler, my program stopped running in real-time. I found
the bottle neck in a call to retrieve an element of an array. This
array is a member of a record as follows:

type buffer_array is array (integer range <>) of real;
type array_ptr is access buffer_array;
type buffer_type is record
    next_index : integer;
    full : boolean;
    buffer : array_ptr;
    size : integer;
end record;

I am trying to implement a circular buffer with the above.

90% of the time was spent on retrieving an element of buffer. Using
speedshop,
I found that the actual time was spent on
System__Secondary_Stack__SS_Release.

Can anyone shed some light on this.

Thanks in advance.

Re: differences between ada95 using O32 and N32 on SGI's

[Mark Lundquist]

Talk to your compiler vendor! :-)

Your question is an implementation-specific one.  You didn't even specify
what compiler you're using.  But in any case, it's probably a technical
support question for them -- I'd be suprised if anyone on c.l.a. can offer
any insight...

But good luck!
-- mark

"Vladimir Bednikov" <Vladimir.Bednikov@ebor.com> wrote in message
news:9gurrd$inf$1@fang.dsto.defence.gov.au...> Hi all,
>
> I have a program written in ada95 on an SGI (irix 6.2). The
> program ran in real-time when I was using the old O32 version
> of the compiler. Since installing the new version (N32) of the
> compiler, my program stopped running in real-time. I found
> the bottle neck in a call to retrieve an element of an array. This
> array is a member of a record as follows:
>
> type buffer_array is array (integer range <>) of real;
> type array_ptr is access buffer_array;
> type buffer_type is record
>     next_index : integer;
>     full : boolean;
>     buffer : array_ptr;
>     size : integer;
> end record;
>
> I am trying to implement a circular buffer with the above.
>
> 90% of the time was spent on retrieving an element of buffer. Using
> speedshop,
> I found that the actual time was spent on
> System__Secondary_Stack__SS_Release.
>
> Can anyone shed some light on this.
>
> Thanks in advance.
>
>

Re: differences between ada95 using O32 and N32 on SGI's

[Vladimir Bednikov]

Hi all,

Fixed the problem. The program ran fine when it was compiled with
gnat3.11p on an SGI with gcc2.8.1. It started acting up when I moved to
gnat3.13p. The problem was that the compiler was pre-executing the
integer'image(blah) statement in the else branch of my get method,
eventhough
it never branches to the else part. The get function for the buffer_type
record I had
is as follows:

The difference in time is five fold.

function get(buffer : in buffer_type; offset : in integer) return real is
    latest_index : integer := buffer.next_index -1;
    buffer_size : integer := buffer.size;
begin
    if (buffer.buffer = null) then
        raise Null_Buffer_Error;
    end if;

    if ((buffer.full) and (offset < buffer_size)) then
        return buffer.buffer((latest_index-offset) mod buffer_size);
    elsif ((not buffer.full) and (offset <= latest_index)) then
        return buffer.buffer(latest_index - offset);
    else
        ada.text_io.put_line("can not get value at offset " &
integer'image(offset));
        if (buffer.full) then
            ada.text_io.put_line("This offset is greater than the maximum
allowed offset of " &
                                            integer'image(buffer_size-1));
        else
            ada.text_io.put_line("This offset is outside the currently valid
range");
        end if;
        return 0.0;
    end if;

    exception
        when others =>
            ada.text_io.put_line("Exception raised in Circular_Buffer.get");
            raise;
end get;

I fixed the problem by adding another level of blocking by placing a begin
.. end
delimeter between the else and end if. This had the effect of delaying the
execution
of integer'image(blah) till its necessary. That is:
    ...
    else
        BEGIN -- this causes the integer'image(offset) to be evaluated when
necessary
            ada.text_io.put_line("can not get value at offset " &
integer'image(offset));
            if (buffer.full) then
                ada.text_io.put_line("This offset is greater than the
maximum allowed offset of " &

integer'image(buffer_size-1));
            else
                ada.text_io.put_line("This offset is outside the currently
valid range");
            end if;
            return 0.0;
        END;
    end if;

"Mark Lundquist" <up.yerz@nospam.com> wrote in message
news:%0LY6.225132$p33.4526532@news1.sttls1.wa.home.com...
> Talk to your compiler vendor! :-)
>
> Your question is an implementation-specific one.  You didn't even specify
> what compiler you're using.  But in any case, it's probably a technical
> support question for them -- I'd be suprised if anyone on c.l.a. can offer
> any insight...
>
> But good luck!
> -- mark
>
> "Vladimir Bednikov" <Vladimir.Bednikov@ebor.com> wrote in message
> news:9gurrd$inf$1@fang.dsto.defence.gov.au...> Hi all,
> >
> > I have a program written in ada95 on an SGI (irix 6.2). The
> > program ran in real-time when I was using the old O32 version
> > of the compiler. Since installing the new version (N32) of the
> > compiler, my program stopped running in real-time. I found
> > the bottle neck in a call to retrieve an element of an array. This
> > array is a member of a record as follows:
> >
> > type buffer_array is array (integer range <>) of real;
> > type array_ptr is access buffer_array;
> > type buffer_type is record
> >     next_index : integer;
> >     full : boolean;
> >     buffer : array_ptr;
> >     size : integer;
> > end record;
> >
> > I am trying to implement a circular buffer with the above.
> >
> > 90% of the time was spent on retrieving an element of buffer. Using
> > speedshop,
> > I found that the actual time was spent on
> > System__Secondary_Stack__SS_Release.
> >
> > Can anyone shed some light on this.
> >
> > Thanks in advance.
> >
> >
>
>