Re: RISC

["Martin Dowie" <martin.dowie@baesystems.com>]

> Do you mean unchecked conversion? That works, but it forces you to move
the
> data twice just to satisfy language rules & may be too inefficient for
some
> apps. Its not A Bad Thing in my estimation, but I'd rather not have to.

No, I really meant checked conversions. We have a whole suite of generics
that take in enumerations and constant arrays of integers (different
subprograms
for different sizes) and provide x<->y conversions.

For arrays of packed booleans we have subprograms that take in 8/16/32
booleans and do the modulo arithmatic. Not exactly efficient, but they seem
to
be highly portable. We also provide a endian_convert a parameter (defaulted
to false). Most of our data does fall on natural word boundaries anyway
(just
not all of them) so the really inefficient routines are hardly ever used. In
most
systems the i/o is a fairly trivial percentage of the %cpu-time and if we
need
to make any optimisations then there is usually a better candidate after a
bit
of analysis.

> Well, that's fine for everything used internal to the system. The moment
> data enters/leaves the system from/to some other source, you *really* want
> to guarantee the representation is what is expected. How would you do this
> without representation clauses?

As above :-)

> You'd have to check with a language lawyer. My impression is that this is
> what the attribute is for. Go ahead and declare a stream of bytes for the
> I/O part to work. Once you get the data, you reference an overlaid record
to
> pull the data apart. I think the 'Valid attribute should force a check of
> the data "assigned" to the record. (Probably works with
Unchecked_Conversion
> as well...) Of course, you just do all this stuff backwards to handle
> output.

Any lawyers out there?


> I don't think overlays were ever not "guaranteed to work" in Ada83 - at
> least no more or less so than in Ada95. (You may have cases where the
> compiler or linker pukes on you. I've had this happen attempting to
overlay
> things from different contexts.) They were/are considered to be "A Bad
> Thing" because of the inherent lack of safety involved. (Much like the use
> of gotos is frowned upon, but they are still supported.) It is recognized
> that overlays can provide an elegant and effective solution to a number of
> problems (such as this one!) if they are used carefully and judiciously.
The
> language attempts to discourage their use because programmers will, like
> most normal people, abuse the privilege if left unrestrained.

RM83, 13.5.something
"Address clauses should not be used to achieve overlays of objects or
 overlays of program units. Nor should a given interrupt be linked to more
 than one entry. Any program using address clauses to achieve such
effects is erroneous."

But I've yet to find anything as explicit about this in RM95 :-(


> I think the ARM probably says something about programs relying on overlays
> being "erroneous" or some other carefully defined term that basically
means
> "it may work but all bets are off from a language lawyer's perspective."
> This is probably because there is no good universal way of defining
behavior
> across all hardware and compiler implementations.
>
> So go ahead and use overlays, but realize you're operating without a net.

I may start toying with overlays if this 'Valid thang works... cheers.