Re: extended operators

jacob navia wrote:
Keith Thompson wrote:
[...]
What exactly does "the last operation" mean?

In ``x = y + z;'' is it the addition or the assignment?

Who knows?

That depends on the ordering of the operations by the
compiler. To avoid such problems you should
only do ONE operation and not a complicated
expression.

Which operations can affect the carry? Is it implementation-defined?


This depends on the processor being used. If the processor doesn't
support the carry flag then it is not possible to do anything
and _carry() returns zero.
[...]
In my opinion, unless you can think of much better answers than I can,
this feature is so implementation-specific that it's not worth
standardizing.

Read the whole thread.

I did. My opinion stands (so far). What's your point?

[...]

To achive best results, only ONE operation should be
between the sequence point X and the last sequence point.

So you can perform a calculation, but you can't store the result?
Or is assignment not an operation?

Well let's try to turn on the brain before posting ok?

Would you care to answer the question, or would you rather just throw insults?

[...]

The _carry() represents a barrier. No optimmizations, code
rearrangements or similar constructs can be carried over a carry
read.

I think you mean that a call to _carry() is a sequence point. If so,
please just say so; if not, please clarify how what you're saying
differs from a sequence point.

Compilers do global code rearrangements across sequence points
AS IF the sequence point would habe been executed sequentially.

A call to _carry() is not a simple function call.

Then perhaps it shouldn't look like a function call. Perhaps it should be a macro, defined in a new header, that expands to some implementation-defined expression (possibly involving compiler magic).

So you'd mandate specific restrictions on generated code in the presence of calls to _carry(), even if the compiler is able to prove that it can perform an optimization without changing the effect? A feature whose main purpose is to enable writing efficient code for things like multi-precision arithmetic is defined in an extremely system-specific manner, it can't be supported on all systems, *and* it disables optimizations.

I find this proposed feature to be extremely "brittle", in the sense that a seemingly innocuous change to any code that uses it can cause it to break. The reason is that the value returned by _carry() is very tightly bound to the operation that generated it, but this binding is not clearly expressed in the source code, and all because of an attempt to create a one-to-one mapping with machine code.

Here's an alternative, inspired by the div() function in <stdlib.h>. A reminder: the div function takes two int arguments and returns a struct containing the quotient and remainder of the arguments. It computes both x/y and x%y in a single operation.

Similarly, addition with overflow detection is an ordinary arithmetic operation that yields two results. So you might have something like this:

typedef struct { int result; _Bool overflow; } result_t;
result_t add(int x, int y);

The ``result'' member is set to the sum of x and y; unlike an ordinary "+" operator, the result is well defined even on overflow. (By the time this is standardized, if ever, perhaps C will require two's complement.) The ``overflow'' member is set to 0 or 1 depending on whether the operation overflowed. Similar functions and result types can be defined for other types and other operations. Perhaps you'd want more than one flag.

The overflow flag is unambiguously associated with the potentially overflowing operation. No special optimization-inhibiting rules are necessary. All these functions can be defined as macros, perhaps using compiler magic, and optimized as aggressively as the implementer cares to do so. And it seems likely that this could be implemented reasonably efficiently on, for example, a MIPS processor, so there's no need to make it processor-specific.

This is mostly off the top of my head; I'm sure that plenty of holes could be shot in it.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: extended operators
    ... between the sequence point X and the last sequence point. ... Perhaps it should be a macro, defined in a new header, that expands to some implementation-defined expression (possibly involving compiler magic). ... main purpose is to enable writing efficient code for things like multi-precision arithmetic is defined in an extremely system-specific manner, it can't be supported on all systems, *and* it disables optimizations. ... The ``result'' member is set to the sum of x and y; unlike an ordinary "+" operator, the result is well defined even on overflow. ...
    (comp.std.c)
  • Re: micro-optimization question
    ... Don't remember what kind of loop caused ... while signed arithmetic has undefined behavior on overflow - so ... The compiler may do whatever it wants with potential ... Profile to find the hot spots where optimization will make a difference, ...
    (comp.lang.c)
  • Re: volatile inhibits side-effects
    ... >> 'volatile' is intended for preventing possible compiler ... >> optimization, so that a 'volatile' qualified object can ... >> acquire a state from an external source without the compiler ... think in terms of sequence points, since the modification, if any, could ...
    (comp.lang.c)
  • Re: Derived data types vs computation time
    ... >> or not, of SEQUENCE in the definition, the compiler may or may be forced ... the standard has no reason at all for the compiler ... Even for most sequence types, the standard does not really mandate ...
    (comp.lang.fortran)
  • Re: Envelope Optimization and Control Using Fuzzy Logic
    ... The basic building tool for envelope optimization is the fuzzy logic Envelope Controller function block. ... Each EC in the chain sequence focuses on a single process variable, with the complete chain forming an efficient and sophisticated optimization strategy. ...
    (sci.engr.control)