John,

> This is about as black and white as it can get with regard to
> interpreting a standard which attempts to deal with the 'unknown'.
>
> Paragraph 6 of Section 6.7.3 of the ISO C standard on 'Type
> qualifiers' states "An object that has volatile-qualified type may be
> modified in ways unknown to the implementation or have other unknown
> side effects."
>
> In simpler terms this tells a compiler DO NOT MAKE ANY ASSUMPTIONS. I
> don't think I need to SPELL OUT why assigning ANY volatile declared
> object to a register is certainly making assumptions about usage of
> the variable.

Volatile qualified requires only that loads/stores are done at required
points and that volatile-qualified variables hold their values in the face
of setjmp and longjmp. What a compiler does with volatile-qualified data,
and how it does it, is implementation defined.

If I use R15 to hold the volatile 'c', it's no different from holding it in
memory. The user either has to know which register it's held in or which
stack location it's held at. Both are inaccessible from standard C. Hence,
using R15 is just as valid as 2(sp)--an ISR would be *better* placed to know
that R15 is where a volatile lay than at 2(SP) which changes.

> Point proven. The naive go off thinking every other compiler is
> inferior because using registers shortens code and improves
> benchmarks.

Actually, not. You might think you've proven the point but then I
conjecture you haven't actually written a production C toolchain.

> With regard to 'jump tables'. Both CCE and IAR provide KNOWN ways to
> generate jump tables. On enquiry Rowley was dismissive.

Oh, I provided examples of O(1) performance from switch using an indexed
table.

> If there was
> a way of generating jump tables they weren't going to tell us. Rather
> odd given that the MSP430 has some interrupt facilities that are
> ideally suited to jump table use, aside from the enormous general
> benefits of jump tables.

Oh, and here we go again. Of course, you're now stepping outside the
standard, aren't you? Of course. Standard suits you when you want to take
a shots and doesn't when you want to try to put your favourite compiler in a
good light.

> I did notice that a listing of ARM assembly code from C from the OPEN
> SOURCE compiler USED by Rowley, that was posted on another group, did
> produce a jump table. I was impressed and said this on the group.
>
> Despite this don't think projects can be easily ported. Normal ARM
> GCC linker command files are generated by Rowley only as long as they
> are needed and then deleted.

What has that got to do with volatile? I have to tell you your deflection
isn't working.

> There have been public comments about not been able to identify any
> contributions made from Rowley to the development of the open source
> compiler used by them. The cutting edge contributions, at the time,
> were coming from www.opensourcery.com, which were well ahead of the
> stultifying, politicised and bureaucratic snails pace the open source
> GCC movement was working at.

...and what has that got to do with it? We provide the sources of the GCC
we distribute, we don't cripple them in any way. So, what EXACTLY are you
saying here, Jon? We're allowed to do this just as much as Hitex are who
ship GCC, or Keil who shipped GCC, or Ronetix who ship GCC, the list is
endless. Isn't that what OPEN SOURCE is all about?

Point me to the place where, in the GPL, it says I can't offer GCC
pre-built?

> Make up your own minds about what is doing on.

And what is "doing on" [sic]?

I asked you to point to a point in the standard that says that I can't use
registers for volatile. You can't. You lose.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Start a New Thread

John,

> This is about as black and white as it can get with regard to
> interpreting a standard which attempts to deal with the 'unknown'.
>
> Paragraph 6 of Section 6.7.3 of the ISO C standard on 'Type
> qualifiers' states "An object that has volatile-qualified type may be
> modified in ways unknown to the implementation or have other unknown
> side effects."
>
> In simpler terms this tells a compiler DO NOT MAKE ANY ASSUMPTIONS. I
> don't think I need to SPELL OUT why assigning ANY volatile declared
> object to a register is certainly making assumptions about usage of
> the variable.
>
> Point proven.

No, point not proven at all, so don't become a barrister. Paragraph 6 of
section 6.7.3 goes on to say:

"... Therefore any expression referring to such an object shall be evaluated
strictly according to the rules of the abstract machine,
as described in 5.1.2.3. Furthermore, at every sequence point the value last
stored in the object shall agree with that prescribed by the abstract
machine, except as modified by the unknown factors mentioned previously.
What constitutes an access to an object that
has volatile-qualified type is implementation-defined."

There's no reference to "don't use a register". In fact, "What constitutes
an access to an object that has volatile-qualified type is
implementation-defined" gives the implementor the ability to define that
access to a volatile-qualified auto is by register *in this case*. But you
omitted that because it doesn't support your argument, it directly
contradicts your argument. (Don't become a barrister, become a politician!)

For auto volatiles, we have the Archelon compiler placing them in registers,
along with CrossWorks (for MSP430, AVR, and MAXQ), and to that I can add the
ARM RealView compiler (evidence below). So far three compilers are
uncovered that put volatile autos in registers and CCE that elects not to.
I'm certain some compilers will, some won't, depending upon *context*.
Certainly the architecture of the code generator that forces memory-based
volatile objects will be simpler *because* those objects do not occupy (the
equivalent of) virtual registers and, therefore, will not subject to classic
optimizations--which is exactly what you require of a volatile object.

Now the evidence from the ARM RealView compiler:

119: void foo(void)
120: {
121: volatile int x;
0x000003A4 E8BD8070 LDMIA R13!,{R4-R6,PC}
122: for (x = 0; x < 100; ++x)
123: ;
0x000003A8 E3A00000 MOV R0,#0x00000000
0x000003AC EA000000 B 0x000003B4
0x000003B0 E2800001 ADD R0,R0,#0x00000001
0x000003B4 E3500064 CMP R0,#0x00000064
0x000003B8 BAFFFFFC BLT 0x000003B0
124: }
125:
0x000003BC E12FFF1E BX R14

> The naive go off thinking every other compiler is
> inferior because using registers shortens code and improves
> benchmarks.

Game over, man, game over! You do not have a persuasive argument. I'm
sorry, you lose this one.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Start a New Thread

You just don't seem to get it. Whether some of your comments were
passing or not, there were good grounds to belive you were joining in
the bullying.

No I was not polite in my response to your passing amateurish remarks
but I was certainly not rude or poorly behaved.

Don't expect politeness if you attack. If you have comments of a
factual nature and expect a polite response, then keep them factual,
which you have certainly failed to do now.

John Heenan

--- In m..., Jon Kirwan wrote:
>
> On Thu, 29 May 2008 03:48:24 -0000, John wrote:
>
> >Sorry if I misinterpreted you. Next time leave the amateurish
bullying
> >psychology out if you expect a polite rerpsonse.
> >
> >John heenan
>
> I will be glad to respond in kind. I started out without name
calling
> and you responded poorly to it. A prod towards better behavior on
> your part is well-reasoned under those circumstances. I'd recommend
> you take your own above advice.
>
> Jon

> >--- In m..., Jon Kirwan wrote:
> >>
> >> On Thu, 29 May 2008 01:16:40 -0000, John wrote:
> >>
> >> >
> >> >5. Now we have a third bully excusing other bullies.
> >>
> >> So someone who doesn't find your earlier argument persuasive
(nor your
> >> current one referencing section 6.7.3), but who struggles to see
if
> >> there might be another way to agree in the broadest way is to be
said
> >> to be bullying you?
> >>
> >> You make me chuckle.
> >>
> >> Jon
> >>
>
Start a New Thread

This is an EXPLICIT simple black and white proof, with additonal
comments, that Rowley is not standards conformant with regard to use
of the the word volatile.

The proof appears banal, however it is a valid proof and it is in the
appropriate style of a valid proof.

The standard requires a volatile qualified object may be modified in
ways unknown. This requires a compiler allows an object to be
modified in ways unknown. If the compiler does not explicitly, with
certainty point and with 100% reliability out how a volatile object
can be modified in ways unknown then the compiler is not standards
conformant.

Rowley does not point put how their volatile qualified object can be
modified in ways unknown. Therefore Rowley is not standards
conformant with regard to the use of the qualifier volatile.

This is the end of the proof.

If Rowley chooses to point out how volatile qualified objects can be
modified reliably with certainty in ways unknown then it can be
argued Rowley will become standards conformant with regard to the use
of the word volatile at a purely technical level that ignores
community expectations.

If they continue to persist in using registers for auto variable
objects declared volatile, even if they point out how they can be
modified they will be out of step with expectations with what is
expected. Hence they will not be conformant at a community level,
which it can be argued is also a relevant standards 'unknown'.

John Heenan

--- In m..., "Paul Curtis" wrote:
>
> John,
>
> > This is about as black and white as it can get with regard to
> > interpreting a standard which attempts to deal with the 'unknown'.
> >
> > Paragraph 6 of Section 6.7.3 of the ISO C standard on 'Type
> > qualifiers' states "An object that has volatile-qualified type
may be
> > modified in ways unknown to the implementation or have other
unknown
> > side effects."
> >
> > In simpler terms this tells a compiler DO NOT MAKE ANY
ASSUMPTIONS. I
> > don't think I need to SPELL OUT why assigning ANY volatile
declared
> > object to a register is certainly making assumptions about usage
of
> > the variable.
> >
> > Point proven.
>
> No, point not proven at all, so don't become a barrister.
Paragraph 6 of
> section 6.7.3 goes on to say:
>
> "... Therefore any expression referring to such an object shall be
evaluated
> strictly according to the rules of the abstract machine,
> as described in 5.1.2.3. Furthermore, at every sequence point the
value last
> stored in the object shall agree with that prescribed by the
abstract
> machine, except as modified by the unknown factors mentioned
previously.
> What constitutes an access to an object that
> has volatile-qualified type is implementation-defined."
>
> There's no reference to "don't use a register". In fact, "What
constitutes
> an access to an object that has volatile-qualified type is
> implementation-defined" gives the implementor the ability to define
that
> access to a volatile-qualified auto is by register *in this case*.
But you
> omitted that because it doesn't support your argument, it directly
> contradicts your argument. (Don't become a barrister, become a
politician!)
>
> For auto volatiles, we have the Archelon compiler placing them in
registers,
> along with CrossWorks (for MSP430, AVR, and MAXQ), and to that I
can add the
> ARM RealView compiler (evidence below). So far three compilers are
> uncovered that put volatile autos in registers and CCE that elects
not to.
> I'm certain some compilers will, some won't, depending upon
*context*.
> Certainly the architecture of the code generator that forces memory-
based
> volatile objects will be simpler *because* those objects do not
occupy (the
> equivalent of) virtual registers and, therefore, will not subject
to classic
> optimizations--which is exactly what you require of a volatile
object.
>
> Now the evidence from the ARM RealView compiler:
>
> 119: void foo(void)
> 120: {
> 121: volatile int x;
> 0x000003A4 E8BD8070 LDMIA R13!,{R4-R6,PC}
> 122: for (x = 0; x < 100; ++x)
> 123: ;
> 0x000003A8 E3A00000 MOV R0,#0x00000000
> 0x000003AC EA000000 B 0x000003B4
> 0x000003B0 E2800001 ADD R0,R0,#0x00000001
> 0x000003B4 E3500064 CMP R0,#0x00000064
> 0x000003B8 BAFFFFFC BLT 0x000003B0
> 124: }
> 125:
> 0x000003BC E12FFF1E BX R14
>
> > The naive go off thinking every other compiler is
> > inferior because using registers shortens code and improves
> > benchmarks.
>
> Game over, man, game over! You do not have a persuasive argument.
I'm
> sorry, you lose this one.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>

Start a New Thread

John, how would you implement automatic volatile for the following
example using your choice of machine

void delay (void)
{
volatile int x;

for (x0; x; x--)
{
;
}
}

?

On 29-May-08, at 5:15 PM, John Heenan wrote:

> This is an EXPLICIT simple black and white proof, with additonal
> comments, that Rowley is not standards conformant with regard to use
> of the the word volatile.
>
> The proof appears banal, however it is a valid proof and it is in the
> appropriate style of a valid proof.
>
> The standard requires a volatile qualified object may be modified in
> ways unknown. This requires a compiler allows an object to be
> modified in ways unknown. If the compiler does not explicitly, with
> certainty point and with 100% reliability out how a volatile object
> can be modified in ways unknown then the compiler is not standards
> conformant.
>
> Rowley does not point put how their volatile qualified object can be
> modified in ways unknown. Therefore Rowley is not standards
> conformant with regard to the use of the qualifier volatile.
>
> This is the end of the proof.
>
> If Rowley chooses to point out how volatile qualified objects can be
> modified reliably with certainty in ways unknown then it can be
> argued Rowley will become standards conformant with regard to the use
> of the word volatile at a purely technical level that ignores
> community expectations.
>
> If they continue to persist in using registers for auto variable
> objects declared volatile, even if they point out how they can be
> modified they will be out of step with expectations with what is
> expected. Hence they will not be conformant at a community level,
> which it can be argued is also a relevant standards 'unknown'.
>
> John Heenan
>
> --- In m..., "Paul Curtis" wrote:
> >
> > John,
> >
> > > This is about as black and white as it can get with regard to
> > > interpreting a standard which attempts to deal with the 'unknown'.
> > >
> > > Paragraph 6 of Section 6.7.3 of the ISO C standard on 'Type
> > > qualifiers' states "An object that has volatile-qualified type
> may be
> > > modified in ways unknown to the implementation or have other
> unknown
> > > side effects."
> > >
> > > In simpler terms this tells a compiler DO NOT MAKE ANY
> ASSUMPTIONS. I
> > > don't think I need to SPELL OUT why assigning ANY volatile
> declared
> > > object to a register is certainly making assumptions about usage
> of
> > > the variable.
> > >
> > > Point proven.
> >
> > No, point not proven at all, so don't become a barrister.
> Paragraph 6 of
> > section 6.7.3 goes on to say:
> >
> > "... Therefore any expression referring to such an object shall be
> evaluated
> > strictly according to the rules of the abstract machine,
> > as described in 5.1.2.3. Furthermore, at every sequence point the
> value last
> > stored in the object shall agree with that prescribed by the
> abstract
> > machine, except as modified by the unknown factors mentioned
> previously.
> > What constitutes an access to an object that
> > has volatile-qualified type is implementation-defined."
> >
> > There's no reference to "don't use a register". In fact, "What
> constitutes
> > an access to an object that has volatile-qualified type is
> > implementation-defined" gives the implementor the ability to define
> that
> > access to a volatile-qualified auto is by register *in this case*.
> But you
> > omitted that because it doesn't support your argument, it directly
> > contradicts your argument. (Don't become a barrister, become a
> politician!)
> >
> > For auto volatiles, we have the Archelon compiler placing them in
> registers,
> > along with CrossWorks (for MSP430, AVR, and MAXQ), and to that I
> can add the
> > ARM RealView compiler (evidence below). So far three compilers are
> > uncovered that put volatile autos in registers and CCE that elects
> not to.
> > I'm certain some compilers will, some won't, depending upon
> *context*.
> > Certainly the architecture of the code generator that forces memory-
> based
> > volatile objects will be simpler *because* those objects do not
> occupy (the
> > equivalent of) virtual registers and, therefore, will not subject
> to classic
> > optimizations--which is exactly what you require of a volatile
> object.
> >
> > Now the evidence from the ARM RealView compiler:
> >
> > 119: void foo(void)
> > 120: {
> > 121: volatile int x;
> > 0x000003A4 E8BD8070 LDMIA R13!,{R4-R6,PC}
> > 122: for (x = 0; x < 100; ++x)
> > 123: ;
> > 0x000003A8 E3A00000 MOV R0,#0x00000000
> > 0x000003AC EA000000 B 0x000003B4
> > 0x000003B0 E2800001 ADD R0,R0,#0x00000001
> > 0x000003B4 E3500064 CMP R0,#0x00000064
> > 0x000003B8 BAFFFFFC BLT 0x000003B0
> > 124: }
> > 125:
> > 0x000003BC E12FFF1E BX R14
> >
> > > The naive go off thinking every other compiler is
> > > inferior because using registers shortens code and improves
> > > benchmarks.
> >
> > Game over, man, game over! You do not have a persuasive argument.
> I'm
> > sorry, you lose this one.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>

Start a New Thread

I realise that my question might not be pedantic

On your choice of machine, how would your conformant compiler
implementation compile the following function? I'd like to see how you
think a compiler implementation should compile this code.

Veronica

On 29-May-08, at 5:43 PM, Veronica Merryfield wrote:

> John, how would you implement automatic volatile for the following
> example using your choice of machine
>
> void delay (void)
> {
> volatile int x;
>
> for (x0; x; x--)
> {
> ;
> }
> }
>
> ?
>
> On 29-May-08, at 5:15 PM, John Heenan wrote:
>
> > This is an EXPLICIT simple black and white proof, with additonal
> > comments, that Rowley is not standards conformant with regard to use
> > of the the word volatile.
> >
> > The proof appears banal, however it is a valid proof and it is in
> the
> > appropriate style of a valid proof.
> >
> > The standard requires a volatile qualified object may be modified in
> > ways unknown. This requires a compiler allows an object to be
> > modified in ways unknown. If the compiler does not explicitly, with
> > certainty point and with 100% reliability out how a volatile object
> > can be modified in ways unknown then the compiler is not standards
> > conformant.
> >
> > Rowley does not point put how their volatile qualified object can be
> > modified in ways unknown. Therefore Rowley is not standards
> > conformant with regard to the use of the qualifier volatile.
> >
> > This is the end of the proof.
> >
> > If Rowley chooses to point out how volatile qualified objects can be
> > modified reliably with certainty in ways unknown then it can be
> > argued Rowley will become standards conformant with regard to the
> use
> > of the word volatile at a purely technical level that ignores
> > community expectations.
> >
> > If they continue to persist in using registers for auto variable
> > objects declared volatile, even if they point out how they can be
> > modified they will be out of step with expectations with what is
> > expected. Hence they will not be conformant at a community level,
> > which it can be argued is also a relevant standards 'unknown'.
> >
> > John Heenan
> >
> > --- In m..., "Paul Curtis" wrote:
> > >
> > > John,
> > >
> > > > This is about as black and white as it can get with regard to
> > > > interpreting a standard which attempts to deal with the
> 'unknown'.
> > > >
> > > > Paragraph 6 of Section 6.7.3 of the ISO C standard on 'Type
> > > > qualifiers' states "An object that has volatile-qualified type
> > may be
> > > > modified in ways unknown to the implementation or have other
> > unknown
> > > > side effects."
> > > >
> > > > In simpler terms this tells a compiler DO NOT MAKE ANY
> > ASSUMPTIONS. I
> > > > don't think I need to SPELL OUT why assigning ANY volatile
> > declared
> > > > object to a register is certainly making assumptions about usage
> > of
> > > > the variable.
> > > >
> > > > Point proven.
> > >
> > > No, point not proven at all, so don't become a barrister.
> > Paragraph 6 of
> > > section 6.7.3 goes on to say:
> > >
> > > "... Therefore any expression referring to such an object shall be
> > evaluated
> > > strictly according to the rules of the abstract machine,
> > > as described in 5.1.2.3. Furthermore, at every sequence point the
> > value last
> > > stored in the object shall agree with that prescribed by the
> > abstract
> > > machine, except as modified by the unknown factors mentioned
> > previously.
> > > What constitutes an access to an object that
> > > has volatile-qualified type is implementation-defined."
> > >
> > > There's no reference to "don't use a register". In fact, "What
> > constitutes
> > > an access to an object that has volatile-qualified type is
> > > implementation-defined" gives the implementor the ability to
> define
> > that
> > > access to a volatile-qualified auto is by register *in this case*.
> > But you
> > > omitted that because it doesn't support your argument, it directly
> > > contradicts your argument. (Don't become a barrister, become a
> > politician!)
> > >
> > > For auto volatiles, we have the Archelon compiler placing them in
> > registers,
> > > along with CrossWorks (for MSP430, AVR, and MAXQ), and to that I
> > can add the
> > > ARM RealView compiler (evidence below). So far three compilers are
> > > uncovered that put volatile autos in registers and CCE that elects
> > not to.
> > > I'm certain some compilers will, some won't, depending upon
> > *context*.
> > > Certainly the architecture of the code generator that forces
> memory-
> > based
> > > volatile objects will be simpler *because* those objects do not
> > occupy (the
> > > equivalent of) virtual registers and, therefore, will not subject
> > to classic
> > > optimizations--which is exactly what you require of a volatile
> > object.
> > >
> > > Now the evidence from the ARM RealView compiler:
> > >
> > > 119: void foo(void)
> > > 120: {
> > > 121: volatile int x;
> > > 0x000003A4 E8BD8070 LDMIA R13!,{R4-R6,PC}
> > > 122: for (x = 0; x < 100; ++x)
> > > 123: ;
> > > 0x000003A8 E3A00000 MOV R0,#0x00000000
> > > 0x000003AC EA000000 B 0x000003B4
> > > 0x000003B0 E2800001 ADD R0,R0,#0x00000001
> > > 0x000003B4 E3500064 CMP R0,#0x00000064
> > > 0x000003B8 BAFFFFFC BLT 0x000003B0
> > > 124: }
> > > 125:
> > > 0x000003BC E12FFF1E BX R14
> > >
> > > > The naive go off thinking every other compiler is
> > > > inferior because using registers shortens code and improves
> > > > benchmarks.
> > >
> > > Game over, man, game over! You do not have a persuasive argument.
> > I'm
> > > sorry, you lose this one.
> > >
> > > --
> > > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3
> processors
> > >
> >
> >
> >
>


Start a New Thread

I just tested this on the IAR compiler.
It does allocate the variable in memory : xx(sp) .
It will do so even if the variable x is defined as REGISTER volatile .
This is with the no-optimization choice.

Personally ... I am just a final user and not a high end professional...
but when I want a variable to "really" be volatile I also keep it
global, and sometimes I place it in some "known" place.
When using automatic variables I really don't care if the compiler
will allocate them in general memory or in registers.
Unless, of course, I shall call assembler routines from the C code or
vice_versa.
In those cases I try to keep very close control on variable
allocation, and it is a whole different story.
My interest in your discussion is because, from the importance you
give to this subject, I feel that my "habits" may be weird or
naive... or both, or worse ...
and I always strive to improve (bit by bit).
Thanks for reading

> > John, how would you implement automatic volatile for the following
> > example using your choice of machine
> >
> > void delay (void)
> > {
> > volatile int x;
> >
> > for (x0; x; x--)
> > {
> > ;
> > }
> > }
> >
> > ?
> >
Start a New Thread

John

Two possible implementations, one using the stack and the other
register 15 (both in compiler output assembly only), one from IAR and
one from a fictitious new compiler that user registers for automatic
volatiles.

??waste_time:
SUB.W #0x2, SP
MOV.W #0x3e8, 0(SP)
??waste_of_time_0:
CMP.W #0x1, 0(SP)
JL ??waste_of_time_1
ADD.W #0xffff, 0(SP)
JMP ??waste_of_time_0
??waste_of_time_1:
ADD.W #0x2, SP
RET

??waste_time:
SUB.W #0x2, SP
MOV.W R15, 0(SP)
MOV.W #0x3e8, R15
??waste_of_time_0:
CMP.W #0x1, R15
JL ??waste_of_time_1
ADD.W #0xffff, R15
JMP ??waste_of_time_0
??waste_of_time_1:
ADD.W #0x2, SP
RET

What "methods unknown" are blocked by either of these implementations
that a compiler might emit.

John Wrote...

>"The standard requires a volatile qualified object may be modified
in ways unknown. "
Ok.

>"This requires a compiler allows an object to be modified in ways
unknown."
How would the compiler do that exactly? How has it done that in either
the above examples?

>"If the compiler does not explicitly, with certainty point and with
100% reliability out how a volatile object can be modified in ways
unknown then the compiler is not standards conformant."
How has my compiler not explicitly, with certainty point and with 100%
reliability out how a volatile object can be modified in ways unknown
for either implementation?

I submit that this is standards compliant in both register and non-
register version.

So, does the Rowley compiler differ? Is the register allocation
random? Is the output assembly not explicit or reliable enough to
allow modification in ways unknown?

On 30-May-08, at 1:36 AM, Ing.Antonio Morra wrote:

>
> >Date: Fri, 30 May 2008 10:33:04 +0200
> >To: Veronica Merryfield
> >From: "Ing.Antonio Morra"
> >Subject: Re: [msp430] Re: Volatile and delay loops
> >
> >At 10:12 AM 5/30/2008,
> >
> >Veronica Merryfield wrote:
> >
> >>Could you post the code with the source and assembler mixed.
> >
> >Here is the C code:
> >
> >void waste_of_time (void)
> >{
> > int volatile LoopCount;
> >
> > for (LoopCount00;LoopCount>0;LoopCount--)
> > {
> > ;
> > }
> >
> >}
> >
> >
> >void main(void)
> >{
> >.......
> >waste_of_time();
> >......
> >}
> >
> >
> >and here is the compiler output, as listed in the intermixed mode
> >... a bit difficult to read, but this is it
> >
> >
> > \ In segment CODE, align 2
> > 1132 void waste_of_time (void)
> > \ waste_of_time:
> > 1133 {
> > \ 000000 2183 SUB.W #0x2, SP
> > 1134 int volatile LoopCount;
> > 1135
> > 1136 for (LoopCount00;LoopCount>0;LoopCount--)
> > \ 000002 B140E8030000 MOV.W #0x3e8, 0(SP)
> > \ ??waste_of_time_0:
> > \ 000008 91930000 CMP.W #0x1, 0(SP)
> > \ 00000C 0338 JL ??waste_of_time_1
> > \ 00000E B1530000 ADD.W #0xffff, 0(SP)
> > \ 000012 FA3F JMP ??waste_of_time_0
> > 1137 {
> > 1138 ;
> > 1139 }
> > 1140
> > 1141 }
> > \ ??waste_of_time_1:
> > \ 000014 2153 ADD.W #0x2, SP
> > \ 000016 3041 RET
> > 1142
> > 1143
> >
> >
> >regards
> >
> >Antonio Morra
>


Start a New Thread

> If Rowley chooses to point out how volatile qualified objects can be
> modified reliably with certainty in ways unknown then it can be
> argued Rowley will become standards conformant with regard to the use
> of the word volatile at a purely technical level that ignores
> community expectations.
>
> If they continue to persist in using registers for auto variable
> objects declared volatile, even if they point out how they can be
> modified they will be out of step with expectations with what is
> expected. Hence they will not be conformant at a community level,
> which it can be argued is also a relevant standards 'unknown'.
>
Hang on John, this is changing away from ISO standard to some other
community expectation standard. Which is it to be?

Start a New Thread