From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public From: Alan E & Carmel J Brain Subject: Re: Porting Experiences (was Ada and Pascal etc ) Date: 1997/11/06 Message-ID: <34623DA4.7EE5@dynamite.com.au> X-Deja-AN: 287312395 References: <34557f2b.1934172@news.mindspring.com> <345E3ACD.A15@gsg.eds.com> <63mcmm$r3s$1@helios.crest.nt.com> <3460A7BB.3CCD27DC@hso.link.com> <63qq9k$njt$1@helios.crest.nt.com> Reply-To: aebrain@dynamite.com.au Organization: @home Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-06T00:00:00+00:00 List-Id: Kaz Kylheku wrote: > > In article <3460A7BB.3CCD27DC@hso.link.com>, > Samuel T. Harris wrote: > >Reading the arguments between Kaz and others, I'm struck > >with the realization that Kaz is missing a significant > >point. As long as application code is not concerned > >with the representation of variables, Kaz is correct > >in his statements that a few simple guidelines insure > >good type choices for portable C code. What Kaz has > >failed to consider, but has been state by others, is > >that sometimes the representation of the type IS > >important to the application, or at least to the > >context in which the application is running. > > Then the application is not portable, by definition. A portable program is one > which is not concerned with the representation of a type. I most strongly disagree. A very, very typical counterexample, found in many, many systems is an I/O handler. For this, there is a standard protocol defined at some level, stating the bit representation of the telegrams. Consider a telegram containing (in a representation-free sense): A telegram type, which is between 0 and 255; A value, which is between 0 and 20000 A 10-character string 6 status flags This is implemented in the specification of the interface as: Bytes 0 Telegram type Bytes 1 Bytes of which the 6 MSBs are the status flags Bytes 2-4 unused Bytes 5-7 The value up to 20000 Bytes 8-17 The character string in ANSI 8-bit, no terminator Bytes 18-19 Unused All boxes on the bus must have a piece of code that can "decode" this telegram. In C, using different C compilers, sure you need #ifdefs and all sorts of other things. In Ada, even Ada-83, the same code on different CPUs with different compilers is guarenteed to use the same representation, if you use the representation clauses provided with the language. For example: type TelegramKindType is ( Conflict, Priority); for TelegramKindType use ( Conflict => 16#FF, Priority => 2#10101010); for TelegramKindType'size use 8; -- 8 bits exactly, no more, no less type TelegramType is record TheKind : TelgramKindType; etc etc etc and for TelegramType use record at mod 8 -- align it to some very portable word boundary TheKind at 0 range 0..7; etc etc etc The point is that the _exact same_ chunk of code is used in _every_ machine. Now if that's not portable, what is? > Interfacing to hardware is outside of the domain of a strictly conforming > C program. A pure C language program communicates with the environment > only through streams. Sounds as if Ada's more powerful here --> :) <---- > I have programmed in such circumstances and managed to remain strictly > conforming. Interfacing heterogeneous architectures can be solved by > identifying a canonical external representation format and then writing > maximally portable routines which encode data items to and from that > format. In my experience, only floating point representations represent > any significant difficulties in this area. I agree, obviously you'll recognise the Ada example I gave above. In Ada, the problem's actually worse: in most cases, the language allows complete portability, you get used to it. But then along comes a problem where the communications telegram has IEEE floats, and the machine you're on only has DEC (or other) floats. In which case you have to write some more code. BTW this is an actual example, I headed the team doing the I/O over a VME bus (Many MB/sec) between a KAV (DEC) card and an i860 card. Under pressure from management (execution time was crucial) an assembler Float converter was written by an Assembler guru. After 2 weeks, a C program was written, that was actually faster, and worked (unlike the assembler). Of course later, I then wrote an Ada conversion routine, that due to an excellent compiler, was faster still, but that's another matter. > >In fact, Ada provides me facilities to exactly map > >the representation of a record right down to the > >location and size of each field to conform to the > >requirements of memory-mapped hardware registers. > > This is also possible with C in a portable way. It is not that convenient, of > course, but we are discussing portability, rather than convenience. > Conforming to external data layout can be done in a highly portable way in C. > It can also be done in non-portable ways which are usually faster. > > Instead of useless talk, why don't we try the following game: you describe the > storage layout, and I will demonstrate a maximally portable C example which can > communicate with that layout. I will entertain you as long as you wish. > > Perhaps you will emerge out of this better armed for situations in which > you have to use C rather than some other preferred tool such as Ada. YES PLEASE. Any help from anyone is always welcome. So much to learn, and only one lifetime, *SIGH* OK, I would like the following: 1st(0th) byte contains telegram type. This has legal values of FF,FE,and 00. If the value is FF, then bytes 4-7 contain an IEEE floating point between -1.7666 e6 and 2.34 e12. Byte 3 contains an enumeration type, which has the values Red,Green, Yellow, corresponding to 01, 10, and FF (hex). If the value is FE, bytes 1-3 contain a binary angle (fixed point), first 13 bits before the binary point. Bytes 4-11 contain a packed ANSI 7-bit string. If the value is 00, then the rest is "don't care". The reading in must check that all values are correct. The floating point will be decoded into the form of mantissa, sign, exponent etc. This is a nice, simple one. I'll get into the really polymorphic records later. Over 2 U. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale