On 26/10/2021 09:26, Niklas Holsti wrote:
> 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?

That is an interesting idea. It would, I think, be feasible for such a
"volatile" function to consider each read and write it does as though it
was a volatile access. But what about other code that it might call -
should "volatile" be recursive here? And what would it really mean to
say that "processor time" is also ordered? I agree that sometimes it is
useful to try and control the points where work is done (such as
ensuring calculations are done outside of a critical section when
possible), but I think it would be hard to get a good definition and
specification of how these volatile functions would work.

I suspect this would need a lot of effort to develop into something
rigorous and definable. But the end result could definitely have its uses.

>> 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.

Only if you take it as a hypothesis.
It can definitely happen if the question is "how" rather than "if".

Stefan

Thomas Koenig [2021-10-26 10:41:27] wrote:
> 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-inline can be a performance killer if people prefer static
> inline functions, which are type-safe and evaluate their arguments
> only once over macros.

You have to understand that the above is used for a Forth compiler which
generates C code internally. So of course, most of the relevant
optimizations are performed by the Forth compiler and aren't needed or
even desired from the C compiler.

The C compiler only needs to do the architecture-dependent part of
optimizations, like register allocation, instruction selection, and
a bit of code scheduling.

Stefan

> 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.

Every time a language allows X, it inevitably prevents you from
doing the things which depend on X never happening.

And vice versa, when a language disallows X, it allows you to do things
that depend on knowing that X will never happen.

So whether X "lets me do things I cannot do in other languages" or
whether it "try to educate me what to use and not to use" is largely
a question of perspective.

Stefan

On 26/10/2021 14:54, Stefan Monnier wrote:
>>> 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.
>
> Only if you take it as a hypothesis.
> It can definitely happen if the question is "how" rather than "if".
>

/Please/ follow standard Usenet attributions when quoting other people's
posts. It is simply common courtesy, and makes threads a lot easier to
follow.

I gave an example of UB in C for which it makes no sense to talk about a
compiler not presuming it can't happen. I could give more (many, many
more), but one is sufficient to make my point.

If you want to stop the compiler doing something you don't like, you
have to specify what that is, and you have to specify what you want it
to do.

On 26/10/2021 14:59, Stefan Monnier wrote:
> Thomas Koenig [2021-10-26 10:41:27] wrote:
>> 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-inline can be a performance killer if people prefer static
>> inline functions, which are type-safe and evaluate their arguments
>> only once over macros.
>
> You have to understand that the above is used for a Forth compiler which
> generates C code internally. So of course, most of the relevant
> optimizations are performed by the Forth compiler and aren't needed or
> even desired from the C compiler.
>
> The C compiler only needs to do the architecture-dependent part of
> optimizations, like register allocation, instruction selection, and
> a bit of code scheduling.
>
>
> Stefan
>

I am not clear here whether these are flags used when compiling the
Gforth transpiler tool, or whether they are flags used when compiling
the output of Gforth. These are two /very/ different situations.

On Monday, October 25, 2021 at 8:30:43 PM UTC-5, Stefan Monnier wrote:
> David Brown [2021-10-25 23:59:16] wrote:
> > On 25/10/2021 19:58, Anton Ertl wrote:
> >> David Brown <david...@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.
<
What valid programming example fits the description "Scan 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.
<
Stacks are allowed to grow upwards and downwards. How do you get the
++ or -- correct on both ?
>
> Such code is rare and we can mostly make it work with current compilers,
<
Still waiting for a valid example.
<
> 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.
<
-O0
>
> 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,
<
Or a cactus stack, or a liked list which is malloc-ed each frame.
<
> 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.
<
Why are you walking the stack ?
>
>
> Stefan

On Tuesday, October 26, 2021 at 12:57:07 AM UTC-5, Quadibloc wrote:
> 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
<
This is the correct solution
* is element by element
× is matrix multiply
<
> 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 Tuesday, October 26, 2021 at 1:21:43 AM UTC-5, Stephen Fuld wrote:
> On 10/24/2021 12:42 AM, 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.
<
> What happens if you multiply two variables with dimension "length"
> together? Does it understand that the result is an "area"?
<
What happens when you multiply 1 width by 1 height ? you get an
Area. But if you multiply 1 vector length by a second vector length
you get a×b×cos(angle(a,b)).
<
If you are going this far--get it right !
<
> 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)

Tim Rentsch wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> 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.

The type mixing in C is an illusion that is a consequence of automatic
conversions. The C compiler knows exactly what types expressions have,
and if those types don't map to known operations then it has a set
of promotion and conversion rules.

Binary operators act on pairs of same-type operands.

For integer + the compiler would have at least two definitions
signed + signed, unsigned + unsigned but they both map to the
same instruction.

For integer * and / signed and unsigned map to different instructions.

C's promotion and conversion rules basically say promote within
signed or unsigned type, and when it runs out of signed integer types
then assume the bit pattern is unsigned.

The difference for strong typing is there is no automatic type changes.
However most C compilers have a warning for operations on mixed 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.

Hmmm... under the hood there are only the physical types that the
hardware supports, and the compiler has to know how to change those.
e.g. integer, single, double, decimal(m.n).

Types may have some additional logical rules applied
and a conversion should apply those too.
e.g. integer range 1..10

But a strong type language compiler doesn't generate all conversions
between all logical and physical types just in case someone needs one.
It has a set of converters for the 3 or 4 physical types, just like C.
Most conversion checks result from assigning a larger to smaller integer
so it checks that you are not putting 10 lbs into a 5 lbs bag.

Tim Rentsch wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>
>> 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.

What changes for strong typing is that if you mix incompatible types
you must specify that you intended to do so. C has some automatic,
transparent conversion between types, like signed to unsigned integer,
that most modern C compilers warn about and most programmers already
include explicit casts, both to document that "yes it was intentional"
and to get the warning to shut up.

Also there may also be rules applied when converting between those
types and you want those rules invoked under your control.

For example, converting a signed-trap to unsigned-sat of the same
size changes the logical type then applies range constraints,
so it checks if the source is negative and sets it to zero.

Converting unsigned-sat to signed-trap of the same size checks if
the source is > INT_MAX (msb == 1) and traps if it is.

>> Yes, Ada got it right, thank you.
>
> I have gotten conflicting information on that point.

There were aspects of Ada83 that I liked and others I didn't.
It has changed a lot since I used it and I see that some things
that I considered problems have been smoothed out.

My tests for language X would be, can one write a compiler for X in X?
How much effort is it to write a GUI Windows/Xwindows interface app in it?
How much effort is it to write an OS in it?
(The last two requires extensive type conversions, so it stress-tests
the ergonomics of the typing rules.)

On 2021-10-26 15:59, Stefan Monnier wrote:
> Thomas Koenig [2021-10-26 10:41:27] wrote:
>> 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-inline can be a performance killer if people prefer static
>> inline functions, which are type-safe and evaluate their arguments
>> only once over macros.
>
> You have to understand that the above is used for a Forth compiler which
> generates C code internally. So of course, most of the relevant
> optimizations are performed by the Forth compiler and aren't needed or
> even desired from the C compiler.
>
> The C compiler only needs to do the architecture-dependent part of
> optimizations, like register allocation, instruction selection, and
> a bit of code scheduling.

That is not how I understand Gforth. Based on earlier discussions with
Anton Ertl, Gforth does not generate C source. It has an internal set of
small C functions or code blocks, compiled by the C compiler when Gforth
is compiled, which implement each predefined Forth "word" (primitive
Forth operation). To compile a user-defined Forth word (a subroutine),
Gforth can either do as most simple interactive Forth systems do, which
is to make a list of the machine addresses of the code blocks for the
words that are used (called) in the subroutine, to be traversed by the
Forth "interpreter", _or_ Gforth can copy and concatenate the machine
code for those words, from the original code blocks for each word,
generating at run-time a new and larger machine code block for the new
word. This in-lines the machine code for each word and means that the
word can be executed as one step in the "interpreter". (I don't think
Gforth then optimizes the in-lined code in any way.)

As I understand it, the gcc options listed above are partly intended to
make this copy-and-concatenate process produce machine code that works
as intended. It amazes me that it actually works on several architectures.

(I hope Anton will correct the above if it is wrong.)

On 10/26/2021 7:34 AM, MitchAlsup wrote:
> On Monday, October 25, 2021 at 8:30:43 PM UTC-5, Stefan Monnier wrote:
>> David Brown [2021-10-25 23:59:16] wrote:
>>> On 25/10/2021 19:58, Anton Ertl wrote:
>>>> David Brown <david...@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.
> <
> What valid programming example fits the description "Scan the stack" ?

libunwind.so?

On 10/26/2021 12:26 AM, Niklas Holsti wrote:
> 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?

Yes IMO

MitchAlsup wrote:
> On Monday, October 25, 2021 at 8:30:43 PM UTC-5, Stefan Monnier wrote:
> <
>> 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.
> <
> What valid programming example fits the description "Scan the stack" ?

In the WinNT structured exception handling model, which they brought
from VMS, the master handler scans backwards through the stack frames
looking for frame handlers. When it finds one, it invokes that frame
handler code _in the context of that frame_ passing an exception descriptor.
The frame handler can either
(a) fix the problem and continue execution where the exception was signaled
(b) resignal the exceptions so the stack scan for handlers continues
(c) unwind some or all of the stack frames invoking each intervening
handlers again but this time as in unwind mode.

In the easiest implementation, if any frame handler is present on a routine
the compiler always spills all live variables before subroutine calls.
Perhaps a smarter version would see the frame handler accessing some
frame local variable and make sure it was NOT held in a preserved
register across any calls, so it would always know where the variable
was located.

(There is more to it than that. For example, on some hardware
some exceptions are not continuable (restartable).
There can also be thread and process last-chance exception handlers,
and thread run-down handlers to release thread resources.)

On Tuesday, October 26, 2021 at 10:48:28 AM UTC-5, EricP wrote:
> Tim Rentsch wrote:
> > Ivan Godard <iv...@millcomputing.com> writes:
> >
> >> 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.
>
> What changes for strong typing is that if you mix incompatible types
> you must specify that you intended to do so. C has some automatic,
> transparent conversion between types, like signed to unsigned integer,
> that most modern C compilers warn about and most programmers already
> include explicit casts, both to document that "yes it was intentional"
> and to get the warning to shut up.
>
> Also there may also be rules applied when converting between those
> types and you want those rules invoked under your control.
>
> For example, converting a signed-trap to unsigned-sat of the same
> size changes the logical type then applies range constraints,
> so it checks if the source is negative and sets it to zero.
<
My 66000 ISA even has an instruction to convert signed to unsigned::
if the signed is negative, then the result is zero.
<
unsigned to signed works similarly:
If the unsigned is going to be negative, then POSMAX is returned
and overflow raised.
<
These are not assignments but conversions and all My 66000 conversions
operate under the principle of best representable value.
>
> Converting unsigned-sat to signed-trap of the same size checks if
> the source is > INT_MAX (msb == 1) and traps if it is.
>
> >> Yes, Ada got it right, thank you.
> >
> > I have gotten conflicting information on that point.
>
> There were aspects of Ada83 that I liked and others I didn't.
> It has changed a lot since I used it and I see that some things
> that I considered problems have been smoothed out.
>
> My tests for language X would be, can one write a compiler for X in X?
<
And can one write the universal printf() for X in X
<
> How much effort is it to write a GUI Windows/Xwindows interface app in it?
> How much effort is it to write an OS in it?
> (The last two requires extensive type conversions, so it stress-tests
> the ergonomics of the typing rules.)

On Tuesday, October 26, 2021 at 11:11:18 AM UTC-5, Ivan Godard wrote:
> On 10/26/2021 7:34 AM, MitchAlsup wrote:
> > On Monday, October 25, 2021 at 8:30:43 PM UTC-5, Stefan Monnier wrote:
> >> David Brown [2021-10-25 23:59:16] wrote:
> >>> On 25/10/2021 19:58, Anton Ertl wrote:
> >>>> David Brown <david...@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.
> > <
> > What valid programming example fits the description "Scan the stack" ?
> libunwind.so?
<
Ok, granted, but this is NOT scanning the stack, it is using the known stack
format to escape from multiple layers simultaneously. It is not, for example
reading every variable looking for a certain pattern or a certain range of patterns.
<
But that function needs to be provided by the compiler as part of its own run
time (support library). It is not something that is willy-nilly generated by a
semi-concerned programmer using a few compiler switches.
<
Also, how does one unwind the stack when one has no access to the parts
of the stack that are protected from the user code ?

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Tuesday, October 26, 2021 at 1:21:43 AM UTC-5, Stephen Fuld wrote:
>> On 10/24/2021 12:42 AM, 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.
><
>> What happens if you multiply two variables with dimension "length"
>> together? Does it understand that the result is an "area"?
><
> What happens when you multiply 1 width by 1 height ? you get an
> Area. But if you multiply 1 vector length by a second vector length
> you get a×b×cos(angle(a,b)).

MathCad (like any other program) will usually not do your thinking
for you, you will have to do that yourself :-)

On 10/26/2021 9:36 AM, MitchAlsup wrote:
> On Tuesday, October 26, 2021 at 11:11:18 AM UTC-5, Ivan Godard wrote:
>> On 10/26/2021 7:34 AM, MitchAlsup wrote:
>>> On Monday, October 25, 2021 at 8:30:43 PM UTC-5, Stefan Monnier wrote:
>>>> David Brown [2021-10-25 23:59:16] wrote:
>>>>> On 25/10/2021 19:58, Anton Ertl wrote:
>>>>>> David Brown <david...@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.
>>> <
>>> What valid programming example fits the description "Scan the stack" ?
>> libunwind.so?
> <
> Ok, granted, but this is NOT scanning the stack, it is using the known stack
> format to escape from multiple layers simultaneously. It is not, for example
> reading every variable looking for a certain pattern or a certain range of patterns.
> <
> But that function needs to be provided by the compiler as part of its own run
> time (support library). It is not something that is willy-nilly generated by a
> semi-concerned programmer using a few compiler switches.
> <
> Also, how does one unwind the stack when one has no access to the parts
> of the stack that are protected from the user code ?

Good question. Our answer is NYF.

On 10/26/2021 9:29 AM, MitchAlsup wrote:
> On Tuesday, October 26, 2021 at 10:48:28 AM UTC-5, EricP wrote:
>> Tim Rentsch wrote:
>>> Ivan Godard <iv...@millcomputing.com> writes:
>>>
>>>> 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.
>>
>> What changes for strong typing is that if you mix incompatible types
>> you must specify that you intended to do so. C has some automatic,
>> transparent conversion between types, like signed to unsigned integer,
>> that most modern C compilers warn about and most programmers already
>> include explicit casts, both to document that "yes it was intentional"
>> and to get the warning to shut up.
>>
>> Also there may also be rules applied when converting between those
>> types and you want those rules invoked under your control.
>>
>> For example, converting a signed-trap to unsigned-sat of the same
>> size changes the logical type then applies range constraints,
>> so it checks if the source is negative and sets it to zero.
> <
> My 66000 ISA even has an instruction to convert signed to unsigned::
> if the signed is negative, then the result is zero.
> <
> unsigned to signed works similarly:
> If the unsigned is going to be negative, then POSMAX is returned
> and overflow raised.
> <
> These are not assignments but conversions and all My 66000 conversions
> operate under the principle of best representable value.

Is that a synonym for "saturation"?

Thomas Koenig <tkoenig@netcologne.de> writes:
>-fno-reorder-blocks puts the compiler back before the very first
>FORTRAN compiler, which invented basic blocks and moving them
>around for optimization.

So you want to imply that this is going to slow gforth down? Let's
test this hypothesis (gcc-10.2 on Skylake):

with with without
-fno-reorder-blocks
default --no-dynamic default
1358614162 1834084907 1959794599 cycles:u onebench.fs
3209609889 4229597875 4499690628 instructions:u onebench.fs

What happens is that without -fno-reorder-blocks a sanity check in
Gforth disables Gforth's dynamic superinstruction optimization (the
sanity check sees that the code is not arranged in one of the ways
needed for the optimization). Interestingly, the slowdown is slightly
worse than when disabling dynamic superinstructions directly, so there
is an additional effect at work. In any case, your implied claim that
-fno-reorder-blocks generally hurts performance is debunked.

>-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.

Ok, after reinstating -fno-reorder-blocks, let's test this hypothesis:

with without
-fno-inline
120 114 non-relocatable primitives
1358614162 1336327000 cycles:u onebench.fs
3209609889 3202121890 instructions:u onebench.fs

Here we indeed see a slight improvement from leaving inlining enabled,
both in cycles for this benchmark and in the reduced number of
non-relocatable primitives (non-relocatable primitives cannot be used
in dynamic superinstructions).

The non-relocatable primitives are there because calls inside a
primitive cause non-relocatability of the primitive on AMD64. But
there is a comment on one of the functions:

it also happens to have better register allocation on AMD64, at the
cost of a function call (and non-relocatability)

Maybe register allocation is better on gcc-10 than what I tested on at
the time.

>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,

How does adding an extension to C help Fortran?

>so your code is certainly very much
>non-conforming.

In terms of the C standard, it's a conformant program.

>Luckily, assigned gotos have been depecated
>in Fortran.

I guess nobody is implementing virtual-machine interpreters in Fortran
these days, much less the kind of dynamic native code generation that
Gforth uses. Both techniques use the labels-as-values extension in
GNU C, and have been used in several programming language
implementations. It is used so widely that icc, clang and tcc have
implemented this extension as well. But nobody implements programming
languages in Fortran these days, so if assigned gotos go away, maybe
nobody will miss them.

>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.

This is not a reduced test case from the original bug report in
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242> (Bug 15252 is not
from me). It's good enough for reproducing the bug, but not good for
illustrative purposes. The code for a typical virtual machine
instruction like + (addition) contains no ifs.

The bug report is about gcc at the time pessimizing the code by
dedupliating the indirect jumps, which made threaded-code interpreters
larger and much slower (ensuring close to 100% miss rate in the BTBs
of the CPUs of the time, compared to ~50% without deduplication). It
also completely disabled dynamic native code generation (which buys
another factor of 2 on larger benchmarks (more on smaller benchmarks)
on machines with BTB for indirect branch prediction).

>> Only some of those are for disabling assumptions about undefined
>> behaviour.
>
>I suspect the rest is for making code like the above work :-)

In the case of -fno-reorder-blocks, to make it work fast.

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

On 2021-10-26 13:43, Thomas Koenig wrote:
> 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).

That trick does not work if the compiler knows enough about what foo()
does, for example by in-lining the call. (If the call is not in-lined,
the order is assured if the compiler cannot determine that foo makes
_no_ volatile accesses; the identities of x and y are irrelevant.
Perhaps you did not note that x and y are assumed volatile.)

The point of my proposal was to assure the ordering whatever the
compiler legally does.

On Tuesday, October 26, 2021 at 12:02:10 PM UTC-5, Ivan Godard wrote:
> On 10/26/2021 9:29 AM, MitchAlsup wrote:
> > On Tuesday, October 26, 2021 at 10:48:28 AM UTC-5, EricP wrote:
> >> Tim Rentsch wrote:
> >>> Ivan Godard <iv...@millcomputing.com> writes:
> >>>
> >>>> 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.
> >>
> >> What changes for strong typing is that if you mix incompatible types
> >> you must specify that you intended to do so. C has some automatic,
> >> transparent conversion between types, like signed to unsigned integer,
> >> that most modern C compilers warn about and most programmers already
> >> include explicit casts, both to document that "yes it was intentional"
> >> and to get the warning to shut up.
> >>
> >> Also there may also be rules applied when converting between those
> >> types and you want those rules invoked under your control.
> >>
> >> For example, converting a signed-trap to unsigned-sat of the same
> >> size changes the logical type then applies range constraints,
> >> so it checks if the source is negative and sets it to zero.
> > <
> > My 66000 ISA even has an instruction to convert signed to unsigned::
> > if the signed is negative, then the result is zero.
> > <
> > unsigned to signed works similarly:
> > If the unsigned is going to be negative, then POSMAX is returned
> > and overflow raised.
> > <
> > These are not assignments but conversions and all My 66000 conversions
> > operate under the principle of best representable value.
<
> Is that a synonym for "saturation"?
<
Sometimes, sometimes not.
wrt signed->unsigned; unsigned saturates negative values to zero
wrt unsigned->signed; signed saturates to POSMAX.
<
But a double->float with RM=ToZero has non-infinities round to non-infinity.

On 2021-10-26 15:09, David Brown wrote:
> On 26/10/2021 09:26, Niklas Holsti wrote:
>> 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?
>
> That is an interesting idea. It would, I think, be feasible for such a
> "volatile" function to consider each read and write it does as though it
> was a volatile access.

I did not mean that. I just meant that the volatile mark would prevent
the compiler from moving any of the code of the function backwards or
forwards over a volatile access or another volatile call. That
constraint would come into play only if the compiler in-lines the call,
or knows enough about the call's effects to try to move the call
instruction (and any associated parameter-evaluation and
parameter-passing code). In other respects the function and any calls to
the function would be compiled normally and behave normally.

> But what about other code that it might call - should "volatile" be
> recursive here?

In the sense that the constraint on code motion would apply also to
nested calls (under in-lining), but again the callees themselves would
be compiled normally and execute normally -- they would not be forced to
use only volatile accesses.

Volatile accesses within foo (and within functions that foo calls) would
have their normal effect on execution order within those functions (or
their in-lined versions). So non-volatile accesses in the in-lined code
could be reordered, but not past volatile accesses (or other volatile
calls) in the caller of foo (that is, not before the assignment to x nor
after the assignment to y).

In the general case, with several levels of in-lining, the compiler
would have to keep track of nested regions such that code within a
region can be moved about within that region, even past inner nested
regions, but not into an outer region. The normal constraints on moving
volatile accesses would also apply within regions and across regions.

> And what would it really mean to say that "processor time" is also
> ordered?

I suppose the language standard would have some fuzzy wording about
"dynamically consumed resources", with processor cycles as an example,
and leave it to each implementation to document what those resources are
for this implementation.

Perhaps the consumption of such resources would be defined as an
observable effect, although the language standard could not define
precisely what that effect consists of and would have to leave it to the
implementation to document.

> I suspect this would need a lot of effort to develop into something
> rigorous and definable.

Probably so.

> But the end result could definitely have its uses.

So it seems, judging from some of the recent discussion here.

On Tuesday, October 26, 2021 at 11:57:44 AM UTC-5, Ivan Godard wrote:
> On 10/26/2021 9:36 AM, MitchAlsup wrote:

> > But that function needs to be provided by the compiler as part of its own run
> > time (support library). It is not something that is willy-nilly generated by a
> > semi-concerned programmer using a few compiler switches.
> > <
> > Also, how does one unwind the stack when one has no access to the parts
> > of the stack that are protected from the user code ?
<
> Good question. Our answer is NYF.
<
Seems to me you have 2 choices:: some HW instruction that performs job at hand
faking access rights {sort of what I do in HW context switches...........}
Or a cheap context switch to a address space with permissions to do the job in SW.
<
It seems painfully obvious that the entirety of the mechanism is to prevent user
(unprivileged code) from accessing those locations {security, RoP,...}