On Tue, 30 Dec 2003 14:19:57 +1000, Clyde wrote:
>On Tue, Dec 30, 2003 at 12:55:42AM -0000, Wolfgang
Reich wrote:
>> Yes, in any implementation I've seen, the caller stores
>> the "placeholder" c and all ... parameters on the stack.
>
>It's not actually necessary to pass the placeholder on the
>stack. It's often done that way (and the ANSI va_start()
>macro requires the placeholder as an argument) but there
>are other ways.
I'm interested in the details, if you are willing to expand a
little on this comment.
Jon
C compiler parameter passing question for the MSP430 target
Started by ●December 29, 2003
Reply by ●December 30, 20032003-12-30
Reply by ●December 30, 20032003-12-30
On Tue, 30 Dec 2003 14:27:45 +1000, Clyde wrote:
>On Mon, Dec 29, 2003 at 05:19:36PM -0800, Jonathan
Kirwan wrote:
>> Okay. But it's also legal to use a parameter prior to the last
>> one before the placeholder. An example of this, in fact, is in
>
>Well, it's not legal. The text is quite specific, the example you cite
is clearly
>wrong. If you look at the foreword to the standard, it states that examples
>are for information only, not part of the standard.
Another thought crosses my mind...
Does this suggest that the example is drawn from code actually
compiled on some compiler, though? And if so, does strict
conformance to the standard mean that code like this, perhaps
found in the "real world", will break? Do compiler vendors
concern themselves with breaking existing code despite the
standards suggesting that they are allowed to do so? Or in
other words, would a compiler vendor be well-advised to make
sure that code like that example *does* work just fine?
Just curious...
Jon
Reply by ●December 30, 20032003-12-30
> On Tue, Dec 30, 2003 at 12:55:42AM -0000, Wolfgang Reich wrote: > > Yes, in any implementation I've seen, the caller stores > > the "placeholder" c and all ... parameters on the stack. > > It's not actually necessary to pass the placeholder on the > stack. It's often done that way (and the ANSI va_start() > macro requires the placeholder as an argument) but there are > other ways. Agreed. Our placeholder is not (in general) passed on the stack, it's treated as a standard parameter like any other. We have an intrinsic function that delivers the base of the variadic part of a function. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430 and ARM processors
Reply by ●December 30, 20032003-12-30
> > On Tue, Dec 30, 2003 at 12:55:42AM -0000, Wolfgang Reich wrote: > > > Yes, in any implementation I've seen, the caller stores > > > the "placeholder" c and all ... parameters on the stack. > > > > It's not actually necessary to pass the placeholder on the > > stack. It's often done that way (and the ANSI va_start() > > macro requires the placeholder as an argument) but there are > > other ways. > > Agreed. Our placeholder is not (in general) passed on the stack, it's > treated as a standard parameter like any other. We have an intrinsic > function that delivers the base of the variadic part of a function. And this intrinsic function doesn't need any argument, yes? So the argument passed to va_start() is simply ignored? If this is so, then Jon's example program http://groups.yahoo.com/group/msp430/message/6370 will work.
Reply by ●December 30, 20032003-12-30
Wolfgang, > > > On Tue, Dec 30, 2003 at 12:55:42AM -0000, Wolfgang Reich wrote: > > > > Yes, in any implementation I've seen, the caller stores the > > > > "placeholder" c and all ... parameters on the stack. > > > > > > It's not actually necessary to pass the placeholder on the stack. > > > It's often done that way (and the ANSI va_start() macro requires > > > the placeholder as an argument) but there are other ways. > > > > Agreed. Our placeholder is not (in general) passed on the stack, > it's > > treated as a standard parameter like any other. We have an > intrinsic > > function that delivers the base of the variadic part of a function. > > And this intrinsic function doesn't need any argument, yes? Correct. > So the argument passed to va_start() is simply ignored? paramN is ignored. paramN is required is for old-style compilers based on Johnson's pcc, IMO. > If this is so, then Jon's example program > http://groups.yahoo.com/group/msp430/message/6370 will work. Correct, although it is an erroneous program by the standard. The correction doesn't appear in TC1 either. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430 and ARM processors
Reply by ●December 30, 20032003-12-30
On Tue, 30 Dec 2003 14:23:12 -0000, you wrote: >Wolfgang, > >> > > On Tue, Dec 30, 2003 at 12:55:42AM -0000, Wolfgang Reich wrote: >> > > > Yes, in any implementation I've seen, the caller stores the >> > > > "placeholder" c and all ... parameters on the stack. >> > > >> > > It's not actually necessary to pass the placeholder on the stack. >> > > It's often done that way (and the ANSI va_start() macro requires >> > > the placeholder as an argument) but there are other ways. >> > >> > Agreed. Our placeholder is not (in general) passed on the stack, >> it's >> > treated as a standard parameter like any other. We have an >> intrinsic >> > function that delivers the base of the variadic part of a function. >> >> And this intrinsic function doesn't need any argument, yes? > >Correct. > >> So the argument passed to va_start() is simply ignored? > >paramN is ignored. paramN is required is for old-style compilers based >on Johnson's pcc, IMO. > >> If this is so, then Jon's example program >> http://groups.yahoo.com/group/msp430/message/6370 will work. > >Correct, although it is an erroneous program by the standard. The >correction doesn't appear in TC1 either. Just for those who may be interested, I tracked down a few bits and pieces which may help out. The following PDF files are available: Latest Draft for ISO/IEC 9899:1999 C Standard: : http://std.dkuug.dk/jtc1/sc22/open/n2794/n2794.pdf This is __NOT__ the final standard, which must be purchased. But it's the last draft that was made available to the public; I believe this is a copy of what was available prior to the final standard being released. The purchased version of the PDF also includes a convenient set of bookmarks -- so that's one way to tell what you've got in hand. Latest Draft Rationale (revision 2) that I have: : http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf As far as I'm aware, this is a _draft_ of the Rationale for the ISO/IEC 9899:1999 C Standard. But it may be the actual Rationale, too. I just don't know. Full Technical Corrigendum 1 for the 1999 C standard: : http://ftp2.ansi.org/download/free_download.asp?document=ISO%2FIEC+9899%2FCor1%3A2001 This is, so far as I'm aware, the actual and official version of the Technical Corrigendum 1 for ISO/IEC 9899:1999 C Standard. I believe WG14 held a vote on making this one available to the public and approved that proposal some time ago. A draft of the "Extensions for the programming language C to support embedded processors": : http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n1021.pdf This is from JTC1 NP 18037, Extensions for the programming language C to support embedded processors, whose project director is Willem Wakker, I believe. Just for information. Jon
Reply by ●December 30, 20032003-12-30
On Tue, 30 Dec 2003 11:42:24 -0800, I wrote:
>Latest Draft Rationale (revision 2) that I have:
>: http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf
>As far as I'm aware, this is a _draft_ of the Rationale for the
>ISO/IEC 9899:1999 C Standard. But it may be the actual
>Rationale, too. I just don't know.
Whoops! This may be the Rationale for C9X and, if I understand
what's written (I may not), that's the C95 standard (C90 + TCOR1
+ TCOR2 + AMD1) and not for the 1999 standard.
Jon
Reply by ●December 30, 20032003-12-30
On Tue, 30 Dec 2003 12:29:00 -0800, I wrote: >On Tue, 30 Dec 2003 11:42:24 -0800, I wrote: > >>Latest Draft Rationale (revision 2) that I have: >>: http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf >>As far as I'm aware, this is a _draft_ of the Rationale for the >>ISO/IEC 9899:1999 C Standard. But it may be the actual >>Rationale, too. I just don't know. > >Whoops! This may be the Rationale for C9X and, if I understand >what's written (I may not), that's the C95 standard (C90 + TCOR1 >+ TCOR2 + AMD1) and not for the 1999 standard. > >Jon Ah, I may have found it. I think N937 is the current draft Rationale. They keep rolling the numbers forward in order to confuse me. ;) http://awgn.antifork.org/openbook/n937.pdf Jon
Reply by ●December 30, 20032003-12-30
On Mon, Dec 29, 2003 at 09:44:07PM -0800, Jonathan Kirwan wrote: > I'm interested in the details, if you are willing to expand a > little on this comment. Well, for example, our PIC compiler passes the address of the variable argument list as a hidden parameter. It has no relation to the address of any other parameter. The PIC has no argument stack. Clyde -- Clyde Stubbs | HI-TECH Software Email: clyde@clyd... | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger clyde@clyd... | AUS: +61 7 3552 7777 +61 7 3552 7778 --- HI-TECH C: compiling the real world.
Reply by ●December 30, 20032003-12-30
On Mon, Dec 29, 2003 at 09:50:29PM -0800, Jonathan Kirwan wrote: > Does this suggest that the example is drawn from code actually > compiled on some compiler, though? And if so, does strict Perhaps. > conformance to the standard mean that code like this, perhaps > found in the "real world", will break? Do compiler vendors It's certainly possible. > concern themselves with breaking existing code despite the > standards suggesting that they are allowed to do so? Or in It depends. In this case, my opinion would be no. There are other cases where it is clearly appropriate to go beyond what is required by the standard, e.g. the maximum allowed length of a line after all macro expansions is something like 512 or 1024, but lots of real world applications need more. Similarly with length of variable names - the standard only requires that 31 characters be significant, but some applications (in particular machine-generated C code) need more. For that particular issue we provide an option to set the number of significant characters, but 31 is the default. -- Clyde Stubbs | HI-TECH Software Email: clyde@clyd... | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger clyde@clyd... | AUS: +61 7 3552 7777 +61 7 3552 7778 --- HI-TECH C: compiling the real world.
