On 2021-10-15, MitchAlsup <MitchAlsup@aol.com> wrote:
> You know, there is a very fine NG suited to discuss the nuances of C,
> what it is, what it is not, and what has been left grey {intentionally,
> or by omission}: comp.lan.c
>
> 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.
>
> The past has taught us that a deft hand is required to put in enough
> "stuff" to make the expression of the compiler efficient, and leave
> out enough "stuff" to allow the implementations to be fast and
> efficient. This paragraph should be what a discussion of what C in
> this NG should be is about--what goes in ISA to make the compiler's
> expression efficient, and what stays out of ISA that makes the
> implementations efficient.
>
> I would suggest what stays out and what goes ISA in has changed
> "a bit" since the RISC revolution burst onto the scene and then withered.
RISC is for compilers CISC for HUMANS :P

--

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

On 2021-10-16, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> John Levine <johnl@taugh.com> writes:
>
>> According to Branimir Maksimovic <branimir.maksimovic@icloud.com>:
>>
>>>> Fortran has evolved. Look at current Fortran, not at something from over
>>>> half a century ago.
>>>
>>> Well, it's not FORTRAN anymore then :P
>>
>> 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.)
You can remember everything by playing associations, just
let memory associate terms and concentrate on what you want
to recall :P

--

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

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.

My hobby ISA has a variety of CompareAndTrap conditional trap instructions
useful for range checks. There is also one for base-1 array checks that
traps if a register value == 0 or unsigned >= limit.

Later I realized these might be susceptible to Spectre
(the security bug, not the Bond villains) because it can allow the
memory op to be performed before the exception is signaled.

But I have an idea for a fix: the solution is to make the
register value to check read-write so there is a write dependency
of any following register readers on the completion of the check.
The register is read and compared to the limit. If in a legal range,
as it usually is, it writes the same value back to the same register
allowing subsequent instructions to proceed.
If outside the legal range it doesn't write the result back causing
subsequent instructions to wait, and it signals an exception.

catge r1,#123 // if (r1 < 123) r1 = r1 else trap
ld r0,[rBase+r1*scale] // ld must wait for r1 to be rewritten by catge

On 10/16/2021 9:53 PM, Tim Rentsch wrote:
> 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).
>

Could be.

Though, sadly, this construct doesn't work in MSVC it seems.

Microsoft has tended to be a little slow on the whole C99 thing...

Note that I tend to go between MSVC, GCC, and Clang; using whatever is
available for the target.

For BJX2, I have BGBCC, but for the most part it implements a C dialect
that is pretty close to that used by MSVC, though with the major
difference that I went with LP64 rather than LLP64. To me it seemed more
useful to have sizeof(long)==sizeof(void *) than to keep 'long' as a 32
bit type.

Generally, a lot of code originally written for Watcom C also ports over
to MSVC reasonably OK, apart from anything which is overly specific to
32-bit systems or 32-bit x86 (such as large blobs of inline ASM).

Usual process was to first port code to MSVC (replacing any x86 ASM
blobs with a plain C reimplementation), and then to port it over to BJX2
(sometimes rewriting a few parts back into BJX2 ASM if needed).

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

Yeah, this makes sense actually.

I didn't actually come up with the "may_alias" attribute, that is
already a GCC feature.

However, my idea here was more wrapping it in a macro to make it look
like a keyword. This is more assuming that people insist that code be
built with strict aliasing, this allows a way to still allow a lot of
the "pointer fun" to keep working.

But, yeah, this sort of thing does add an extra level of hassle to
porting DOS era code over to GCC (if one wants it to work natively).
Thus far I had done this a few times as its own sub-project.

Have yet to get around to trying to port ROTT to build using GCC or
Clang yet though, could probably get around to this at some point.

I could almost do a "proper" Wolfenstein 3D port as well, except that
the original source-code isn't under a convenient license (what I have
instead is a hacked version of the ROTT engine which can more-or-less
pretend to be the Wolfenstein 3D engine, though this is still a bit
"rough" / "not entirely authentic").

Also, my quick/dirty attempt to port 16-bit TurboC code to 64-bits was a
bit messy. A secondary issue is that I can't really redistribute the
original Wolf3D asset data either. (It is a little easier with Doom
Engine games in that one can have the users supply their own WADs, and
there is a cleaner line of separation between the engine and asset data
than there was with Wolf3D).

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

Also makes sense.

BGBCC also has the 'restrict' keyword, as does MSVC.

On Sunday, October 17, 2021 at 6:18:11 AM UTC+3, Branimir Maksimovic wrote:
> On 2021-10-15, Michael S <already...@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?

Me, personally? Neither.
Others, I'd guess, would be able to answer only if you specify a sort of software that you are planning to develop.

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

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> 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?

Because gfortran is (mostly) a volunteer effort, people just haven't
gotten a round tuit. The reason is probably that people activate
bounds checking only on debugging code, much like Hoare described.

On 15/10/2021 18: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?  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.
>

I am not at all sure what I would want here, or what would be practical.

Yes, the tools would need to know a lot more about the hardware in order
to get a reasonable idea of the timings. (They would not necessarily
need exact hardware - some things could be run-time configurable.)
There would need to be more support library features than you have today
in C.

But when I think about the kinds of things I need to do in my coding,
that are not supported by C (or C++, or, I believe, other languages),
things discussed here like accessing data through different pointer
types or wrapping or otherwise defined integer overflow simply are not
at all important. On the extremely few occasions where these might be
relevant, C already has ways to handle them with efficient results. And
I do low-level and small-systems embedded programming - exactly the kind
of programming that people think need such features.

No, what I am missing is precise control over some kinds of executions,
ways to specify timings, and ways to give the compiler more information
so that it can treat more things as undefined behaviour, resulting in
safer and more efficient code.

I want to be able to say "do this calculation /now/, not just some time
between when you have the inputs ready and need the output". C has no
such concept. You can order memory accesses by using "volatile", but
that does not affect any other kind of operation or calculation, or
ordering of non-volatile memory accesses. So if I want to push all
non-critical work outside of a critical section, C can't give me that.
This is a real problem:

<https://www.nongnu.org/avr-libc/user-manual/optimization.html>

I know how to get the effect needed here using gcc inline assembly
statements with no assembly (most of the "inline assembly" statements I
write actually contain no assembly at all!). But of course it would be
vastly better to have such features in the language than rather obscure
compiler-specific inline assembly macros.

I want to be able to say "make this bit of code as fast as possible". I
want to be able to say "warn me at compile-time if this section is
expected to take more than x clock cycles" (yes, I know this only makes
sense on smaller and simpler processors - but that's when you need it).

I would like to be able to tell the compiler "x is between 1 and 3 here
- optimise using that knowledge, and ignore the possibility that it is
outside that range". Again, I can do a lot of this in gcc - using
__builtin_unreachable() to indicate undefined behaviour. (Yes, I am
/adding/ undefined behaviour to improve my code.)

Some of the things I would like could be done by standardising things
that can be expressed with gcc. Other things, I have no good idea of
how they could be handled.

But what I /can/ say is that I think these things would be a lot more
useful for low-level code, OS's, and the like, than making signed
integer overflow wrap, or disabling TBAA.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>Right, but switches are not hubs, and they create a separate collision
>domain for each switch port.

At least they try. The switch keeps track of the MAC addresses
reachable through each port, and forwards only the traffic addressed
to that MAC addresses on that port. If there are more MAC addresses
involved than the switches table can hold, switches broadcast
everything on all ports, like hubs.

> So no shared "ether", or so I understand.

Basically, the ether is still there, and switches fall back to ether
behaviour when their optimizations cannot be applied. In the usual
case, however, they do not broadcast.

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

WLAN is wireless LAN (aka Wifi, whatever that stands for). The
acronym for wide-area networks is WAN (but has fallen pretty much out
of use, not that everything is Intenet).

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

On Sunday, October 17, 2021 at 1:27:22 AM UTC+3, Michael S wrote:
> 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".

I founded a problematic variant.
Putting aside unnecessary details, it was something like that:

#define TIME_VAL (*(volatile uint32_t*)0x12345608))
#define ACTION_REG (*(volatile uint32_t*)0x43215604))

extern uint32_t gl_wait0, gl_wait1, gl_wait2;
void foo(int moo, uint32_t t0)
{
uint32_t wait0_clk = gl_wait0 * 0.42;
uint32_t wait1_clk = gl_wait1 * 0.42;
uint32_t wait2_clk = gl_wait2 * 0.42;

while (TIME_VAL-t0 < wait0_clk);
if (moo) {
ACTION_REG = 142;
while (TIME_VAL-t0 < wait1_clk);
ACTION_REG = 242;
} else {
ACTION_REG = 242;
while (TIME_VAL-t0 < wait2_clk);
ACTION_REG = 142;
}
}

And compiler transformation was like that:

void foo(int moo, uint32_t t0)
{
uint32_t wait0_clk = gl_wait0 * 0.42;

while (TIME_VAL-t0 < wait0_clk);
if (moo) {
ACTION_REG = 142;
uint32_t wait1_clk = gl_wait1 * 0.42;
while (TIME_VAL-t0 < wait1_clk);
ACTION_REG = 242;
} else {
ACTION_REG = 242;
uint32_t wait2_clk = gl_wait2 * 0.42;
while (TIME_VAL-t0 < wait2_clk);
ACTION_REG = 142;
}
}

Perfectly legal transformation, one can even say - reasonable, but it took original developer by surprise.
Even for gray-bearded developer like myself, it took considerable time to start suspecting in the right direction.

Thomas Koenig <tkoenig@netcologne.de> writes:
>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
> 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?

On a Skylake (Core i5-6600K) with gfortran 10.2 I see even an even
bigger speed difference (see below). It seems that gfortran manages
to auto-vectorize withoit -fcheck=bounds, but does not auto-vectorize
with. To get the auto-vectorization out of the way, I compiled with
-O2 and otherwise the same options, and get the following inner loops:

add $0x1,%rdx
cmp %rdx,%r9
jl 151e <__mm_MOD_do_mm+0x31e>
add %r11,%rax
add %r10,%rcx
movss (%rcx),%xmm0 cmp %rdx,%r8
add $0x1,%edx jl 153b <__mm_MOD_do_mm+0x33b>
add %rdi,%rcx movss (%rcx),%xmm0
mulss %xmm1,%xmm0 lea 0x1(%rdx),%esi
addss (%rax),%xmm0 mulss %xmm1,%xmm0
movss %xmm0,(%rax) addss (%rax),%xmm0
add %r8,%rax movss %xmm0,(%rax)
cmp %esi,%edx cmp %edi,%esi
jne 1350 <__mm_MOD_do_mm+0x160> jle 13f0 <__mm_MOD_do_mm+0x1f0>

Here are cycles (user mode):

-O2 -O3
2,076,049,869 404,881,743 #nothing else
4,046,737,707 4,046,930,388 -fcheck=bounds

And here are instructions:

-O2 -O3
9,054,386,405 1,432,153,392 #nothing else
14,060,384,677 12,060,378,638 -fcheck=bounds

An interesting aspect is that this is a throughput-limited application
(in contrast to most code which is latency-limited). Here the
additional instructions from the checking do not just increase the
IPC, they increase the cycles (and actually IPC is a bit lower; the
reason for that is unclear to me). You see the 9 vs. 14 instructions
in the inner loop nicely in the instruction counts.

>>>Compilers need to become better at moving
>>>checking code out of loops.
>>
>> Again, support needed.
>
>See above.

Yes, gfortran definitely needs to become better at this. This is an
easy case, and I am surprised that it cannot do this.

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

Ivan Godard <ivan@millcomputing.com> writes:
>On 10/16/2021 9:07 AM, Anton Ertl wrote:
>> 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.

You can certainly afford a NaT bit per cache line and even per 16 bits
with DDR4 ECC DIMMs (DDR5 and ECC is going to be an interesting
story). If you want ECC and a NaT bit per byte, you need to make
DIMMs with 80 bits per 64-bit word (e.g., 10 8-bit-wide devices), no
need to be Samsung, but you lose the economies of scale of the
commodity DIMM market, so you probably don't want to go there.

For detecting most uses use-after-free, a NaT bit per 16 bits seems
plenty.

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

On 16/10/2021 18:07, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:

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

Just for completeness, I can give you the answer here. If char is
smaller than int, then the addition of two signed chars is always going
to be fully defined. If char is the same size as int, then it could
overflow (of course it could not overflow when adding 127 + 127, as int
will always be big enough to hold 254).

The conversion from int down to signed char is fully defined if the
signed char can hold the value, otherwise it is "implementation-defined
or an implementation-defined signal is raised". That means the
implementation has to document a specific handling here - but it is
allowed to have some kind of trap or error handling rather than a
particular value.

In practice, of course, virtually all compilers will do the conversion
as modulo reduction (or two's complement wrapping, if you prefer).
Maybe some will offer trapping as an alternative to aid in debugging.

So - defined by the implementation, not undefined.

Victor Yodaiken <victor.yodaiken@gmail.com> writes:

[...]

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

That statement gives a rule for what happens in the abstract
machine. What happens in the actual machine is allowed to be
different, per section 5.1.2.3.

Michael S <already5chosen@yahoo.com> writes:

> On Saturday, October 16, 2021 at 9:23:45 PM UTC+3, Niklas Holsti wrote:
>
>> On 2021-10-16 20:03, Michael S wrote:

[...]

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

Note that these definitions have unbalanced parentheses.

>>> 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;
>>> }
>>>
>>> [which was compiled to something like]
>>>
>>> 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.
>>
>>> 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.

If 'bar' were extern rather than auto that might change the order
of code produced, but the comment about making 'bar' volatile is
right: if 'bar' were declared volatile then the while() loop
must not be moved to execute before the assignment to 'bar'. As
the code stands moving the while() loop to execute before the
assignment to 'bar' is allowed by the C standard (as surprising
and disgusting as that might be).

On Sunday, October 17, 2021 at 6:39:07 AM UTC-5, David Brown wrote:

> I want to be able to say "do this calculation /now/, not just some time
> between when you have the inputs ready and need the output". C has no
> such concept. You can order memory accesses by using "volatile", but
> that does not affect any other kind of operation or calculation, or
> ordering of non-volatile memory accesses. So if I want to push all
> non-critical work outside of a critical section, C can't give me that.
> This is a real problem:

Agreed. The Standard says statements should be executed in order unless
otherwise "indicated", but this seems to be a dead letter. In fact the now optional
(and always awful) threads component allows for arbitrary compiler movements
of statements
within synchronization blocks. This standards language was not properly edited when
the concurrency/thread stuff became optional and both WG14 and gcc/clang
seem to believe that they can ignore statement order pretty much everywhere.
> I would like to be able to tell the compiler "x is between 1 and 3 here
> - optimise using that knowledge, and ignore the possibility that it is
> outside that range". Again, I can do a lot of this in gcc - using
> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
> /adding/ undefined behaviour to improve my code.)

Good example of how the concept of undefined has become too much of the hammer used
on every problem.

> Some of the things I would like could be done by standardising things
> that can be expressed with gcc. Other things, I have no good idea of
> how they could be handled.
>
> But what I /can/ say is that I think these things would be a lot more
> useful for low-level code, OS's, and the like, than making signed
> integer overflow wrap, or disabling TBAA.

This depends on what you are doing. For OS "in the large"
those things are more of a problem.

#include <bigdatastructureT.h>

f(T* x){
// T.i is signed int, but work unsigned to allow modular arithmetic
unsigned int *i = (unsigned int *)&T->i;
*i += read_sensor();
....
}

and then to find out at some much later time that someone changed T.i to a long
and the optimizer has silently deleted the assignment.
What I want here is for the compiler to WARN me there is a possible type error and
not for the compiler to silently "optimize" it .

or
if ( ptr < &stack[0])stackoverflow();

OOPS! That comparison is UB and whole statement can be silently deleted

or ....

Linux has 30million some lines of code (God save us), it's going to have very different problems than
a device driver or microcontroller code. Many UB ill effects come from the inevitable problems
of a huge, old, codebase touched by many different people, few of whom have much visibility
into the larger system.

On Sunday, October 17, 2021 at 5:27:35 PM UTC+3, Tim Rentsch wrote:
> Michael S <already...@yahoo.com> writes:
>
> > On Saturday, October 16, 2021 at 9:23:45 PM UTC+3, Niklas Holsti wrote:
> >
> >> On 2021-10-16 20:03, Michael S wrote:
>
> [...]
> >>> 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))
> Note that these definitions have unbalanced parentheses.

> >>> 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;
> >>> }
> >>>
> >>> [which was compiled to something like]
> >>>
> >>> 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.
> >>
> >>> 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.
>
> If 'bar' were extern rather than auto that might change the order
> of code produced, but the comment about making 'bar' volatile is
> right: if 'bar' were declared volatile then the while() loop
> must not be moved to execute before the assignment to 'bar'.

Are you sure?
According to my understanding, meaning of volatile, when applied to auto variable is not defined in Standard.
In practice, I'd guess that gcc will honor it, but it does not seem to be guaranteed.

> As
> the code stands moving the while() loop to execute before the
> assignment to 'bar' is allowed by the C standard (as surprising
> and disgusting as that might be).

On 16/10/2021 19: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;
> }
> 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.
>
>

Yes, that kind of thing is a valid transform in C.

With gcc, there is a solution using inline assembly - you give the
compiler an empty assembly statement, but say it has to use "bar" as an
input.

(You could also make "bar" a volatile variable, but that would be less
efficient.)

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;

asm volatile("" :: "" (bar) : );

if (moo) {
while (TIME_VAL-t0 < dt);
}
ACTION_REG = bar;
}

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

> I want to be able to say "do this calculation /now/, not just some time
> between when you have the inputs ready and need the output". C has no
> such concept. You can order memory accesses by using "volatile", but
> that does not affect any other kind of operation or calculation, or
> ordering of non-volatile memory accesses. So if I want to push all
> non-critical work outside of a critical section, C can't give me that.
> This is a real problem:
>
><https://www.nongnu.org/avr-libc/user-manual/optimization.html>

For the particular problem described there,

#define cli() __asm volatile( "cli" ::: "memory" )
#define sei() __asm volatile( "sei" ::: "memory" )
unsigned int ivar;
void test2( unsigned int val )
{ val = 65535U / val;
cli();
ivar = val;
sei();
}

it should be possible to write a version for cli which has a
register operand. What about (x86 assembly here)

#define cli_reg(var) __asm volatile ( "cli" :"=r" (var): "r" (var) :)
#define sti() __asm volatile( "sti" ::: "memory" )
unsigned int ivar;
void test2( unsigned int val )
{ val = 65535U / val;
cli_reg (val);
ivar = val;
sti();
}

By declaring val as both input and output, and being a register,
gcc generates for me

000000000000000 <test2>:
0: 31 d2 xor %edx,%edx
2: b8 ff ff 00 00 mov $0xffff,%eax
7: f7 f7 div %edi
9: fa cli
a: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 10 <test2+0x10>
10: fb sti
11: c3 ret

which has the cli/sti pair right where you want it.

On 17/10/2021 16:54, Michael S wrote:
> On Sunday, October 17, 2021 at 5:27:35 PM UTC+3, Tim Rentsch wrote:
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Saturday, October 16, 2021 at 9:23:45 PM UTC+3, Niklas Holsti wrote:
>>>
>>>> On 2021-10-16 20:03, Michael S wrote:
>>
<snip>
>>>>
>>>> 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.
>>
>> If 'bar' were extern rather than auto that might change the order
>> of code produced, but the comment about making 'bar' volatile is
>> right: if 'bar' were declared volatile then the while() loop
>> must not be moved to execute before the assignment to 'bar'.
>
> Are you sure?
> According to my understanding, meaning of volatile, when applied to auto variable is not defined in Standard.
> In practice, I'd guess that gcc will honor it, but it does not seem to be guaranteed.
>

I have not noticed anything in the standard to suggest that "volatile"
is restricted to non-auto variables. Can you give a reference?

Making "bar" extern may or may not change the ordering - it is not
required to do so.

>> As
>> the code stands moving the while() loop to execute before the
>> assignment to 'bar' is allowed by the C standard (as surprising
>> and disgusting as that might be).

On 16/10/2021 22:01, Tim Rentsch wrote:
> 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.
>

The reordering is allowed very clearly by the execution model of C -
only the order and effects of observable behaviour are important, and
everything else can be re-arranged, combined, split, moved, or whatever
suits the compiler. An execution model that /required/ the calculation
of "bar" before the loop would need to be significantly different from
that of C - it would require a model that added "doing work" to
observable behaviour.

As I mentioned in another post, I'd like some standardised way to get
the effect Michael was looking for, without the inefficiencies of using
"volatile" and without the non-portable inline assembly solution I gave.
But I would not want such ordering to be the norm in C - that would
greatly reduce the compiler's optimisation opportunities while providing
no benefit in virtually all cases.

On 17/10/2021 14:11, Michael S wrote:
> On Sunday, October 17, 2021 at 1:27:22 AM UTC+3, Michael S wrote:
>> 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".
>
> I founded a problematic variant.
> Putting aside unnecessary details, it was something like that:
>
> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> #define ACTION_REG (*(volatile uint32_t*)0x43215604))
>
> extern uint32_t gl_wait0, gl_wait1, gl_wait2;
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> uint32_t wait2_clk = gl_wait2 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }
>
> And compiler transformation was like that:
>
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> uint32_t wait2_clk = gl_wait2 * 0.42;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }
>
> Perfectly legal transformation, one can even say - reasonable, but it
> took original developer by surprise. Even for gray-bearded developer
> like myself, it took considerable time to start suspecting in the
> right direction.
>

I can see that being surprising if you haven't thought about it before
or seen it in other code - despite being reasonable and understandable
once you have realised what was going on.

asm volatile ("" :: "" (wait1_clk), "" (wait2_clk));

It is not portable, of course, but neither is the code you have in the
first place. And it is cheaper than using "volatile" as it doesn't need
extra memory addresses on the stack.

(Some compilers support "volatile register" variables, but that is not
standard either.)

On 10/17/2021 4:39 AM, David Brown wrote:
> On 15/10/2021 18: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?  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.
>>
>
> I am not at all sure what I would want here, or what would be practical.
>
> Yes, the tools would need to know a lot more about the hardware in order
> to get a reasonable idea of the timings. (They would not necessarily
> need exact hardware - some things could be run-time configurable.)
> There would need to be more support library features than you have today
> in C.
>
> But when I think about the kinds of things I need to do in my coding,
> that are not supported by C (or C++, or, I believe, other languages),
> things discussed here like accessing data through different pointer
> types or wrapping or otherwise defined integer overflow simply are not
> at all important. On the extremely few occasions where these might be
> relevant, C already has ways to handle them with efficient results. And
> I do low-level and small-systems embedded programming - exactly the kind
> of programming that people think need such features.
>
> No, what I am missing is precise control over some kinds of executions,
> ways to specify timings, and ways to give the compiler more information
> so that it can treat more things as undefined behaviour, resulting in
> safer and more efficient code.
>
> I want to be able to say "do this calculation /now/, not just some time
> between when you have the inputs ready and need the output". C has no
> such concept. You can order memory accesses by using "volatile", but
> that does not affect any other kind of operation or calculation, or
> ordering of non-volatile memory accesses. So if I want to push all
> non-critical work outside of a critical section, C can't give me that.
> This is a real problem:
>
> <https://www.nongnu.org/avr-libc/user-manual/optimization.html>
>
> I know how to get the effect needed here using gcc inline assembly
> statements with no assembly (most of the "inline assembly" statements I
> write actually contain no assembly at all!). But of course it would be
> vastly better to have such features in the language than rather obscure
> compiler-specific inline assembly macros.
>
> I want to be able to say "make this bit of code as fast as possible". I
> want to be able to say "warn me at compile-time if this section is
> expected to take more than x clock cycles" (yes, I know this only makes
> sense on smaller and simpler processors - but that's when you need it).
>
> I would like to be able to tell the compiler "x is between 1 and 3 here
> - optimise using that knowledge, and ignore the possibility that it is
> outside that range". Again, I can do a lot of this in gcc - using
> __builtin_unreachable() to indicate undefined behaviour. (Yes, I am
> /adding/ undefined behaviour to improve my code.)
>
>
> Some of the things I would like could be done by standardising things
> that can be expressed with gcc. Other things, I have no good idea of
> how they could be handled.
>
> But what I /can/ say is that I think these things would be a lot more
> useful for low-level code, OS's, and the like, than making signed
> integer overflow wrap, or disabling TBAA.
>

Interesting, especially in the context of hardware using temporal
addressing. The compiler distinguishes between instructions that
schedule withConsumers (so their lifetimes are as short as possible, the
usual case) and those that schedule withProducers (for instructions like
store that have no consumers, or like load which wants to be early to
give the caches as much time as possible to come up with a value).
However, within those categories the compiler is free to reorder so long
as it satisfies ordering and dataflow constraints.

However, the compiler internally has available a pseudo-instruction
called "spacer". This gets inserted into the nominal instruction list
for certain schedule control actions needed by administrative
instructions not relevant here, but it has the general property that
other instructions cannot be moved across a spacer. The spacer is purely
an ordering device; there is no such hardware instruction and it is
elided when producing the binary.

We do not, but could, define an intrinsic for spacer. If we did, would
it address part of your desire? Alternatively, while spacer blocks all
instructions, our ISA distinguishes idempotent instructions like add
from non-idempotent ("nonspeculable" in our terminology) instructions
like store, and there could be a flavor of spacer that blocked only
non-speculables. Do you think general or non-speculable blockages be the
more useful, or perhaps both should be supplied?

> I found a problematic variant.
[...]
> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> #define ACTION_REG (*(volatile uint32_t*)0x43215604))
>
> extern uint32_t gl_wait0, gl_wait1, gl_wait2;
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> uint32_t wait2_clk = gl_wait2 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }
>
> And compiler transformation was like that:
>
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> uint32_t wait2_clk = gl_wait2 * 0.42;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }

Ah, that makes sense, yes. It's a very reasonable rewrite seen from the
point of view of reducing the amount of work done (don't bother
computing `wait[12]_clk` if you're not going to use it), and since the
operations moved are pure, the semantics is preserved.

Thanks for the example. As a language designer it makes me wonder how
I could let the author of the code clarify the intended behavior while
still allowing the compiler enough freedom to make "obvious"
simplifications (typically useful for code that is the result of
macroexpansion or inlining).

Maybe the empty loop is part of the key?

Stefan

Michael S <already5chosen@yahoo.com> writes:

[.. on code reordering and volatile ..]

> I founded a problematic variant.
> Putting aside unnecessary details, it was something like that:
>
> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> #define ACTION_REG (*(volatile uint32_t*)0x43215604))

(Same comment as before regarding unbalanced parentheses.)

> extern uint32_t gl_wait0, gl_wait1, gl_wait2;
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> uint32_t wait2_clk = gl_wait2 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }
>
> And compiler transformation was like that:
>
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> uint32_t wait2_clk = gl_wait2 * 0.42;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }

Here again the surprising code reordering can be prevented by
making the three local variables volatile.

> Perfectly legal transformation, one can even say - reasonable, but
> it took original developer by surprise.

I think it would take most developers by surprise. The rules for
how volatile works exactly are AFAICT not widely known.

> Even for gray-bearded developer like myself, it took considerable
> time to start suspecting in the right direction.

The rules for how volatile works are IMO perhaps the most broken
part of the C standard. What is allowed isn't clear from the
wording (one might even say the wording doesn't express it), and
the consequences are often surprising. So I have to agree your
complaints have some justification.

A rule of thumb for volatile and code reordering: reordering is
not allowed for two volatile accesses, but reordering is allowed
to move non-volatile accesses across volatile accesses (assuming
of course there are no direct dependencies). I don't claim this
rule is absolutely right but I think it's a good first check.

Incidentally, it isn't absolutely necessary to declare the three
locals as volatile to avoid the unfortunate code reordering.
That can be done using volatile a bit more selectively:

uint32_t wait0_clk;
uint32_t wait1_clk;
uint32_t wait2_clk;
*(volatile uint32_t*) &wait0_clk = gl_wait0 * 0.42;
*(volatile uint32_t*) &wait1_clk = gl_wait1 * 0.42;
*(volatile uint32_t*) &wait2_clk = gl_wait2 * 0.42;

Depending on circumstances one or the other of these techniques
may give better results than the other (or more likely just be
down in the noise so it wouldn't really matter which one is
used).

(I have verified the results regarding volatile and code
reordering under gcc with -O2.)

Michael S <already5chosen@yahoo.com> schrieb:

>#define TIME_VAL (*(volatile uint32_t*)0x12345608))
>#define ACTION_REG (*(volatile uint32_t*)0x43215604))
>
> extern uint32_t gl_wait0, gl_wait1, gl_wait2;
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> uint32_t wait2_clk = gl_wait2 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }
>
> And compiler transformation was like that:
>
> void foo(int moo, uint32_t t0)
> {
> uint32_t wait0_clk = gl_wait0 * 0.42;
>
> while (TIME_VAL-t0 < wait0_clk);
> if (moo) {
> ACTION_REG = 142;
> uint32_t wait1_clk = gl_wait1 * 0.42;
> while (TIME_VAL-t0 < wait1_clk);
> ACTION_REG = 242;
> } else {
> ACTION_REG = 242;
> uint32_t wait2_clk = gl_wait2 * 0.42;
> while (TIME_VAL-t0 < wait2_clk);
> ACTION_REG = 142;
> }
> }
>
> Perfectly legal transformation, one can even say - reasonable,
> but it took original developer by surprise. Even for gray-bearded
> developer like myself, it took considerable time to start suspecting
> in the right direction.

It's not quite clear to me what the problem was.

Did gl_wait1 and gl_wait2 change their values while the first
while loop was running? If so, declaring them as "extern volatile"
should have done the trick.