[Info-vax] Ada array initialisation, was: Re: OT: lightweight 90s viewer for Level 2 Postscript. Plus compiler-related obscureness.

[John Wallace]

On Aug 24, 12:50 pm, Simon Clubley <clubley at remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2012-08-23, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>
>
>
>
>
>
>
>
> > On 2012-08-23, John Wallace <johnwalla... at gmail.com> wrote:
>
> >> What's the difference between an Ada array whose elements are
> >> initialised using something like:
> >> array_instance : [const?] array_type := (scalar_a'address,
> >> scalar_b'address ...);
> >> and an array initialised using the notation
> >> array_instance : [const?] array_type := ( 1 => scalar_a'address, 2 =>
> >> scalar_b'address);
>
> >> The correct answer, apparently, is that they are intended to be
> >> equivalent, at least in the obvious case where every element in an
> >> array with an integer index is initialised (or something like that).
>
> > Assuming the lower bound on the array is 1, then they should indeed
> > be identical. The notation in the latter example is known as a "named
> > aggregate" if you want to look it up.
>
> >> However, two of us independently spotted at the same time today that
> >> the two notations when fed into the older compiler generate different
> >> initialisers. One notation correctly generates initialisers which at
> >> run time end up in the right place in ROM (if const) or RAM (if not
> >> const). The other notation just allocates space in RAM (in bss) with
> >> nothing to initialise it (not even something in ROM to copy to RAM to
> >> set it up). The one with " => " is the wrong'un in this picture.
>
> > The compiler is wrong, wrong, wrong. Since it's placed it in .bss, it's
> > clearly ignored the initialisation values. The compiler is broken.
>
> I've had a think about this to try and come up with a scenario in which
> the compiler isn't as broken as it appears to be and I do have one
> suggestion.
>
> It occured to me that the apparently broken compiler, when it sees named
> aggregates, may be choosing to setup the array at elaboration time instead
> of at compilation time.
>
> In this case, it would be correct for the array to be placed in .bss,
> because the elaboration code, which is executed before the procedure
> itself, would setup the array at runtime.
>
> If true, the question then becomes if the expected elaboration code is
> been suppressed at build time, or if the compiler generated elaboration
> code is not been copied to the final executable correctly because
> something is wrong in the linker script.
>
> If it's a elaboration problem, this may catch you in different unrelated
> areas as well, so it may be worth you considering this possibility even
> if you have what appears to be a workaround for the original problem.
>
> Simon.
>
> --
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

[probably my last contribution on this particular subtopic]

Same thought occured at work, which means either it's another good
idea, or we're both equally daft. You pick.

A quick test was added to attempt to check the general theory of
whether elaboration had run or not by the time the relevant bit of
test program got to run. The extra code indicated that elaboration had
run.

A last ditch attempt to confirm this was to change the makefile to
leave all the .s files around. There was no evidence of the required
initialisations in the .s file, leading to the conclusion that
somewhere earlier in the compiler was for some invisible reason
discarding the required initialisations.

As a functional workaround has been identified, the subject is closed
(at least for now); there are plenty more pressing things to do.