Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #61986 > unrolled thread

Sequence points and commit to memory

Back to article view | Back to comp.lang.c

Contents

  Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 11:43 +0100
    Re: Sequence points and commit to memory Richard Heathfield <rjh@cpax.org.uk> - 2015-05-14 12:02 +0100
      Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 13:39 +0200
        Re: Sequence points and commit to memory Richard Heathfield <rjh@cpax.org.uk> - 2015-05-14 13:18 +0100
          Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 23:11 +0200
    Re: Sequence points and commit to memory Stephen Sprunk <stephen@sprunk.org> - 2015-05-14 09:06 -0500
    Re: Sequence points and commit to memory Siri Cruz <chine.bleu@yahoo.com> - 2015-05-14 08:35 -0700
      Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:23 -0700
        Re: Sequence points and commit to memory Siri Cruz <chine.bleu@yahoo.com> - 2015-05-14 10:44 -0700
          Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 11:09 -0700
            Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 12:58 -0700
            Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-14 16:31 -0500
              Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 17:24 -0700
                Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-14 20:18 -0500
                  Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-15 09:34 +0200
                    Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-15 10:18 -0500
                    Re: 'register' attribute (was: Sequence points and commit to memory) Morris Dovey <mrdovey@iedu.com> - 2015-05-16 01:26 -0500
                      Re: 'register' attribute David Brown <david.brown@hesbynett.no> - 2015-05-17 00:02 +0200
                        Re: 'register' attribute Morris Dovey <mrdovey@iedu.com> - 2015-05-16 19:29 -0500
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-15 09:52 -0700
                Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 13:27 -0400
                  Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-15 10:50 -0700
                Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-15 12:32 -0500
        Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 23:23 +0200
          Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-15 09:42 -0700
            Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 13:13 -0400
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 08:32 -0700
            Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-15 10:35 -0700
            Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-15 11:08 -0700
              Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:40 -0500
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 08:48 -0700
            Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-15 21:46 +0100
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 08:56 -0700
                Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 19:35 +0100
                  Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 09:49 -0700
                    Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-19 09:04 +0100
                    Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-19 08:42 -0700
      Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:00 +0100
        Re: Sequence points and commit to memory Siri Cruz <chine.bleu@yahoo.com> - 2015-05-14 14:26 -0700
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:33 +0100
        Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 23:38 +0200
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 23:04 +0100
            Re: Sequence points and commit to memory Stephen Sprunk <stephen@sprunk.org> - 2015-05-15 13:09 -0500
              Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-15 21:56 +0100
                Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 17:30 -0400
                  Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 07:51 +0100
                    Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-16 22:10 -0400
                      Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:25 +0200
                        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-18 18:55 -0400
                          Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 09:10 +0200
                            Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-19 12:05 -0400
                              Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 18:42 +0200
                Re: Sequence points and commit to memory Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 16:33 -0500
                  Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:27 +0200
                    Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-18 19:05 -0400
                      Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 00:09 +0000
                        Re: Sequence points and commit to memory Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 01:11 +0100
                          Re: Sequence points and commit to memory Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:02 -0700
                        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-18 23:21 -0400
                          Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 06:25 +0000
                            Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 08:58 +0200
                              Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 23:20 +0000
                                Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-20 12:31 +0200
                            Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-19 12:10 -0400
                              Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 23:24 +0000
                      Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 09:05 +0200
                        Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-19 08:37 -0700
                        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-19 12:14 -0400
                          Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 19:02 +0200
              Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:46 -0500
            Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-17 00:20 +0200
              Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-17 18:19 +0100
                Re: Sequence points and commit to memory Philip Lantz <prl@canterey.us> - 2015-05-17 16:11 -0700
                  Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-18 08:30 +0100
                    Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:31 -0700
                      Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-18 11:11 -0700
                        Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 09:37 -0700
                      Re: Sequence points and commit to memory Ian Collins <ian-news@hotmail.com> - 2015-05-19 17:40 +1200
                        Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-19 01:31 -0500
                          Re: Sequence points and commit to memory Ian Collins <ian-news@hotmail.com> - 2015-05-19 20:38 +1200
                            Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-19 10:50 -0500
                    Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:46 +0200
                Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:35 +0200
        Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:42 -0500
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 07:58 +0100
            Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-16 02:18 -0500
              Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 08:36 +0100
                Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-17 04:31 -0500
                  Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-17 18:24 +0100
                    Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:55 +0200
    Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 11:26 -0700
      Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:07 +0100
        Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 14:22 -0700
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:36 +0100
      Re: Sequence points and commit to memory Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-22 08:16 -0700
        Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-22 11:31 -0700
    Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 00:05 -0400
      Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-15 22:25 +0100
        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 17:56 -0400
    Re: Sequence points and commit to memory Nobody <nobody@nowhere.invalid> - 2015-05-17 10:04 +0100
    Re: Sequence points and commit to memory Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 08:11 -0700

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#62274

On 19/05/15 08:25, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
> (snip)
>>>> On a platform which supports interrupts, a conforming implementation of
>>>> C must generate code that will still produce the behavior defined by the
>>>> standard for the source code. 
> 
> (snip, then I wrote)
>>> How about on CPUs that support imprecise interrupts?
>  
>> I'm unfamiliar with that term. Is there any conceivable method to
>> generate code that has the behavior defined by the standard, even if
>> execution of that code is interrupted by imprecise interrupts? 
> 
> Imprecise interrupts occur on processors with out-of-order execution
> and, further, out-of-order retirement. (Many processors now have
> out-of-order execution, but manage to arrange things such that the
> effects happen in order.)
> 
>> If so,
>> whatever approach needs to be taken to achieve that result is mandatory
>> for conforming implementations of C on those platforms. If not,
>> conforming implementations of C are not possible on those platforms.
> 
> I suspect that the causes of imprecise interrupts already cause UB,
> such that it doesn't matter. They do make debugging harder, though.
> 
> Some causes of imprecise interrupts are overflow, underflow,
> divide by zero, protection (accessing memory that doesn't belong
> to you), unaligned memory access. When one of those occurs, the
> CPU has to finish instructions that have already started, possibly
> generaring more interrupts. 
> 
> But debuggers might not be able to report the cause of a protection
> or alignment violation. 
> 
> Mostly, imprecise interrupts went away when vitual storage arrived.
> If you can't identify the instruction causing a page fault, it isn't
> possible to do the page-in and restart. Instructions can't change
> any permanent state until it is known that no page fault will occur.
> 

That is not exactly the way I think of the term "imprecise interrupt".
Terminology and details vary somewhat between processor architectures,
but I believe that in the more complex cpus I have worked with, there is
a distinction between asynchronous interrupts (caused by an external
source rather than the instruction stream), precise exceptions
(including divide-by-zero, address errors, etc.), and imprecise
exceptions (which might include floating point assist exceptions).

For a precise exception, when the exception handler is entered you know
exactly which instruction caused it.  All instructions prior to the
faulting one have completed, while none of the following instructions
have started (or their effects have been rolled back).

For an imprecise exception, there may be overlap in the pipelining - it
works more like an unusual form of function call instruction.

[toc] | [prev] | [next] | [standalone]

#62318

David Brown <david.brown@hesbynett.no> wrote:

(snip, I wrote)
>> Imprecise interrupts occur on processors with out-of-order execution
>> and, further, out-of-order retirement. (Many processors now have
>> out-of-order execution, but manage to arrange things such that the
>> effects happen in order.)
 
(snip)

>> I suspect that the causes of imprecise interrupts already cause UB,
>> such that it doesn't matter. They do make debugging harder, though.
 
>> Some causes of imprecise interrupts are overflow, underflow,
>> divide by zero, protection (accessing memory that doesn't belong
>> to you), unaligned memory access. When one of those occurs, the
>> CPU has to finish instructions that have already started, possibly
>> generaring more interrupts. 

The CPU that I most knew imprecise interrupts on was an IBM 360/91.
Some other large 360's and 370's also had them, but most not as many
as the 91. 
 
(snip)
>> Mostly, imprecise interrupts went away when vitual storage arrived.
>> If you can't identify the instruction causing a page fault, it isn't
>> possible to do the page-in and restart. Instructions can't change
>> any permanent state until it is known that no page fault will occur.
 
> That is not exactly the way I think of the term "imprecise interrupt".
> Terminology and details vary somewhat between processor architectures,
> but I believe that in the more complex cpus I have worked with, there is
> a distinction between asynchronous interrupts (caused by an external
> source rather than the instruction stream), precise exceptions
> (including divide-by-zero, address errors, etc.), and imprecise
> exceptions (which might include floating point assist exceptions).

For the 360/91, fixed point overflow, fixed point divide, 
floating point underflow, floating point overflow, and floating point
divide all generate imprecise interrupts. 
 
> For a precise exception, when the exception handler is entered you know
> exactly which instruction caused it.  All instructions prior to the
> faulting one have completed, while none of the following instructions
> have started (or their effects have been rolled back).

Yes.
 
> For an imprecise exception, there may be overlap in the pipelining - it
> works more like an unusual form of function call instruction.
 
-- glen

[toc] | [prev] | [next] | [standalone]

#62337

On 20/05/15 01:20, glen herrmannsfeldt wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> 
> (snip, I wrote)
>>> Imprecise interrupts occur on processors with out-of-order execution
>>> and, further, out-of-order retirement. (Many processors now have
>>> out-of-order execution, but manage to arrange things such that the
>>> effects happen in order.)
>  
> (snip)
> 
>>> I suspect that the causes of imprecise interrupts already cause UB,
>>> such that it doesn't matter. They do make debugging harder, though.
>  
>>> Some causes of imprecise interrupts are overflow, underflow,
>>> divide by zero, protection (accessing memory that doesn't belong
>>> to you), unaligned memory access. When one of those occurs, the
>>> CPU has to finish instructions that have already started, possibly
>>> generaring more interrupts. 
> 
> The CPU that I most knew imprecise interrupts on was an IBM 360/91.
> Some other large 360's and 370's also had them, but most not as many
> as the 91. 
>  
> (snip)
>>> Mostly, imprecise interrupts went away when vitual storage arrived.
>>> If you can't identify the instruction causing a page fault, it isn't
>>> possible to do the page-in and restart. Instructions can't change
>>> any permanent state until it is known that no page fault will occur.
>  
>> That is not exactly the way I think of the term "imprecise interrupt".
>> Terminology and details vary somewhat between processor architectures,
>> but I believe that in the more complex cpus I have worked with, there is
>> a distinction between asynchronous interrupts (caused by an external
>> source rather than the instruction stream), precise exceptions
>> (including divide-by-zero, address errors, etc.), and imprecise
>> exceptions (which might include floating point assist exceptions).
> 
> For the 360/91, fixed point overflow, fixed point divide, 
> floating point underflow, floating point overflow, and floating point
> divide all generate imprecise interrupts. 

I assume that's because those instructions were overlapped with others,
so by making them imprecise, and thereby allowing other logically later
instructions to complete, you make the hardware a good deal simpler.

>  
>> For a precise exception, when the exception handler is entered you know
>> exactly which instruction caused it.  All instructions prior to the
>> faulting one have completed, while none of the following instructions
>> have started (or their effects have been rolled back).
> 
> Yes.
>  
>> For an imprecise exception, there may be overlap in the pipelining - it
>> works more like an unusual form of function call instruction.
>  
> -- glen
> 

[toc] | [prev] | [next] | [standalone]

#62296

On 05/19/2015 02:25 AM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
> (snip)
>>>> On a platform which supports interrupts, a conforming implementation of
>>>> C must generate code that will still produce the behavior defined by the
>>>> standard for the source code. 
> 
> (snip, then I wrote)
>>> How about on CPUs that support imprecise interrupts?
>  
>> I'm unfamiliar with that term. Is there any conceivable method to
>> generate code that has the behavior defined by the standard, even if
>> execution of that code is interrupted by imprecise interrupts? 
> 
> Imprecise interrupts occur on processors with out-of-order execution
> and, further, out-of-order retirement. (Many processors now have
> out-of-order execution, but manage to arrange things such that the
> effects happen in order.)
> 
>> If so,
>> whatever approach needs to be taken to achieve that result is mandatory
>> for conforming implementations of C on those platforms. If not,
>> conforming implementations of C are not possible on those platforms.
> 
> I suspect that the causes of imprecise interrupts already cause UB,
> such that it doesn't matter. They do make debugging harder, though.

In that case, the standard imposes no restrictions on the behavior of
the program, making it trivial to satisfies the standard's requirements,
so a conforming implementation of C doesn't have to worry about them. It
follows that they won't occur in strictly conforming code, so they pose
no problems that matter to such code.

[toc] | [prev] | [next] | [standalone]

#62319

James Kuyper <jameskuyper@verizon.net> wrote:

(snip, I wrote)
>> I suspect that the causes of imprecise interrupts already cause UB,
>> such that it doesn't matter. They do make debugging harder, though.
 
> In that case, the standard imposes no restrictions on the behavior of
> the program, making it trivial to satisfies the standard's requirements,
> so a conforming implementation of C doesn't have to worry about them. It
> follows that they won't occur in strictly conforming code, so they pose
> no problems that matter to such code.

One that used to be a problem for Fortran was alignment.

It used to be believed (maybe because the standard required it) 
that COMMON was not allowed to be padded. The fix for this was to
trap the alignment exception, copy the data, perform the operation
on the copied data, and copy back. That only works with precise
interrupts, so you can find the failing instruction.

This would be a problem for C if a struct wasn't allowed to
pad to align members. As far as I know, though, now Fortran and
C allow padding, so no more alignment problems.

-- glen

[toc] | [prev] | [next] | [standalone]

#62275

On 19/05/15 01:05, James Kuyper wrote:
> On 05/18/2015 06:27 PM, David Brown wrote:
> ...
>> The compiler doesn't know about interrupts - only the programmer knows 
>> about them.  So if the compiler can determine that function_call() is 
>> independent of pointer_manipulations, but the programmer knows that 
>> interrupt routines may introduce a dependency, then it is the 
>> programmer's responsibility to tell this to the compiler by forcing a 
>> dependency in some way.  Valid methods include memory barriers and the 
>> use of "volatile".
> 
> On a platform which supports interrupts, a conforming implementation of
> C must generate code that will still produce the behavior defined by the
> standard for the source code. If that means spilling registers to memory
> whenever a sequence point is crossed, even though an interrupt is the
> only possible reason why such spilling is needed - then those registers
> must be spilled - because the platform does permit such interruptions.
> 

C has no concept of interrupts, or of flow changes outside the sequence
given in the source code, or of actions or effects outside the source
code, except through the use of "volatile".  C compilers "support"
interrupts in that they know there is no such thing!  This applies to
/all/ C compilers on /all/ platforms - there are very few processors
that don't have some sort of interrupt mechanism.

There /are/ languages with support for multiple threads of execution
(interrupts can be viewed as a special form of threading), but even they
would not try to make everything "interrupt safe" by spilling registers
to memory or other nonsense.  It could not possibly work (interrupts
could happen in the middle of the spill operations), and would
necessitate such incredibly poor code that we would still be using
assembler.

Thus is it is up to the programmer to be aware of interrupts and any
interaction between interrupt code and "main loop" code, and take
appropriate measures (such as using "volatile" correctly) - just like
for multi-threaded programming.

[toc] | [prev] | [next] | [standalone]

#62290

David Brown <david.brown@hesbynett.no> writes:
[...]
> C has no concept of interrupts, or of flow changes outside the sequence
> given in the source code, or of actions or effects outside the source
> code, except through the use of "volatile".  C compilers "support"
> interrupts in that they know there is no such thing!  This applies to
> /all/ C compilers on /all/ platforms - there are very few processors
> that don't have some sort of interrupt mechanism.
[...]

N1570 5.2.3 is titled "Signals and interrupts".  It requires that
a function's behavior is not altered when a signal is received,
as long as it uses only objects with automatic storage duration.

7.14 describes the <signals.h> header.

7.26 describes the <threads.h> header.

The "Signals and interrupts" discussion and <signals.h> go back to
C89/C90; <threads.h> is new in C11, and is optional.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#62297

On 05/19/2015 03:05 AM, David Brown wrote:
> On 19/05/15 01:05, James Kuyper wrote:
>> On 05/18/2015 06:27 PM, David Brown wrote:
>> ...
>>> The compiler doesn't know about interrupts - only the programmer knows 
>>> about them.  So if the compiler can determine that function_call() is 
>>> independent of pointer_manipulations, but the programmer knows that 
>>> interrupt routines may introduce a dependency, then it is the 
>>> programmer's responsibility to tell this to the compiler by forcing a 
>>> dependency in some way.  Valid methods include memory barriers and the 
>>> use of "volatile".
>>
>> On a platform which supports interrupts, a conforming implementation of
>> C must generate code that will still produce the behavior defined by the
>> standard for the source code. If that means spilling registers to memory
>> whenever a sequence point is crossed, even though an interrupt is the
>> only possible reason why such spilling is needed - then those registers
>> must be spilled - because the platform does permit such interruptions.
>>
> 
> C has no concept of interrupts, or of flow changes outside the sequence
> given in the source code, or of actions or effects outside the source
> code, except through the use of "volatile".  C compilers "support"
> interrupts in that they know there is no such thing! ...

This is fine, so long as they support interrupts in a way that doesn't
prevent C programs from having the behavior defined for them by the
standard. If that's not possible, then there can be no conforming
implementations of C on such platforms.

> ... This applies to
> /all/ C compilers on /all/ platforms - there are very few processors
> that don't have some sort of interrupt mechanism.
> 
> There /are/ languages with support for multiple threads of execution

Note: C2011 is one of those.

[toc] | [prev] | [next] | [standalone]

#62304

On 19/05/15 18:14, James Kuyper wrote:
> On 05/19/2015 03:05 AM, David Brown wrote:
>> On 19/05/15 01:05, James Kuyper wrote:
>>> On 05/18/2015 06:27 PM, David Brown wrote:
>>> ...
>>>> The compiler doesn't know about interrupts - only the programmer knows
>>>> about them.  So if the compiler can determine that function_call() is
>>>> independent of pointer_manipulations, but the programmer knows that
>>>> interrupt routines may introduce a dependency, then it is the
>>>> programmer's responsibility to tell this to the compiler by forcing a
>>>> dependency in some way.  Valid methods include memory barriers and the
>>>> use of "volatile".
>>>
>>> On a platform which supports interrupts, a conforming implementation of
>>> C must generate code that will still produce the behavior defined by the
>>> standard for the source code. If that means spilling registers to memory
>>> whenever a sequence point is crossed, even though an interrupt is the
>>> only possible reason why such spilling is needed - then those registers
>>> must be spilled - because the platform does permit such interruptions.
>>>
>>
>> C has no concept of interrupts, or of flow changes outside the sequence
>> given in the source code, or of actions or effects outside the source
>> code, except through the use of "volatile".  C compilers "support"
>> interrupts in that they know there is no such thing! ...
>
> This is fine, so long as they support interrupts in a way that doesn't
> prevent C programs from having the behavior defined for them by the
> standard. If that's not possible, then there can be no conforming
> implementations of C on such platforms.
>
>> ... This applies to
>> /all/ C compilers on /all/ platforms - there are very few processors
>> that don't have some sort of interrupt mechanism.
>>
>> There /are/ languages with support for multiple threads of execution
>
> Note: C2011 is one of those.
>

No, it has a simple tagged-on interface in <threads.h> that was 
introduced as an afterthought, long after it was of any real use.  If it 
had been included in C90 or even C99, operating systems might have used 
it as the basis for the API's - but now it is far too late to move 
people from Posix, Win32, wxWidgets, QT, or the dozens of embedded RTOS 
APIs.

Anyway, this still does not mean C11 has real support for multiple 
threads.  There are other languages which have it as fundamental to the 
language, with features such as compile-time checks to avoid race 
conditions, control flow structures for integrating multiple threads 
directly in the code, direct language support for inter-thread 
communication, etc.

[toc] | [prev] | [next] | [standalone]

#62079

On Fri, 15 May 2015 13:09:00 -0500, Stephen Sprunk
<stephen@sprunk.org> wrote:

>On 14-May-15 17:04, James Harris wrote:
>> I think I am safe from cross-unit optimisations because I compile
>> each source file separately. There is no communication between them,
>> even to say which object files will work with which other object
>> files, until the linker is run.
>
>Some implementations will "compile" source files to an intermediate
>language, then finish translation during the linking stage, making
>cross-unit (aka "whole program") optimizations possible.


On some implementations, LTCG is the default behavior (MSVC under VS,
for example).  Unlike, say PGO, LTCG is actually a generally usable
option.  It's largely the default here.

[toc] | [prev] | [next] | [standalone]

#62134

On 15/05/15 00:04, James Harris wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:mj34ho$jll$1@dont-email.me...
>> On 14/05/15 23:00, James Harris wrote:
>
> ...
>
>>> In the absence of being able to code a proper memory barrier (as per
>>> David's suggestion) volatile is a good choice.
>>>
>>> For the moment I have chosen to make some updates in a function in a
>>> separate translation unit with the idea that when the called function
>>> returns across the TU boundary its updates will *have* to have been
>>> written to memory.
>>
>> /Bad/ idea.  You are introducing additional pessimations in a hope of
>> making the code correct - and restricting yourself to using a compiler
>> (or compiler options) that don't allow cross-unit optimisations.
>
> I have not heard the word "pessimations" before.

As Stephen says, it should have been "pessimisations" (neither are in 
Thunderbird's dictionary, so my spelling was slightly random).  It means 
you are making the code worse than it need be, rather than better.

>
> I think I am safe from cross-unit optimisations because I compile each
> source file separately. There is no communication between them, even to
> say which object files will work with which other object files, until
> the linker is run.

You are safe today, but not for the future - link-time optimisation is 
getting better and better in modern compilers, and is increasingly 
popular.  When you find you can save perhaps 10-15% code space by 
enabling a command-line switch for LTO, you /will/ be tempted.  (At the 
moment, debugging LTO code is still a challenge.)  And even though the 
files are compiled separately, the resulting code is combined at link-time.

It is best to be in the habit of writing code that works because it is 
correct, not because of a particular choice of command-line options.

>
>> Making u volatile would be simpler, safer, and more efficient - even
>> if it leads to occasional extra accesses.  You can always make a local
>> copy of it in a non-volatile variable if that helps.
>
> Agreed.
>
> ...
>
>>> Example function below. In this case I had to make
>>> two updates atomic so have added interrupt disable and restore around
>>> it
>>> but the main point is that the updates *should* AFAICS be guaranteed
>>> to
>>> end up in memory before the function returns. After all, there's no
>>> way
>>> they can be kept in registers after the function ends if the compiler
>>> has no way to do inter-function optimisation.
>>>
>>> void dnode_delete(dnode_t *x) {
>>>     unsigned state;
>>>
>>>     /* Disable interrupts */
>>>     state = irqrx_set(IRQRX_DISABLE);
>>>
>>>     x->prev.next = x.next;
>>>     x->next.prev = x.prev;
>>>
>>>     /* Restore interrupt handling */
>>>     irqrx_set(state);
>>> }
>>>
>>> The code is ostentibly simple but making it robust is not!
>>>
>>
>> And it is still not correct.  There is a good chance that the compiler
>> will generate the code you want, but it certainly does not have to -
>> so you are playing a very dangerous game.
>>
>> The key issue is that while the irqrx_set function is presumably
>> volatile (or uses a volatile access to the irq flag), and thus the
>> compiler guarantees that the interrupts will be disabled and then
>> restored, the standards say nothing about the ordering of volatile
>> accesses with respect to non-volatile accesses.
>
> The irqrx_set function is not even in C. It is written in assembly.

So?  The compiler can know a fair amount about inline assembly functions 
too.  Unless it is declared as volatile, the compiler can re-arrange and 
re-order the assembly function because it knows exactly what data may or 
may not be affected by it (since you tell it this information with the 
inputs, outputs and clobbers for the assembly function).

If it is an external assembly function, then the compiler knows little - 
but it can still make some assumptions about how it could affect (or 
not) local variables and data, as it assumes the external assembly 
function follows certain rules and conventions.

>
> But the main point is that I intended the above dnode_delete function to
> commit all of its changes to memory before it returns to its caller.

That's fairly obvious.  I am just suggesting ways to help you tell the 
/compiler/ what you want to do.

>
>>   The compiler could move the assignments to before the interrupt
>> disable, or after the restore, or in pretty much any other order it
>> wants.
>
> That is a big surprise - and a big problem. Are you sure that a compiler
> could do that? If it did it would change the semantics of the program.
>

Yes, I have no doubts.  And I have no doubts that it happens in practice 
(though it is unlikely to happen here - the compiler won't move things 
around unless there are clear advantages in doing so.  It is seldom 
awkward just to annoy people!).

I have seen people write code like this:

	int x = long_calculation();
	disableInterrupts();
	volatile_variable = x;
	enableInterrupts();

and been surprised when the compiler moves the long_calculation() into 
the interrupt-disabled area.

I have also seen code like this:

	testPinOn();	// Using volatile write to a PORT
	longCalculation();
	testPinOff();

and try to use an oscilloscope to measure the time taken by 
longCalculation() - only to discover that it has been moved before or 
after the testPin functions, so the pin goes on and off within a few 
instruction cycles.

[toc] | [prev] | [next] | [standalone]

#62186

"David Brown" <david.brown@hesbynett.no> wrote in message 
news:mj8fps$7ru$1@dont-email.me...
> On 15/05/15 00:04, James Harris wrote:
>> "David Brown" <david.brown@hesbynett.no> wrote in message
>> news:mj34ho$jll$1@dont-email.me...

...

>>>   The compiler could move the assignments to before the interrupt
>>> disable, or after the restore, or in pretty much any other order it
>>> wants.
>>
>> That is a big surprise - and a big problem. Are you sure that a 
>> compiler
>> could do that? If it did it would change the semantics of the 
>> program.
>>
>
> Yes, I have no doubts.  And I have no doubts that it happens in 
> practice (though it is unlikely to happen here - the compiler won't 
> move things around unless there are clear advantages in doing so.  It 
> is seldom awkward just to annoy people!).
>
> I have seen people write code like this:
>
> int x = long_calculation();
> disableInterrupts();
> volatile_variable = x;
> enableInterrupts();
>
> and been surprised when the compiler moves the long_calculation() into 
> the interrupt-disabled area.

AFAICS the only way the compiler should do that is if it could prove 
that interrupts would be disabled prior to the disableInterrupts call 
that you show so that the call will always be a no-op. If the compiler 
cannot prove that for all possible execution paths it should not, 
AFAICS, reorder the code as it did.

> I have also seen code like this:
>
> testPinOn(); // Using volatile write to a PORT
> longCalculation();
> testPinOff();
>
> and try to use an oscilloscope to measure the time taken by 
> longCalculation() - only to discover that it has been moved before or 
> after the testPin functions, so the pin goes on and off within a few 
> instruction cycles.

Possibly some slow hardware response to turning the pin on, or the 
longCalculation taking less time than expected? Rather than look at the 
timing do you remember whether you checked the generated code to see 
whether the compiler had really moved the longCalculation as you 
suggest? If it had then that has to be a compiler bug, doesn't it in 
that it has changed the effect of the program?

James

[toc] | [prev] | [next] | [standalone]

#62206

James Harris wrote:
> 
> "David Brown" <david.brown@hesbynett.no> wrote in message 
> news:mj8fps$7ru$1@dont-email.me...
> > On 15/05/15 00:04, James Harris wrote:
> >> "David Brown" <david.brown@hesbynett.no> wrote in message
> >> news:mj34ho$jll$1@dont-email.me...
> 
> ...
> 
> >>>   The compiler could move the assignments to before the interrupt
> >>> disable, or after the restore, or in pretty much any other order it
> >>> wants.
> >>
> >> That is a big surprise - and a big problem. Are you sure that a 
> >> compiler
> >> could do that? If it did it would change the semantics of the 
> >> program.
> >>
> >
> > Yes, I have no doubts.  And I have no doubts that it happens in 
> > practice (though it is unlikely to happen here - the compiler won't 
> > move things around unless there are clear advantages in doing so.  It 
> > is seldom awkward just to annoy people!).
> >
> > I have seen people write code like this:
> >
> > int x = long_calculation();
> > disableInterrupts();
> > volatile_variable = x;
> > enableInterrupts();
> >
> > and been surprised when the compiler moves the long_calculation() into 
> > the interrupt-disabled area.
> 
> AFAICS the only way the compiler should do that is if it could prove 
> that interrupts would be disabled prior to the disableInterrupts call 
> that you show so that the call will always be a no-op. If the compiler 
> cannot prove that for all possible execution paths it should not, 
> AFAICS, reorder the code as it did.

The compiler doesn't know anything about interrupts.

Sequence points affect the behavior of the abstract machine; in the real 
machine, the compiler only needs to worry about the ordering of volatile 
accesses (as long as every thing else gives the same results as the 
abstract machine).

If long_calculation doesn't involve any volatile accesses (which I 
presume it doesn't), the compiler can put it any where it wants, even 
before the call to main, as long as the result is the same. (Obviously, 
if it depends on input, it can't be done before that input is 
available.)

> > I have also seen code like this:
> >
> > testPinOn(); // Using volatile write to a PORT
> > longCalculation();
> > testPinOff();
> >
> > and try to use an oscilloscope to measure the time taken by 
> > longCalculation() - only to discover that it has been moved before or 
> > after the testPin functions, so the pin goes on and off within a few 
> > instruction cycles.
> 
> Possibly some slow hardware response to turning the pin on, or the 
> longCalculation taking less time than expected? Rather than look at the 
> timing do you remember whether you checked the generated code to see 
> whether the compiler had really moved the longCalculation as you 
> suggest? If it had then that has to be a compiler bug, doesn't it in 
> that it has changed the effect of the program?

No, not a compiler bug. Again, if longCalculation() doesn't involve any 
volatile accesses, the compiler can move it. Timing is not considered an 
"effect of the program."

[toc] | [prev] | [next] | [standalone]

#62213

"Philip Lantz" <prl@canterey.us> wrote in message 
news:MPG.2fc2c01210c570f926@news.eternal-september.org...
> James Harris wrote:
>>
>> "David Brown" <david.brown@hesbynett.no> wrote in message
>> news:mj8fps$7ru$1@dont-email.me...
>> > On 15/05/15 00:04, James Harris wrote:
>> >> "David Brown" <david.brown@hesbynett.no> wrote in message
>> >> news:mj34ho$jll$1@dont-email.me...
>>
>> ...
>>
>> >>>   The compiler could move the assignments to before the interrupt
>> >>> disable, or after the restore, or in pretty much any other order 
>> >>> it
>> >>> wants.
>> >>
>> >> That is a big surprise - and a big problem. Are you sure that a
>> >> compiler
>> >> could do that? If it did it would change the semantics of the
>> >> program.
>> >>
>> >
>> > Yes, I have no doubts.  And I have no doubts that it happens in
>> > practice (though it is unlikely to happen here - the compiler won't
>> > move things around unless there are clear advantages in doing so. 
>> > It
>> > is seldom awkward just to annoy people!).
>> >
>> > I have seen people write code like this:
>> >
>> > int x = long_calculation();
>> > disableInterrupts();
>> > volatile_variable = x;
>> > enableInterrupts();
>> >
>> > and been surprised when the compiler moves the long_calculation() 
>> > into
>> > the interrupt-disabled area.
>>
>> AFAICS the only way the compiler should do that is if it could prove
>> that interrupts would be disabled prior to the disableInterrupts call
>> that you show so that the call will always be a no-op. If the 
>> compiler
>> cannot prove that for all possible execution paths it should not,
>> AFAICS, reorder the code as it did.
>
> The compiler doesn't know anything about interrupts.

No, but the way that interrupts are disabled may be seen by the 
compiler. Imagine that on a certain machine the disableInterrupts call 
sets a value in a memory-mapped register and that register value has 
already been set (and the memory-mapped register address has not been 
declared as volatile).

> Sequence points affect the behavior of the abstract machine; in the 
> real
> machine, the compiler only needs to worry about the ordering of 
> volatile
> accesses (as long as every thing else gives the same results as the
> abstract machine).
>
> If long_calculation doesn't involve any volatile accesses (which I
> presume it doesn't), the compiler can put it any where it wants, even
> before the call to main, as long as the result is the same. 
> (Obviously,
> if it depends on input, it can't be done before that input is
> available.)

I can see this in two ways and I don't know which model the compiler is 
supposed to follow. The two are

1. The compiler can prove that the disableInterrupts call will not be 
able to modify any of this function's *internal* state, possibly because 
this function operates only on automatic variables and there are no 
pointers into this function's memory. It therefore feels free to reorder 
statements around the disableInterrupts call.

2. The compiler does not know what disableInterrupts does so it realises 
that it cannot reorder it with respect to other statements.

I suppose the one which is correct comes down to what the C compiler 
considers to comprise the state of the abstract machine.

>> > I have also seen code like this:
>> >
>> > testPinOn(); // Using volatile write to a PORT
>> > longCalculation();
>> > testPinOff();
>> >
>> > and try to use an oscilloscope to measure the time taken by
>> > longCalculation() - only to discover that it has been moved before 
>> > or
>> > after the testPin functions, so the pin goes on and off within a 
>> > few
>> > instruction cycles.
>>
>> Possibly some slow hardware response to turning the pin on, or the
>> longCalculation taking less time than expected? Rather than look at 
>> the
>> timing do you remember whether you checked the generated code to see
>> whether the compiler had really moved the longCalculation as you
>> suggest? If it had then that has to be a compiler bug, doesn't it in
>> that it has changed the effect of the program?
>
> No, not a compiler bug. Again, if longCalculation() doesn't involve 
> any
> volatile accesses, the compiler can move it. Timing is not considered 
> an
> "effect of the program."

No, but order of operations seems to be the key thing. I would have 
hoped that the compiler would only reorder operations if it could prove 
that such reordering did not have an impact on the effect of the 
program.

James

[toc] | [prev] | [next] | [standalone]

#62226

On Monday, May 18, 2015 at 12:30:34 AM UTC-7, James Harris wrote:
> "Philip Lantz" <prl@canterey.us> wrote in message 
> news:MPG.2fc2c01210c570f926@news.eternal-september.org...
> > James Harris wrote:
> >>
> >> "David Brown" <david.brown@hesbynett.no> wrote in message
> >> news:mj8fps$7ru$1@dont-email.me...
> >> > On 15/05/15 00:04, James Harris wrote:
> >> >> "David Brown" <david.brown@hesbynett.no> wrote in message
> >> >> news:mj34ho$jll$1@dont-email.me...
> >>
> >> ...
> >>
> >> >>>   The compiler could move the assignments to before the interrupt
> >> >>> disable, or after the restore, or in pretty much any other order 
> >> >>> it
> >> >>> wants.
> >> >>
> >> >> That is a big surprise - and a big problem. Are you sure that a
> >> >> compiler
> >> >> could do that? If it did it would change the semantics of the
> >> >> program.
> >> >>
> >> >
> >> > Yes, I have no doubts.  And I have no doubts that it happens in
> >> > practice (though it is unlikely to happen here - the compiler won't
> >> > move things around unless there are clear advantages in doing so. 
> >> > It
> >> > is seldom awkward just to annoy people!).
> >> >
> >> > I have seen people write code like this:
> >> >
> >> > int x = long_calculation();
> >> > disableInterrupts();
> >> > volatile_variable = x;
> >> > enableInterrupts();
> >> >
> >> > and been surprised when the compiler moves the long_calculation() 
> >> > into
> >> > the interrupt-disabled area.
> >>
> >> AFAICS the only way the compiler should do that is if it could prove
> >> that interrupts would be disabled prior to the disableInterrupts call
> >> that you show so that the call will always be a no-op. If the 
> >> compiler
> >> cannot prove that for all possible execution paths it should not,
> >> AFAICS, reorder the code as it did.
> >
> > The compiler doesn't know anything about interrupts.
> 
> No, but the way that interrupts are disabled may be seen by the 
> compiler. Imagine that on a certain machine the disableInterrupts call 
> sets a value in a memory-mapped register and that register value has 
> already been set (and the memory-mapped register address has not been 
> declared as volatile).
> 
> > Sequence points affect the behavior of the abstract machine; in the 
> > real
> > machine, the compiler only needs to worry about the ordering of 
> > volatile
> > accesses (as long as every thing else gives the same results as the
> > abstract machine).
> >
> > If long_calculation doesn't involve any volatile accesses (which I
> > presume it doesn't), the compiler can put it any where it wants, even
> > before the call to main, as long as the result is the same. 
> > (Obviously,
> > if it depends on input, it can't be done before that input is
> > available.)
> 
> I can see this in two ways and I don't know which model the compiler is 
> supposed to follow. The two are
> 
> 1. The compiler can prove that the disableInterrupts call will not be 
> able to modify any of this function's *internal* state, possibly because 
> this function operates only on automatic variables and there are no 
> pointers into this function's memory. It therefore feels free to reorder 
> statements around the disableInterrupts call.
> 
> 2. The compiler does not know what disableInterrupts does so it realises 
> that it cannot reorder it with respect to other statements.
> 
> I suppose the one which is correct comes down to what the C compiler 
> considers to comprise the state of the abstract machine.
> 
> >> > I have also seen code like this:
> >> >
> >> > testPinOn(); // Using volatile write to a PORT
> >> > longCalculation();
> >> > testPinOff();
> >> >
> >> > and try to use an oscilloscope to measure the time taken by
> >> > longCalculation() - only to discover that it has been moved before 
> >> > or
> >> > after the testPin functions, so the pin goes on and off within a 
> >> > few
> >> > instruction cycles.
> >>
> >> Possibly some slow hardware response to turning the pin on, or the
> >> longCalculation taking less time than expected? Rather than look at 
> >> the
> >> timing do you remember whether you checked the generated code to see
> >> whether the compiler had really moved the longCalculation as you
> >> suggest? If it had then that has to be a compiler bug, doesn't it in
> >> that it has changed the effect of the program?
> >
> > No, not a compiler bug. Again, if longCalculation() doesn't involve 
> > any
> > volatile accesses, the compiler can move it. Timing is not considered 
> > an
> > "effect of the program."
> 
> No, but order of operations seems to be the key thing. I would have 
> hoped that the compiler would only reorder operations if it could prove 
> that such reordering did not have an impact on the effect of the 
> program.
> 
> James

The spirit of C would suggest that C programs should not be aware of
interrupts. That is, if interrupts occur they should be handled in such
a way as to not affect any running C programs. That said, how does a C
program get input?

K&R visualized input as reading successive bytes from a byte source 
(visualized as a file). This is what I would call "pull" input - the
code needs bytes so it asks for them. Problems arise with "push" 
input - something outside the code demands the code take action. 
Interrupts, of course, can be an example of push input. But so can almost
any other device.   

In my opinion there is a fundamental difficulty here. Modern computer
configurations seem to demand event-driven programs. The question is 
whether the C langauge can be made to fit comfortably into an event-
diven world. It can be forced in but the fits I have seen are far from
comfortable.

[toc] | [prev] | [next] | [standalone]

#62235

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> The spirit of C would suggest that C programs should not be aware of
> interrupts. That is, if interrupts occur they should be handled in such
> a way as to not affect any running C programs. That said, how does a C
> program get input?

I think someone already mentioned <signal.h>.

> K&R visualized input as reading successive bytes from a byte source 
> (visualized as a file). This is what I would call "pull" input - the
> code needs bytes so it asks for them. Problems arise with "push" 
> input - something outside the code demands the code take action. 
> Interrupts, of course, can be an example of push input. But so can almost
> any other device.   
>
> In my opinion there is a fundamental difficulty here. Modern computer
> configurations seem to demand event-driven programs. The question is 
> whether the C langauge can be made to fit comfortably into an event-
> diven world. It can be forced in but the fits I have seen are far from
> comfortable.

C11 adds <threads.h>.  If you want to say that that violates the "spirit
of C" I won't argue with you, but it would be a bit pointless.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#62298

On Monday, May 18, 2015 at 11:11:19 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > The spirit of C would suggest that C programs should not be aware of
> > interrupts. That is, if interrupts occur they should be handled in such
> > a way as to not affect any running C programs. That said, how does a C
> > program get input?
> 
> I think someone already mentioned <signal.h>.
 
We are certainly talking at cross purposes. The proper dismissive
comment on my rhetorical question is <stdio.h>.

To quote K&R 1978 " Inout and outout facilities are not part the C
language ... Nevertheless, real programs do interact wih\th their
environment ... we will describe "the standard I/O library ... "

They describe getchar and putchar, (s)prinf and (s)scanf, getc and
putc, fgets and fputs and a fe miore functions. They are vague 
about where all this is actually defined but it is clearly not the
Unix interface which the subject of their chapter. Signals came later.

Already signals fit awkwardly into C. 

I have to stop now. But I think that make it clear what I mean by the
spirit of C.






> > K&R visualized input as reading successive bytes from a byte source 
> > (visualized as a file). This is what I would call "pull" input - the
> > code needs bytes so it asks for them. Problems arise with "push" 
> > input - something outside the code demands the code take action. 
> > Interrupts, of course, can be an example of push input. But so can almost
> > any other device.   
> >
> > In my opinion there is a fundamental difficulty here. Modern computer
> > configurations seem to demand event-driven programs. The question is 
> > whether the C langauge can be made to fit comfortably into an event-
> > diven world. It can be forced in but the fits I have seen are far from
> > comfortable.
> 
> C11 adds <threads.h>.  If you want to say that that violates the "spirit
> of C" I won't argue with you, but it would be a bit pointless.
> 
> -- 
> Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
> Working, but not speaking, for JetHead Development, Inc.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#62270

David Kleinecke wrote:
>
> In my opinion there is a fundamental difficulty here. Modern computer
> configurations seem to demand event-driven programs. The question is
> whether the C langauge can be made to fit comfortably into an event-
> diven world. It can be forced in but the fits I have seen are far from
> comfortable.

So do you consider the early 80's workstation that supported X to be 
"modern"?  C has probably been used for event driven systems form day 
(or at lease week) one.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#62272

On 5/19/15 12:40 AM, Ian Collins wrote:

> The question is
> whether the C langauge can be made to fit comfortably into an event-
> diven world. It can be forced in but the fits I have seen are far from
> comfortable.

It can – and the event-response connections are most comfortable when 
handled/facilitated by a layer that application writers can take for 
granted.

It's not at all unusual for embedded systems to be designed around 
device interrupts - and there the degree of comfort is determined by 
quality of design (surely no surprise).

Before there were formal C standards, Borland introduced an 'interrupt' 
attribute, which provided appropriate function entry/exit code for 
MS-DOS (and I think OS2) environments and made ISR writing /really/ 
easy. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62278

Morris Dovey wrote:
> On 5/19/15 12:40 AM, Ian Collins wrote:
>
>> The question is
>> whether the C langauge can be made to fit comfortably into an event-
>> diven world. It can be forced in but the fits I have seen are far from
>> comfortable.

No I didn't!

Please take more care with your quotes.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web