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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7722b78486dfd336 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Zero_Fill pragma, other proposition Date: Wed, 21 Jul 2004 16:07:40 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.uni-berlin.de u7jOJxatSmO/E11HwhJyVwonItRrvsFd3Oh61z/+ZtkMk0TPE= User-Agent: Opera M2/7.51 (Win32, build 3798) Xref: g2news1.google.com comp.lang.ada:2319 Date: 2004-07-21T16:07:40+01:00 List-Id: On Wed, 21 Jul 2004 11:20:32 +0200, wrote: > type Message is record > Id : Message_Id; > Data : Byte_Stream; > end record; > > for Message use record > Id at 0 range 0 .. 7; > Spare at 0 range 8 .. 15 := 0; --> ADDED > Data at 0 range 16 .. 65; > end record; A slight variation on this idea is: type Message is record Id : Message_Id; Data : Byte_Stream; end record; for Message use record Id at 0 range 0 .. 7; all 0 at 0 range 8 .. 15; Data at 0 range 16 .. 65; end record; However, this requires a change to the language syntax. I'm sure that it is too late to make any such drastic proposals for the Amendment now. It might also be argued that this syntax confuses record layout issues with initialisation issues (but I think that would be too finicky). I had intended to implement a Zero_Fill pragma for the AdaOS compiler (ECLAT), regardless of whether this pragma were accepted for the Amendment. It would then be an implementation defined pragma, and not in violation of the standard. I must add, if we are going to suggest alterations to the record representation clause, there are at a couple of other things it would be 'nice to have'. Quite often a single scalar component is broken into two or more pieces in a machine representation; it would be nice to have a way to tell the compiler where these pieces are, and to stitch them together when reading the component and split them up when updating it. A good example is the 32-bit segment descriptor layout of the IA-32, where the offset field is broken into three separate pieces. Quite often a component fits exactly into one storage element. It is then pointless (if harmless) to have to express the 'range ...' part. For example: -- assuming System.Storage_Unit = 16 type Call_Gate_Descriptor is record Num_Param: Parameter_Count; DPL: Privilege_Level; Present: Boolean; Segment: Selector_Number; Offset: Offset_32; end record; type Call_Gate_Descriptor is record Num_Param at 2 range 0 .. 4; all 0 at 2 range 5 .. 9; all 1 at 2 range 10 .. 11; all 0 at 2 range 12 .. 12; DPL at 2 range 13 .. 14; Present at 2 range 15 .. 15; Segment at 1 range 0 .. 15; Offset (range 0 .. 15 => at 0 range 0 .. 15, range 16 .. 31 => at 3 range 0 .. 15); end record; for Call_Gate_Descriptor'Size use 64; This is, of course, a realistic example (taken from the IA-32). Assuming a storage element is 16 bits, it would be nice if the three occurrances of "range 0 .. 15" in this example could be omitted. I rather cheekily feel that I could get away with putting these extensions into the compiler, since they are compatible with standard Ada, and I can't see anyone actually complaining (unless they write something in ECLAT and then try to port it). I feel this is the sort of facility that some Ada compilers should support. I can see that imposing it on all compilers is likely to be seen as draconian. It is said that the Ada 95 revision is what put the final nail in the coffin of DEC Ada. The above doesn't solve the problem of telling the compiler to zero out the gaps between components in an array. -- Nick Roberts