From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,499aecb327172d23 X-Google-Attributes: gid103376,public From: tmoran@bix.com Subject: Re: Receiver Buffer Representation Clause (novice question) Date: 2000/03/02 Message-ID: #1/1 X-Deja-AN: 592038846 References: <38BDB743.BB95E16F@interact.net.au> X-Complaints-To: abuse@pacbell.net X-Trace: news.pacbell.net 951962646 207.214.215.17 (Wed, 01 Mar 2000 18:04:06 PST) Organization: SBC Internet Services NNTP-Posting-Date: Wed, 01 Mar 2000 18:04:06 PST Newsgroups: comp.lang.ada Date: 2000-03-02T00:00:00+00:00 List-Id: >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