Re: Ada compiler differences

[Nick Roberts <nick.roberts@acm.org>]

Magnus wrote:

> Could someone please point me to a list of things that may be
> implementation dependent in different ADA compilers and/or on
> different platforms?

One could write a book about this subject. It is too complex to state
completely in a few paragraphs.

The first question you should ask, for a particular program you are
developing, is "Does this need to be portable?" In most cases, the
answer will be "No", and so your question does not arise.

Admittedly, it can occasionally happen that a problem which would
normally be categorised as a porting problem can occur when upgrading
from one version of a compiler to the next.

For cases where it does arise:

> I know that things like 'access and structures without repspec may
> differ. But what else?

The underlying representation (and implementational details) of these
things will differ, but their semantics (as defined by the standard)
should not.

The general principle is that if you write your program so that its
correctness depends only upon the semantics required by the Ada
standard, you should be able to port the program without having to
change it. The standard carefully defines which aspects are
implementation defined.

If timing considerations are really important, you may well have
considerable porting problems anyway.

> Or rather: how can I write code that really is platform (and
> compiler) independent in Ada?

Generally, you cannot. However, you generally /can/ write Ada programs
that require very little changes to be ported. Typically, the best
technique is to move everything that might need to be changed during a
port into separate (library) packages, so that the places where changes
are required are isolated from the rest of the code.

There are lots of subtle gotchas, unfortunately, that you may need to
watch out for. I can list a few.

Re-entrancy of pre-defined subprograms: on some implementations, if two
tasks make simultaneous calls to a subprogram in certain pre-defined
library packages, one or both will not work correctly. If you are lucky,
your program will just crash; if you are unlicky, it will be a source of
subtle, intermittent, infuriatingly uncatchable bugs. Theoretically, this
should never happen unless both subprogram calls make reference to the
same variable (or file). In practice, I think you'll find some
implementations are less than perfect in this area. If you are not
careful, you can run into re-entrancy problems with your own subprograms,
too. Since different implementations can multitask in very different
ways, its often the case that a potential re-entrancy problem doesn't
manifest itself until a program is ported.

Aliasing: implementations are sometimes allowed to choose whether to pass
a parameter by value or by reference (indirectly). If it so happens that
a call to a subprogram effectively passes the same variable as two
different (formal) parameters, the subprogram has two different 'paths'
to the variable, without knowing it. The order in which updates to the
variable occur could change from one implementation to another, in this
situation. This can be a source of some really mysterious bugs, when
porting.

Order dependency: implementations are generally allowed to choose in what
order they evaluate the expressions passed as (actual) parameters to a
subprogram call. If more than one of these expressions has a side-effect,
and the side-effects could interact in some way, it possible that the
order the implementation chooses could affect the behaviour of a program.
This can be a source of subtle and nasty bugs when porting.

The values of everything declared in the predefined package 'System' are
all implementation defined, as well as in its children, and the
subprograms will all work differently. There may be extra imp-def
declarations, and some declarations may be omitted or different to what
the standard states. So use of these packages needs care, from a
portability perspective. It's best to avoid using anything here if you
can.

-- 
HTH
Nick Roberts