Ivan Godard <ivan@millcomputing.com> schrieb:
> On 10/24/2021 9:30 PM, BGB wrote:

>> And, on the other side, people try to take stuff that is basically
>> fantasy (eg, Star Wars), and awkwardly retrofit a bunch of "science"
>> into it.
>>
>> Or, as the say, "sufficiently advanced technology is indistinguishable
>> from magic" but it is more like "sufficient technobabble over magic is
>> indistinguishable from technology".
>
> +1 !

I like "Any technology that is distinguishable from magic is
insufficiently advanced" better :-)

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
> [...]
>
>> I realize that some of the above needs clarifying and also that
>> some of the ideas are controversial. My purpose is to start a
>> dialog (not necessarily one continuing in this newsgroup) and to
>> indicate a general direction of where I think the C standard
>> should be going. My thanks to everyone for your attention.
>
> It will be extremely hard to get consensus on what you proposed
> adopted into the current C standard. [...]

Granted.

The point of my comments is not to accomplish a particular set of
changes but to start discussion and get agreement on individual
changes (and not all at once). There are still lots of details
that need to be worked out, and I knew that while I was writing
the previous posting. Proposals for changes to the C standard
are more likely to succeed when there is consensus from a larger
group than just one person. I don't mind pitching in on the work
but I'm still just one person. If others participate and agree
then the result will be a better proposal and also one that will
carry more weight. I know some people would rather just sit back
and complain about how bad C is (or C compilers are), and who say
that things just aren't going to change. My hope is there are
other people who are more optimistic.

Like my chemistry friends used to say, if you're not part of the
solution, you're part of the precipitate.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 2021-10-23 23:44, Tim Rentsch wrote:
>
>> Ivan Godard <ivan@millcomputing.com> writes:
>>
>>> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>>>
>>>> On 10/19/2021 9:20 AM, EricP wrote:
>>>>
>>>>> Ivan Godard wrote:
>>>>>
>>>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>>
>>>>>>> The only mechanism I can think of that can handle that kind of
>>>>>>> flexibility smoothly would be based on multiple language data
>>>>>>> types, and an ISA with separate instructions for each operation
>>>>>>> on each type.
>>>>>>
>>>>>> As for example:
>>>>>> enumWithTraits(intNumEnums, overflowCode,
>>>>>> excepting,
>>>>>> modulo,
>>>>>> saturating,
>>>>>> widening
>>>>>> );
>>>>>> available in every kind of operation that can overflow?
>>>>>
>>>>> I don't know what you mean.
>>>>>
>>>>> I mean that only the programmer knows their intent and since
>>>>> that intent changes and they need a way to express it.
>>>>> A one-size-fits-all approach isn't flexible enough.
>>>>>
>>>>> The compiler already handles overloading operators for different
>>>>> integral and float data types and sizes. This expands on that
>>>>> mechanism.
>>>>
>>>> I think the disconnect is the following. Ivan showed what
>>>> capabilities are/will be in the Mill hardware ISA. You talked
>>>> about what the programmer intends. The disconnect is that the
>>>> current C language doesn't provide a mechanism to "connect" the
>>>> two, at least in many cases. Several proposals have been made here
>>>> (pragmas, compile options, etc.), but none are apparently part of
>>>> the standard.
>>>>
>>>> I should note that at least a good part of these are specifiable in,
>>>> for example Ada. The very extensive type system in Ada is, IMO one
>>>> of its biggest strengths.
>>>
>>> Well put. Besides Ada, also consider C++ in which you can define
>>> classes saturatingShort, saturatingInt, etc and overload the
>>> operators to produce an intrinsic which in turn invokes a native
>>> instruction (Mill) or sequence (whatever). Writing the library is
>>> annoying, but using it is convenient and natural.
>>
>> Let me offer a different perspective here. User-defined types
>> work well for situations where there is only one operand of an
>> "unusual" type, or where several operands are homogeneous in a
>> particular "unusual" type. A key aspect of the problem here is
>> not when all the operands have the same type but when they may
>> have different types.
>
> In the Ada case, the idea (= spirit) is that you cannot combine
> different types in that way -- for example, you cannot by default
> add a signed integer to a modular integer. The programmer has to
> convert one or both operands explicitly to compatible types,

I understand. My point is about environments like C or C++
where mixing of different types is allowed, and the result
type depends on the operand types.

> or [let the compiler know in some other way what it should do in
> various specific cases, such as function overloading]

This alternative illustrates the kinds of problems I'm talking
about. Types have to know, in some sense, about other types,
and the resultant code growth in N*N rather than linear.

Ivan Godard <ivan@millcomputing.com> writes:

> On 10/23/2021 1:44 PM, Tim Rentsch wrote:
>
>> Ivan Godard <ivan@millcomputing.com> writes:
>>
>>> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>>>
>>>> On 10/19/2021 9:20 AM, EricP wrote:
>>>>
>>>>> Ivan Godard wrote:
>>>>>
>>>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>>
>>>>>>> The only mechanism I can think of that can handle that kind of
>>>>>>> flexibility smoothly would be based on multiple language data
>>>>>>> types, and an ISA with separate instructions for each operation
>>>>>>> on each type.
>>>>>>
>>>>>> As for example:
>>>>>> enumWithTraits(intNumEnums, overflowCode,
>>>>>> excepting,
>>>>>> modulo,
>>>>>> saturating,
>>>>>> widening
>>>>>> );
>>>>>> available in every kind of operation that can overflow?
>>>>>
>>>>> I don't know what you mean.
>>>>>
>>>>> I mean that only the programmer knows their intent and since
>>>>> that intent changes and they need a way to express it.
>>>>> A one-size-fits-all approach isn't flexible enough.
>>>>>
>>>>> The compiler already handles overloading operators for different
>>>>> integral and float data types and sizes. This expands on that
>>>>> mechanism.
>>>>
>>>> I think the disconnect is the following. Ivan showed what
>>>> capabilities are/will be in the Mill hardware ISA. You talked
>>>> about what the programmer intends. The disconnect is that the
>>>> current C language doesn't provide a mechanism to "connect" the
>>>> two, at least in many cases. Several proposals have been made here
>>>> (pragmas, compile options, etc.), but none are apparently part of
>>>> the standard.
>>>>
>>>> I should note that at least a good part of these are specifiable in,
>>>> for example Ada. The very extensive type system in Ada is, IMO one
>>>> of its biggest strengths.
>>>
>>> Well put. Besides Ada, also consider C++ in which you can define
>>> classes saturatingShort, saturatingInt, etc and overload the
>>> operators to produce an intrinsic which in turn invokes a native
>>> instruction (Mill) or sequence (whatever). Writing the library is
>>> annoying, but using it is convenient and natural.
>>
>> Let me offer a different perspective here. User-defined types
>> work well for situations where there is only one operand of an
>> "unusual" type, or where several operands are homogeneous in a
>> particular "unusual" type. A key aspect of the problem here is
>> not when all the operands have the same type but when they may
>> have different types. In many cases we want the choice of
>> trapping or wrapping or saturating to go with the operation, not
>> with the types of operands used. What should the result be in a
>> case where a trapping short and a wrapping int and a saturating
>> long are all added together? The combination of width on one
>> axis and choice of behavior rule on a different axis means a
>> non-linear number of types to define. To branch off a bit, now
>> add the aspect of units for different quantities. What should
>> happen if a saturating long inch is added to a saturating long
>> centimeter? User-defined types don't scale well when there are
>> multiple independent axes. Also there is the question of
>> understanding what the consequences are when different types are
>> combined. My experience doing this kind of thing in C++ leads me
>> to think figuring out the interactions along different axes would
>> be challenging, even just as a client of an existing set of
>> classes.

[...]

> As for your sum of sat+wrap+trunc, there's a simple solution: don't
> pollute the types of the operations with the types of the
> arguments. Let + take arguments and produce results from Z, and then
> check when that is assigned or passed to see if it conforms to the
> well defined and unambiguous type of the destination. [...]

That's fine if that behavior is what is wanted. My comment is
about a wider range of application, including for example
combination rules more like what C or C++ have. What you are
saying, in effect, is that user-defined types work just fine, but
only if we are willing to change how things work; in short they
offer a great solution, but to a different problem.

> Yes, Ada got it right, thank you.

I have gotten conflicting information on that point.

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Anton Ertl wrote:
>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>> That isn't a solution. If the problem is to satisfy both sides,
>>> killing the branch of the language that satisfies one of them
>>> constitutes failure; one side is not satisfied.
>>>
>>> However, reality is more complex than that. The reality is
>>> that C99 and gcc are viewed by the dissatisfied side as
>>> just that "solution" as having happened already...
>>
>> Actually, it seems to me that C++ is the solution for the nasal demon
>> worshippers. And once C compilers started to be written by C++
>> programmers, they applied the C++ view of how to deal with undefined
>> behaviour also to C.
>
>So why aren't more people switching to Rust?

More generally, why aren't people switching to other programming
languages? Because they have a legacy of C code. For new projects,
switching to a different language is much easier, although of course
in a C shop, switching still incurs some pain.

E.g., in Gforth we plan to do a Forth native-code compiler in Forth to
replace the existing virtual machine interpreter written in C (and
native-code generator that copies native code produced by the gcc);
But even when we have done that, eliminating C completely will be
hard; the current plan still has C there for bootstrapping purposes.

As for Rust specifically, my impression is that Rust is a solution for
those who want to restrict themselves to the discipline represented by
the Rust type system, and they get nice properties (no undefined
behaviour(?)) from it. But if what you want to do lies outside of
that realm, you have to take the escape hatch, and are back where you
started. But at least the Rust compiler will tell you when you tread
beyond the pale, unlike with C undefined behaviour.

>I took a look at RustCrypto, specifically how they handle bigint
>operations, and I was extremely impressed: You get the exact same direct
>access to both 64 and 128-bit signed and unsigned ints, and the
>naive/natural way to express "(hi, lo) = a + ( b*c) + carry" works
>as-is, and generates the same optimal code as you can get from clang
>when compiling C(++).

What else do you expect? It's the same back end.

>In Rust aliasing is even less of a problem than in Fortran afaik. :-)

Damning with faint praise? Fortran's touted benefit is that it will
assume function parameters don't alias. I.e., if you pass overlapping
parameters, bad things can happen. I would really hope that Rust does
not have this problem, otherwise it would lose the major benefit it has.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Ivan Godard wrote:
>
>> Here's a quick one, looks like an algebra problem but is actually
>> for 3D visualization. It was on a scholarship test, and we later
>> used it in recruiting at PDC:
>>
>> Given a cube, one on a side. Inscribed sphere, tangent to the cube's
>> faces. In each corner an inscribed sphere, tangent to the three cube
>> faces and the central sphere. What is the volume of the cube not
>> occupied by the spheres?
>
> That seemed really hard, but I'm pretty sure it helps a lot to realize
> that each of those smaller corner spheres can have a smaller cube
> around it, and that three of those cube faces will overlap with the
> larger cube. This means that first, the diagonal distance from the
> large sphere to a corner will be (3^-3 - 1)/2, or about 0.22.

Of course you mean sqrt(3), not 3**-3 or 3**(1./3.)

> That
> distance will then be split by a small sphere with the same ratio from
> center to corner, or (1+power(3,1/3)) * (-1+power(3,1/3)) / 4.
>
> Am I on the right track?

Here is how I reasoned it.

First I considered just one corner of the cube, with a unit
sphere (so radius one) inside, rather than a unit cube (so
in my case the cube is 2x2x2, but one corner of it is 1x1x1).

The diagonal of the corner cube is sqrt(3). The corner part
of the sphere still has radius one.

The inset sphere in the corner, let me assign that radius k.
The tangent point and center of the inset sphere are collinear
with the center of the large sphere and the corner of the
corner cube. Like what you point out, the inset sphere has
an octant that is tangent to the cube corner, with distance k
between the inset sphere center to each face, so that means

1 + k + k sqrt(3) = sqrt(3)

which lets us solve for k, so we know the volume of one
inset sphere.

For the answer, the volume of the cube corner is 1, and
the volume of this octant of the large sphere is 4/3 pi / 8
and the volume of the inset sphere is 4/3 pi k**3, with
the volume of the cube corner being 1, giving

1 - 4/3 pi /8 - 4/3 pi k**3

Of course that's only one eighth of the whole thing, but
since we started with a linear scale factor of two the
multiply by 8 and divide by 8 cancel, and that's our
answer. At least, I hope it is.. I know my mental
machinery is not always reliable.

Bonus problem: same question, but for a 4-dimensional
cube with 4-dimensional spheres.

David Brown <david.brown@hesbynett.no> writes:
>On 23/10/2021 19:24, Anton Ertl wrote:
>> Actually, it seems to me that C++ is the solution for the nasal demon
>> worshippers. And once C compilers started to be written by C++
>> programmers, they applied the C++ view of how to deal with undefined
>> behaviour also to C.
....
>But since I
>have no idea what a "C++ view of UB" might be or how it might differ
>from a "C view of UB"

I am not surprised.

Just in case somebody else finds my statement too cryptic: There have been
dialogs along the lines of

A: Assuming that programs do not perform undefined behaviour allows
optimizing "a*2/2" into "a", and that's important for performance.

B: But nobody writes such code with the intention of it being
optimized into "a". If I want "a", I write "a", and if I write
"a*2/2", I want something other than "a" in the overflow case.

A: It could be the result of macro expansion.

B: Oh, really?

Recently someone mentioned some C++ principle in connection with
undefined behaviour; something like "zero-cost abstractions". And
then I realized that in the C++ world people may write code that's
quite far from the base language, and this is processed by the
template processor in several layers until it arrives in the base
layer, and the end result may indeed contain something like "a*2/2",
and the C++ programmer may indeed want that to be optimized to "a". I
still find it hard to believe that such code occurs in expanded C++
code, but the point is that a C++ programmer probably finds it easy to
believe.

In the dialog above A exhibits the C++ view of how to deal with
undefined behaviour, while B doesn't.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> writes:

> On Saturday, October 23, 2021 at 6:09:53 PM UTC-5, Tim Rentsch wrote:
>
>> BGB <cr8...@gmail.com> writes:
>>
>>> On 10/12/2021 10:31 AM, Tim Rentsch wrote:
>>>
>>>> George Neuner <gneu...@comcast.net> writes:
>>>>
>>>> [...]
>>>>
>>>>> GCs for uncooperative languages (like C) do check potential
>>>>> pointers - i.e. properly aligned values - against the heap limits
>>>>> as a first step. But what the GC really needs to know is if a
>>>>> pointer refers to an actual allocated block. Determining /that/
>>>>> is a lot harder because the value must be range checked against
>>>>> every allocation, not just against the heap limits.
>>>>
>>>> It does take more development effort. It need not incur a
>>>> significantly larger run-time cost.
>>>
>>> Average-case cost for many GC designs is fairly low.
>>>
>>> One downside is the creation of delays or stalls.
>>>
>>> For example, if one has a mark/sweep collector, there is a visible
>>> (and potentially fairly obvious) stall whenever the GC runs. In a
>>> soft-real-time application (like a 3D game), it can get really
>>> annoying to have a game which periodically stalls.
>>>
>>> In harder real-time uses, these sorts of delays are unacceptable.
>>> [...]
>>
>> Certainly it is true that many GC schemes can have large delays
>> at times, and that for some applications such delays are absolutely
>> unacceptable.
>>
>> However, it is also true that some GC schemes have large delays
>> only very rarely (with much shorter delays being more common),
>> and also that some applications don't mind long delays at all as
>> long as the amortized cost is fairly low.
>>
>> More generally, the kinds of arguments I see against using GC
>> tend to be pointing out that there are some situations where
>> using GC doesn't satisfy the requirements. And that's true:
>> some applications are so demanding and resource hungry that
>> they need a lot of care and specialized machinery to get done
>> whatever it is they need to get done, and trying to use GC
>> can get in the way of that.
>>
>> Unfortunately the implicit argument that follows is that because
>> GC isn't good everywhere that it must not be good anywhere.
>> Obviously that's a bogus argument (which explains why it is
>> almost always implicit).
>>
>> In truth GC works just fine for many or most application areas,
>
> The other truth is that most applications do not need any GC whatsoever.
> {Where most means over 50%}

That is a vacuous statement.

On Monday, October 25, 2021 at 12:59:40 PM UTC-5, Tim Rentsch wrote:
> MitchAlsup <Mitch...@aol.com> writes:
>
> > On Saturday, October 23, 2021 at 6:09:53 PM UTC-5, Tim Rentsch wrote:
> >
> >> BGB <cr8...@gmail.com> writes:
> >>
> >>> On 10/12/2021 10:31 AM, Tim Rentsch wrote:
> >>>
> >>>> George Neuner <gneu...@comcast.net> writes:
> >>>>
> >>>> [...]
> >>>>
> >>>>> GCs for uncooperative languages (like C) do check potential
> >>>>> pointers - i.e. properly aligned values - against the heap limits
> >>>>> as a first step. But what the GC really needs to know is if a
> >>>>> pointer refers to an actual allocated block. Determining /that/
> >>>>> is a lot harder because the value must be range checked against
> >>>>> every allocation, not just against the heap limits.
> >>>>
> >>>> It does take more development effort. It need not incur a
> >>>> significantly larger run-time cost.
> >>>
> >>> Average-case cost for many GC designs is fairly low.
> >>>
> >>> One downside is the creation of delays or stalls.
> >>>
> >>> For example, if one has a mark/sweep collector, there is a visible
> >>> (and potentially fairly obvious) stall whenever the GC runs. In a
> >>> soft-real-time application (like a 3D game), it can get really
> >>> annoying to have a game which periodically stalls.
> >>>
> >>> In harder real-time uses, these sorts of delays are unacceptable.
> >>> [...]
> >>
> >> Certainly it is true that many GC schemes can have large delays
> >> at times, and that for some applications such delays are absolutely
> >> unacceptable.
> >>
> >> However, it is also true that some GC schemes have large delays
> >> only very rarely (with much shorter delays being more common),
> >> and also that some applications don't mind long delays at all as
> >> long as the amortized cost is fairly low.
> >>
> >> More generally, the kinds of arguments I see against using GC
> >> tend to be pointing out that there are some situations where
> >> using GC doesn't satisfy the requirements. And that's true:
> >> some applications are so demanding and resource hungry that
> >> they need a lot of care and specialized machinery to get done
> >> whatever it is they need to get done, and trying to use GC
> >> can get in the way of that.
> >>
> >> Unfortunately the implicit argument that follows is that because
> >> GC isn't good everywhere that it must not be good anywhere.
> >> Obviously that's a bogus argument (which explains why it is
> >> almost always implicit).
> >>
> >> In truth GC works just fine for many or most application areas,
> >
> > The other truth is that most applications do not need any GC whatsoever.
> > {Where most means over 50%}
>
> That is a vacuous statement.
<
OK, how much GC does 'cat' need ? 'more' ? 'less', 'ls', '|', 'vi',.....'dev/null',...

On 25/10/2021 19:26, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/10/2021 19:24, Anton Ertl wrote:
>>> Actually, it seems to me that C++ is the solution for the nasal demon
>>> worshippers. And once C compilers started to be written by C++
>>> programmers, they applied the C++ view of how to deal with undefined
>>> behaviour also to C.
> ...
>> But since I
>> have no idea what a "C++ view of UB" might be or how it might differ
>>from a "C view of UB"
>
> I am not surprised.
>
> Just in case somebody else finds my statement too cryptic: There have been
> dialogs along the lines of
>
> A: Assuming that programs do not perform undefined behaviour allows
> optimizing "a*2/2" into "a", and that's important for performance.
>
> B: But nobody writes such code with the intention of it being
> optimized into "a". If I want "a", I write "a", and if I write
> "a*2/2", I want something other than "a" in the overflow case.
>

Perhaps that applies to some programmers. Some other people write code
that might contain a range of small functions and macros which they
expect to be inlined with corresponding optimisations including
re-arrangement of expressions, constant propagation, strength reduction,
etc. They expect the compiler to generate results using the "as-if"
rule to get efficient results. It is the job of the programmer to write
clear, maintainable and flexible code - it is the job of the compiler to
turn that into efficient object code. The programmer is expected to
understand and follow the rules of the language, as is the compiler. If
the programmer wants a particular result or effect but does not describe
it correctly in the language, he/she can't expect the compiler to be a
mind-reader and give them something they did not ask for.

> A: It could be the result of macro expansion.
>
> B: Oh, really?

Yes, really. Or the result of function inlining, constant propagation,
function cloning, or many other optimisation techniques. C++ code in
particular would often be useless if such optimisations were not used.

Of course turning "a * 2 / 2" into "a" is not going to come up very
often, or make a big difference - it's just one of countless small
optimisations, each making a tiny contribution on average but summing to
a significant improvement overall.

>
> Recently someone mentioned some C++ principle in connection with
> undefined behaviour; something like "zero-cost abstractions". And
> then I realized that in the C++ world people may write code that's
> quite far from the base language, and this is processed by the
> template processor in several layers until it arrives in the base
> layer, and the end result may indeed contain something like "a*2/2",
> and the C++ programmer may indeed want that to be optimized to "a". I
> still find it hard to believe that such code occurs in expanded C++
> code, but the point is that a C++ programmer probably finds it easy to
> believe.
>
> In the dialog above A exhibits the C++ view of how to deal with
> undefined behaviour, while B doesn't.
>

Eh, okay. If you say so.

To me it sounds more like A is a mixture of an understanding of the
language combined with an exaggerated hope for optimisation (which you
no doubt added "for effect"). B exhibits the attitude of people who
won't take responsibility for their own coding, and expect the compiler
to give them the results they want regardless of what they asked for,
justified with sarcasm rather than logic.

But now at least I know what you mean by a "C++ view of UB" and a "C
view of UB", despite the two languages having an identical concept of UB
and despite them usually being used with exactly the same compiler.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

> Fortran's touted benefit is that it will
> assume function parameters don't alias. I.e., if you pass overlapping
> parameters, bad things can happen.

You're leaving out some details.

If you have overlapping actual arguments and change one of them,
then bad things can happen. For this to occur, at least one of
them has to be INTENT(INOUT) or no INTENT, which should not happen
in new code.

Changing INTENT(IN) is caught by the compiler.

David Brown <david.brown@hesbynett.no> writes:
>On 23/10/2021 15:56, Quadibloc wrote:
>> and nothing is preventing them from taking the last version
>> of gcc they liked, and maintaining it themselves. They could
>> even issue a language standard for a language which they
>> could call CC (for "Classic C") or something.
>
>Actually, the gcc folks already did that for the "other side". They
>added the "-fwrapv" flag, and the "-fno-strict-aliasing" flag, and the
>"-fno-delete-null-pointer-checks" flag, and probably others.

There's the rub. With the "probably others" you cannot use the
supposed successor of the known-working gcc as a drop-in replacement,
because the supposed successor may fail to work with the old flags.
There may be new flags which make the supposed successor behave as a
drop-in replacement, but for an existing dried-and-cut package this
does not help; it may fail to compile out of the box with the supposed
successor. Also, the new flag for disabling an "optimization" may
appear only several versions after the "optimization" was enabled by
default (this happened for -fwrapv), which means that several gcc
versions may be unusable (and then the next "optimization" without
flag may be in the versions that allow disabling the previous
"optimization" and so on).

At this point the advocates of undefined behaviour tell me that the
right approach is to keep a known-good gcc around, and build the
package with that and distribute it in binary form. Way to go for a
compiler like gcc that was originally intended to advance the cause of
free software (for clang OTOH things may be different).

That being said, recent gcc versions have not exhibited behaviour that
broke something in Gforth by doing something that I consider
inappropriate. gcc-7 got much more aggressive with tail-duplication,
which caused the sanity check in Gforth to disable a very effective
optimization in Gforth, but I consider tail duplication a legitimate
optimization. We found a workaround for that (won't help old gforth
versions, of course; they work, but without the disabled
optimization).

Supposedly the gcc maintainers are now testing new releases on a much
wider code basis, and use that for a conservative approach towards
optimization, and we may be seeing the benefit of that. I.e., maybe
the gcc maintainers have changed their attitude to be more responsible
(at least partially; my last look in the bug tracker was not so
encouraging) than what fans of undefined behaviour advocate.

>They got gcc for free (without
>having to maintain it), and they too could use the "-fwrapv" and
>"-fno-strict-aliasing". Not only would their old broken code still
>work, but they could now be sure that it would continue to work in the
>future, albeit as non-portable code.

If that was guaranteed, I would not complain (well, only that this was
not announced from the start). And gcc could certainly take the
presence of both "-fwrapv" and "-fno-strict-aliasing" as a hint that
the programmer does not want the compiler to assume that the program
does not perform undefined behaviour. Those who want to re-enable
specific assumptions could then list the respective flags, e.g.,
"-fdelete-null-pointer-checks".

Currently Gforth's configure.ac checks whether the C compiler
understands the following flags (and uses all those that the C
compiler understands):

-fno-gcse
-fcaller-saves
-fno-defer-pop
-fno-inline
-fwrapv
-fchar-unsigned
-fno-strict-aliasing
-fno-cse-follow-jumps
-fno-reorder-blocks
-fno-reorder-blocks-and-partition
-fno-toplevel-reorder
-fno-trigraphs
-falign-labels=1
-falign-loops=1
-falign-jumps=1
-fno-delete-null-pointer-checks

Only some of those are for disabling assumptions about undefined
behaviour. But OTOH I think that there are flags for disabling
assumptions that are not included in this list.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> writes:
> I was a sophomore in an Algebra 2 class comprised of mostly seniors.
> I sat in the back of the room so as to not annoy the seniors. One day I
> was doing Latin homework and not paying any attention, at which time
> the teacher called upon me, I looked at the scribbling on the board and
> emitted the correct answer. The teacher did not bother me again. The
> seniors were both annoyed and amazed.

end of 5th grade there was achievement test that had x+y=3, 2x+y=5,
solve for x and y. this was small rural school system and I had no idea
what it was .. I asked and was told algebra. next time county bookmobile
came through, I checked out algebra book ... by the end of summer had
finished all the school math books the bookmobile had. school system
didn't allow skipping any classes (one exception was physics sophmore
year with seniors, which required that they also be taking senior trig
.... but I had finished senior trig before 6th grade started) ... I did
make cardboard slide rules during 6th grade and by the middle of the
following summer was able to order a $4 sliderule from sears. 8th grade,
read science fiction books during math class, got 100s on everything
except zero for class participation).

In highschool I worked for the local hardware store and would
periodically get loaned out to local contractors. I managed to save
enough money I had enough to start at univ. in the fall. Summer after
freshman year, I got job as foreman on construction job (in part because
I could run the survey instrument, had three nine person crews) ...
spring had been wet and they were way behind schedule and started
working 80+hr weeks (time&half for 41-60, and double time for >60
.... more money/month until a number of years after graduation).

.... took intro to computers/fortran my sophmore year, univ. had 709
tape->tape with 1401 front-end tape<->unit record. End of class, I got
student job rewriting 1401 MPIO for 360/30 (univ. had been sold 360/67
for tss/360 replacing 709/1401 ... 360/30 interim replacing 1401 pending
360/67) ... I got to design & implement my own stand alone monitor,
device drivers, interrupt handlers, error recovery, storage management,
etc (they could have just continued to use MPIO in 1401 emulation on
360/30, but it apparently was part of gaining 360 experience). Univ.
shutdown datacenter on weekends ... and I had the whole place dedicated
to myself for 48hrs straight, although 48hrs w/o sleep made monday
classes a little hard). Within a year of taking computing/fortran intro
class, I was hired fulltime to be responsible for os/360 systems
(tss/360 never came to production fruition so ran as 360/65).

Student fortran jobs had ran less than second on 709 tape->tape
.... initially with os/360 running as 360/65 took over minute. I
installed hasp which cut it in half. I then started doing carefully
crafted SYSGENS for placement of files and PDS members for optimized arm
seeks and multi-track searches ... cutting another 2/3rds to 12.9sec
(student jobs never ran faster than 709 until installed Waterloo's
WATFOR).

Then before I graduate, I'm hired fulltime into a small group in the
Boeing CFO's office to help with the formation of Boeing Computer
Services (consolidate all dataprocessing into an independent business
unit to better monetize the investment, including offering services to
non-Boeing entities). I thot Renton datacenter was possibly largest in
the world, something like $200M-$300M (60s $$$) in IBM 360s, 360/65s
arriving faster than they could be installed, boxes constantly staged in
hallways around machine room. 747-3 was flying skies of seattle getting
FAA flt. certification. Some point at the univ. I had gotten a copy of
Cambridge's (virtual machine) CP67 that I could play with on the
weekends. When I was hired at Boeing, the CFO office just had a small
machine room for 360/30 that was used for the company payroll ... but
they expanded the machine room and installed a 360/67 for me to play
with CP67 as much as I wanted to (when I wasn't doing other stuff). When
I graduate, I join the IBM science center (instead of staying at
Boeing).

Late 70s/early 80s, I was blamed for online computer conferencing on the
internal network (larger than arpanet/internet from just about beginning
until sometime mid/late 80s), folklore is that when corporate executive
committee was told about it, 5of6 wanted to fire me (some claim that
some 25,000 employees were reading, even tho only about 300 were
participating). One of the outcomes was researcher was paid to study
how I communicate, sat in the back of my office for 9months taking notes
on how I communicated, went with me to meetings, got copies of all
incoming & outgoing email and logs of all instant messages. Results were
papers, books, and Stanford Phd (joint language & computer ai, winograd
was advisor on computer at side). The researcher had spent several
years as ESL instructor ... and commented that my use of English is
characteristic of non-native speaker (fluent in some other language)
.... except I have no non-English native (natural) language.

--
virtualization experience starting Jan1968, online at home since Mar1970

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Ivan Godard wrote:
>>
>>> Here's a quick one, looks like an algebra problem but is actually
>>> for 3D visualization. It was on a scholarship test, and we later
>>> used it in recruiting at PDC:
>>>
>>> Given a cube, one on a side. Inscribed sphere, tangent to the cube's
>>> faces. In each corner an inscribed sphere, tangent to the three cube
>>> faces and the central sphere. What is the volume of the cube not
>>> occupied by the spheres?
>>
>> That seemed really hard, but I'm pretty sure it helps a lot to realize
>> that each of those smaller corner spheres can have a smaller cube
>> around it, and that three of those cube faces will overlap with the
>> larger cube. This means that first, the diagonal distance from the
>> large sphere to a corner will be (3^-3 - 1)/2, or about 0.22.
>
> Of course you mean sqrt(3), not 3**-3 or 3**(1./3.)

Oops... :-(

>> That
>> distance will then be split by a small sphere with the same ratio from
>> center to corner, or (1+power(3,1/3)) * (-1+power(3,1/3)) / 4.
>>
>> Am I on the right track?
>
> Here is how I reasoned it.
>
> First I considered just one corner of the cube, with a unit
> sphere (so radius one) inside, rather than a unit cube (so
> in my case the cube is 2x2x2, but one corner of it is 1x1x1).

I did the same, then I noticed that I had to divide by 2.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 25/10/2021 19:58, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/10/2021 15:56, Quadibloc wrote:
>>> and nothing is preventing them from taking the last version
>>> of gcc they liked, and maintaining it themselves. They could
>>> even issue a language standard for a language which they
>>> could call CC (for "Classic C") or something.
>>
>> Actually, the gcc folks already did that for the "other side". They
>> added the "-fwrapv" flag, and the "-fno-strict-aliasing" flag, and the
>> "-fno-delete-null-pointer-checks" flag, and probably others.
>
> There's the rub. With the "probably others" you cannot use the
> supposed successor of the known-working gcc as a drop-in replacement,
> because the supposed successor may fail to work with the old flags.

Actually, you /can/ - you do so by writing code that has defined
behaviour (defined by the C standard, target ABI, compiler
documentation, etc.).

Where you get in trouble is if you rely on behaviour that is not defined
anywhere and expect it to stay consistent.

I think the scope for that is getting smaller - the big issues that crop
up regularly have already been covered by the flags listed above.

I can only really think of two remaining situation where people could
reasonably assume certain behaviour, but it is not actually guaranteed
by the standards or the compiler - boundary points between functions,
and boundary points across compilation units.

Some people assume that functions are compiled independently, and this
enforces ordering on execution, memory accesses, etc. They think that
if a function calls another function, then that call acts like a memory
barrier of some sort. But of course that is not the case - the compiler
can, for example, assume that the called function does not access any
local variables that don't "escape", and if it can see the function
definition at compilation time, it can inline the code or do all sorts
of re-arrangements and optimisations. I don't know any gcc flags that
blacklist inter-procedural optimisations specifically - there are lots
of "ipa" optimisation flags, many enabled at -O1.

Secondly, many more people will assume that if the functions are in
different compilation units, then they are compiled independently. This
is more often the case - but if you have link-time optimisation (a
technology that has been used in compilers for at least three decades,
so it is not new) then you get inter-procedural optimisations just as if
they were in the same file.

> There may be new flags which make the supposed successor behave as a
> drop-in replacement, but for an existing dried-and-cut package this
> does not help; it may fail to compile out of the box with the supposed
> successor. Also, the new flag for disabling an "optimization" may
> appear only several versions after the "optimization" was enabled by
> default (this happened for -fwrapv), which means that several gcc
> versions may be unusable (and then the next "optimization" without
> flag may be in the versions that allow disabling the previous
> "optimization" and so on).
>
> At this point the advocates of undefined behaviour tell me that the
> right approach is to keep a known-good gcc around, and build the
> package with that and distribute it in binary form. Way to go for a
> compiler like gcc that was originally intended to advance the cause of
> free software (for clang OTOH things may be different).
>

Ultimately, the only way to be /completely/ sure is to be specific about
the compiler.

In my business - small-systems embedded programming - it is important to
be sure. I leave as little to chance or variation as possible. Thus I
write my code to avoid undefined behaviour (as best I can as a mere
human programmer), use as much static error checking, test as well as I
can, etc. But I also consider the toolchain as part of the project and
archive it. That way I can always re-create a bit-perfect copy of the
binary when resurrecting old projects. Embedded compilers and libraries
don't always have the same level of testing and stability as heavily
used desktop tools, so this avoids introducing the risk of new bugs,
regressions in efficiency, or changes in the details of extensions. And
if I /have/ made a mistake and my code is accidentally dependent on the
luck of how some UB is implemented, the results will be consistently lucky!

Obviously, however, that is not appropriate for all kinds of programming
tasks. When you don't have such control, you have a greater
responsibility to make sure your code doesn't attempt to execute UB and
that non-portable code is limited to things that are reasonable.
Sometimes it can be appropriate to add things like pragmas to enable
-fwrapv or -fno-strict-aliasing - that is more robust than demanding
particular compiler flags from the build system.

> That being said, recent gcc versions have not exhibited behaviour that
> broke something in Gforth by doing something that I consider
> inappropriate. gcc-7 got much more aggressive with tail-duplication,
> which caused the sanity check in Gforth to disable a very effective
> optimization in Gforth, but I consider tail duplication a legitimate
> optimization. We found a workaround for that (won't help old gforth
> versions, of course; they work, but without the disabled
> optimization).
>

I appreciate that something like Gforth could be a particularly awkward
kind of program where particular code generation techniques or
optimisations might have a negative effect.

> Supposedly the gcc maintainers are now testing new releases on a much
> wider code basis, and use that for a conservative approach towards
> optimization, and we may be seeing the benefit of that. I.e., maybe
> the gcc maintainers have changed their attitude to be more responsible
> (at least partially; my last look in the bug tracker was not so
> encouraging) than what fans of undefined behaviour advocate.
>

My understanding is that the gcc team (and testers) have done a lot of
wide testing for a long time now, including builds of everything in the
Debian repositories. A lot of the more publicised cases of unexpected
optimisations have come during pre-release testing - which is precisely
why they do pre-release testing.

>> They got gcc for free (without
>> having to maintain it), and they too could use the "-fwrapv" and
>> "-fno-strict-aliasing". Not only would their old broken code still
>> work, but they could now be sure that it would continue to work in the
>> future, albeit as non-portable code.
>
> If that was guaranteed, I would not complain (well, only that this was
> not announced from the start). And gcc could certainly take the
> presence of both "-fwrapv" and "-fno-strict-aliasing" as a hint that
> the programmer does not want the compiler to assume that the program
> does not perform undefined behaviour. Those who want to re-enable
> specific assumptions could then list the respective flags, e.g.,
> "-fdelete-null-pointer-checks".

I think it is probably impossible to have a compiler that does not make
some assumptions about the non-execution of UB. To take an obvious
example, if you define a function in one unit with a particular set of
parameters, then declare it and call it in a different unit with a
different set of parameters, it is UB. A compiler will obviously assume
that when you declare a function and call it, that the function really
takes those parameter types - it is assuming that such UB does not occur.

There are specific examples of UB where there is a particular
interpretation that people could reasonably expect if the behaviour had
been defined. TBAA violations are a fine example. Signed integer
overflow is another, though less clear - I am not inclined to accept a
clearly wrong answer as an "obvious" interpretation. However, you can
certainly argue that these, along with things like certain shifts of
negative values, could all be grouped under one "-fdefine-some-ub" flag.

But UB in general would still exist, and the compiler must be able to
assume that UB does not occur. What you are doing is /not/ restricting
optimisation based on UB, but instead adding additional semantics to the
language for certain aspects, giving defined behaviour to particular
things that the language standard leaves as UB. I have no problem with
that.

>
> Currently Gforth's configure.ac checks whether the C compiler
> understands the following flags (and uses all those that the C
> compiler understands):
>
> -fno-gcse
> -fcaller-saves
> -fno-defer-pop
> -fno-inline
> -fwrapv
> -fchar-unsigned
> -fno-strict-aliasing
> -fno-cse-follow-jumps
> -fno-reorder-blocks
> -fno-reorder-blocks-and-partition
> -fno-toplevel-reorder
> -fno-trigraphs
> -falign-labels=1
> -falign-loops=1
> -falign-jumps=1
> -fno-delete-null-pointer-checks
>
> Only some of those are for disabling assumptions about undefined
> behaviour. But OTOH I think that there are flags for disabling
> assumptions that are not included in this list.
>

David Brown [2021-10-25 23:59:16] wrote:
> On 25/10/2021 19:58, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 23/10/2021 15:56, Quadibloc wrote:
>>>> and nothing is preventing them from taking the last version
>>>> of gcc they liked, and maintaining it themselves. They could
>>>> even issue a language standard for a language which they
>>>> could call CC (for "Classic C") or something.
>>>
>>> Actually, the gcc folks already did that for the "other side". They
>>> added the "-fwrapv" flag, and the "-fno-strict-aliasing" flag, and the
>>> "-fno-delete-null-pointer-checks" flag, and probably others.
>>
>> There's the rub. With the "probably others" you cannot use the
>> supposed successor of the known-working gcc as a drop-in replacement,
>> because the supposed successor may fail to work with the old flags.
>
> Actually, you /can/ - you do so by writing code that has defined
> behaviour (defined by the C standard, target ABI, compiler
> documentation, etc.).

Sometimes it's not an option. To mention an example I brought up here
a few times, AFAIK you can't write code which scans the stack.
This is inherently an operation whose result can't be strictly defined
by the standard, but the problem is that it means you're necessarily at
the mercy of the compiler.

Such code is rare and we can mostly make it work with current compilers,
but it would be nice to have some way to tell the compiler that this is
UB-on-purpose and hence optimizations shouldn't presume that UB is
impossible on that code.

Of course, that won't be sufficient to give the code a meaningful and
reliable semantics: after all, the compiler may decide to use multiple
stacks, divided into multiple small chunks, and it may decide to
represent its stack in any kind of creative way. These are really
fundamentally "undefined" and inherently depend on the compiler's
internals. But being able to write the loop that scans between the two
pointers which we think represent the top and bottom of the stack would
be a good step.

Stefan

On Sunday, October 24, 2021 at 1:42:23 AM UTC-6, Thomas Koenig wrote:
> Ivan Godard <iv...@millcomputing.com> schrieb:
> > The lit history is full of efforts to put units into the type systems.
> > They sure look plausible but don't work. Think of a NR sqrt routine.

> MathCad has got this right. It is not a compiled language,
> but it certainly works. I use it a lot in my day job for simple
> engineering calculations: You see the formulas, you immediately
> see the output, you do input in units (like kg/h), you can convert
> the output to units you want.
>
> And, of course, it complains if you try to add or subtract
> dimensions that do not match.
>
> (Notice I said "dimensions" in the last sentence - adding an inch
> to a meter is fine, because both get converted automatically,
> but adding a meter to a second is an error. Nomenclature:
> Length is a dimension, meter or inch are units, of length
> in this case).
>
> It even handles square roots of units and dimensions, which
> are sometimes used, as characteristics of distillations colums,
> for example.
>
> It handles units and dimensions as floating point numbers.
> For dimensions, using rational numbers would probably be better.

This is interesting; I am glad to hear that a language is available
that can handle physical quantities with units correctly, thus
reducing problems created by mistakes in dimensional analysis
by the programmer.

And given that statement of the _benefit_ of doing this, I think
that one _could_ in a compiled language flag floating-point
quantities with units, so that the compiler would give an error or
warning if incorrect arithmetic operations were specified with them.

This reminds me: on my web site, in my description of a
proposed language, I've proposed an extension to the type
system for languages like FORTRAN that are used for numerical
computation.

The language is based on one I'd come up with many years ago
back when I was a student in University. It was basically a fancy
Fortran with additional ease of use features.

So if A, B, and C are arrays, one could write A=B+C or A=B*C
instead of having to write a DO loop.

I spoke to someone else about it, and I noted that A=B*C was
element-by-element, not matrix multiplication, in response to
a question. The other fellow thought I was being too slavish
in following APL.

I thought about the matter further.

I felt I _was_ right in handling _arrays_ that way. Making matrix
multiplication the default for multiplying arrays was giving
inappropriate semantic content to the notion of an array.

But I felt the other fellow had a point too. Matrix multiplication
is important in scientific and engineering computation.

So I came up with what was, to me, a solution.

In FORTRAN, there is a COMPLEX data type. In my language,
I had already added, as an obvious extension, a QUATERNION
data type.

Well, then.

What about a MATRIX data type?

Given that a MATRIX would bind an a x b grid of scalar
elements into a *mathematical object* which would be
subject to special rules and operations, whereas a two-dimensional
array is just a plain collection of things, you can have an array of
matrices, but *not* a matrix of arrays (basically for the same
reason you can't have a complex number whose real and imaginary
parts are each an array with the same dimensions).

This makes sense to me, but apparently to no one else, as it
has yet to catch the world by storm.

John Savard

On 10/24/2021 12:42 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> The lit history is full of efforts to put units into the type systems.
>> They sure look plausible but don't work. Think of a NR sqrt routine.
>
> MathCad has got this right. It is not a compiled language,
> but it certainly works. I use it a lot in my day job for simple
> engineering calculations: You see the formulas, you immediately
> see the output, you do input in units (like kg/h), you can convert
> the output to units you want.
>
> And, of course, it complains if you try to add or subtract
> dimensions that do not match.

What happens if you multiply two variables with dimension "length"
together? Does it understand that the result is an "area"? And that is
a simple case. You can get far more complex combinations than that. It
seems to me that this could be a nearly bottomless pit.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Tuesday, October 26, 2021 at 12:21:43 AM UTC-6, Stephen Fuld wrote:

> What happens if you multiply two variables with dimension "length"
> together? Does it understand that the result is an "area"? And that is
> a simple case. You can get far more complex combinations than that. It
> seems to me that this could be a nearly bottomless pit.

Well, since things like kg-m/sec^2 are valid dimensions, presumably
multiplying and dividing dimensions is okay. You just get a combination
of dimensions, and then you can only add or subtract it to something with
the same combination.

But only dimensionless numbers could be raised to powers that weren't
integer constants... that limitation should avoid the really bad problems.

John Savard

On 26/10/2021 03:30, Stefan Monnier wrote:
> David Brown [2021-10-25 23:59:16] wrote:
>> On 25/10/2021 19:58, Anton Ertl wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 23/10/2021 15:56, Quadibloc wrote:
>>>>> and nothing is preventing them from taking the last version
>>>>> of gcc they liked, and maintaining it themselves. They could
>>>>> even issue a language standard for a language which they
>>>>> could call CC (for "Classic C") or something.
>>>>
>>>> Actually, the gcc folks already did that for the "other side". They
>>>> added the "-fwrapv" flag, and the "-fno-strict-aliasing" flag, and the
>>>> "-fno-delete-null-pointer-checks" flag, and probably others.
>>>
>>> There's the rub. With the "probably others" you cannot use the
>>> supposed successor of the known-working gcc as a drop-in replacement,
>>> because the supposed successor may fail to work with the old flags.
>>
>> Actually, you /can/ - you do so by writing code that has defined
>> behaviour (defined by the C standard, target ABI, compiler
>> documentation, etc.).
>
> Sometimes it's not an option. To mention an example I brought up here
> a few times, AFAIK you can't write code which scans the stack.
> This is inherently an operation whose result can't be strictly defined
> by the standard, but the problem is that it means you're necessarily at
> the mercy of the compiler.
>

Code like that has to be specific to the particular compiler and often
to particular versions and flag sets. Eventually you can reach a point
where the code is "defined" in terms of what you see it has produced.
(I suppose someone could write a non-deterministic compiler, but that
might be an unpopular choice!)

> Such code is rare and we can mostly make it work with current compilers,
> but it would be nice to have some way to tell the compiler that this is
> UB-on-purpose and hence optimizations shouldn't presume that UB is
> impossible on that code.
>

That can't happen, in general. The best you can do is give defined
behaviours to some specific classes of UB. You can say, for example,
that all memory accesses should be treated as "volatile". (Of course,
you can do that anyway - if you want some memory accesses to be handled
"exactly as you write", then make them volatile.) Or you can say that
you want all signed overflow to be wrapping (you can use casts to
unsigned for that).

The closest you can get, perhaps, would be to add "#pragma GCC optimize
0" to the code to disable all optimisations in that part.

> Of course, that won't be sufficient to give the code a meaningful and
> reliable semantics: after all, the compiler may decide to use multiple
> stacks, divided into multiple small chunks, and it may decide to
> represent its stack in any kind of creative way. These are really
> fundamentally "undefined" and inherently depend on the compiler's
> internals. But being able to write the loop that scans between the two
> pointers which we think represent the top and bottom of the stack would
> be a good step.
>

A couple of "volatile" qualifiers on your pointers should handle that
nicely. (But as you say, it won't guarantee that things are put on the
stack in the way you might expect.)

To be fair, I suppose, the meaning of using "pointer to volatile"
pointers has been poorly defined in C - it is not until the upcoming C23
that "volatile semantics for lvalues" is actually standardised.
However, all known compilers have always treated accesses using volatile
pointers as "non-optimised".

On 2021-10-26 0:59, David Brown wrote:

> I can only really think of two remaining situation where people could
> reasonably assume certain behaviour, but it is not actually guaranteed
> by the standards or the compiler - boundary points between functions,
> and boundary points across compilation units.
>
> Some people assume that functions are compiled independently, and this
> enforces ordering on execution, memory accesses, etc. They think that
> if a function calls another function, then that call acts like a memory
> barrier of some sort. But of course that is not the case -

These discussions of volatile, and execution order wrt timing, gave me
an idea: perhaps C (and other languages) should allow marking functions
(subprograms) as "volatile", with the meaning that all of the effects of
a call of that function (including use of processor time) should be
ordered as volatile accesses are ordered, with respect to other volatile
accesses.

For example, if x and y are volatile variables, and foo is a volatile
function, then in this code

x = 1;
foo ();
y = 1;

we would be sure that all effects and all dynamic resource usage of the
foo() call would occur between the assignments to x and to y.

A more flexible approach would be to mark selected function calls as
volatile, in the same way that C allows in-line use of
pointer-to-volatile to force a volatile access to an object that is not
itself marked volatile. Something like:

x = 1;
(volatile) foo ();
y = 1;

Are volatile functions and/or volatile function calls a good idea?

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

> Currently Gforth's configure.ac checks whether the C compiler
> understands the following flags (and uses all those that the C
> compiler understands):
>
> -fno-gcse
> -fcaller-saves
> -fno-defer-pop
> -fno-inline
> -fwrapv
> -fchar-unsigned
> -fno-strict-aliasing
> -fno-cse-follow-jumps
> -fno-reorder-blocks
> -fno-reorder-blocks-and-partition
> -fno-toplevel-reorder
> -fno-trigraphs
> -falign-labels=1
> -falign-loops=1
> -falign-jumps=1
> -fno-delete-null-pointer-checks

Wow.

-fno-reorder-blocks puts the compiler back before the very first
FORTRAN compiler, which invented basic blocks and moving them
around for optimization.

-fno-inline can be a performance killer if people prefer static
inline functions, which are type-safe and evaluate their arguments
only once over macros.

But then, I understand from an old PR of yours (PR 15252) that
gforth makes heavy use of "goto variable", an extension that
(IIRC) was originally put into gcc by Craig Burley to support
assigned gotos in FORTRAN, so your code is certainly very much
non-conforming. Luckily, assigned gotos have been depecated
in Fortran.

For the readers who do not know what I am talking about,
here is a reduced test case from the PR:

int f(int i, int j)
{ static void *a[5] = {&&b,&&c,&&d,&&e,&&f};

if (i >=5) i = 0; if (i<=0)i=5;
goto *a[i];
e:
i++; if (i >=5) i = 0; if (i<=0)i=5;
j++;
goto *a[i];
f:
i--; if (i >=5) i = 0; if (i<=0)i=5;
j--;
goto *a[i];
b:
i+=2; if (i >=5) i = 0; if (i<=0)i=5;
goto *a[i];
c:
i*=2; if (i >=5) i = 0; if (i<=0)i=5;
goto *a[i];
d:;
}

With this sort of code, I can understand why a lot of optimizations
like moving basic blocks around can mess up your implementation.

> Only some of those are for disabling assumptions about undefined
> behaviour.

I suspect the rest is for making code like the above work :-)

Niklas Holsti <niklas.holsti@tidorum.invalid> schrieb:

> For example, if x and y are volatile variables, and foo is a volatile
> function, then in this code
>
> x = 1;
> foo ();
> y = 1;
>
> we would be sure that all effects and all dynamic resource usage of the
> foo() call would occur between the assignments to x and to y.

You can have that already by having pointers to x and y escape
(i.e. put bar(&x, &y) before it).

If the compiler cannot determine that foo() does not touch these
variables, then the order is assured.

(And no, I am not a fan of that particular feature of C).

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 10/24/2021 12:42 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> The lit history is full of efforts to put units into the type systems.
>>> They sure look plausible but don't work. Think of a NR sqrt routine.
>>
>> MathCad has got this right. It is not a compiled language,
>> but it certainly works. I use it a lot in my day job for simple
>> engineering calculations: You see the formulas, you immediately
>> see the output, you do input in units (like kg/h), you can convert
>> the output to units you want.
>>
>> And, of course, it complains if you try to add or subtract
>> dimensions that do not match.
>
> What happens if you multiply two variables with dimension "length"
> together? Does it understand that the result is an "area"?

It understands that the result is a length squared (and you can
put in an area measurement if you feel like it).

The only thing it cannot determine is the difference between
torque and work - when I calculate a torque, a "J" automtically
appears as a unit. I can change it to "N m" by hand, though.

> And that is
> a simple case. You can get far more complex combinations than that. It
> seems to me that this could be a nearly bottomless pit.

It works pretty well, as long as your formulas are consistent.

Some people like to write fomulas like pressure = velocity ^1.2342,
of course it will be flagged. However, the problem is with the
people writing the formula, not the program.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>Anton Ertl wrote:
>>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>>> That isn't a solution. If the problem is to satisfy both sides,
>>>> killing the branch of the language that satisfies one of them
>>>> constitutes failure; one side is not satisfied.
>>>>
>>>> However, reality is more complex than that. The reality is
>>>> that C99 and gcc are viewed by the dissatisfied side as
>>>> just that "solution" as having happened already...
>>>
>>> Actually, it seems to me that C++ is the solution for the nasal demon
>>> worshippers. And once C compilers started to be written by C++
>>> programmers, they applied the C++ view of how to deal with undefined
>>> behaviour also to C.
>>
>>So why aren't more people switching to Rust?
>
> More generally, why aren't people switching to other programming
> languages? Because they have a legacy of C code.

Or because they like the language, or do not feel like being
constrained, or the language is not available on their
favorite platform, or...

In general, I am in favor of languages which lets me do things I
cannot do in other languages. I am less a fan of languages which
try to educate me what to use and not to use.