According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>> As my thesis advisor Alan Perlis said when I was a student in the
>> 1970s, I don't know what language people will be using in the year
>> 2000, but it will be called Fortran.
>
>I wouldn't be surprised if Alan Perlis said this, but I think it
>was said originally by Tony Hoare. (Disclaimer: my memory is
>known to be faulty at times, and I have made no attempt to find
>sources to support my unreliable memory.)

I don't think Alan claimed it was original. But he did like to say it.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 10/16/2021 11:40 AM, Ivan Godard wrote:
> On 10/16/2021 8:18 AM, Stephen Fuld wrote:
>> On 10/16/2021 7:52 AM, Ivan Godard wrote:
>>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>>>
>>>>>> This, however, is a NG devoted to architectures that can run C and
>>>>>> all sorts of other languages. Architectures and implementations of
>>>>>> those architectures.
>>>>>>
>>>>>> It should a design goal of any architect to provide an efficient and
>>>>>> straightforward instruction set that enables compilers to produce
>>>>>> small, efficient, correct applications from a given set of source
>>>>>> code.
>>>>>
>>>>> You are, of course, correct.
>>>>>
>>>>> There is another goal, which is to have zero or low overhead for
>>>>> error checking.  If I may quote C.A.R. Hoare:
>>>>>
>>>>> # Finally, it is absurd to make elaborate security checks on debugging
>>>>> # runs, when no trust is put in the results, and then remove them
>>>>> # in production runs, when an erroneous result could be expensive
>>>>> # or disastrous.  What would we think of a sailing enthusiast who
>>>>> # wears his lifejacket when training on dry land, but takes it off
>>>>> # as soon as he goes to sea?
>>>>>
>>>>> The reason for this is that some languages like C make error
>>>>> checking very difficult (for example, finding out the valid range
>>>>> for pointer arithmetic in a function needs information from the
>>>>> caller, which is not available via the standard language).
>>>>>
>>>>> There are languages where the necessary info is provided, Ada
>>>>> and Fortran among them.  However, that there is a rather large
>>>>> overhead in code size and, more importantly, execution time.
>>>>> IIRC (but correct me if I'm wrong) even gnat comes which range
>>>>> checking switched off by default.
>>>>>
>>>>> To extend the metaphor above, the lifejacket comes combined with
>>>>> a sea anchor, which is not good if you want to go somewhere.
>>>>>
>>>>> There are a couple of notorious bug classes which surface again
>>>>> and again.  Buffer overruns are a classic, as are "use after free"
>>>>> errors and signed overruns.
>>>>>
>>>>> First, buffer overruns.  Compilers need to become better at moving
>>>>> checking code out of loops.  One idea that could help (with compiler
>>>>> support, of course) is to define a valid range for a register
>>>>> (which could hold an address to an array or an index) to be in
>>>>> for a certain amount of instructions, trapping if it is outside.
>>>>> Maybe a few "range registers" with a way to associate a certain
>>>>> register with them, to allow spill / restore.
>>>>>
>>>>> Signed overruns - the very topic we are discussing here.  Integer
>>>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>>>
>>>>> Use after free - much more difficult.  It might be possible to
>>>>> have a hardware list of "poisoned" address ranges from which it is
>>>>> not permitted to load.  Very expensive (comparable to
>>>>> cache) and would probably cache only the most recently freed
>>>>> memory blocks.  Not sure if this is worth it.
>>>>>
>>>>> Ideas?  Comments?
>>>>
>>>> The run time cost of things like buffer overrun checking is reduced
>>>> on modern OoO CPUs, as (assuming the compiler makes the information
>>>> available) the checking can be done in parallel with the subsequent
>>>> instructions, and only commit those instructions if the check
>>>> passes. The same idea might help with the signed overflow problems.
>>>
>>> Signed overflow does not require delayed check; it requires control
>>> of delivery of the checked event.
>>
>> Agreed.  I may not have been clear, but I think what I was proposing
>> (adding the check instructions if needed) does that.
>>
>>> Not everything is vanilla C;
>>
>> My personal bias is showing, but Thank Goodness!
>>
>>> there are other languages with other rules, and even in C there are
>>> pragmas and flags. So sometimes you should check and sometimes not,
>>> and you can't afford control flow to decide.
>>
>> If you don't want the check, then don't generate the check
>> instructions.   My only point was that the check instructions, if
>> required, cost less now than they used to, because the check can be
>> done in parallel with the subsequent instructions, as long as those
>> subsequent instructions don't commit before the check is passed.
>
> I differ, and would say: as long as no instructions are committed which
> depend upon the success of the check and irretrievably alter system state.

That's fine. It better states what, I think, you and I agree on
conceptually.

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

On 10/16/2021 11:44 AM, Ivan Godard wrote:
> On 10/16/2021 9:07 AM, Anton Ertl wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>> [bounds checking]
>>> There are languages where the necessary info is provided, Ada
>>> and Fortran among them.  However, that there is a rather large
>>> overhead in code size and, more importantly, execution time.
>>
>> Please support your claim with empirical results.
>>
>>> Compilers need to become better at moving
>>> checking code out of loops.
>>
>> Again, support needed.  My impression is that the Cousots solved this
>> problem pretty well in the 1970, and for the common case their
>> solution is good enough.  And it's not clear that much can be done for
>> the other cases.
>>
>>> Signed overruns - the very topic we are discussing here.  Integer
>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>
>> Consider:
>>
>> signed char a=127;
>> signed char b=127;
>> signed char c;
>> c=a+b;
>>
>> The addition is defined in C.  Maybe the narrowing of the result in
>> the assignment is undefined, C standards lawyers will know.
>>
>> But of course, the major question is who wants this?  Who uses -ftrapv
>> on MIPS and Alpha which have such instructions (for 32 bits and 64
>> bits, relevant for their I32LP64 C).
>>
>>> Use after free - much more difficult.  It might be possible to
>>> have a hardware list of "poisoned" address ranges from which it is
>>> not permitted to load.  Very expensive (comparable to
>>> cache) and would probably cache only the most recently freed
>>> memory blocks.  Not sure if this is worth it.
>>
>> If you have NaT bits associated with the memory, you could fill the
>> free()d memory with NaTs.
>
> I would love to have NaT bits (NaR in our terminology) associated with
> memory. It's certainly doable, but not economically feasible IMO, unless
> you are Samsung.

I was thinking about (ab)using a modification of your mechanism that
allows reading zeros when you load from uninitialized memory, but I
suspect the overhead might be way to high.

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

Michael S <already5chosen@yahoo.com> writes:

> A war story from ~2 years ago (I am not sure if details of code are
> correct, but sure about principle):
>
> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> #define ACTION_REG (*(volatile uint32_t*)0x43215604))
>
> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> {
> uint32_t bar;
> if (moo)
> bar = 0.42 * arg - 11.3;
> else
> bar = 0.43 * arg + 11.7;
>
> if (moo) {
> while (TIME_VAL-t0 < dt);
> }
> ACTION_REG = bar;
> }
>
> TIME_VAL is a hardware register that contains free running counter
> incrementing every CPU clock.
> A write to ACTION_REG initiates important hardware activity.
> Execution environment - ARM Cortex-M3 - based micro-controller. M3
> core has no caches and in our case all interrupts were disabled, so
> we expected very consistent and very small time variation between
> designated time and action.
> I practice we observed not very consistent and absurdly large delay
> of several microsecons.
>
> It turned out that smart compiler (yes, it was gcc -O2, but I
> believe that other compilers are not immune although we didn't
> observe the problem with IAR) changed our code to something like
> that:
>
> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> {
> uint32_t bar;
> if (moo) {
> while (TIME_VAL-t0 < dt);
> bar = 0.42 * arg - 11.3;
> } else {
> bar = 0.43 * arg + 11.7;
> }
> ACTION_REG = bar;
> }
>
> For those, not familiar with Cortex-M, these cores have no
> double-precision hardware, so calculation of bar indeed takes few
> uSec and that's the reason why code was structured to do it outside
> of time-critical section.

I echo the comments of Niklas Holsti (which unfortunately my news
reader lost after I read them): this re-ordering is allowed (not
obviously, but unfortunately apparently intendedly) by the ISO C
standard. The problem can be remedied by making 'bar' (and maybe
also 'moo') volatile.

John Levine <johnl@taugh.com> writes:

> According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>
>>> As my thesis advisor Alan Perlis said when I was a student in the
>>> 1970s, I don't know what language people will be using in the year
>>> 2000, but it will be called Fortran.
>>
>> I wouldn't be surprised if Alan Perlis said this, but I think it
>> was said originally by Tony Hoare. (Disclaimer: my memory is
>> known to be faulty at times, and I have made no attempt to find
>> sources to support my unreliable memory.)
>
> I don't think Alan claimed it was original. But he did like to say it.

I have fond memories of Alan Perlis from when he was teaching at
Caltech during the time I was a student there.

On Saturday, October 16, 2021 at 9:23:45 PM UTC+3, Niklas Holsti wrote:
> On 2021-10-16 20:03, Michael S wrote:
> > On Friday, October 15, 2021 at 7:07:36 PM UTC+3, Stephen Fuld wrote:
> >> On 10/15/2021 8:38 AM, David Brown wrote:
> >>
> >> snip
> >>> There are lots of things that are missing in C's model. Really, I think
> >>> the fuss about flat address spaces, aliasing pointers, integer overflow,
> >>> and so on, are all peanuts compared to the /big/ missing point - C has
> >>> no concept of timing. For a lot of low level or embedded code, being
> >>> able to specify timing constraints, requirements or restrictions in the
> >>> programming language would be /hugely/ more useful than knowing that you
> >>> can safely compare two random addresses (a requirement I have never
> >>> needed or considered at all useful - and one that can easily be handled
> >>> by casting to uintptr_t if you actually needed it).
> >>
> >> Can you expound on what kind of syntax and semantics you want a language
> >> to have for the timing related stuff? Since the compiler, much less
> >> than language, doesn't know about the speed of the eventual hardware the
> >> program will be run on, I don't see how it can specify timing.
> >>
> >>
> >> --
> >> - Stephen Fuld
> >> (e-mail address disguised to prevent spam)
> >
> > A war story from ~2 years ago (I am not sure if details of code are
> > correct, but sure about principle):
> >
> > #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> > #define ACTION_REG (*(volatile uint32_t*)0x43215604))
> >
> > void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> > {
> > uint32_t bar;
> > if (moo)
> > bar = 0.42 * arg - 11.3;
> > else
> > bar = 0.43 * arg + 11.7;
> >
> > if (moo) {
> > while (TIME_VAL-t0 < dt);
> > }
> > ACTION_REG = bar;
> > }
> >
> > TIME_VAL is a hardware register that contains free running counter
> > incrementing every CPU clock.
> > A write to ACTION_REG initiates important hardware activity.
> > Execution environment - ARM Cortex-M3 - based micro-controller.
> > M3 core has no caches and in our case all interrupts were disabled,
> > so we expected very consistent and very small time variation
> > between designated time and action.> I practice we observed not very
> > consistent and absurdly large delay of several microsecons. >
> > It turned out that smart compiler (yes, it was gcc -O2, but I
> > believe that other compilers are not immune although we didn't
> > observe the problem with IAR) changed our code to something like
> > that: >
> > void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> > {
> > uint32_t bar;
> > if (moo) {
> > while (TIME_VAL-t0 < dt);
> > bar = 0.42 * arg - 11.3;
> > } else {
> > bar = 0.43 * arg + 11.7;
> > }
> > ACTION_REG = bar;
> > }
> That is of course an allowed re-ordering of the code. A nice reminder
> for us all to be careful and aware of such things.
> > For those, not familiar with Cortex-M, these cores have no
> > double-precision hardware,
> (As an aside: was it intended to use double precision? Or was that a
> mistake due to omitted "f" suffixes on the floating literals?)

It was not strictly necessary to do calculations in double, but it was preferable.
At very least, out of principle of economy of thought.
After all, 'double' is always as precise as input and output tipes, i.e. uint32t.
One can't say it about 'float' so before using 'float' one has to do analysis.

> > so calculation of bar indeed takes few uSec and that's the reason why
> > code was structured to do it outside of time-critical section.
> As I think has been commented recently here, C can be forced to obey the
> source-code order by good use of "volatile". Making "bar" volatile
> should have solved this problem.
>

Generally speaking, it's only correct if bar is external to the module.

> How did you solve it?

I don't remember. Solving it was not a hard part.
The hard part was understanding why the problem appeared at all.

> > But, as mentioned above, C language has no concept of time or
> > time-criticality. IIRC, Ada is no better
> Ada at least has the concept of task priorities, which is certainly an
> aspect of time-criticality. But within a single task, the same kind of
> reordering as in the above example could happen in Ada too. And the
> solution is the same: use "volatile".

Is "volatile" even part of Ada83? I don't remember anything like that in the Ada textbook that I read in late 80s.
Checked in Wikipedia and it seems that, indeed, it's later addition.

On 10/16/2021 12:20 PM, Stephen Fuld wrote:
> On 10/16/2021 11:44 AM, Ivan Godard wrote:
>> On 10/16/2021 9:07 AM, Anton Ertl wrote:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> [bounds checking]
>>>> There are languages where the necessary info is provided, Ada
>>>> and Fortran among them.  However, that there is a rather large
>>>> overhead in code size and, more importantly, execution time.
>>>
>>> Please support your claim with empirical results.
>>>
>>>> Compilers need to become better at moving
>>>> checking code out of loops.
>>>
>>> Again, support needed.  My impression is that the Cousots solved this
>>> problem pretty well in the 1970, and for the common case their
>>> solution is good enough.  And it's not clear that much can be done for
>>> the other cases.
>>>
>>>> Signed overruns - the very topic we are discussing here.  Integer
>>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>
>>> Consider:
>>>
>>> signed char a=127;
>>> signed char b=127;
>>> signed char c;
>>> c=a+b;
>>>
>>> The addition is defined in C.  Maybe the narrowing of the result in
>>> the assignment is undefined, C standards lawyers will know.
>>>
>>> But of course, the major question is who wants this?  Who uses -ftrapv
>>> on MIPS and Alpha which have such instructions (for 32 bits and 64
>>> bits, relevant for their I32LP64 C).
>>>
>>>> Use after free - much more difficult.  It might be possible to
>>>> have a hardware list of "poisoned" address ranges from which it is
>>>> not permitted to load.  Very expensive (comparable to
>>>> cache) and would probably cache only the most recently freed
>>>> memory blocks.  Not sure if this is worth it.
>>>
>>> If you have NaT bits associated with the memory, you could fill the
>>> free()d memory with NaTs.
>>
>> I would love to have NaT bits (NaR in our terminology) associated with
>> memory. It's certainly doable, but not economically feasible IMO,
>> unless you are Samsung.
>
> I was thinking about (ab)using a modification of your mechanism that
> allows reading zeros when you load from uninitialized memory, but I
> suspect the overhead might be way to high.

We looked at having uninit read as NaR. If real Samsung had NaR bits
then you could write a speculative NaR and later discard it harmlessly;
without Samsung we have to fault a NaR store, which limits the degree of
performance gain available from speculation. With NaR uninits but no
Samsung we can nanny the programmer, but the common zero init (as
nannied) becomes explicit, lowering performance. Absent Samsung, we
decided that the reliability gain from nannying wasn't as good as the
performance gain from zero; YMMV. Might well have gone the other way had
Samsung been aboard.

On Saturday, October 16, 2021 at 9:58:06 PM UTC+3, John Levine wrote:
> According to Tim Rentsch <tr.1...@z991.linuxsc.com>:
> >> As my thesis advisor Alan Perlis said when I was a student in the
> >> 1970s, I don't know what language people will be using in the year
> >> 2000, but it will be called Fortran.
> >
> >I wouldn't be surprised if Alan Perlis said this, but I think it
> >was said originally by Tony Hoare. (Disclaimer: my memory is
> >known to be faulty at times, and I have made no attempt to find
> >sources to support my unreliable memory.)
> I don't think Alan claimed it was original. But he did like to say it.
>

It does not look like he was right, so.
By 2000 Fortran became a very niche language used by tiny fraction of professional programmers.
A similar prediction made for Ethernet in early 90s so far holds much better.

>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On 10/16/2021 10:57 AM, Niklas Holsti wrote:
> On 2021-10-15 19:07, Stephen Fuld wrote:
>> On 10/15/2021 8:38 AM, David Brown wrote:
>>
>> snip
>>
>>> There are lots of things that are missing in C's model.  Really, I think
>>> the fuss about flat address spaces, aliasing pointers, integer overflow,
>>> and so on, are all peanuts compared to the /big/ missing point - C has
>>> no concept of timing.  For a lot of low level or embedded code, being
>>> able to specify timing constraints, requirements or restrictions in the
>>> programming language would be /hugely/ more useful than knowing that you
>>> can safely compare two random addresses (a requirement I have never
>>> needed or considered at all useful - and one that can easily be handled
>>> by casting to uintptr_t if you actually needed it).
>>
>> Can you expound on what kind of syntax and semantics you want a
>> language to have for the timing related stuff?
>
>
> I believe there have been languages, or language proposals, where
> real-time constraints can be defined in the source. The term "Real-Time
> Euclid" comes to mind, but my search found only pay-walled references,
> some in the IEEE Digital Library.
>
>
>> Since the compiler, much less than language, doesn't know about the
>> speed of the eventual hardware the program will be run on, I don't
>> see how it can specify timing.
>
> Some compilers do know a lot about the target HW and its timing, and use
> this knowledge for selecting optimizations, but the precision of this
> knowledge depends on the predictability of the HW timing. Some machines,
> such as the Mill and PRET and the XMOS machines, are designed to have
> predictable, deterministic timing (as far as possible -- of course
> caches and such will not be entirely predictable). Small
> microcontrollers for embedded systems used to have very predictable
> timing (in the absence of caches and such).

Yes, but . . . Even if you have a CPU model number, its speed may depend
on which bin it came from in the manufacturing process. And, nothing
prevents one from running say a 2 GHz processor at say 1.5 GHz (say to
increase error resistance, or for longer life, or whatever). These are
the kinds of things I was thinking of.

I guess it can work for specific cases, but I am doubtful of a general
solution.

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

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

[factor ~ 6 in bounds checking for simple matmul code
in Fortran]

> I'd like to see the asm for do_mm.

It's lengthy, but godbolt.org can give it to you:
https://godbolt.org/z/1zPxaqnoY

> Because the range for each loop variable is deterministic
> from the size of the passed arrays.

> It should be able to do just 3 bounds checks before loop start,
> compare range of k to size (b,1), range of i to size(c,1),
> range of j to size(c,2). then loop without index checks.
> Other index checks are unnecessary because range of k is
> derived from size(b,2), range of k from size(a,2), range of i from size(a,1).

> While the loop index variables may change, their range is loop invariant.
> That makes the index bounds checks hoistable as loop invariants.

Your analysis is correct, and this is why I submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66158
about six years ago :-)

It's debatable who should be responsible for fixing this - the
Fortran front end could insert the checks before the DO loops, or
it could hand a better representation to the middle end (including
the ranges of the DO variables), or the middle end could be expected
to figure it out for itself.

However, from this short example, it should be clear why bounds
checking is often turned off in production code. This is something
I would like to change, and hardware could definitely help there.

@Mitch: What would the slowdown be for bounds checking for such
a matrix multiplication on My 66000?

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>
>>> [...]
>>>
>>>> There is also the restriction on the complexity, which makes
>>>>
>>>> #! /bin/sh
>>>> echo "Program to complex, aborting" 1>&2
>>>>
>>>> a valid C compiler according to the standard.
>>>
>>> Not true. Feel free to ask in comp.std.c if you want
>>> to understand why.
>>
>> I'd be interested, but why not have it out in this forum
>> where the discussion started out?
>
> Several reasons, but the most important one is this part
> of the discussion has strayed far enough outside the local
> topicality bounds that I feel obliged to redirect it.

So, for the time being, I'll file that as an assertion that
has not been backed up. Fine by me.

On 2021-10-16 20:49, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>> [bounds checking]
>>> There are languages where the necessary info is provided, Ada
>>> and Fortran among them. However, that there is a rather large
>>> overhead in code size and, more importantly, execution time.
>>
>> Please support your claim with empirical results.
>
> $ cat mm.f90
> module mm
> implicit none
> contains
> subroutine do_mm (a,b,c)
> real, dimension(:,:), intent(in) :: a, b
> real, dimension(:,:), intent(out) :: c

(Btw, shouldn't C be "in out"? I got a correct warning from GNAT when I
made it just "in".)

> integer :: i, j, k
> do j=1, size(b,2)
> do k=1, size(a,2)
> do i=1, size(a,1)
> c(i,j) = c(i,j) + a(i,k) * b(k,j)
> end do
> end do
> end do
> end subroutine do_mm
> end module mm
>
> $ cat main.f90
> program main
> use mm
> implicit none
> real, dimension(:,:), allocatable :: a, b, c
> character (len=20) :: line
> real :: t1, t2
> allocate (a(1000,1000), b(1000,1000), c(1000,1000))
> call random_number (a)
> call random_number (b)
> call cpu_time (t1)
> call do_mm(a,b,c)
> call cpu_time (t2)
> write (unit=line,fmt=*) c(1,1)
> write (*,*) t2-t1
> end program main
> $ gfortran -O3 mm.f90 main.f90
> $ ./a.out
> 9.59559977E-02
> $ gfortran -fcheck=bounds -O3 mm.f90 main.f90
> $ ./a.out
> 0.563069999
>
> Is a factor of 5.8 significant enough for you?

With Ada/GNAT -O2 on a small MacBook Air, I found no significant
slow-down from all checks suppressed (-gnatp) to checks on (-gnato),
compared to the standard deviation in 10 test executions of each case.
This is a bit surprising, but nice (if true). The program did steadily
use close to 100% of a processor core, so it seems there was scant
interference from other jobs. The absolute times are all larger than in
the Fortran case, above, but of course the computers are different too.

Program follows. Note that I added some preconditions to Do_MM, on the
sanity of the matrix index ranges. However, these seem to have no
significant effect on the execution time, whether checks are enabled or
suppressed.

$ cat mm.ads

package MM is

type Matrix is array (Positive range <>, Positive range <>) of Float;

procedure Randomize (M : out Matrix);

procedure Do_MM (A, B : in Matrix; C : in out Matrix)
with Pre =>
A'First(2) = B'First(1)
and A'Last (2) = B'Last (1)
and C'First(1) = A'First(1)
and C'Last (1) = A'Last (1)
and C'First(2) = B'First(2)
and C'Last (2) = B'Last (2);

end MM;

$ cat mm.adb
with Ada.Numerics.Float_Random;

package body MM is

procedure Randomize (M : out Matrix)
is
use Ada.Numerics.Float_Random;
Gen : Generator;
begin
Reset (Gen);
for I in M'Range(1) loop
for J in M'Range(2) loop
M(I,J) := Random (Gen);
end loop;
end loop;
end Randomize;

procedure Do_MM (A, B : in Matrix; C : in out Matrix)
is
begin
for J in B'Range(2) loop
for K in A'Range(2) loop
for I in A'Range(1) loop
C(I,J) := C(I,J) + A(I,K) * B(K,J);
end loop;
end loop;
end loop;
end Do_MM;

end MM;

$ cat main.adb
with Ada.Real_Time;
with Ada.Text_IO;

with MM;

procedure Main
is
use Ada.Real_Time;
type Matrix_Ref is access MM.Matrix;
A, B, C : Matrix_Ref := new MM.Matrix (1 .. 1000, 1 .. 1000);
T1, T2: Time with Volatile;

begin

MM.Randomize (A.all);
MM.Randomize (B.all);
MM.Randomize (C.all);

T1 := Clock;
MM.Do_MM (A.all, B.all, C.all);
T2 := Clock;

Ada.Text_IO.Put_Line (Duration'Image (
To_Duration (T2 - T1)));

end Main;

On 2021-10-16 23:06, Michael S wrote:
> On Saturday, October 16, 2021 at 9:58:06 PM UTC+3, John Levine wrote:
>> According to Tim Rentsch <tr.1...@z991.linuxsc.com>:
>>>> As my thesis advisor Alan Perlis said when I was a student in the
>>>> 1970s, I don't know what language people will be using in the year
>>>> 2000, but it will be called Fortran.
>>>
>>> I wouldn't be surprised if Alan Perlis said this, but I think it
>>> was said originally by Tony Hoare. (Disclaimer: my memory is
>>> known to be faulty at times, and I have made no attempt to find
>>> sources to support my unreliable memory.)
>> I don't think Alan claimed it was original. But he did like to say it.
>>
>
> It does not look like he was right, so.

Wasn't a similar claim made about BASIC? Perhaps a copy-cat? Plenty of
programs are written in Visual Basic these days, but of course many
programs are written in non-"Basic" languages too.

> A similar prediction made for Ethernet in early 90s so far holds much better.

Really? My impression is that most networks are now separate
point-to-point links connected by routers, which means that there is no
shared "ether". (I'm not sure about WLANs, however.)

On Saturday, October 16, 2021 at 11:37:33 PM UTC+3, Niklas Holsti wrote:
> On 2021-10-16 23:06, Michael S wrote:
> > On Saturday, October 16, 2021 at 9:58:06 PM UTC+3, John Levine wrote:
> >> According to Tim Rentsch <tr.1...@z991.linuxsc.com>:
> >>>> As my thesis advisor Alan Perlis said when I was a student in the
> >>>> 1970s, I don't know what language people will be using in the year
> >>>> 2000, but it will be called Fortran.
> >>>
> >>> I wouldn't be surprised if Alan Perlis said this, but I think it
> >>> was said originally by Tony Hoare. (Disclaimer: my memory is
> >>> known to be faulty at times, and I have made no attempt to find
> >>> sources to support my unreliable memory.)
> >> I don't think Alan claimed it was original. But he did like to say it.
> >>
> >
> > It does not look like he was right, so.
> Wasn't a similar claim made about BASIC? Perhaps a copy-cat? Plenty of
> programs are written in Visual Basic these days, but of course many
> programs are written in non-"Basic" languages too.
> > A similar prediction made for Ethernet in early 90s so far holds much better.
> Really? My impression is that most networks are now separate
> point-to-point links connected by routers,

In corporate world majority of nodes is connected to switches.
Some switches a connected to routers directly, but I'd guess that in majority of cases connection to router travels through several switches.
At home, I don't know. Would guess that majority of internet-connected homes on planet Earth has no LAN at all.
That is, there is LAN technically, but it is used exclusively to connect nodes to WAN rather than to each other.

> which means that there is no
> shared "ether".

They are *called* Ethernet despite having pretty much nothing in common with Aloha-based 10BASE-T.

> (I'm not sure about WLANs, however.)

I think, a prediction was made specifically about *local* networks.

On 2021-10-16 23:07, Stephen Fuld wrote:
> On 10/16/2021 10:57 AM, Niklas Holsti wrote:
>> On 2021-10-15 19:07, Stephen Fuld wrote:
>>> On 10/15/2021 8:38 AM, David Brown wrote:
>>>
>>> snip
>>>
>>>> There are lots of things that are missing in C's model.  Really, I
>>>> think
>>>> the fuss about flat address spaces, aliasing pointers, integer
>>>> overflow,
>>>> and so on, are all peanuts compared to the /big/ missing point - C has
>>>> no concept of timing.  For a lot of low level or embedded code, being
>>>> able to specify timing constraints, requirements or restrictions in the
>>>> programming language would be /hugely/ more useful than knowing that
>>>> you
>>>> can safely compare two random addresses (a requirement I have never
>>>> needed or considered at all useful - and one that can easily be handled
>>>> by casting to uintptr_t if you actually needed it).
>>>
>>> Can you expound on what kind of syntax and semantics you want a
>>> language to have for the timing related stuff?

[snip]

>>> Since the compiler, much less than language, doesn't know about the
>>> speed of the eventual hardware the program will be run on, I don't
>>> see how it can specify timing.
>>
>> Some compilers do know a lot about the target HW and its timing, and
>> use this knowledge for selecting optimizations, but the precision of
>> this knowledge depends on the predictability of the HW timing. Some
>> machines, such as the Mill and PRET and the XMOS machines, are
>> designed to have predictable, deterministic timing (as far as possible
>> -- of course caches and such will not be entirely predictable). Small
>> microcontrollers for embedded systems used to have very predictable
>> timing (in the absence of caches and such).
>
> Yes, but . . . Even if you have a CPU model number, its speed may depend
> on which bin it came from in the manufacturing process.  And, nothing
> prevents one from running say a 2 GHz processor at say 1.5 GHz (say to
> increase error resistance, or for longer life, or whatever).  These are
> the kinds of things I was thinking of.

That is the question of predictability of HW timing. If the processor
varies its clock frequency or other timing parameters dynamically,
timing becomes quite unpredictable, and I agree that timing
specifications in the source code will be less useful. However, they
might still enable run-time checks of deadline violations or other
violations of timing specifications (whether the system can do anything
to recover from such errors is another thorny issue).

Assuming a constant clock frequency, if the source code specifies timing
not in clock cycles but in seconds, the tools (the compiler and the WCET
analyzer) must of course be given the expected clock frequency as a
parameter, and the compilation/analysis is valid only for that clock
frequency or a higher frequency.

> I guess it can work for specific cases, but I am doubtful of a general
> solution.

WCET analysis is in general unsolvable. But it works in some cases (for
predictable processors and suitably designed programs).

On 2021-10-16 23:51, Michael S wrote:
> On Saturday, October 16, 2021 at 11:37:33 PM UTC+3, Niklas Holsti wrote:
>> On 2021-10-16 23:06, Michael S wrote:
>>> On Saturday, October 16, 2021 at 9:58:06 PM UTC+3, John Levine wrote:
>>>> According to Tim Rentsch <tr.1...@z991.linuxsc.com>:
>>>>>> As my thesis advisor Alan Perlis said when I was a student in the
>>>>>> 1970s, I don't know what language people will be using in the year
>>>>>> 2000, but it will be called Fortran.
>>>>>
>>>>> I wouldn't be surprised if Alan Perlis said this, but I think it
>>>>> was said originally by Tony Hoare. (Disclaimer: my memory is
>>>>> known to be faulty at times, and I have made no attempt to find
>>>>> sources to support my unreliable memory.)
>>>> I don't think Alan claimed it was original. But he did like to say it.
>>>>
>>>
>>> It does not look like he was right, so.
>> Wasn't a similar claim made about BASIC? Perhaps a copy-cat? Plenty of
>> programs are written in Visual Basic these days, but of course many
>> programs are written in non-"Basic" languages too.
>>> A similar prediction made for Ethernet in early 90s so far holds much better.
>> Really? My impression is that most networks are now separate
>> point-to-point links connected by routers,
>
> In corporate world majority of nodes is connected to switches.

Right, but switches are not hubs, and they create a separate collision
domain for each switch port. So no shared "ether", or so I understand.

> They are *called* Ethernet despite having pretty much nothing in
> common with Aloha-based 10BASE-T.

Ah, of course, I forgot that the prediction was about naming, and not
about nature. Sorry for my mis-firing neuron.

>> (I'm not sure about WLANs, however.)
>
> I think, a prediction was made specifically about *local* networks.

I meant Wireless LANs, not Wide-area LANs, apologies for using the wrong
acronym.

On Saturday, October 16, 2021 at 12:03:21 PM UTC-5, Michael S wrote:
> On Friday, October 15, 2021 at 7:07:36 PM UTC+3, Stephen Fuld wrote:
> > On 10/15/2021 8:38 AM, David Brown wrote:
> >
> > snip
> > > There are lots of things that are missing in C's model. Really, I think
> > > the fuss about flat address spaces, aliasing pointers, integer overflow,
> > > and so on, are all peanuts compared to the /big/ missing point - C has
> > > no concept of timing. For a lot of low level or embedded code, being
> > > able to specify timing constraints, requirements or restrictions in the
> > > programming language would be /hugely/ more useful than knowing that you
> > > can safely compare two random addresses (a requirement I have never
> > > needed or considered at all useful - and one that can easily be handled
> > > by casting to uintptr_t if you actually needed it).
> > Can you expound on what kind of syntax and semantics you want a language
> > to have for the timing related stuff? Since the compiler, much less
> > than language, doesn't know about the speed of the eventual hardware the
> > program will be run on, I don't see how it can specify timing.
> >
> >
> > --
> > - Stephen Fuld
> > (e-mail address disguised to prevent spam)
> A war story from ~2 years ago (I am not sure if details of code are correct, but sure about principle):
>
> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> #define ACTION_REG (*(volatile uint32_t*)0x43215604))
>
> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> {
> uint32_t bar;
> if (moo)
> bar = 0.42 * arg - 11.3;
> else
> bar = 0.43 * arg + 11.7;
>
> if (moo) {
> while (TIME_VAL-t0 < dt);
> }
> ACTION_REG = bar;
> }
>
> TIME_VAL is a hardware register that contains free running counter incrementing every CPU clock.
> A write to ACTION_REG initiates important hardware activity.
> Execution environment - ARM Cortex-M3 - based micro-controller.
> M3 core has no caches and in our case all interrupts were disabled, so we expected very consistent and very small time variation
> between designated time and action.
> I practice we observed not very consistent and absurdly large delay of several microsecons.
>
> It turned out that smart compiler (yes, it was gcc -O2, but I believe that other compilers are not immune although we didn't observe the problem with IAR)
> changed our code to something like that:
> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> {
> uint32_t bar;
> if (moo) {
> while (TIME_VAL-t0 < dt);
> bar = 0.42 * arg - 11.3;
> } else {
> bar = 0.43 * arg + 11.7;
> }
> ACTION_REG = bar;
> }
> For those, not familiar with Cortex-M, these cores have no double-precision hardware, so calculation of bar indeed takes few uSec and that's the reason why code was structured to do it outside of time-critical section.
> But, as mentioned above, C language has no concept of time or time-criticality.
> IIRC, Ada is no better and Fortran is certainly no better.´

I have asked at the WG 14 why it is allowed to ignore
"Except as indicated, statements are executed in sequence."
or where it is "indicated" otherwise, but have not heard a good explanation..

Tim Rentsch [2021-10-16 13:01:16] wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
>> {
>> uint32_t bar;
>> if (moo) {
>> while (TIME_VAL-t0 < dt);
>> bar = 0.42 * arg - 11.3;
>> } else {
>> bar = 0.43 * arg + 11.7;
>> }
>> ACTION_REG = bar;
>> }
[...]
> I echo the comments of Niklas Holsti (which unfortunately my news
> reader lost after I read them): this re-ordering is allowed (not
> obviously, but unfortunately apparently intendedly) by the ISO C
> standard. The problem can be remedied by making 'bar' (and maybe
> also 'moo') volatile.

Beside the question of whether it's allowed by the spec, for me the main
question would be to understand why the compiler decided to swap the
order between the loop and the computation of `bar`.

I can't see any obvious benefit. It shortens the time between computing
`bar` and using it, which is bad from a code-scheduling perspective.
There doesn't need to be any register pressure which would justify an
effort to reduce live ranges... What's the point?

Stefan

According to Michael S <already5chosen@yahoo.com>:
>On Saturday, October 16, 2021 at 9:58:06 PM UTC+3, John Levine wrote:
>> According to Tim Rentsch <tr.1...@z991.linuxsc.com>:
>> >> As my thesis advisor Alan Perlis said when I was a student in the
>> >> 1970s, I don't know what language people will be using in the year
>> >> 2000, but it will be called Fortran. ...

>It does not look like he was right, so.
>By 2000 Fortran became a very niche language used by tiny fraction of professional programmers.

Well, he was right to the extent that there is still a language called Fortran in active use,
and it is very different from the Fortran we used in the 1970s.

There were plenty of other languages at the time, with various forces backing C and Pascal,
but Fortran keeps chugging along.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

> Your analysis is correct, and this is why I submitted
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66158
> about six years ago :-)

The question becomes: is this unfixed just because it's not high enough
priority (because virtually noone activates bounds checking, possibly
because of a chicken&egg problem), or is there something more
fundamental at play?

What does such a test look like in a lnaguage like Java where bounds
checking is always enabled, and hence where the motivation to perform
such optimizations might be higher?

Stefan

On 10/16/2021 4:52 PM, John Levine wrote:
> According to Michael S <already5chosen@yahoo.com>:
>> On Saturday, October 16, 2021 at 9:58:06 PM UTC+3, John Levine wrote:
>>> According to Tim Rentsch <tr.1...@z991.linuxsc.com>:
>>>>> As my thesis advisor Alan Perlis said when I was a student in the
>>>>> 1970s, I don't know what language people will be using in the year
>>>>> 2000, but it will be called Fortran. ...
>
>> It does not look like he was right, so.
>> By 2000 Fortran became a very niche language used by tiny fraction of professional programmers.
>
> Well, he was right to the extent that there is still a language called Fortran in active use,
> and it is very different from the Fortran we used in the 1970s.
>
> There were plenty of other languages at the time, with various forces backing C and Pascal,
> but Fortran keeps chugging along.
>

Give it a few more years and you may find people trying to implement
"serious business" software in Python or similiar...

On Sunday, October 17, 2021 at 12:51:26 AM UTC+3, Stefan Monnier wrote:
> Tim Rentsch [2021-10-16 13:01:16] wrote:
> > Michael S <already...@yahoo.com> writes:
> >> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> >> {
> >> uint32_t bar;
> >> if (moo) {
> >> while (TIME_VAL-t0 < dt);
> >> bar = 0.42 * arg - 11.3;
> >> } else {
> >> bar = 0.43 * arg + 11.7;
> >> }
> >> ACTION_REG = bar;
> >> }
> [...]
> > I echo the comments of Niklas Holsti (which unfortunately my news
> > reader lost after I read them): this re-ordering is allowed (not
> > obviously, but unfortunately apparently intendedly) by the ISO C
> > standard. The problem can be remedied by making 'bar' (and maybe
> > also 'moo') volatile.
> Beside the question of whether it's allowed by the spec, for me the main
> question would be to understand why the compiler decided to swap the
> order between the loop and the computation of `bar`.
>
> I can't see any obvious benefit. It shortens the time between computing
> `bar` and using it, which is bad from a code-scheduling perspective.
> There doesn't need to be any register pressure which would justify an
> effort to reduce live ranges... What's the point?
>
>
> Stefan

As I said at the beginning of my post, I don't remember an exact code. It was more complicated than what I presented.
I'd try to find it tomorrow.
I do remember that there was a logical explanation for compiler's decision. For some value of "logical".

According to BGB <cr88192@gmail.com>:
>> There were plenty of other languages at the time, with various forces backing C and Pascal,
>> but Fortran keeps chugging along.
>
>Give it a few more years and you may find people trying to implement
>"serious business" software in Python or similiar...

I have some bad news for you.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

BGB <cr88192@gmail.com> writes:

> On 10/15/2021 6:49 AM, Tim Rentsch wrote:
>
>> BGB <cr88192@gmail.com> writes:
>>
>>> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>>>
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>
>>>>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>>>>
>>>>>> Can you cast a pointer to a different type? Sure.
>>>>>>
>>>>>> Can you dereference it?
>>>>>
>>>>> No.
>>>>
>>>> This statement is wrong, or at best much overstated. There are
>>>> plenty of situations where a C pointer value converted to a
>>>> different type may be safely and portably dereferenced.
>>>> Certainly that isn't always true, but it isn't always false
>>>> either.
>>>
>>> Yeah. For some types of code it is desirable to be able to cast
>>> and dereference a pointer as whatever type matches what one wants
>>> to do with it. [...]
>>
>> If what is wanted is to take the bits of one type and interpret
>> them as bits of a different type (assuming of course that the two
>> types have the same size), it's easy to do that by using a union
>> intermediate. (In some cases an intermediate is not needed and the
>> reinterpretation can be done using conversion of pointer values.)
>
> Yeah, a union works, but it is kinda awkward.

In C90 unions were awkward. In C99 and later there are compound
literals:

#define BITCAST( Tin, e, Tout ) ( \
(union {Tin in; Tout out;} ){ .in = (e) }.out \
)

int
test( float *pf ){
return BITCAST( float, *pf, int );
}

Generated code in gcc -O1 is one movl (plus a ret, of course,
although presumably any overhead would be compiled away if the
function were made inline).

>> If what is wanted is to have pointers of different types that
>> point to the same memory, and interleave access to the same
>> memory using the different pointer types, and do that safely,
>> this cannot be done in general (although it can be done under
>> some particular sets of conditions).
>
> Granted, this is one weakness of most of my "TBAA but with local
> exclusion" ideas.
>
> Arguably, one would want something like "volatile, but weaker".
> If one were to abuse volatile for this, then it would create
> incentive to try to "optimize" the use of volatile, defeating its
> primary reason for existing (namely things like memory-mapped IO
> and similar).
>
>
> But, say, we can have an optional 'may_alias' keyword (or
> something to this effect), say, which could be defined as, say:

> #ifdef __CC_HAS_ALIAS__
> #define may_alias [[may_alias]] //nicer attribute syntax
> #elif defined(_MSC_VER)
> #define may_alias // MSVC doesn't use TBAA by default
> #elif defined(__GNUC__)
> #define may_alias __attribute__((may_alias)) // GCC already has this
> #else
> #define may_alias volatile // well, whatever, use 'volatile'
> #endif
>
> then, say:
>
> void foo(may_alias int *pa, may_alias float *pb)
> {
> ...
> }
>
> Where the compiler may not make any TBAA style assumptions about
> whether 'pa' or 'pb' may alias with each other, but which may
> still cache values in other contexts (which do not depend on
> aliasing between these pointers), unlike volatile which sort of
> forces every access though these pointers to do a load or store
> (making it sort of a sledgehammer solution to the usual TBAA
> issues).
>
> Likewise, it would not require disabling TBAA for the entire
> program.

I'm not sure this idea is practicable, but even if it is it's
not a good idea. A "may alias" attribute is selectively turning
on safety. That's backwards: the default assumption should be
that code is safe (and all aliasing is allowed), with a way of
attaching an optional attribute to turn OFF safety (so TBAA
analysis may be used for those cases). C would be improved if
this principle were extended to other kinds of UB, such what
happens on signed overflow - the crazy optimizations should be
allowed only if the programmer explicitly says so.

Note that 'restrict' gets this right - the default is that
aliasing is allowed, with 'restrict' attaching an option that
says aliasing will /not/ happen with this pointer (and it's
the developer's fault if that assertion is violated).

On 2021-10-15, Michael S <already5chosen@yahoo.com> wrote:
> On Friday, October 15, 2021 at 12:11:58 PM UTC+3, Branimir Maksimovic wrote:
>> On 2021-10-14, Thomas Koenig <tko...@netcologne.de> wrote:
>> > Branimir Maksimovic <branimir....@icloud.com> schrieb:
>> >
>> >> Fortran is pre structured era, spagetti code.
>> >
>> > Your knowledge seems to be stuck in the 1980s.
>> >
>> > To see what was available in Fortran 95,
>> > around 25 years ago, you could try reading
>> > https://en.wikipedia.org/wiki/Fortran_95_language_features
>> So what do you recommend? Fortran or ADA?
>> --
>
> The name of the language is Ada.
> ADA is a misspelling preferred by Mitch Alsup. I don't know what are his reasons.
>
OK, Ada. What do you recommend?
>
>>
>> 7-77-777
>> Evil Sinner!
>> with software, you repeat same experiment, expecting different results...

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...