From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,442eb9212004f30 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!postnews.google.com!26g2000hsk.googlegroups.com!not-for-mail From: petter_fryklund@hotmail.com Newsgroups: comp.lang.ada Subject: Re: Problem using Ada.Text_IO.Modular_IO Date: Fri, 11 Jul 2008 06:26:24 -0700 (PDT) Organization: http://groups.google.com Message-ID: <867127d8-3b21-40dd-bb76-f19cd349b21e@26g2000hsk.googlegroups.com> References: <4eab7055-df3d-4d56-87da-8248829da1da@26g2000hsk.googlegroups.com> <32e35e5a-3cae-4fdc-be4a-3ae1e146e9f3@l64g2000hse.googlegroups.com> <48772c92$0$6601$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: 148.2.192.140 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1215782784 24122 127.0.0.1 (11 Jul 2008 13:26:24 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 11 Jul 2008 13:26:24 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 26g2000hsk.googlegroups.com; posting-host=148.2.192.140; posting-account=ACEctQoAAAD3d42JSpp6_fpg88BhdFDo User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:1112 Date: 2008-07-11T06:26:24-07:00 List-Id: On 11 Juli, 14:16, a...@anon.org (anon) wrote: > I did not comment Adam's two paragraphs because I did not want to cut > him down. > > Now, UNISYS at one time used 9-bit/18/36-bits (power of 3) instead of > power of 2. But the norm for todays computers is base 2, that's is the > only reason the specs only use 2**N instead of including 3**N for UNISYS. > > If you look at RM B.2 (7-8) which suggest that if the "target architectur= e" > support N-bits words then the "implementation shall provide" that > defintion in both signed and modular types. [ I think Adam forgot to look > at that one. ] Since, most system today sopport 8/16/32 and 64-bit words > then the "Interfaces" package shall contain definitions for those words. > And since vendor has done the work for us, so why not use it. > > But my main point is that you should know what is in the packages on > the system that you are using and how they work. And if they save time > in creating a partition then use them. > > Plus, as for compatibility with other Ada vendors or future GNAT versions= , > well my talks with Adacore over the death of GLADE suggest that they do > not care for the term "compatibility " any more. =A0Also, if we do not us= e > each part of the GNAT Ada package it might disappear in the next > specification version of Ada. Which may come out sooner than we think, > just an idea that came from my talks with Adacore. > > In <48772c92$0$6601$9b4e6...@newsspool2.arcor-online.net>, Georg Bauhaus = writes: > > > > >anon wrote: > >> Why re-invent the Wheel!!! If we spend all day re-stating that which > >> has been done then nothing new get done that day! > > >As Adam is pointing out below---in two paragraphs which I think > >are really recommended reading---Unsigned_64 is defined for a > >specific programming context. Typically that of interfacing > >to 2**N bit addressable hardware, N >=3D 3. > > >When a program does not perform any interfacing, but still > >uses types from Interfaces, then in a sense its use of type is > >close to C's approach to the fundamental type system: > >In C, you have fundamental "scalar" types that say, > >"at least that many bits, some operations, some behavior at the > >bounds, and please look up the rest in the compiler's > >documentation". =A0When Ada allows the programmer to work at a > >higher level of type isolation and expressiveness, without loosing > >any performance, not having to consult compiler docs, > >isn't this a win? > > >I recall a c.l.ada message from a university teacher of embedded > >systems programming (model trains, I think) whose classes had > >switched from C to Ada. After that, the students had achieved more > >and got better results. The effect was attributed to Ada's > >fundamental type system and types defined in terms of the > >(abstracted) problem domain. =A0I.e., not just Interfaces. > > >> In <32e35e5a-3cae-4fdc-be4a-3ae1e146e...@l64g2000hse.googlegroups.com>= , Adam Beneschan writes: > > >>> Of course, it really doesn't matter which one you use (except, > >>> perhaps, to help prevent incorrect type conversions). =A0The only > >>> differences have to do with readability, pedagogy, and helping make > >>> your programs self-documenting. =A0But ever since Ada was designed, t= he > >>> position of the Ada community has been that it's better to avoid usin= g > >>> the standard numeric types provided by Ada (Integer, Float) and defin= e > >>> your own that explicitly include the numeric range you need. =A0You s= eem > >>> to be going in the opposite direction, by recommending that this user > >>> use a standard type provided by the language rather than defining his > >>> own (although the standard type you recommend is certainly better > >>> defined than Integer or Float). > > >>> Another issue is that an implementation doesn't have to provide > >>> Interfaces.Unsigned_64. =A0It should be present on any target process= or > >>> whose addressable unit is an 8-bit byte or a 16-, 32-, or 64-bit > >>> word. =A0But I've seen processors in the past that use 6-bit characte= rs > >>> or 36-bit words, and in those cases, using Unsigned_64 instead of "mo= d > >>> 2**64" will turn a portable program into a nonportable one. =A0I'll > >>> grant that such processors are rare these days. > > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--= Adam > > >-- > >Georg Bauhaus > >Y A Time Drainhttp://www.9toX.de- D=F6lj citerad text - > > - Visa citerad text - Well the word length on UNISYS (SPERRY) has nothing to do with power of three. A word could also be 6x6 bits. Or can, there are still some UNISYS equipment around.