From walter@bytecraft.com Tue Jun 22 15:25:09 2004 Return-Path: X-Original-To: embedded-c@open-std.org Delivered-To: embedded-c@open-std.org Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by ghz.klid.dk (Postfix) with ESMTP id 976DE3760A for ; Tue, 22 Jun 2004 15:25:05 +0200 (CEST) Received: from granite.sentex.ca (ns.sentex.ca [199.212.134.1]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i5MDOkUQ079399; Tue, 22 Jun 2004 09:24:47 -0400 (EDT) (envelope-from walter@bytecraft.com) Received: from bytecraft.com (p72ka.xDSL-1mm.sentex.ca [64.7.151.73]) by granite.sentex.ca (8.12.10/8.12.10) with ESMTP id i5MDOWke089652; Tue, 22 Jun 2004 09:24:41 -0400 (EDT) (envelope-from walter@bytecraft.com) Message-ID: <40D832A8.14807E81@bytecraft.com> Date: Tue, 22 Jun 2004 09:22:48 -0400 From: Walter Banks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: willemw@ace.nl Cc: embedded-c@open-std.org, John Hauser Subject: Re: (embedded-c.208) RE: Corrections on TR 18037 References: <20040622121742.B70833760C@ghz.klid.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > --- the current specification allows global named-registers > to be initialized: > register REG_A int reg_a = 32; Although we need to be clear on this issue we also need to point out that most processor registers are also volatile. On the compiler we did for an automotive engine controller one of the beta test groups heavily used structures and unions in their code. They did two interesting things. In the first case they put packed structures on the top of some of the processor registers both in the case of a processor register that had natural fields and in a case of a general purpose register. In another case they declared an index register as a pointer to struct which had the effect of generating some very tight code. w.. Willem Wakker wrote: > > There are some more problems/issues; I will produce a document > with a full list for the pre-Redmond meeting (which I am > planning to attend). > > --- the current specification allows global named-registers > to be initialized: > register REG_A int reg_a = 32; > It is however unclear when, and by whom this initialization > should be done (one could imagine that the register storage > onto which the variable maps does not really exist until some > device is initialized by some user code). > Proposal: disallow initializers on named-register variables. > > --- the relationship beween named-registers and 6.9.2 (external > object definitions) need to specified: when there is no > initializer in the named-register declaration, the declaration > is not an external definition for the identifier. The declaration > is however also not a tentative definition, because it has a > storage-class specifier. Then, what is it? > > --- consider > > // file 1 > register REG_A int reg_a; > > // file 2 > extern int reg_a; > int main() { return reg_a; } > > According to the new constraints for 6.7.1 this is not allowed: > "If an object is declared with a named-register storage-class > specifier, every declaration of that object shall include the > same named-register storage-class specifier." > The shall implies that a diagnostic is required here. However, so far > C compilers have not been required to diagnose such issues across > translation units. Is this really the intention? > > --- the rounding functions in 7.18a.6.3 require that "Fractional > bits beyond the rounding point are set to zero in the result"; > this should not apply when saturation has occurred. > > --- 7.18a.6.1 (fp arithmetic support functions) does not specify > what happens if an integer result overflows. > > --- the current text requires that overflow handling is done > before rounding; this is counter intuitive, and not what is done > for floating-point overflow/rounding. As it happens, the order > in which overflow and rounding are done has no effect on the > result when saturation is used for overflow handling. > Hence, if we change the order, the result remains the same > for saturation. However, with the current required order, mod_wrap > as overflow handling (which is allowed but not required) cannot > (reasonably) be implemented. It is therefore proposed to change > the order. > > - Willem Wakker. > > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > Willem Wakker email: > cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc > ACE Consulting bv tel: +31 20 664 6416 > De Ruyterkade 113 fax: +31 20 675 0389 > 1011 AB Amsterdam, The Netherlands www: http://www.ace.nl > eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee > > > -----Original Message----- > > From: John Hauser [mailto:jhauser@jhauser.us] > > Sent: Saturday, June 19, 2004 2:38 AM > > To: embedded-c@open-std.org > > Subject: (embedded-c.207) Corrections on TR 18037 > > > > > > > I have 2 corrections on the text of 18037; to be discussed in > > > Redmond for a TC. > > > > Those two don't look controversial. > > > > Where do we stand with the other fixes? Here's the list I know of: > > > > A. Rename "strtok" to "strto_k". (Ugh.) > > > > B. Remove the definition of "additionally access-qualified version of a > > type" from the new text for 6.2.5, and rewrite 6.5 as spelled out in > > message embedded-c.195. (Doug Gwyn has suggested replacing the word > > "minus" there by "without".) > > > > Sadly, I also discovered a new problem: > > > > C. In the new text for 6.7.2.1, the TR adds a constraint: > > > > The _specifier-qualifier-list_ in the declaration of a member of > > a structure or union shall not include an address space > > qualifier. > > > > This is a mistake, because it keeps us from declaring something > > innocuous like > > > > struct onePointer { _X int *pX; }; > > > > As written, the constraint would make the member declaration > > invalid, whereas we only intended to prohibit declarations such as > > this: > > > > struct oneInteger { _X int iX; }; > > > > I propose we change the constraint to be: > > > > Within a structure or union specifier, the type of a member > > shall not be qualified by an address space qualifier. > > > > > > Willem, will you be attending the Redmond meeting? If not, I could > > volunteer to go and be responsible for the TR and/or a TC. > > > > - John Hauser > > > > > >