comp.lang.ada
 help / color / mirror / Atom feed
* Re: Receiver Buffer Representation Clause (novice question)
       [not found] <38BDB743.BB95E16F@interact.net.au>
@ 2000-03-02  0:00 ` tmoran
  0 siblings, 0 replies; only message in thread
From: tmoran @ 2000-03-02  0:00 UTC (permalink / raw)


>type Byte is range 0..16#FF#;
>type Line_Number_Type is range 0..16#3#;

  They are equivalent to

type Byte is range 0 .. 255;
type Line_Number_Type is range 0 .. 3;

  The difference is just in readability & understandability.
Presumably the original author was trying to stay in hex rather
than decimal since you are dealing with bytes and bits.  He
could instead have used base 2 and said

  type Byte is range 0 .. 2#11111111#;
  type Line_Number_Type is range 0 .. 2#11#;
but counting 1's is more error prone and less clear.

>use record at mod 2 is a new creature I have not encountered
>before.  I am also testing my fledgling knowledge by asking
>anyone if, for instance,  at 0 range x..x;
>defines a single bit boolean value to signal a
>condition as True or False, is initialized to False and
>pertains to the bit at x;

  The "at mod 2" in this record representation clause is the
older Ada 83 way to tell the compiler you want these records
aligned on even addresses.  It still works, but

  for Receiver_Buffer'alignment use 2;
is the newer way to say it.

  The "at n range x ..  y" means "skip n bytes, then use bits
x through y", and indeed a boolean would commonly use a single
bit.  Whether it is initialized depends not on the
representation clause, but on the record specification.  Your
spec does not specify any initial values, so they could be
anything.  If instead you had, for instance,
    Parity_Error : BOOLEAN := False;
then the Parity_Error field of a Receiver_Buffer would
be initialized to False.  Similarly for the other fields.

  RX_Buffer :  Receiver_Buffer; for RX_Buffer use at
Memory_Address(16#00FF_0000#); suggests that you have some
hardware, or at least an external interrupt handler or
something, that is putting the RX_Buffer data at a particular
memory address.  Specifying initial values for its fields
might be misleading if the hardware is going to control what's
there.  If the address is memory mapped IO, then specifying
initial values will clearly require that the program write
them to that address, which might cause some undesirable IO
operation to occur.  So think hard whether you actually want
your program to set initial values in RX_Buffer.
   BTW, the "use at" is also old-fashioned.  The newer way
would be
  for RX_Buffer'address use Memory_Address(16#00FF_0000#);

  Since the RX_Buffer is at a specified address, it doesn't
really need a separate alignment clause.  (I wonder what your
compiler would do if you said even alignment and then gave an
odd memory address?)  If that's the only Receiver_Buffer where
alignment matters, then its alignment clause appears quite
unnecessary.

  You really, really, ought to have an Ada reference or text.
You could look these things up faster than you can write a
question, and you'll most likely find a clearer answer.  If
you don't one handy, search at www.AdaPower.com




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-03-02  0:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <38BDB743.BB95E16F@interact.net.au>
2000-03-02  0:00 ` Receiver Buffer Representation Clause (novice question) tmoran

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox