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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1cf653444208df72 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-16 03:09:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news-FFM2.ecrc.net!news.iks-jena.de!lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: comp.lang.ada Subject: Re: ada vs. cpp Date: Tue, 16 Oct 2001 10:08:56 +0000 (UTC) Organization: IKS GmbH Jena Message-ID: References: <9q7na102nqn@drn.newsguy.com> <3BCBF40A.BBDD4FE6@free.fr> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1003226936 7136 217.17.192.37 (16 Oct 2001 10:08:56 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Tue, 16 Oct 2001 10:08:56 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Xref: archiver1.google.com comp.lang.ada:14644 Date: 2001-10-16T10:08:56+00:00 List-Id: * Jean-Marc Bourguet wrote: >Lutz Donnerhacke wrote: >> This DSP is always funny because sizeof(int[8]) == 4. This causes several >> memory reservation problems. > >This is not a standard conforming implementation which requires: > >sizeof(char) = 1 Ack. >sizeof(int) >= sizeof(char) Ack. Implementation holds, because sizeof(int) == 1. >sizeof(int[8]) = 8 * sizeof(int) Nack. Or are packed arrays unsupported? Even, if the addressing granularity is finer than the character size? >so sizeof(int[8]) >= 8 No necessary. Let's have a look at X3-J11 (C99): 6.5.3.4 The sizeof operator : Semantics : :2 The sizeof operator yields the size (in bytes) of its operand, ... : :3 When applied to an operand that has type char, unsigned char, or signed : char (...) the result is 1. When applied to an operant that hast array : type, the result is the total number of bytes in the array. ... Consequence: No compiler is a conforming one when a char is not a byte?! And look! 3.7.1 says: : character: single-byte character: bit representation that fits in a byte. But oops! That's not a char. 6.2.5 says :3 An object declared as type char is large enough to store any member of the : basic execution character set. If a member of the basic execution set is : stored in a char object, its value is guaranteed to be positive. If any : other character is stored in a char object, the resulting value is : implementation-defined but shall be within the range of values that can be : represented in that type. There is no reason for a byte limited character. But 6.2.6.1 contains an interesting note: :3 Values stored in unsigned bit-fields and objects of type unsigned char : shall be represented using a pure binary notation. 40) : :4 Values stored in non-bit-field objects of any other object type consits of : n x CHAR_BIT bits, where n is the size of an object of that type, in bytes. : ... :40) ... A byte contains CHAR_BIT bits ... Ah I see: C requires (by a footnote) that Storage_Units are similar to a char. Unfortunly this DSP addresses 32bit objects and is able to deal efficiently with 16bit registers. An other DSP I have changes the Storage_Unit over the address range: Starting with 8 bit bytes from 0 .. 16#f_ffff#, 16 bit bytes from 16#10_0000# .. 16#1f_ffff#, and 32 bit bytes from 16#2f_ffff# .. 16#ffff_ffff#. *gna*