* Ada 83 - avoiding unchecked conversions. @ 1996-11-27 0:00 Ensco Vendor 1996-11-27 0:00 ` Robert I. Eachus ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Ensco Vendor @ 1996-11-27 0:00 UTC (permalink / raw) we have two 16 bit integers which we need to assemble into a single 32 bit integer (one is high order, the other low order). We wish to avoid unchecked conversion if we can. Is there a standard accepted way of doing this? Mary Cronk ENSCO at Lockheed Martin, Owego, NY, US mary.m.cronk@lmco.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-11-27 0:00 Ada 83 - avoiding unchecked conversions Ensco Vendor @ 1996-11-27 0:00 ` Robert I. Eachus 1996-11-29 0:00 ` Robert Dewar 1996-12-02 0:00 ` Ted Dennison 2 siblings, 0 replies; 22+ messages in thread From: Robert I. Eachus @ 1996-11-27 0:00 UTC (permalink / raw) In article <329C63BC.41C6@lmco.com> Mary Cronk <mary.m.cronk@lmco.com> writes: > we have two 16 bit integers which we need to assemble into a single 32 > bit integer (one is high order, the other low order). We wish to avoid > unchecked conversion if we can. Is there a standard accepted way of > doing this? I could ask why you want to avoid Unchecked_Conversion, since in this case the message of the name is exactly what you apparently want, a conversion that does no checking. But I won't ask. The best way to do this in Ada 95 is to have the low order word declared as a modular type, and the upper word as a 16-bit integer: type Mod16 is mod 2**16; type Int16 is range -2**15..2**15-1; type Int32 is range -2**31..2**31-1; ... function Merge_Halves(High: Int16; Low: Mod16) return Int32 is begin return Int32(High) * 2**16 + Int32(Low); end Merge_Halves; If you are using Ada 83 and want portability, or you have the low order bits in a signed number for some reason: function Merge_Halves(High, Low: Int16) return Int32 is begin if Low >= 0 then return Int32(High) * 2**16 + Int32(Low); else return Int32(High) * 2**16 + (2**16 + Int32(Low)); end if; end Merge_Halves; You may be tempted to write: return Int32(High + 1) * 2**16 + Int32(Low); But that risks overflow, as does just omitting the parentheses. A VERY clever compiler might be able to figure out a way to simplify the expression and still do no range checking, but I'll settle for compilers that replace the multiply with a shift, and only do an overflow check on the final add. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-11-27 0:00 Ada 83 - avoiding unchecked conversions Ensco Vendor 1996-11-27 0:00 ` Robert I. Eachus @ 1996-11-29 0:00 ` Robert Dewar 1996-12-01 0:00 ` Darel Cullen 1996-12-02 0:00 ` Ted Dennison 2 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 1996-11-29 0:00 UTC (permalink / raw) Mary asks "we have two 16 bit integers which we need to assemble into a single 32 bit integer (one is high order, the other low order). We wish to avoid unchecked conversion if we can. Is there a standard accepted way of doing this? " I always wonder when people say "I want to do X without using the obvious method for doing X". Can you explain why you don't want to use unchecked conversion here. Is there a real technical reason, or simply some kind of arbitrary rule in action? Of course you can do this assembly using multiplication (X * 2**16 + y). which is more appropriate depends on EXACTLY the abstract semantics of what you are doing (I mean which of unchecked conversion or multiplication) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-11-29 0:00 ` Robert Dewar @ 1996-12-01 0:00 ` Darel Cullen 1996-11-30 0:00 ` Robert Dewar 1996-12-11 0:00 ` Richard Riehle 0 siblings, 2 replies; 22+ messages in thread From: Darel Cullen @ 1996-12-01 0:00 UTC (permalink / raw) In article <dewar.849275146@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> spoke thus :- >Mary asks [snip] > >" > > >I always wonder when people say "I want to do X without using the obvious >method for doing X". Can you explain why you don't want to use unchecked >conversion here. Is there a real technical reason, or simply some kind >of arbitrary rule in action? > >Of course you can do this assembly using multiplication (X * 2**16 + y). >which is more appropriate depends on EXACTLY the abstract semantics of >what you are doing (I mean which of unchecked conversion or multiplication) > In this case, I wouldnt be surprised if the employer had some kind of 'coding standards' that generally tend to remove alot of the more useful features of a language , such as unchecked conversion/deallocation, or compiler pragmas, these documents tend to be sweeping, and have to be adhered too. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Darel J. Cullen Software Engineer Email: Darel@djcull.demon.co.uk Url: http://www.djcull.demon.co.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-01 0:00 ` Darel Cullen @ 1996-11-30 0:00 ` Robert Dewar 1996-12-11 0:00 ` Richard Riehle 1 sibling, 0 replies; 22+ messages in thread From: Robert Dewar @ 1996-11-30 0:00 UTC (permalink / raw) Darel says " In this case, I wouldnt be surprised if the employer had some kind of 'coding standards' that generally tend to remove alot of the more useful features of a language , such as unchecked conversion/deallocation, or compiler pragmas, these documents tend to be sweeping, and have to be adhered too." Sure I realize that this happens sometimes, but I like to know when it is happening, I have no interest in spending my time helping people recover from their own deliberately idiotic behavior. Once I heard a presentation from someone talking about AI in C vs Ada. He announced that C was much more efficient than Ada for this purposes. Digging into this nonsense claim, we discovered that he was using new for each allocation in the case of Ada, but in C was not using malloc for each allocation, but instead had written his own storage allocator for the C case. There followed the following discussion. Q. But why aren't you using malloc in C? A. Much too inefficient, we could not afford the inefficiency! Q. But then why not do the same thing in Ada? A. Impossible to do it in Ada! Q. What are you talking about, of course you can do this using chapter 13 facilities. A. We aren't allowed to use anything from chapter 13 Q. Why not? A. It would result in non-portable code Q. No less portable than your C code?? A. Our C code is completely portable, we have run it on two different machines. etc. you get the idea :-) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-01 0:00 ` Darel Cullen 1996-11-30 0:00 ` Robert Dewar @ 1996-12-11 0:00 ` Richard Riehle 1 sibling, 0 replies; 22+ messages in thread From: Richard Riehle @ 1996-12-11 0:00 UTC (permalink / raw) On Sun, 1 Dec 1996, Darel Cullen wrote: In reply to a well-stated comment on the captioned topic, > In this case, I wouldnt be surprised if the employer had some kind > of 'coding standards' that generally tend to remove alot of > the more useful features of a language , such as unchecked > conversion/deallocation, or compiler pragmas, these documents tend to > be sweeping, and have to be adhered too. Does anyone else find it odd that the people who make up rules about programming are often people who no longer write programs. In some cases, they are people who have never written code in the language for which they are defining such rules. Richard Riehle ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-11-27 0:00 Ada 83 - avoiding unchecked conversions Ensco Vendor 1996-11-27 0:00 ` Robert I. Eachus 1996-11-29 0:00 ` Robert Dewar @ 1996-12-02 0:00 ` Ted Dennison 1996-12-10 0:00 ` Matthew Heaney 2 siblings, 1 reply; 22+ messages in thread From: Ted Dennison @ 1996-12-02 0:00 UTC (permalink / raw) Ensco Vendor wrote: > > we have two 16 bit integers which we need to assemble into a single 32 > bit integer (one is high order, the other low order). We wish to avoid > unchecked conversion if we can. Is there a standard accepted way of > doing this? > Does the target object have to be a 32-bit integer, or does it just have to be the *size* of a 32-bit integer? Often times folks will back themselves into a corner where they have to do unchecked conversion because they didn't choose their data types very well. Of course, often there is some sort of I/O or system binding that REQUIRES use of an unnatural data type. In that case, unchecked conversion is the proper tool for the job. Doing any kind of semantic calisthenics simply to aviod unchecked conversion is liable to cause more problems than are solved. -- T.E.D. | Work - mailto:dennison@escmail.orl.lmco.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-02 0:00 ` Ted Dennison @ 1996-12-10 0:00 ` Matthew Heaney 0 siblings, 0 replies; 22+ messages in thread From: Matthew Heaney @ 1996-12-10 0:00 UTC (permalink / raw) >Ensco Vendor wrote: >> >> we have two 16 bit integers which we need to assemble into a single 32 >> bit integer (one is high order, the other low order). We wish to avoid >> unchecked conversion if we can. Is there a standard accepted way of >> doing this? Unchecked conversion is the accepted way of doing this: function To_Integer_32 (Low, High : Integer_16) return Integer_32 is type Integer_32_Record is record High_Order : Integer_16; Low_Order : Integer_16; end record; for Integer_32_Record use record High_Order at 0 range 16 .. 32; Low_Order at 0 range 0 .. 15; end record; for Integer_32_Record'Size use 32; function To_Integer_32 is new Unchecked_Conversion ( Integer_32_Record, Integer_32); The_Record : constant Integer_32_Record := ( High_Order => High, Low_Order => Low); begin return To_Integer_32 (The_Record); end; Because the source and target types have the same size, this should be completely portable. Some shops have the rule "Thou shalt not use Unchecked_Conversion." But this is silly; use it when it makes sense. The proper place to use Unchecked_Conversion is at the interface boundary of the sytem. That seems to be the case for you, because you're manipulating types whose size is known explicitly (16 and 32 bit integers). -------------------------------------------------------------------- Matthew Heaney Software Development Consultant mheaney@ni.net (818) 985-1271 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <md5:8B831999BCF200C6E70994BDF6CC529F>]
* Re: Ada 83 - avoiding unchecked conversions. [not found] <md5:8B831999BCF200C6E70994BDF6CC529F> @ 1996-12-11 0:00 ` Chris Sparks (Mr. Ada) 1996-12-11 0:00 ` Dewi Daniels ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Chris Sparks (Mr. Ada) @ 1996-12-11 0:00 UTC (permalink / raw) Ensco Vendor wrote: > > we have two 16 bit integers which we need to assemble into a single 32 > bit integer (one is high order, the other low order). We wish to > avoid unchecked conversion if we can. Is there a standard accepted > way of doing this? Matt Heaney wrote: > > Unchecked conversion is the accepted way of doing this: It is an accepted way however not the only way. > function To_Integer_32 (Low, High : Integer_16) > return Integer_32 is > > type Integer_32_Record is > record > High_Order : Integer_16; > Low_Order : Integer_16; > end record; > > for Integer_32_Record use > record > High_Order at 0 range 16 .. 32; You mean 31. > Low_Order at 0 range 0 .. 15; You have to be careful here due to portability and bit ordering. > end record; > > for Integer_32_Record'Size use 32; > > function To_Integer_32 is > new Unchecked_Conversion ( > Integer_32_Record, > Integer_32); > > The_Record : constant Integer_32_Record := ( > High_Order => High, > Low_Order => Low); > begin > return To_Integer_32 (The_Record); > end; Here's Mine: with Interfaces; use Interfaces; with System; function To_Integer_32 (Low : in Integer_16; High : in Integer_16) return Integer_32 is type Integer_32_Record is record High_Order : Integer_16; Low_Order : Integer_16; end record; for Integer_32_Record use record High_Order at 0 range 16 .. 31; Low_Order at 0 range 0 .. 15; end record; for Integer_32_Record'Size use 32; The_Record : constant Integer_32_Record := (High_Order => High, Low_Order => Low); The_Record_Address : constant System.Address := The_Record'Address; Result : Integer_32; for Result'Address use The_Record_Address; -- New way --for Result use at The_Record_Address; -- Old way begin return Result; end To_Integer_32; with Interfaces; use Interfaces; with Ada.Text_IO; use Ada.Text_IO; with To_Integer_32; procedure T is A : Integer_32 := -1; begin Put_Line ("A" & Integer_32'Image (A)); A := To_Integer_32 (Low => 10, High => 0); Put_Line ("A" & Integer_32'Image (A)); A := To_Integer_32 (Low => 0, High => 10); Put_Line ("A" & Integer_32'Image (A)); end T; I compiled this with 3.07 under HPUX and got the following results: A-1 A 655360 A 10 The low/high ordering is incorrectly represented for the HP (Portability issue). > Because the source and target types have the same size, this should be > completely portable. Yes. > Some shops have the rule "Thou shalt not use Unchecked_Conversion." > But this is silly; use it when it makes sense. I concur. Using Address Clauses would not be the right choice when a component within a structure has an initializing value (pointers, explicit initializations). > The proper place to use Unchecked_Conversion is at the interface > boundary of the sytem. That seems to be the case for you, because you're > manipulating types whose size is known explicitly (16 and 32 bit integers). I don't know what this means. Chris Sparks ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-11 0:00 ` Chris Sparks (Mr. Ada) @ 1996-12-11 0:00 ` Dewi Daniels 1996-12-12 0:00 ` Richard Kenner 1996-12-11 0:00 ` Matthew Heaney 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 22+ messages in thread From: Dewi Daniels @ 1996-12-11 0:00 UTC (permalink / raw) On Wed, 11 Dec 1996 07:43:07 -0800, "Chris Sparks (Mr. Ada)" <sparks@AISF.COM> wrote: > The_Record_Address : constant System.Address :=3D The_Record'Address; > Result : Integer_32; > for Result'Address use The_Record_Address; -- New way >--for Result use at The_Record_Address; -- Old way Ada 83 prohibits the use of address clauses to alias two variables (LRM 13.5). I believe it's legal in Ada 95. My preference would be to use an unchecked conversion. --=20 Dewi Daniels Marietta, Georgia ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-11 0:00 ` Dewi Daniels @ 1996-12-12 0:00 ` Richard Kenner 1996-12-17 0:00 ` Eric Miller 0 siblings, 1 reply; 22+ messages in thread From: Richard Kenner @ 1996-12-12 0:00 UTC (permalink / raw) In article <32b03008.564464@netnews.worldnet.att.net> dewi@cableol.co.uk (Dewi Daniels) writes: >Ada 83 prohibits the use of address clauses to alias two variables >(LRM 13.5). I believe it's legal in Ada 95. My preference would be to >use an unchecked conversion. An unchecked conversion is much more efficient. Using an address clause not only forces the object into memory, but disables many optimizations on it (essentially treats it as volatile). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-12 0:00 ` Richard Kenner @ 1996-12-17 0:00 ` Eric Miller 1996-12-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 22+ messages in thread From: Eric Miller @ 1996-12-17 0:00 UTC (permalink / raw) Richard Kenner wrote: > > In article <32b03008.564464@netnews.worldnet.att.net> dewi@cableol.co.uk (Dewi Daniels) writes: > >Ada 83 prohibits the use of address clauses to alias two variables > >(LRM 13.5). I believe it's legal in Ada 95. My preference would be to > >use an unchecked conversion. > > An unchecked conversion is much more efficient. Using an address > clause not only forces the object into memory, but disables many > optimizations on it (essentially treats it as volatile). I'm fairly certain that we're heading into compiler-specific territory now. Efficiency issues are tough to generalize. I used to work at the same company as a guy who was having problems with a program that ran (essentially in batch) for several hours. One of his optimizations was to switch all the unchecked conversions to conversions using overlays. Apparently on that compiler (VAX Ada 1.something) unchecked conversion was doing some checks. My recommendation is to use unchecked conversion because you're doing just what your code says you're doing. Overlays just give the reader one more thing to think about. Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-17 0:00 ` Eric Miller @ 1996-12-18 0:00 ` Robert Dewar 1996-12-18 0:00 ` Robert A Duff 1996-12-19 0:00 ` Keith Thompson 0 siblings, 2 replies; 22+ messages in thread From: Robert Dewar @ 1996-12-18 0:00 UTC (permalink / raw) iEric said "using overlays. Apparently on that compiler (VAX Ada 1.something) unchecked conversion was doing some checks. " Note that the unchecked in unchecked conversion is talking about omitting normal compile time checks for type correctness. It is NOT talking about runtime checking (whatever that might mean). In general you cannot assume that unchecked conversion takes no code. Some of the time it may take no code, but there is no reason to think, or even considerable desirable, that a compiler would never generate code for an unchecked conversion. Sometimes you would get the wrong result in the absence of generating code. For example, suppose that packed 5 bit arrays were stored left justified in a register, and 5 bit integers were stored right justified. Well the compiler had beetter emit a shift for the unchecked conversion or it will get the wrong result (remembr that the semantics of unchecked conversion is quite well defined, it is not some kind of implementation dependent unknown op0eration). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-18 0:00 ` Robert Dewar @ 1996-12-18 0:00 ` Robert A Duff 1996-12-19 0:00 ` Keith Thompson 1 sibling, 0 replies; 22+ messages in thread From: Robert A Duff @ 1996-12-18 0:00 UTC (permalink / raw) In article <dewar.850929268@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >iEric said >"using overlays. Apparently on that compiler (VAX Ada 1.something) >unchecked conversion was doing some checks. >" >Note that the unchecked in unchecked conversion is talking about omitting >normal compile time checks for type correctness. It is NOT talking about Another efficiency issue about unch_conv is whether or not it makes a copy. An instance of U_C is a function, so one would normally assume that calling it makes a copy of the argument. This is what the Ada 83 RM said, and this is no doubt why U_C was inefficient in some early version of VAX Ada. However, the Ada 83 ARG ruled that the function result may be returned by reference in some cases, and Ada 95 agrees with that ruling (see 13.9(12)). So if you do: Some_Procedure(Unch_Conv(X)); then Some_Procedure might actually be receiving the address of X, rather than the address of a copy of X. This is different (and often more efficient) than the semantics normal function calls. And the difference is detectable. - Bob ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-18 0:00 ` Robert Dewar 1996-12-18 0:00 ` Robert A Duff @ 1996-12-19 0:00 ` Keith Thompson 1996-12-26 0:00 ` Robert Dewar 1 sibling, 1 reply; 22+ messages in thread From: Keith Thompson @ 1996-12-19 0:00 UTC (permalink / raw) In <dewar.850929268@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: [...] > Note that the unchecked in unchecked conversion is talking about omitting > normal compile time checks for type correctness. It is NOT talking about > runtime checking (whatever that might mean). In general you cannot assume > that unchecked conversion takes no code. Some of the time it may take > no code, but there is no reason to think, or even considerable desirable, > that a compiler would never generate code for an unchecked conversion. Certainly unchecked conversion can require some code in some cases, but one wouldn't normally expect that code to include constraint checks. > Sometimes you would get the wrong result in the absence of generating > code. For example, suppose that packed 5 bit arrays were stored left > justified in a register, and 5 bit integers were stored right justified. > Well the compiler had beetter emit a shift for the unchecked conversion > or it will get the wrong result (remembr that the semantics of > unchecked conversion is quite well defined, it is not some kind of > implementation dependent unknown op0eration). I agree that the compiler needs to emit a shift for this case, but it shouldn't generate a check that the result is within the declared range of its subtype. This makes it the programmer's responsibility to guarantee that the result will be a valid value of the target subtype (if possible, by using a target subtype that covers all possible bit patterns), or to deal with it properly if it isn't. On the other hand, if the result of a unchecked conversion is assigned to an object, there may well be a constraint check on the assignment. -- Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 "SPOON!" -- The Tick ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-19 0:00 ` Keith Thompson @ 1996-12-26 0:00 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 1996-12-26 0:00 UTC (permalink / raw) Keity says "I agree that the compiler needs to emit a shift for this case, but it shouldn't generate a check that the result is within the declared range of its subtype. This makes it the programmer's responsibility to guarantee that the result will be a valid value of the target subtype (if possible, by using a target subtype that covers all possible bit patterns), or to deal with it properly if it isn't." Notice that the shouldn't here corresponds to implementation advice in the RM, not to any requirement, so code that counts on there being no check is potentially non-portable. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-11 0:00 ` Chris Sparks (Mr. Ada) 1996-12-11 0:00 ` Dewi Daniels @ 1996-12-11 0:00 ` Matthew Heaney 1996-12-12 0:00 ` Chris Brand 1996-12-14 0:00 ` BGaffney42 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 22+ messages in thread From: Matthew Heaney @ 1996-12-11 0:00 UTC (permalink / raw) In article <32AED68A.48BE@aisf.com>, "Chris Sparks (Mr. Ada)" <sparks@AISF.COM> wrote: >> function To_Integer_32 (Low, High : Integer_16) >> return Integer_32 is >> >> type Integer_32_Record is >> record >> High_Order : Integer_16; >> Low_Order : Integer_16; >> end record; >> >> for Integer_32_Record use >> record >> High_Order at 0 range 16 .. 32; > >You mean 31. > >> Low_Order at 0 range 0 .. 15; > >You have to be careful here due to portability and bit ordering. Someone else also pointed that out to me. Does anyone know how to use the Bit_Order attribute to make this portable? Is this acceptable: for Integer_32_Record'Bit_Order use System.Low_Bit_First; I'm confused because I'm not sure whether storage unit 0 refers to the most significant bit or the least significant. Does the Bit_Order attribute only affect the interpretation of the bits, or of the storage unit too? > The_Record_Address : constant System.Address := The_Record'Address; > Result : Integer_32; > for Result'Address use The_Record_Address; -- New way >--for Result use at The_Record_Address; -- Old way I disagree with this "solution." Overlays are never the way to go when Unchecked_Conversion will do. >> Some shops have the rule "Thou shalt not use Unchecked_Conversion." >> But this is silly; use it when it makes sense. > >I concur. Using Address Clauses would not be the right choice when >a component within a structure has an initializing value (pointers, >explicit initializations). Yes, that it true, but it's still not the right solution here. Unchecked_Conversion is. >> The proper place to use Unchecked_Conversion is at the interface >> boundary of the sytem. That seems to be the case for you, because you're >> manipulating types whose size is known explicitly (16 and 32 bit integers). > >I don't know what this means. "Close-to-metal" programming. Think of a program as a system with definate boundaries. The boundaries for an embedded system, say, are the computer itself (the OS or kernal, etc) and hardware devices over which you perform external I/O. When you do external device I/O, you have to know explicitly what the size and representation is of all the data you exchange with the other processor, because you both have to agree on a common format. Ada excels in this area because it allows you to state explicitly what the representation of the data is by using size clauses and representation clauses. But knowing the representation of the data is only important at the hardware level, ie "the interface boundary." Internal to the software there's a lot going on that doesn't depend on representation of the data, so we want to practice some information hiding by letting the compiler choose the representation. For example, type T is range 1 .. 10; I can use type T to do some calculations, but I certainly don't care if T occupies 8, 16, or 32 bits. It's a perfectly valid request to not use Unchecked_Conversion on types like T, because I'm inside the software system. But at the I/O layer, I can't use types like T because I really do need to know T's representation (because I have to send it to someone else outside the system). So yes, I often really do need to use Unchecked_Conversion - at the interface boundary. Shops that make rules like "Don't use Unchecked_Conversion" mean well but are confusing the internal and external aspects of the (software) system. This confusion is also the reason why shops often say "Thou shalt not use predefined types, because it's not portable." This too is another silly rule. It would be perfectly valid for such a rule at the interface layer, because I have to know the representation of my types. But internal to the software system, I don't care, and using predefined types is just another form of information hiding. I've often seen code like this type Stack is limited private; type Length_Type is range ... for Lenght_Type'Size use 32; function Length (S : Stack) return Length_Type; ... private type Stack is ...; end; This is pure overkill: who cares what the representation of the stack length attribute is? It's also wrong because they didn't use a representation clause on the representation of type Stack. Are you going to send the stack object across an interface? If not, then why do you care what the representation is? function Length (S : Stack) return Natural; is a perfectly good use of a predefined type. Another egregious example is with array declarations: type T_Array is array (Integer_32 range <>) of T; This is completely wrong: who cares what the representation of the array index subtype is? You never care about that even at the interface layer, because you don't actually send the array index across the interface - only the components of the array. Which is why using a subtype of Positive is often the best type for an array index subtype. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant mheaney@ni.net (818) 985-1271 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-11 0:00 ` Matthew Heaney @ 1996-12-12 0:00 ` Chris Brand 1996-12-13 0:00 ` Stephen Leake 1996-12-14 0:00 ` BGaffney42 1 sibling, 1 reply; 22+ messages in thread From: Chris Brand @ 1996-12-12 0:00 UTC (permalink / raw) Matthew Heaney wrote: > [cut] > But knowing the representation of the data is only important at the > hardware level, ie "the interface boundary." Internal to the software > there's a lot going on that doesn't depend on representation of the data, > so we want to practice some information hiding by letting the compiler > choose the representation. > [cut] > > This confusion is also the reason why shops often say "Thou shalt not use > predefined types, because it's not portable." This too is another silly > rule. > > It would be perfectly valid for such a rule at the interface layer, because > I have to know the representation of my types. But internal to the > software system, I don't care, and using predefined types is just another > form of information hiding. > [examples cut] I worked on a project where the rule was not to use predefined types. We had a package defining the "base types" to use, with all their representation clauses and everything and we had to base our types on these. The main type was an "Integer_16". This was great while we were using a 286 target. It was only when we ported it to a 486 target (where 16-bit values need more work than 32-bit ones) that we noticed the disadvantage of such a rule. Left to itself, the compiler would have chosen a 16-bit value for most things on the 286 and a 32-bit value on the 486. Of course, if you take these things away, people have to think about "what is a sensible upper bound for this type ?" :-) -- Chris Stating my own opinions, not those of my company. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-12 0:00 ` Chris Brand @ 1996-12-13 0:00 ` Stephen Leake 1996-12-14 0:00 ` Robert A Duff 0 siblings, 1 reply; 22+ messages in thread From: Stephen Leake @ 1996-12-13 0:00 UTC (permalink / raw) Chris Brand wrote: > > Matthew Heaney wrote: > > > [cut] > > But knowing the representation of the data is only important at the > > hardware level, ie "the interface boundary." Internal to the software > > there's a lot going on that doesn't depend on representation of the data, > > so we want to practice some information hiding by letting the compiler > > choose the representation. > > > [cut] > > > > This confusion is also the reason why shops often say "Thou shalt not use > > predefined types, because it's not portable." This too is another silly > > rule. > > > > It would be perfectly valid for such a rule at the interface layer, because > > I have to know the representation of my types. But internal to the > > software system, I don't care, and using predefined types is just another > > form of information hiding. > > > [examples cut] > > I worked on a project where the rule was not to use predefined types. > We had a package defining the "base types" to use, with all their > representation clauses and everything and we had to base our types on > these. > The main type was an "Integer_16". > > This was great while we were using a 286 target. It was only when we > ported > it to a 486 target (where 16-bit values need more work than 32-bit ones) > that we noticed the disadvantage of such a rule. Left to itself, the > compiler would have chosen a 16-bit value for most things on the 286 and > a 32-bit value on the 486. > > Of course, if you take these things away, people have to think about > "what is a sensible upper bound for this type ?" :-) Perhaps there should have been a type "Fast_Integer", with the understanding that it was at least 16 bits (this is of course just Standard.Integer). Then programmers can use Fast_Integer when they don't really care about the size. > > -- > Chris > Stating my own opinions, not those of my company. -- - Stephe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-13 0:00 ` Stephen Leake @ 1996-12-14 0:00 ` Robert A Duff 0 siblings, 0 replies; 22+ messages in thread From: Robert A Duff @ 1996-12-14 0:00 UTC (permalink / raw) In article <32B17F46.123B@gsfc.nasa.gov>, Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote: >Perhaps there should have been a type "Fast_Integer", with the >understanding that it was at least 16 bits (this is of course just >Standard.Integer). Then programmers can use Fast_Integer when they don't >really care about the size. Sometimes, you want "an integer of at least so-and-so range, but I don't mind if it has more range, so long as it doesn't cost me any efficiency". To say that in Ada 95: type Specific_Range is range -10_000..10_000; subtype T is Specific_Range'Base; Then use T all over. Other times, you want an integer type that has something to do with the amount of addressable memory on the machine. E.g. type String, where the index type is Integer, and one presumes that Integer is 16 bits on a 16-bit machine, and 32 bits on a 32-bit machine -- that makes sense, since you won't want to create 10 megabyte strings on the 16-bit machine, but you might on the 32-bit machine. - Bob ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-11 0:00 ` Matthew Heaney 1996-12-12 0:00 ` Chris Brand @ 1996-12-14 0:00 ` BGaffney42 1 sibling, 0 replies; 22+ messages in thread From: BGaffney42 @ 1996-12-14 0:00 UTC (permalink / raw) I'm sorry, I must be missing something. Why would you want to use Unchecked_Conversion or some form of overlay for this problem? Why can't the following function be used (assuming Integer_16 and Integer_32 are defined with appropriate ranges and 'Sizes? function Convert (Hi, Lo : Integer_16) return Integer_32 is Shift_16 : constant Integer_32 := 2**16; begin if Lo < 0 then return Integer_32(Hi) * Shift_16 + (Shift_16 + Integer_32(Lo)); else return Integer_32(Hi) * Shift_16 + Integer_32(Lo); end if; end Convert; -- _really_ psycho engineer -- using Ada as a toy and _not_ working for an Ada vendor! --Brian Gaffney ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada 83 - avoiding unchecked conversions. 1996-12-11 0:00 ` Chris Sparks (Mr. Ada) 1996-12-11 0:00 ` Dewi Daniels 1996-12-11 0:00 ` Matthew Heaney @ 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 22+ messages in thread From: Robert I. Eachus @ 1996-12-19 0:00 UTC (permalink / raw) In article <32B6905F.FC4@tiac.net> Eric Miller <ewmiller@tiac.net> writes: > I used to work at the same company as a guy who was having > problems with a program that ran (essentially in batch) for > several hours. One of his optimizations was to switch all the > unchecked conversions to conversions using overlays. Apparently > on that compiler (VAX Ada 1.something) unchecked conversion was > doing some checks. As I remember it, early versions of VAX Ada flushed stored state in the compiler in a couple of cases where it later turned out not to be needed. As I remember it, two cases were on all statement labels and on all subprogram calls, even if inlined. This caused the stack pointer to be reloaded. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~1996-12-26 0:00 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-11-27 0:00 Ada 83 - avoiding unchecked conversions Ensco Vendor 1996-11-27 0:00 ` Robert I. Eachus 1996-11-29 0:00 ` Robert Dewar 1996-12-01 0:00 ` Darel Cullen 1996-11-30 0:00 ` Robert Dewar 1996-12-11 0:00 ` Richard Riehle 1996-12-02 0:00 ` Ted Dennison 1996-12-10 0:00 ` Matthew Heaney [not found] <md5:8B831999BCF200C6E70994BDF6CC529F> 1996-12-11 0:00 ` Chris Sparks (Mr. Ada) 1996-12-11 0:00 ` Dewi Daniels 1996-12-12 0:00 ` Richard Kenner 1996-12-17 0:00 ` Eric Miller 1996-12-18 0:00 ` Robert Dewar 1996-12-18 0:00 ` Robert A Duff 1996-12-19 0:00 ` Keith Thompson 1996-12-26 0:00 ` Robert Dewar 1996-12-11 0:00 ` Matthew Heaney 1996-12-12 0:00 ` Chris Brand 1996-12-13 0:00 ` Stephen Leake 1996-12-14 0:00 ` Robert A Duff 1996-12-14 0:00 ` BGaffney42 1996-12-19 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox