--------
7.19.6 Formatted input/output functions

1 The formatted input/output functions shall behave as
if there is a sequence point after the actions
associated with each specifier.
--------

(There is a footnote about fprintf associated with the above.
But it seems more by way of providing an example than by
limiting the meaning of the above, so I don't include it
here.)

Is this serious? A sequence point (as if) between each
specifier? In other words, the following has defined
behavior?

int *s= &mybuf[0];
scanf( "%d %d %d", s++, s++, s++ );

I would have imagined otherwise. Or I'm just reading the text
wrong.

Thanks,
Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

The behavior is defined and is older than C99.

The following is on OpenIndiana x86 w/ the Sun compiler. -xtransition warn=
s about changes between K&R and ISO C.
oi%rhb {71} cat tst.c
#include

int main(){

int i = 0;

printf( "%d %d %d\n" ,i++ ,i++ ,i++ );

}


oi%rhb {72} cc -xtransition -o tst tst.c
oi%rhb {73} ./tst
0 1 2
oi%rhb {74}


FWIW Reasonable levels of compiler complexity mandate the rule. There's a =
tendency to forget that the MSP430 is about as powerful as the PDP11 on whi=
ch C was created.

Have Fun!
Reg

--- On Tue, 8/7/12, Jon Kirwan wrote:

> From: Jon Kirwan
> Subject: [msp430] C 1999 standard question I'm not clear on
> To: "MSP430 List"
> Date: Tuesday, August 7, 2012, 6:14 PM
> --------
> 7.19.6 Formatted input/output functions
>
>   1   The formatted input/output
> functions shall behave as
>       if there is a sequence point after the
> actions
>       associated with each specifier.
> --------
>
> (There is a footnote about fprintf associated with the
> above.
> But it seems more by way of providing an example than by
> limiting the meaning of the above, so I don't include it
> here.)
>
> Is this serious? A sequence point (as if) between each
> specifier? In other words, the following has defined
> behavior?
>
>   int *s= &mybuf[0];
>   scanf( "%d %d %d", s++, s++, s++ );
>
> I would have imagined otherwise. Or I'm just reading the
> text
> wrong.
>
> Thanks,
> Jon
>
>
>
>
>
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Tue, 7 Aug 2012 18:57:53 -0700 (PDT), you wrote:

>The behavior is defined and is older than C99.

I was only looking at C99 standard when reading that part.

What surprised me is that (I believe) calls to other, non
stdio.h functions, would be undefined behavior. I think the
value of a variable can be read (once) only so as to perform
the ++ or -- update to it. But the idea that each specifier
indicates a sequence point seems to place restrictions. Were
I doing this, I think I'd evaluate each parameter to a
function call from left to right ALWAYS, so as to permit
easier handling of the stdio.h cases.

No matter how it plays, another interesting point is that the
standard ONLY makes this point about these I/O functions. Not
others.

I suppose it is because of %n.

>The following is on OpenIndiana x86 w/ the Sun compiler. -xtransition warns about changes between K&R and ISO C.
>
>oi%rhb {71} cat tst.c
>#include
>int main(){
> int i = 0;
> printf( "%d %d %d\n" ,i++ ,i++ ,i++ );
>}
>
>oi%rhb {72} cc -xtransition -o tst tst.c
>oi%rhb {73} ./tst
>0 1 2
>oi%rhb {74}
>
> FWIW Reasonable levels of compiler complexity mandate the
> rule. There's a tendency to forget that the MSP430 is about
> as powerful as the PDP11 on which C was created.

Well.... not quite.
http://www.infinitefactors.org/jonk/msp430.html

Thanks for the addition. And I'm still curious to hear from
those who know the darker corners of this.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> http://www.infinitefactors.org/jonk/msp430.html

Nice page. Take a look at the MSP430X instruction set (with extended address
space) even more compromisses ;-).

M.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 8 Aug 2012 07:26:27 +0000 (UTC), you wrote:

>> http://www.infinitefactors.org/jonk/msp430.html
>
>Nice page. Take a look at the MSP430X instruction set (with extended address
>space) even more compromisses ;-).

Oh, please. I don't want to get depressed, again. Anything in
particular you want to draw my attention towards and ruin my
day with? ;)

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On 08/08/2012 09:34, Jon Kirwan wrote:
> On Wed, 8 Aug 2012 07:26:27 +0000 (UTC), you wrote:
>
> >> http://www.infinitefactors.org/jonk/msp430.html
> >
> >Nice page. Take a look at the MSP430X instruction set (with extended
> address
> >space) even more compromisses ;-).
>
> Oh, please. I don't want to get depressed, again. Anything in
> particular you want to draw my attention towards and ruin my
> day with? ;)
>
> Jon
>

How about the whole concept of 20-bit data, registers and addresses?
It's a complete mess, causes immense hassle for tool developers, and
makes function prologue/epilogue (especially for interrupts) take twice
the ram and twice the time, since you have to save twice the data (since
/maybe/ the caller has 20-bit data in the register at the time).

If you want to introduce longer addressing to a 16-bit chip, the only
sane way to do it is to have double registers for 32-bit addresses.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> On 08/08/2012 09:34, Jon Kirwan wrote:
> > On Wed, 8 Aug 2012 07:26:27 +0000 (UTC), you wrote:
> >
> > >> http://www.infinitefactors.org/jonk/msp430.html
> > >
> > >Nice page. Take a look at the MSP430X instruction set (with extended
> > address
> > >space) even more compromisses ;-).
> >
> > Oh, please. I don't want to get depressed, again. Anything in
> > particular you want to draw my attention towards and ruin my day with?
> > ;)
> >
> > Jon
> >
>
> How about the whole concept of 20-bit data, registers and addresses?
> It's a complete mess, causes immense hassle for tool developers, and make=
s
> function prologue/epilogue (especially for interrupts) take twice the ram
> and twice the time, since you have to save twice the data (since /maybe/
> the caller has 20-bit data in the register at the time).
>
> If you want to introduce longer addressing to a 16-bit chip, the only san=
e
> way to do it is to have double registers for 32-bit addresses.

Well, having seen the architecture develop before what was introduced, what
you have now is better than what was originally proposed. :-)

The designers of the MSP430 did not want to go to a 32-bit architecture.
The 20-bit architecture is a half-way house.

I think that RAL's implementation of extended addressing is probably what
most would want: code that can span the whole 1MB address space with data
limited to 16 bits. It is a compromise, some customers do want 20-bit data
addressing, but they do not understand the implications at the machine leve=
l
of what they ask for.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

The format argument rules for printf & scanf are fairly complex They tell =
the library function how many arguments to expect to find on the stack and =
even to get the precision part of the format string from the stack.

An obvious way to implement the functions would be to scan the format strin=
g counting descriptors and then sit in a loop executing operations for each=
of the descriptors and the corresponding argument going from left to right=
.

In the jargon of C, that implies a sequence point between each format descr=
iptor. The var args discussion in section 7.15 and in particular, the rati=
onal give more information, albeit, rather tersely. I think you'll find i=
t is doing the obvious thing given the complexities that variable argument =
functions must handle.

There was great concern about implementing var args in a portable fashion w=
/o imposing performance constraints.

Have Fun!
Reg

FWIW The 2nd edition of Unix was developed on a PDP 11/20 which was a 16 bi=
t machine that had 8 KB of memory. That was the machine used to implement =
the typesetting system for the patent department. The success of that syst=
em led to a quick succession of larger machines. It's hard to tell from t=
he Bell System Technical Journal papers what machine was in use when C was =
created.

There's quite a bit of interesting history in "Unix System Readings and App=
lications". Most of the papers are available on line now.

BTW thanks for the link. Good stuff.

--- On Tue, 8/7/12, Jon Kirwan wrote:

> From: Jon Kirwan
> Subject: Re: [msp430] C 1999 standard question I'm not clear on
> To: "MSP430 List"
> Date: Tuesday, August 7, 2012, 9:28 PM
> On Tue, 7 Aug 2012 18:57:53 -0700
> (PDT), you wrote:
>
> >The behavior is defined and is older than C99.
>
> I was only looking at C99 standard when reading that part.
>
> What surprised me is that (I believe) calls to other, non
> stdio.h functions, would be undefined behavior. I think the
> value of a variable can be read (once) only so as to
> perform
> the ++ or -- update to it. But the idea that each specifier
> indicates a sequence point seems to place restrictions.
> Were
> I doing this, I think I'd evaluate each parameter to a
> function call from left to right ALWAYS, so as to permit
> easier handling of the stdio.h cases.
>
> No matter how it plays, another interesting point is that
> the
> standard ONLY makes this point about these I/O functions.
> Not
> others.
>
> I suppose it is because of %n.
>
> >The following is on OpenIndiana x86 w/ the Sun
> compiler.  -xtransition warns about changes between
> K&R and ISO C.
> >
> >oi%rhb {71} cat tst.c
> >#include
> >int main(){
> >   int i = 0;
> >   printf( "%d %d %d\n" ,i++ ,i++ ,i++
> );
> >}
> >   
> >oi%rhb {72} cc -xtransition -o tst tst.c
> >oi%rhb {73} ./tst
> >0 1 2
> >oi%rhb {74}
> >   
> > FWIW Reasonable levels of compiler complexity mandate
> the
> > rule.  There's a tendency to forget that the
> MSP430 is about
> > as powerful as the PDP11 on which C was created. 
>
>
> Well.... not quite.
>     http://www.infinitefactors.org/jonk/msp430.html
>
> Thanks for the addition. And I'm still curious to hear from
> those who know the darker corners of this.
>
> Jon
>
>
>
>
>
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 8 Aug 2012 05:56:57 -0700 (PDT), you wrote:

> FWIW The 2nd edition of Unix was developed on a PDP 11/20
> which was a 16 bit machine that had 8 KB of memory. That
> was the machine used to implement the typesetting system for
> the patent department. The success of that system led to a
> quick succession of larger machines. It's hard to tell from
> the Bell System Technical Journal papers what machine was in
> use when C was created.

I worked on Unix v6 kernel back in the day. Two years after
release, though, memory serving. Early 1978.

> There's quite a bit of interesting history in "Unix System
> Readings and Applications". Most of the papers are
> available on line now.

Yes, I've read at least a few.

>BTW thanks for the link. Good stuff.

Thanks for the kind comment!

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )