* Rep-spec question @ 1999-11-10 0:00 Joe Wisniewski 1999-11-10 0:00 ` Ted Dennison ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Joe Wisniewski @ 1999-11-10 0:00 UTC (permalink / raw) Given the following: type Rec is b : boolean; end record; for rec use record b at 0 range 0..63; end record; for rec'size use 64; can any assumptions be made as to where the byte(s) representing the boolean are stored? Joe Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 Rep-spec question Joe Wisniewski @ 1999-11-10 0:00 ` Ted Dennison 1999-11-10 0:00 ` Joe Wisniewski 1999-11-10 0:00 ` Robert A Duff 1999-11-10 0:00 ` Tucker Taft 2 siblings, 1 reply; 16+ messages in thread From: Ted Dennison @ 1999-11-10 0:00 UTC (permalink / raw) In article <80ck3b$deu$1@nnrp1.deja.com>, Joe Wisniewski <wisniew@acm.org> wrote: > Given the following: > > type Rec is > b : boolean; > end record; > > for rec use record > b at 0 range 0..63; > end record; > for rec'size use 64; > > can any assumptions be made as to where the > byte(s) representing the boolean are stored? Not unless your compiler docs say so. I'm not even sure that is required to compile. If you want to put the boolean in a specific place, try using something like: for rec use record b at 1 range 5..5; -- 6th bit of second byte end record; for rec'size use 64; (This isn't guaranteed to compile either) -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 ` Ted Dennison @ 1999-11-10 0:00 ` Joe Wisniewski 1999-11-10 0:00 ` Ted Dennison 0 siblings, 1 reply; 16+ messages in thread From: Joe Wisniewski @ 1999-11-10 0:00 UTC (permalink / raw) In article <80clia$ein$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > In article <80ck3b$deu$1@nnrp1.deja.com>, > Joe Wisniewski <wisniew@acm.org> wrote: > > Given the following: > > > > type Rec is > > b : boolean; > > end record; > > > > for rec use record > > b at 0 range 0..63; > > end record; > > for rec'size use 64; > > > > can any assumptions be made as to where the > > byte(s) representing the boolean are stored? > > Not unless your compiler docs say so. I'm not even sure that is required > to compile. > > If you want to put the boolean in a specific place, try using something > like: > > for rec use record > b at 1 range 5..5; -- 6th bit of second byte > end record; > for rec'size use 64; > > (This isn't guaranteed to compile either) You are not saying that is required NOT to compile. Correct? Joe > > -- > T.E.D. > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 ` Joe Wisniewski @ 1999-11-10 0:00 ` Ted Dennison 1999-11-11 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Ted Dennison @ 1999-11-10 0:00 UTC (permalink / raw) In article <80clr0$etf$1@nnrp1.deja.com>, Joe Wisniewski <wisniew@acm.org> wrote: > In article <80clia$ein$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > for rec'size use 64; > > > > (This isn't guaranteed to compile either) > > You are not saying that is required NOT to compile. > Correct? Yes!..er..No!..er, I'm not sure what your question really was. :-) At the risk of opening the "implementation advice" can of worms again, the size clause above is not required to be accepted by an implementation. But if your vendor follows the recomendation in the implementaion advice (which most should), then it will compile. The implementation advice in question (from 13.3) is: --- The recommended level of support for the Size attribute of objects is: A Size clause should be supported for an object if the specified Size is at least as large as its subtype's Size, and corresponds to a size in storage elements that is a multiple of the object's Alignment (if the Alignment is nonzero). --- There's also the minor issue that a "storage element" is not required to be 1 byte. But the vast majority of them (if not all) will be. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 ` Ted Dennison @ 1999-11-11 0:00 ` Robert Dewar 1999-11-11 0:00 ` Ted Dennison 1999-11-11 0:00 ` Keith Thompson 1999-11-11 0:00 ` Robert A Duff 2 siblings, 1 reply; 16+ messages in thread From: Robert Dewar @ 1999-11-11 0:00 UTC (permalink / raw) In article <80cqb7$if9$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > At the risk of opening the "implementation advice" can of > worms again, > the size clause above is not required to be accepted by an > implementation. But if your vendor follows the recomendation in the > implementaion advice (which most should), then it will compile. The > implementation advice in question (from 13.3) is: Ted, please get this right in future :-) We just got through discussing this. Implementation advice in chapter 13 becomes *REQUIREMENTS* if the systems programming annex is implemented. Since any serious compiler implements this annex, this is in fact a requirement! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-11 0:00 ` Robert Dewar @ 1999-11-11 0:00 ` Ted Dennison 1999-11-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 16+ messages in thread From: Ted Dennison @ 1999-11-11 0:00 UTC (permalink / raw) In article <80djt4$4jt$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <80cqb7$if9$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > At the risk of opening the "implementation advice" can of > > worms again, > > the size clause above is not required to be accepted by an > > implementation. But if your vendor follows the recomendation > in the > > implementaion advice (which most should), then it will > compile. The > > implementation advice in question (from 13.3) is: > > Ted, please get this right in future :-) We just got through Say it enough and I might get it. :-) But an even stronger statement than you made, such as "this works on all known compilers", is not the same as "this is guaranteed to work on all compilers". It is not. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-11 0:00 ` Ted Dennison @ 1999-11-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1999-11-12 0:00 UTC (permalink / raw) In article <80ek3j$qnq$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > But an even stronger statement than you made, such as "this > works on all > known compilers", is not the same as "this is guaranteed to work on all > compilers". It is not. Sorry, I don't understand. You obviously do NOT use rep clauses on a compiler that does not claim annex C conformance. Noting that rep clauses are not guaranteed to be implemented in the absence of annex C is of course true, but completely uninteresting, since no one in practice who knows what they are doing even a little bit would make the mistake of thinking otherwise. In practice, all compilers that are intended for use in environments where rep clauses make sense implement Annex C in any case, so in practice, there is no problem here. Yes, I suppose someone could be sufficiently unaware that they would use a compiler that does not implement annex C and be suprised, but that's just a special case of people not knowing the language, and being surprised by their lack of knowledge. If you are saying that you have a compiler that claims annex C compliance and does not implement all the recommended clauses in chapter 13, then the compiler is non-conforming, or more pragmatically, you have found a bug in the compiler and should report it. It for sure is the case in Ada 95 that optional annexes are optional, and (how amazing) compilers that do not implement optional annexes cannot be expected by users to provide the facilities in those annexes! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 ` Ted Dennison 1999-11-11 0:00 ` Robert Dewar @ 1999-11-11 0:00 ` Keith Thompson 1999-11-12 0:00 ` Robert A Duff ` (2 more replies) 1999-11-11 0:00 ` Robert A Duff 2 siblings, 3 replies; 16+ messages in thread From: Keith Thompson @ 1999-11-11 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > In article <80clr0$etf$1@nnrp1.deja.com>, [...] > The implementation advice in question (from 13.3) is: > > --- > The recommended level of support for the Size attribute of objects is: > > A Size clause should be supported for an object if the specified Size is > at least as large as its subtype's Size, and corresponds to a size in > storage elements that is a multiple of the object's Alignment (if the > Alignment is nonzero). > --- Which raises some interesting questions. This implies that an implementation that follows the advice must accept the following: N : Integer; for N'Size use 1_000_000 * Integer'Size; (assuming sufficient memory). Where do the significant bits go? What if N is aliased, and you create a pointer to it (think about endianness)? If you pass N as a parameter, how many bits are actually passed? I think there's an AI that modifies the above advice. As I recall, it says that an implementation needn't accept a size clause for an integer object if the specified size is bigger than the size of the largest supported integer type. (This could still make things interesting if, for example, Short_Integer is 16 bits, and you declare a Short_Integer object specified to be 32 or 64 bits, especially on a big-endian machine.) I'm too lazy to look up the AI; perhaps someone else can do so. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> "Oh my gosh! You are SO ahead of your time!" -- anon. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-11 0:00 ` Keith Thompson @ 1999-11-12 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert Dewar 1999-11-12 0:00 ` Nick Roberts 2 siblings, 0 replies; 16+ messages in thread From: Robert A Duff @ 1999-11-12 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: >...I'm too lazy to look up the AI; perhaps someone > else can do so. AI's 51 and 109 talk about 'Size and 'Alignment. As far as I know, they are not yet approved by the ARG. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-11 0:00 ` Keith Thompson 1999-11-12 0:00 ` Robert A Duff @ 1999-11-12 0:00 ` Robert Dewar 1999-11-12 0:00 ` Nick Roberts 2 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1999-11-12 0:00 UTC (permalink / raw) In article <yecogd0pmc2.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > Which raises some interesting questions. This implies that an > implementation that follows the advice must accept the > following: > > N : Integer; > for N'Size use 1_000_000 * Integer'Size; > > (assuming sufficient memory). GNAT says: 1. package xxx is 2. N : Integer; 3. for N'Size use 1_000_000 * Integer'Size; | >>> warning: 31999936 bits of "N" unused 4. end xxx; > Where do the significant bits go? If you care about this, don't use a silly declaration like the one above :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-11 0:00 ` Keith Thompson 1999-11-12 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert Dewar @ 1999-11-12 0:00 ` Nick Roberts 2 siblings, 0 replies; 16+ messages in thread From: Nick Roberts @ 1999-11-12 0:00 UTC (permalink / raw) Keith Thompson wrote: > ... > I think there's an AI that modifies the above advice. > ... It's AI95-00051/08 (98-04-01), which is binding. I won't quote the entire thing wholesale, but in the middle it says: ----- 3. For a non-aliased object, the implementation should support a Size clause specifying a Size up to (at least) the following values, which depends on the class of the object. (Similarly, the implementation should support a Component_Size clause and a record_representation_clause specifying the Size of a component up to (at least) these values, depending on the class of the component.) - For a signed integer, up to the Size of the largest signed integer type supported by the implementation. - For a modular integer, up to the Size of the largest modular type supported by the implementation. - For an object of an enumerated type, up to the Size of the largest signed integer type, or the largest modular type, whichever is smaller. For fixed point, floating point, access, and composite objects, the implementation need not support any Size other than what would be chosen by default. In the discrete case, any extra bits are set to appropriate values when assigning to the object whose Size has been specified; for example, the value being assigned should be zero-extended or sign-extended as appropriate. When reading from the object, any extra bits may be ignored. ----- Which I think more or less clarifies the question. -- Nick Roberts Computer Consultant (UK) http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 ` Ted Dennison 1999-11-11 0:00 ` Robert Dewar 1999-11-11 0:00 ` Keith Thompson @ 1999-11-11 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert Dewar 2 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 1999-11-11 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > There's also the minor issue that a "storage element" is not required to > be 1 byte. But the vast majority of them (if not all) will be. ^^^^^^^^^^ The definition of "storage element" is of course determined by the hardware, and most hardware these days has 8-bit bytes, but not all. For example, the ADI SHARC chip has 32-bit storage elements, so of course Averstar's SHARC Ada compiler reflects that. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-11 0:00 ` Robert A Duff @ 1999-11-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1999-11-12 0:00 UTC (permalink / raw) In article <wccvh7913dw.fsf@world.std.com>, Ted Dennison <dennison@telepath.com> writes: > > There's also the minor issue that a "storage element" is not > required to be 1 byte. But the vast majority of them (if not > all) will be. Ted, you worry furiously (:-) that compilers might not implement annex C because it is not required (when in practice in all relevant cases, compilers DO implement annex C), yet you make the suggestion ("if not all") that all compilers in practice have storage_unit set to 8, which is most certainly not the case (check the validated compilers list and VSR's, there is more than one counter-example). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 Rep-spec question Joe Wisniewski 1999-11-10 0:00 ` Ted Dennison @ 1999-11-10 0:00 ` Robert A Duff 1999-11-10 0:00 ` Tucker Taft 2 siblings, 0 replies; 16+ messages in thread From: Robert A Duff @ 1999-11-10 0:00 UTC (permalink / raw) Joe Wisniewski <wisniew@acm.org> writes: > Given the following: > > type Rec is > b : boolean; > end record; > > for rec use record > b at 0 range 0..63; > end record; > for rec'size use 64; > > can any assumptions be made as to where the > byte(s) representing the boolean are stored? No. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 Rep-spec question Joe Wisniewski 1999-11-10 0:00 ` Ted Dennison 1999-11-10 0:00 ` Robert A Duff @ 1999-11-10 0:00 ` Tucker Taft 1999-11-11 0:00 ` Robert A Duff 2 siblings, 1 reply; 16+ messages in thread From: Tucker Taft @ 1999-11-10 0:00 UTC (permalink / raw) Joe Wisniewski wrote: > > Given the following: > > type Rec is > b : boolean; > end record; > > for rec use record > b at 0 range 0..63; > end record; > for rec'size use 64; > > can any assumptions be made as to where the > byte(s) representing the boolean are stored? You can pretty safely assume that an enumeration value is stored in the low-order bits of the 64-bit component you have specified. I would expect this only to be supported on implementations that support 64-bit integers. Another interesting question is what are the representations of False and True. I suspect that on some targets, True is all ones, while False is zero. On such a target, the answer to your question is "any byte". ;-) > > Joe -Tuck -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rep-spec question 1999-11-10 0:00 ` Tucker Taft @ 1999-11-11 0:00 ` Robert A Duff 0 siblings, 0 replies; 16+ messages in thread From: Robert A Duff @ 1999-11-11 0:00 UTC (permalink / raw) Tucker Taft <stt@averstar.com> writes: > You can pretty safely assume that an enumeration value is stored in > the low-order bits of the 64-bit component you have specified. Right, but where the low-order bits are is determined by endianness. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-11-12 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-10 0:00 Rep-spec question Joe Wisniewski 1999-11-10 0:00 ` Ted Dennison 1999-11-10 0:00 ` Joe Wisniewski 1999-11-10 0:00 ` Ted Dennison 1999-11-11 0:00 ` Robert Dewar 1999-11-11 0:00 ` Ted Dennison 1999-11-12 0:00 ` Robert Dewar 1999-11-11 0:00 ` Keith Thompson 1999-11-12 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert Dewar 1999-11-12 0:00 ` Nick Roberts 1999-11-11 0:00 ` Robert A Duff 1999-11-12 0:00 ` Robert Dewar 1999-11-10 0:00 ` Robert A Duff 1999-11-10 0:00 ` Tucker Taft 1999-11-11 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox