* Re: Ada 95 Numerics questions for the experts [not found] <3401C14B.480@gsfc.nasa.gov> @ 1997-08-25 0:00 ` Robert Dewar [not found] ` <dewar.872560585@merv> 1 sibling, 0 replies; 25+ messages in thread From: Robert Dewar @ 1997-08-25 0:00 UTC (permalink / raw) Michael asks <<a) X'model_epsilon b) X'model_small c) something else d) it depends (if so how?) >> the only possible answer is d). You need to figure out exactly what test you need, and then program it. Perhaps an exact equality is appropriate, perhaps using one of the measures related to rounding discrepancies is appropriate, perhaps some entirely different test is appropriate (for example if you are doing Simpon's rule integration, you need to be quite careful about the test for convergence, and a test like model_epsilon will likely be much TOO tight, and will miss the convergence point -- I used to have great fun giving this out as an assignment early on, students sure burned up a lot of CPU time missing the convergence point :-) If the equality is to do with comparing observations from the physical world, then you need to find out how precise these observations are. For example, suppose we are searching a data base of people for a match, and one of the items is the height represented in floating point. A test for equal heights using model_epsilon or anything similar would be ludicrous. Instead we need to get some idea of how accurate the data is, and perhaps 0.5 might be a reasonable tolerance for comparing heights in inches. On the other hand, to repeat an example I have given before, if you are computing square roots using Newton Raphson iteration on a machine with a reasonable floating-point model, iteration to identify may be appropriate. There is no easy answer to your question, you are simply fooling yourself if you think you can replace analysis by a simple rule of the type suggested by (a) or (b) above. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <dewar.872560585@merv>]
[parent not found: <jcreem-2608970711210001@ljd155.sanders.lockheed.com>]
[parent not found: <dewar.872630607@merv>]
[parent not found: <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com>]
* Re: Ada 95 Numerics questions for the experts [not found] ` <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com> @ 1997-08-27 0:00 ` Robert Dewar [not found] ` <jeffrey.m.creem-2808970708260001@ljd155.sanders.lockheed.com> 1997-08-27 0:00 ` David C. Hoos, Sr. 1997-08-30 0:00 ` Robert A Duff 2 siblings, 1 reply; 25+ messages in thread From: Robert Dewar @ 1997-08-27 0:00 UTC (permalink / raw) Jeff says <<GNATs ability to handle rep specs like your example is actually very cool and the first compiler I know of that handles this type of case. The AdaMajic front end is even more limited than not allowing your cool example. Even something like type My_Type is range 0 .. 7; for My_Type'size use 3; type My_Array is array(1 .. 8) of M for My_Array'size use 24; Is not allowed because the element size of My_Arary is less than 8 it rounds to 8 for each element. This can be a real pain at times. While I basically agree with the rational in the LRM for the minimum level of support I think that if a compiler supports the systems programming annex that rep specs like mine above should be required (of course I would think that since it is something I wanted....I'm not biased :)>> Actually DEC Ada 83 handles biased types (the reason we implemented it in GNAT was for DEC Ada 83 conmpatibility). Also, your example is wrong thinking. You cannot (more accurately should not be able to) use a size clause to affect the internal layout of an array. Obviously the default layout for MY_array would be expected to use one byte/element., If you want the packed representation, you must use pragma Pack, and then indeed GNAT will happily pack the 8 elements into 24 bits. The relevant RM quote is RM 13.3(53) 53 A Size clause on a composite subtype should not affect the internal layout of components. GNAT follows this implementation advice. If it were not followed, you can get surprising expensive change of representation conversions happening behind your back as a result of type derivation. It is a continuing problem that, despite similar advice in Ada 83 AI's, some Ada 83 compilers, notably VADS, violate this implementation advice, so oftem we have to tell people to add a pragma Pack. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <jeffrey.m.creem-2808970708260001@ljd155.sanders.lockheed.com>]
* Re: Ada 95 Numerics questions for the experts [not found] ` <jeffrey.m.creem-2808970708260001@ljd155.sanders.lockheed.com> @ 1997-08-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 25+ messages in thread From: Robert Dewar @ 1997-08-28 0:00 UTC (permalink / raw) Jeff said <<do. Since most of my prior experience has been with VADS I never took note of that LRM reference however I still am a fan of the size clause being applied after the pragma pack since if the pack does not pack the elements as tightly as you'd like the size clause gives the compiler an oportunity to complain that it can not fit the structure into the number of bits your have requested.>> Indeed, the confirming size clause is definitely appropriate. In fact consider the example that inspired the thread: type x is range 0 .. 7; for x'size use 3; type r is array (1 .. 8) of x; pragma Pack (r); for r'size use 24; The size clause says here, I *really* want tight packing, the RM allowed expansion to 4 bits is not acceptable. Now your code will be accpted by GNAT that is doing what you want, but rejected by a compiler taking advantage of the RM's permissiveness here. Of course this rejection may mean you have a problem on your hands, but at least you know right away at compile time. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts [not found] ` <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com> 1997-08-27 0:00 ` Robert Dewar @ 1997-08-27 0:00 ` David C. Hoos, Sr. 1997-08-27 0:00 ` Jeff Creem 1997-08-27 0:00 ` Robert Dewar 1997-08-30 0:00 ` Robert A Duff 2 siblings, 2 replies; 25+ messages in thread From: David C. Hoos, Sr. @ 1997-08-27 0:00 UTC (permalink / raw) Just a couple of points, viz.: 1. The DEC Ada compiler for VAXen allowed biased rep clauses, as well. It's gratifying that gnat chose to implement this also. 2. The problem with your packed array example, however, is that what you are asking the compiler to do is to force array elements which are smaller than one byte to straddle byte boundaries. No compiler likes to do this, as far as I know. (Record components straddling byte boundaries, are another matter, and they are handled quite nicely without any ugly source code). Simply using pragma Pack instead of a "for 'size use 24" clause will result in your 8-element x 3-bit array occupying 32 bits, which is not bad at all. Undoubtedly, the extra code required to mask and shift the varying amounts as a function of the array index would substantially exceed the one byte of array size saved. Besides, even if the compiler did give you your 24-bit array, it would probably skip to the next 32-bit boundary for the next object in memory, anyway. Even gnat will not give you a 24-bit array for this case (at least the WinNT version 3.09). David C. Hoos, Sr. Jeff Creem <jeffrey.m.creem@lmco.com> wrote in article <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com>... > In article <dewar.872630607@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > >Jeff says > > > Even something like > > type My_Type is range 0 .. 7; > for My_Type'size use 3; > type My_Array is array(1 .. 8) of M > for My_Array'size use 24; > > > Is not allowed because the element size of My_Arary is less than 8 it > rounds to 8 for each element. This can be a real pain at times. While > I basically agree with the rational in the LRM for the minimum level of > support I think that if a compiler supports the systems programming annex that > rep specs like mine above should be required (of course I would think > that since it is something I wanted....I'm not biased :) > > The cool GNAT rep spec example that robert gave would also be nice but > probably not required. If a compiler does not support the rep specs > like in roberts example the code to work around it is pretty minor, if > it does not support component sizes less than 8 and you really need > them to interface to hardware, the code gets ugly very quickly and > often starts to look like ugly C code. > > > In any case GNAT handles everything I've ever wanted in a rep spec.. Too > bad there is not a supported vxWorks port.. > > Jeff > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-27 0:00 ` David C. Hoos, Sr. @ 1997-08-27 0:00 ` Jeff Creem 1997-08-28 0:00 ` Robert Dewar 1997-08-27 0:00 ` Robert Dewar 1 sibling, 1 reply; 25+ messages in thread From: Jeff Creem @ 1997-08-27 0:00 UTC (permalink / raw) In article <01bcb2f2$b512f700$928871a5@dhoos>, "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote: >Just a couple of points, viz.: > > 1. The DEC Ada compiler for VAXen allowed biased rep clauses, as well. > It's gratifying that gnat chose to implement this also. > > 2. The problem with your packed array example, however, is that what you > are asking the compiler to do is to force array elements which are >smaller than > one byte to straddle byte boundaries. No compiler likes to do this, >as far as I > know. (Record components straddling byte boundaries, are another >matter, and they But VADS, Apex and GNAT all do handle this (essentially) > are handled quite nicely without any ugly source code). > Simply using pragma Pack instead of a "for 'size use 24" clause will >result in your > 8-element x 3-bit array occupying 32 bits, which is not bad at all. > Undoubtedly, the extra code required to mask and shift the varying >amounts as Nope. The AdaMajic front end (Green hills in this case) rounds the components to 8 bits even in the precense of a pragma pack you get a 64 Byte array. > a function of the array index would substantially exceed the one >byte of array > size saved. Besides, even if the compiler did give you your 24-bit >array, it would > probably skip to the next 32-bit boundary for the next object in >memory, anyway. Actually in the real code that the example came from, the array was an element of a record with another field. The total length of the record was then 32 bits. > Even gnat will not give you a 24-bit array for this case (at least >the WinNT version 3.09). > It gives you a 32 bit array (which Is what I would expect) but does allow you to stick it in a record with another 8 bits and have a structure which is a total of 32 bits long.. Again very nice ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-27 0:00 ` Jeff Creem @ 1997-08-28 0:00 ` Robert Dewar 1997-08-28 0:00 ` Jeff Creem 1997-08-29 0:00 ` Tucker Taft 0 siblings, 2 replies; 25+ messages in thread From: Robert Dewar @ 1997-08-28 0:00 UTC (permalink / raw) <<Nope. The AdaMajic front end (Green hills in this case) rounds the components to 8 bits even in the precense of a pragma pack you get a 64 Byte array.>> SOunds like a bug to me, since these compilers say they support annex C, this means that the implementation advice in chapter 13 (13.2(9)) 9 For a packed array type, if the component subtype's Size is less than or equal to the word size, and Component_Size is not specified for the type, Component_Size should be less than or equal to the Size of the component subtype, rounded up to the nearest factor of the word size. which of course becomes a requirement if you claim annex C support. Reading this paragraph, we see that it is OK to round up to 4-bits, but certainly not 8-bits. As I noted before, GNAT does not round up at all, and packs tightly at 3 bits, letting components spill over byte and word boundaries. This is not required by para 9, but is of course consistent with it ("less than or equal"). ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-28 0:00 ` Robert Dewar @ 1997-08-28 0:00 ` Jeff Creem 1997-08-29 0:00 ` Tucker Taft 1 sibling, 0 replies; 25+ messages in thread From: Jeff Creem @ 1997-08-28 0:00 UTC (permalink / raw) In article <dewar.872745692@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >SOunds like a bug to me, since these compilers say they support >annex C, this means that the implementation advice in chapter 13 (13.2(9)) > > 9 For a packed array type, if the component subtype's Size is less > than or equal to the word size, and Component_Size is not > specified for the type, Component_Size should be less than or > equal to the Size of the component subtype, rounded up to the > nearest factor of the word size. > >which of course becomes a requirement if you claim annex C support. > >Reading this paragraph, we see that it is OK to round up to 4-bits, >but certainly not 8-bits. It was a matter of me misreading the error message. It says that the specified compontent size 3 is not a factor of 8, rounding to a factor ... Which of read as rouding to a multiple of 8 (multiple/factor boy I better run back to 2nd grade). Even still I think my original (modified by Robert) comment holds that while the AdaMajic front end meets the requirements of the LRM it does the minimum needed to meet those requirements in most areas (no support for Ada 83 only attributes and pragmas) and limited support (although correct) for rep specs. Jeff ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-28 0:00 ` Robert Dewar 1997-08-28 0:00 ` Jeff Creem @ 1997-08-29 0:00 ` Tucker Taft 1997-08-30 0:00 ` Robert A Duff ` (3 more replies) 1 sibling, 4 replies; 25+ messages in thread From: Tucker Taft @ 1997-08-29 0:00 UTC (permalink / raw) Robert Dewar (dewar@merv.cs.nyu.edu) wrote: : <<Nope. The AdaMajic front end (Green hills in this case) rounds the : components to 8 bits even in the precense of a pragma pack : you get a 64 Byte array.>> : SOunds like a bug to me, since these compilers say they support : annex C, this means that the implementation advice in chapter 13 (13.2(9)) : ... Sounds like a misconception to me. The compiler supports packing to the bit level. It would be helpful if the actual source code that illustrated the problem were posted, because we have never had a bug report relating to an inability to pack. As far as packing to an array of 3-bits per element versus 4-bits per element, we have generally chosen to follow the recommendations of the RM. Going beyond the RM is not always in the customer's interest, as they may have to move to another Ada compiler at some point, and one of the goals of standardization is portability between implementations. For example, we used to support very long source lines, though the actual limit was a bit hard to define. We now support exactly 200 as the maximum length of a line (which is the length guaranteed by the RM), because supporting something like 256 or some other number chosen by us did not seem to be doing the customer a great favor. Of course, if a customer was willing to pay extra to get tighter packing, perhaps in the presence of some special pragma Jam_Packed(xxx), we would be happy to accommodate them (I think this general "disclaimer" applies to ACT as well ;-). However, as mentioned above, we have currently chosen to follow the RM recommendations as closely as possible for the "standard" pragma Pack, and if you find that we don't, please file a bug report. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA P.S. By the way, on our 24-bit-per-storage-unit target, we pack arrays to element sizes of 1, 2, 3, 4, 6, 8, and 12. I remember someone once arguing for a word size of 72 bits on the grounds that it had a lot of factors ;-). ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-29 0:00 ` Tucker Taft @ 1997-08-30 0:00 ` Robert A Duff 1997-08-31 0:00 ` Tom Moran ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-08-30 0:00 UTC (permalink / raw) In article <EFoIvv.JtA.0.-s@inmet.camb.inmet.com>, Tucker Taft <stt@houdini.camb.inmet.com> wrote: >...I remember someone >once arguing for a word size of 72 bits on the grounds that it had >a lot of factors ;-). With a storage element of 9 bits, I presume? I mean the word size pretty much has to be a power-of-2 times the storage element size, right? - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-29 0:00 ` Tucker Taft 1997-08-30 0:00 ` Robert A Duff @ 1997-08-31 0:00 ` Tom Moran 1997-09-01 0:00 ` Robert Dewar 1997-09-01 0:00 ` Robert Dewar 3 siblings, 0 replies; 25+ messages in thread From: Tom Moran @ 1997-08-31 0:00 UTC (permalink / raw) > someone once arguing for a word size of 72 bits on the grounds that it had > a lot of factors 60 has just as many factors and was in fact the word size, as I recall, on the CDC 6600 series. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-29 0:00 ` Tucker Taft 1997-08-30 0:00 ` Robert A Duff 1997-08-31 0:00 ` Tom Moran @ 1997-09-01 0:00 ` Robert Dewar 1997-09-01 0:00 ` Robert Dewar 3 siblings, 0 replies; 25+ messages in thread From: Robert Dewar @ 1997-09-01 0:00 UTC (permalink / raw) Tuck said <<As far as packing to an array of 3-bits per element versus 4-bits per element, we have generally chosen to follow the recommendations of the RM. Going beyond the RM is not always in the customer's interest, as they may have to move to another Ada compiler at some point, and one of the goals of standardization is portability between implementations. >> This is certainly a legitimate goal, but very different from the goal of GNAT which is to be as inclusive as possible, so that it is as easy as possible to move code *from* other compilers *to* GNAT. We have found many customers who need close packing at arbitrary bit sizes (or GNAT would not support it!) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-29 0:00 ` Tucker Taft ` (2 preceding siblings ...) 1997-09-01 0:00 ` Robert Dewar @ 1997-09-01 0:00 ` Robert Dewar 1997-09-02 0:00 ` Robert A Duff ` (2 more replies) 3 siblings, 3 replies; 25+ messages in thread From: Robert Dewar @ 1997-09-01 0:00 UTC (permalink / raw) Tuck said <<As far as packing to an array of 3-bits per element versus 4-bits per element, we have generally chosen to follow the recommendations of the RM. Going beyond the RM is not always in the customer's interest, as they may have to move to another Ada compiler at some point, and one of the goals of standardization is portability between implementations.>> Tuck says "follow the recomendations" here where he means "follow the minimal requirements". There is a big difference. In this particular, case the RM recommendation is that the level of packing (for 3-bit components) result in a component size less than or equal to 4. GNAT chooses 3. Since 3 is (last time I looked) less than or equal to 4, GNAT is not "going beyond" the RM here, it is following the implementation advice of the RM (and this IA is in fact a requirement, given that GNAT supports Annex C). If Tuck had wasnted the RM to recommend that the component size should be exactly 4, he should have written this (although I am not sure others would have agreed it was a good choice, we have seem quite a bit of code that demands close packaing of 3-bit components (both VADS and Alsys at least, supported this feature). Yes, as Tuck says, if your primary concern is that code written for your compiler be easy to move to other compilers, then you implement the minimal lower bound. But if, as in the case of GNAT, your primary goal is to be inclusive, and correctly process code from other existing compilers providing a wide range of functionality that is permitted by the RM, but not required, or recommended against, then you implement the maximum. Note that GNAT whereever possible follows the advice in the RM even if it causes portability troubles. A common example is the following type arr8 is array (1..8) of boolean; for arr8'size use 8; The RM permits the size clause to cause implicit packing, but recommends against it. VADS at least permitted this implicit packing (even though there was an AI that recommended against it). Consequently in GNAT, we reject the above, and require an explicit pragma Pack. The workdaround for existing code here is easy, and the code is arguably clearer with the pragma there in any case. However, if you have code that depends on close packed 3 bit components, you are completely up the creak if your compiler does not support it! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-01 0:00 ` Robert Dewar @ 1997-09-02 0:00 ` Robert A Duff 1997-09-02 0:00 ` Fergus Henderson [not found] ` <mheaney-ya023680000209972104030001@news.ni.net> 2 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-09-02 0:00 UTC (permalink / raw) In article <dewar.873149493@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >Note that GNAT whereever possible follows the advice in the RM even if >it causes portability troubles. A common example is the following > > type arr8 is array (1..8) of boolean; > for arr8'size use 8; > >The RM permits the size clause to cause implicit packing, but recommends >against it. It would be pretty hard for the RM to do anything more than "recommend" here. After all, the compiler is allowed to use 1-bit components all the time (even if that's not a good idea), or to use 1-bit components if the program is compiled on a the first Tuesday of the month (an even worse idea!), or to follow the phase of the moon. Given that, how could the RM do more than "recommend"? >... VADS at least permitted this implicit packing (even though >there was an AI that recommended against it). One can't blame VADS *too* much. The AI appeared after VADS had implemented some particular mechanism. Ada 95 merely codified the AI into the RM. >Consequently in GNAT, we reject the above, and require an explicit pragma >Pack. Or, presumably, a "for arr8'Component_Size use 1;". Good. >... The workdaround for existing code here is easy, and the code is >arguably clearer with the pragma there in any case. > >However, if you have code that depends on close packed 3 bit components, >you are completely up the creak if your compiler does not support it! And, also unfortunately, the RM doesn't nail down what 3-bit components would mean. On a 32-bit machine, it might mean 10 3-bit components per word, with a 2-bit wastage in each word, or it might mean 3-bit components, crossing word boundaries, with no wastage. Sigh. I don't feel *too* bad about that -- other languages with similar features (eg packed arrays in Pascal) are even less specific. - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-01 0:00 ` Robert Dewar 1997-09-02 0:00 ` Robert A Duff @ 1997-09-02 0:00 ` Fergus Henderson [not found] ` <mheaney-ya023680000209972104030001@news.ni.net> 2 siblings, 0 replies; 25+ messages in thread From: Fergus Henderson @ 1997-09-02 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Tuck said > >> Going beyond the RM is not always in the customer's interest, >> as they may have to move to another Ada compiler at some point, and >> one of the goals of standardization is portability between implementations. > >Tuck says "follow the recomendations" here where he means "follow the >minimal requirements". There is a big difference. ... >Yes, as Tuck says, if your primary concern is that code written for your >compiler be easy to move to other compilers, then you implement the >minimal lower bound. But if, as in the case of GNAT, your primary goal >is to be inclusive, and correctly process code from other existing >compilers providing a wide range of functionality that is permitted by >the RM, but not required, or recommended against, then you implement >the maximum. Does GNAT have an option to warn about the use of non-portable constructs such as the ones discussed in this thread? -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <mheaney-ya023680000209972104030001@news.ni.net>]
* Re: Ada 95 Numerics questions for the experts [not found] ` <mheaney-ya023680000209972104030001@news.ni.net> @ 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Matthew Heaney [not found] ` <EFxt94.F5F@world.std.com> 1 sibling, 1 reply; 25+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) Matthew says (responding to me) <<>Note that GNAT whereever possible follows the advice in the RM even if >it causes portability troubles. A common example is the following > > type arr8 is array (1..8) of boolean; > for arr8'size use 8; > >The RM permits the size clause to cause implicit packing, but recommends >against it. VADS at least permitted this implicit packing (even though >there was an AI that recommended against it). > >Consequently in GNAT, we reject the above, and require an explicit pragma >Pack. The workdaround for existing code here is easy, and the code is >arguably clearer with the pragma there in any case. I'm confused: why wouldn't you recommend that T'Component_Size be used, instead of pragma Pack? for arr8'Component_Size use 1; instead of pragma Pack (arr8);>> shrug! for a compiler that implements annex C, these are guaranteed to have identical effect, and in fact one cannot imagine a compiler not supporting pragma Pack for this case. Note that specifying a component_size other than 1,2,4,8 etc. is NOT guaranteed to give a no gaps imlementation even if the implementatoin advice IS followed (see RM 13.3(73)). But back to your example, since both declarations have EXACTLY the same status: a) if the chapter 13 IA is not followed (annex C not supported), then neither declaration is guaranteed to give a no-gaps implementation. b) if the chapter 13 IA is followed (annex C supported), then both declarations are guaranteed to give a no-gaps implementation. So there is really no need to have a preference for one over the other, and I suspect that your preference is based on some misunderstanding of the RM requirements. If you go to non-standard sizes like 3,5,7, then in GNAT, both declarations are still equivalent, up to a component size of 32. But as we have heard, that is not necessarily the case with other Ada 95 compilers. To be specific, consider the example: type x is range 0 .. 7; type r is array (1 .. 10) of x; 1) pragma Pack (r); 2) for r'Component_Size use 3; If you use BOTH these declarations, then they must be either obeyed with close packing or rejected as illegal. If you use 1) without 2), then an implementation supporting annex C must give you a component size of 3 or 4 (assuming typical implementations). The Intermetrics compiler gives 4, GNAT will give 3. (the Intermetrics compiler should reject the combination of both 1) and 2) together, since it does not support this combination) If you use 2) without 1), then even an implementation supporting annex C is completely free to do whatever it wants -- that's probably an oversight, and I would guess that typical implementations will behave the same as if 1) is used without 2). Anyway in this case, GNAT will still pack tightly to 3 bits. I do not know what the Intermetrics compiler will do in this case, since, as I say, the RM places no bounds on what an implementation can do if given a component size without a pack pragma and it is not a factor or a multiple of the word size. Here is the para in question 73 An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_ Sizes, the array should contain no gaps between components. For other Component_Sizes (if supported), the array should contain no gaps between components when packing is also specified; the implementation should forbid this combination in cases where it cannot support a no-gaps representation. So all in all, pragma Pack is stronger than using Component_Size in a compiler implementing annex C, and in a compiler not implementing annex C, there are no requirements at all, except to reject 1) and 2) together if you don't do them right, so perhaps actually the most reliable thing is to always use BOTH declarations, that way they must be obeyed or rejected and if we are talking about 1,2,4 etc, we know exactly what obeyed means. So to be specific: type r is array (1 .. 8) of Boolean; pragma Pack (r); for r'component_size use 1; must either be obeyed with close packing, or rejected, even bvy a compiler that does not say anything about supporting annex C. I find this all quite odd, but that is what the RM, quite clearly, says!!!! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-05 0:00 ` Robert Dewar @ 1997-09-05 0:00 ` Matthew Heaney 1997-09-08 0:00 ` Robert A Duff 0 siblings, 1 reply; 25+ messages in thread From: Matthew Heaney @ 1997-09-05 0:00 UTC (permalink / raw) In article <dewar.873504953@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > For > other Component_Sizes (if supported), the array should contain no > gaps between components when packing is also specified; the > implementation should forbid this combination in cases where it > cannot support a no-gaps representation. That about explains it. I wasn't aware that packing and component_size clauses were intended to be used together. I assumed that by specifying the component size to be 3, that that meant the component size should be 3. How naive of me! -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-05 0:00 ` Matthew Heaney @ 1997-09-08 0:00 ` Robert A Duff 1997-09-08 0:00 ` Matthew Heaney 0 siblings, 1 reply; 25+ messages in thread From: Robert A Duff @ 1997-09-08 0:00 UTC (permalink / raw) In article <mheaney-ya023680000509972116500001@news.ni.net>, Matthew Heaney <mheaney@ni.net> wrote: >That about explains it. I wasn't aware that packing and component_size >clauses were intended to be used together. I assumed that by specifying >the component size to be 3, that that meant the component size should be 3. >How naive of me! Well, it should, but what should 'Component_Size be for an array of 3-bit components, where the implementation puts 10 of them in each word, and leaves a gap of 2-bits at the end of each word? (I'm assuming 32-bit words, here.) If there's a "gap" of 1 bit between each 3-bit component, then I don't think that should be called a "gap" at all -- we should call that situation "4-bit components". - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-08 0:00 ` Robert A Duff @ 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Robert A Duff 0 siblings, 1 reply; 25+ messages in thread From: Matthew Heaney @ 1997-09-08 0:00 UTC (permalink / raw) In article <EG7FIq.Ivw@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: >>I assumed that by specifying >>the component size to be 3, that that meant the component size should be 3. >>How naive of me! > >Well, it should, I'm confused by this answer. What does you mean when you say that the component size "should" be 3? Is it 3, or isn't it? Assuming conformance to Annex C, can a compiler legally compile the declaration (that doesn't have a pragma Pack), and _not_ give the array a component size of 3? >but what should 'Component_Size be for an array of >3-bit components, where the implementation puts 10 of them in each word, >and leaves a gap of 2-bits at the end of each word? (I'm assuming >32-bit words, here.) > >If there's a "gap" of 1 bit between each 3-bit component, then I don't >think that should be called a "gap" at all -- we should call that >situation "4-bit components". Again, I am confused by your answer. What does it mean to say that "I don't think" it should be called a gap, or we "should" call the situtation 4-bit components? Doesn't the RM define the meaning of the term "gap"? What was the intent of the RM, if it doesn't define gap? Yes or no: According to the RM, is dense, no-gaps-between-the-components packing _implied_ by the specification of a Component_Size clause? Or is pragma Pack always required as part a declaration? Robert says that both a pragma Pack and a component size clause are required to be given in order to guarantee that component size. Is this the intent of the RM? Or is he reading the RM too literally? (I should rephrase that last question: Is there an error in the RM, such that its statements about also requiring a pragma Pack, are ambiguous?) -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-08 0:00 ` Matthew Heaney @ 1997-09-09 0:00 ` Robert A Duff 0 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-09-09 0:00 UTC (permalink / raw) In article <mheaney-ya023680000809972047000001@news.ni.net>, Matthew Heaney <mheaney@ni.net> wrote: >In article <EG7FIq.Ivw@world.std.com>, bobduff@world.std.com (Robert A >Duff) wrote: > >>>I assumed that by specifying >>>the component size to be 3, that that meant the component size should be 3. >>>How naive of me! >> >>Well, it should, > >I'm confused by this answer. What does you mean when you say that the >component size "should" be 3? You tell me. You're the one who used the word "should". You said "... should be 3", and I agreed, yes it should. ;-) >...Is it 3, or isn't it? Assuming conformance >to Annex C, can a compiler legally compile the declaration (that doesn't >have a pragma Pack), and _not_ give the array a component size of 3? Yes. But there's a case where it's not clear what it *means* for the component size to be 3: >>but what should 'Component_Size be for an array of >>3-bit components, where the implementation puts 10 of them in each word, >>and leaves a gap of 2-bits at the end of each word? (I'm assuming >>32-bit words, here.) So, what's *your* answer to the above 2-bit gap example? Imagine that there's no rep clauses, but the implementation just happens to choose the above representation. Now what does T'Component_Size return? The RM's answer is that these components are 3 bits. They're certainly not 4 bits. And we don't have any way of imagining that they're 3.2 bits (that is 32 bits per word, divided by 10 components per word), since Component_Size is an integer number. Sometimes I feel like chapter 13 is like one of those showers where a single knob controls both the temperature and the water flow, so you can have a small amount of cold water, or a lot of hot water, but you can't have a trickle of hot water. I would prefer to have orthogonal controls. >>If there's a "gap" of 1 bit between each 3-bit component, then I don't >>think that should be called a "gap" at all -- we should call that >>situation "4-bit components". > >Again, I am confused by your answer. What does it mean to say that "I >don't think" it should be called a gap, or we "should" call the situtation >4-bit components? Doesn't the RM define the meaning of the term "gap"? >What was the intent of the RM, if it doesn't define gap? The RM tries to define "gap" (in 13.1(7), with lots of AARM verbiage explaining what we thought we meant), but like lots of things in chap 13, the term "gap" is at the wrong semantic level, so definitions are sometimes unclear or meaningless. The "intent" is as I stated above -- if there are 8 components per 32-bit word, that's considered 4-bit components, not 3-bit components with 1-bit gaps in between each one. RM83 didn't define "gap" at all, but the common usage made it much harder to nail down the meaning of rep clauses, since the compiler could pretend to insert bogus gaps all over the place. The intent of 13.1(7) was, in part, to prevent that. >Yes or no: According to the RM, is dense, no-gaps-between-the-components >packing _implied_ by the specification of a Component_Size clause? Or is >pragma Pack always required as part a declaration? The intent is that 'Component_Size = 3 might mean full packing, or might mean a single 2-bit gap at the end of each word, and pragma Pack forces the former (if supported at all). But Robert has pointed out that 13.3(73) also seems to allow *more* than a 2-bit gap per word, which was obviously not intended. (I say "obviously", because it would make "for T'Component_Size use 3;" completely useless. See also 13.3(73.a) for a hint as to what was meant.) Note that if an implementation tried to take Robert's literal reading, and say that 3-bits causes a 1-bit gap between each component, then it would have to mask out that bit on loads, as required by 13.1(7) -- at least if you think 13.1(7) means anything at all. But no implementation would do *that*, so I think you're safe assuming the intent will hold. I really think you have to read chap 13 in a "friendly" way, since it's not (and can't be) quite as precise as the rest of the RM. I mean, consider a strict reading wrt: type Color is (Red, Yellow, Green); for Color use (Red => 100, Yellow => 205, Green => 320); Suppose the implementation says, "Yes, we represent Red as 100, but we're free to represent integer numbers however we like, and we choose (in this case) to represent 100 as the bit pattern consisting of all zeros. Likewise, we represent 205 as ...0001, and 320 as ...0010." Nothing in the RM forbids that, when read strictly, but it would totally negate the point of the rep clause. The ACVC is quite correct to forbid the above interpretation, even though it takes a "nudge, nudge, you know what we mean" sort of reading of chap 13. >Robert says that both a pragma Pack and a component size clause are >required to be given in order to guarantee that component size. Is this >the intent of the RM? Or is he reading the RM too literally? (I should >rephrase that last question: Is there an error in the RM, such that its >statements about also requiring a pragma Pack, are ambiguous?) - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <EFxt94.F5F@world.std.com>]
* Re: Ada 95 Numerics questions for the experts [not found] ` <EFxt94.F5F@world.std.com> @ 1997-09-06 0:00 ` Robert Dewar 1997-09-08 0:00 ` Robert A Duff 0 siblings, 1 reply; 25+ messages in thread From: Robert Dewar @ 1997-09-06 0:00 UTC (permalink / raw) Bob said <<It depends what you're trying to do. If you really care about the exact size of the components (e.g. because you're interfacing to external hardware or software), then use a Component_Size clause. If you just want to squeeze the thing down to a reasonably small size, because you know that will be more efficient, then pragma Pack is more appropriate. In the case mentioned here, where the components will fit in 1 bit, it won't actually make any difference, that is: >for arr8'Component_Size use 1; > >instead of > >pragma Pack (arr8); both of the above will result in arr8'Component_Size = 1, and arr8'Size = 8.>> This is surpringly wrong. Bob, you must go read the RM, it was written by this clever fellow Bob Duff, and will tell you the TRUTH :-) :-) First, in the absence of implementation of annex C, neither declaration will guarantee close packing. In the presence of close packing, it is true that both will guarantee this, but given the two declarations pragma Pack (array_type); for array_type'component_size use array_component_type'size; it is never the case that, as suggested by Bob Duff's quote, that the second form is somehow more exact than the first. I find this odd, but then I did not write the RM! There are two issues to consider 1. Is annex C implemented? If not, then either of these declarations on their own may have no effect. 2. If annex C is implemented, then is the component size or size of the component a factor or multiple of the word size? if yes, then either of these two declarations will do the job if NOT, then pragma Pack is stronger because it will do no worse than go up to the next factor (e.g. 3 moved to 4), but a component size clause can be completely ignored, since there is no requirement to implement component clauses in this case (technically what you do is to accept the component claiuse, but then implement allowed gaps), Note that using BOTH clauses together is useful, since in this case, the RM guarantees that a compiler that accepts the clauses, even if it does not implment Annex C, MUSt do the right thing. Odd eh? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-06 0:00 ` Robert Dewar @ 1997-09-08 0:00 ` Robert A Duff 1997-09-08 0:00 ` Matthew Heaney 0 siblings, 1 reply; 25+ messages in thread From: Robert A Duff @ 1997-09-08 0:00 UTC (permalink / raw) I said: ><<It depends what you're trying to do. If you really care about the exact >size of the components (e.g. because you're interfacing to external >hardware or software), then use a Component_Size clause. If you just >want to squeeze the thing down to a reasonably small size, because you >know that will be more efficient, then pragma Pack is more appropriate. In article <dewar.873592294@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >This is surpringly wrong. Bob, you must go read the RM, it was written >by this clever fellow Bob Duff, and will tell you the TRUTH :-) :-) Sorry, I should have clarified that my advice was stylistic. It doesn't matter what the RM says -- stylistically, Pack means "minimize space, more or less", and "for T'Component_Size use N" means, "I want exactly N-bit components". Surely Pack had that feeling in Ada 83, and the addition of requirements in Ada 95 was merely a response to implementations that failed to do *anything* to minimize space, so we had to specify *how much* (as a minimum) space has to be minimized. Besides, the allegedly "clever" Bob Duff who wrote that portion of the RM is no more. I no longer spend 24-hours a day thinking about language issues. ;-) >First, in the absence of implementation of annex C, neither declaration >will guarantee close packing. Yeah, yeah, I know that all bets are off if the impl doesn't support Annex C. - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-08 0:00 ` Robert A Duff @ 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Robert A Duff 0 siblings, 1 reply; 25+ messages in thread From: Matthew Heaney @ 1997-09-08 0:00 UTC (permalink / raw) In article <EG7FA3.EKK@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: >Sorry, I should have clarified that my advice was stylistic. It doesn't >matter what the RM says -- stylistically, Pack means "minimize space, >more or less", and "for T'Component_Size use N" means, "I want exactly >N-bit components". Surely Pack had that feeling in Ada 83, and the >addition of requirements in Ada 95 was merely a response to >implementations that failed to do *anything* to minimize space, so we >had to specify *how much* (as a minimum) space has to be minimized. Assume conformance to Annex C, and I compile this declaration: type T is range 0 .. 7; type A is array (Integer range 1 .. 10) of T; for A'Component_Size use 3; Yes or no: if the implementation doesn't support a component size of 3, can it still compile this declaration, giving A some other component size? From what Robert Dewar said, it seems that, if we interpret the RM literally, one must also include a pragma Pack, in order to get the compiler to reject the declaration (if it doesn't support a component size of 3). I ask because there might be a bug in the RM, and that the intentation of the RM is that the compiler reject the declaration above, in spite of the fact that there is no pragma Pack, if it doesn't support that component size. So, Bob Duff, writer of the RM, answer yes or no: is pragma Pack required in the example above, in order to guarantee that the component size really is 3? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-09-08 0:00 ` Matthew Heaney @ 1997-09-09 0:00 ` Robert A Duff 0 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-09-09 0:00 UTC (permalink / raw) In article <mheaney-ya023680000809972030110001@news.ni.net>, Matthew Heaney <mheaney@ni.net> wrote: >So, Bob Duff, writer of the RM, answer yes or no: is pragma Pack required >in the example above, in order to guarantee that the component size really >is 3? First define what you mean by "the component size really is 3", and then I'll answer the question. ;-) (I'm not sure how I got promoted from RM co-author to RM author.) By the way, note that the PDP-10 had hardware support for the 10 3-bit components per 33-bit word, with a 2-bit gap at the end of each word, and it would make no sense to do tighter packing on that machine. (Well, it was actually a 36-bit word, but you know what I mean -- something like 5 7-bit components per 36-bit word, with a 1-bit gap, which was the only sensible representation of Ada 83's String type. Note that String has a pragma Pack.) - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts 1997-08-27 0:00 ` David C. Hoos, Sr. 1997-08-27 0:00 ` Jeff Creem @ 1997-08-27 0:00 ` Robert Dewar 1 sibling, 0 replies; 25+ messages in thread From: Robert Dewar @ 1997-08-27 0:00 UTC (permalink / raw) David said (with nasty lines > 80 chars :-) 2. The problem with your packed array example, however, is that what you are asking the compiler to do is to force array elements which are smaller than one byte to straddle byte boundaries. No compiler likes to do this, as far as I know. (Record components straddling byte boundaries, are another matter, and they are handled quite nicely without any ugly source code). Simply using pragma Pack instead of a "for 'size use 24" clause will result in your 8-element x 3-bit array occupying 32 bits, which is not bad at all. Undoubtedly, the extra code required to mask and shift the varying amounts as a function of the array index would substantially exceed the one byte of array size saved. Besides, even if the compiler did give you your 24-bit array, it would probably skip to the next 32-bit boundary for the next object in memory, anyway. Even gnat will not give you a 24-bit array for this case (at least the WinNT version 3.09). GNAT most certainly allows elements to straddle storage boundaries, and will tightly pack any component size up to 32 bits. The following is quite acceptable to GNAT: package j is type x is range 1 .. 5; for x'size use 3; type r is array (0 .. 7) of x; pragma Pack (r); for r'size use 24; type m is array (1 .. 10) of r; pragma pack (m); for m'size use 240; end j; ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Ada 95 Numerics questions for the experts [not found] ` <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com> 1997-08-27 0:00 ` Robert Dewar 1997-08-27 0:00 ` David C. Hoos, Sr. @ 1997-08-30 0:00 ` Robert A Duff 2 siblings, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-08-30 0:00 UTC (permalink / raw) In article <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com>, Jeff Creem <jeffrey.m.creem@lmco.com> wrote: >...The AdaMajic >front end is even more limited than not allowing your cool example. >Even something like > >type My_Type is range 0 .. 7; >for My_Type'size use 3; >type My_Array is array(1 .. 8) of M >for My_Array'size use 24; > >Is not allowed because the element size of My_Arary is less than 8 it >rounds to 8 for each element. Any compiler that supports the above is broken (assuming a typical 32-bit machine). I doubt if either GNAT or AdaMagic support it (can you show the exact code you compiled on both compilers?). A Size clause does not control the internal layout of components. Instead, you should use "for My_Array'Component_Size use 3;" or "for My_Array'Component_Size use 4;" or "pragma Pack(My_Array);". Assuming a typical 32-bit machine, the compiler must support 4-bit components (if it claims to support the SP annex), and it *might* support 3-bit components -- this applies to both Pack and Component_Size. Component_Size is for when you care about the exact size, whereas Pack is for when you want the compiler to minimize space, but don't particularly care about (in this case) 3 vs. 4. For a record with 8 3-bit components, on the other hand, the compiler must support 3-bit packing. Perhaps we should have required the same for arrays that fit in a word. Note that "for My_Type'size use 3;" is redundant -- My_Type'Size = 3 by default. You can put in the Size clause just to get a warm comfy feeling that the compiler agrees with you on the size, if you like, but it's not strictly necessary. - Bob ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~1997-09-09 0:00 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3401C14B.480@gsfc.nasa.gov> 1997-08-25 0:00 ` Ada 95 Numerics questions for the experts Robert Dewar [not found] ` <dewar.872560585@merv> [not found] ` <jcreem-2608970711210001@ljd155.sanders.lockheed.com> [not found] ` <dewar.872630607@merv> [not found] ` <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com> 1997-08-27 0:00 ` Robert Dewar [not found] ` <jeffrey.m.creem-2808970708260001@ljd155.sanders.lockheed.com> 1997-08-28 0:00 ` Robert Dewar 1997-08-27 0:00 ` David C. Hoos, Sr. 1997-08-27 0:00 ` Jeff Creem 1997-08-28 0:00 ` Robert Dewar 1997-08-28 0:00 ` Jeff Creem 1997-08-29 0:00 ` Tucker Taft 1997-08-30 0:00 ` Robert A Duff 1997-08-31 0:00 ` Tom Moran 1997-09-01 0:00 ` Robert Dewar 1997-09-01 0:00 ` Robert Dewar 1997-09-02 0:00 ` Robert A Duff 1997-09-02 0:00 ` Fergus Henderson [not found] ` <mheaney-ya023680000209972104030001@news.ni.net> 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Matthew Heaney 1997-09-08 0:00 ` Robert A Duff 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Robert A Duff [not found] ` <EFxt94.F5F@world.std.com> 1997-09-06 0:00 ` Robert Dewar 1997-09-08 0:00 ` Robert A Duff 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Robert A Duff 1997-08-27 0:00 ` Robert Dewar 1997-08-30 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