On 2021-10-13 16:57, David Brown wrote:
> On 13/10/2021 11:11, Branimir Maksimovic wrote:
>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>>>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>>>> hence not all caps) is that its syntax makes it easier to write correct
>>>>> programs, and harder, though of course not impossible, to make the kind
>>>>> of errors this thread has been talking about.
>>>>>
>>>>> But others here are far more qualified to discuss this than I am.
>>>>>
>>>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>>>> IDE support :P
>>>
>>> Again, others are more qualified than I am to comment, but it appears
>>> that GNAT (GNU Ada compiler) is available on MacOS.
>>>
>>
>> Yes, but is only for x86, does not builds for my M1.
>> Interrestingly except gforth (without extensions)
>> there is no forth for M1, as well.
>
> I think that is mainly due to Apple's determination to stop people using
> Apple devices for any development other than Apple applications using
> Apple's tools and paying Apple's fees (for whatever they can get away
> with). I can appreciate that an M1 machine gives you a lot of
> processing power in a small and low-power device, but they seem to be
> competing with Windows in their battle to make programmers' and small
> developers' lives as inconvenient as possible.
>
> Maybe they'll make an Ada front-end to clang, and call it "gnat" to
> confuse their users like they did with their C compiler.

AIUI, AdaCore are working on a GNAT (Ada compiler) variant based on
clang/llvm rather than gcc. But i believe it is still considered
"experimental".

On 2021-10-13, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> schrieb:
>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>>>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>>>> hence not all caps) is that its syntax makes it easier to write correct
>>>>> programs, and harder, though of course not impossible, to make the kind
>>>>> of errors this thread has been talking about.
>>>>>
>>>>> But others here are far more qualified to discuss this than I am.
>>>>>
>>>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>>>> IDE support :P
>>>
>>> Again, others are more qualified than I am to comment, but it appears
>>> that GNAT (GNU Ada compiler) is available on MacOS.
>>>
>>
>> Yes, but is only for x86, does not builds for my M1.
>> Interrestingly except gforth (without extensions)
>> there is no forth for M1, as well.
>
> AFAIK, there will be M1 support in gcc 12. Interestingly enough,
> it was the lack of a Fortran compiler which mostly drove demand
> for this port.
Great! Thanks!

--

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

On 2021-10-13, David Brown <david.brown@hesbynett.no> wrote:
> On 13/10/2021 11:11, Branimir Maksimovic wrote:
>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>> On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>>>> On 2021-10-13, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>>>> To me, the big advantage of Ada (it's a woman's name, not an acronym -
>>>>> hence not all caps) is that its syntax makes it easier to write correct
>>>>> programs, and harder, though of course not impossible, to make the kind
>>>>> of errors this thread has been talking about.
>>>>>
>>>>> But others here are far more qualified to discuss this than I am.
>>>>>
>>>> OK, I'll try it, it, but on macOS I can't have compiler, let alone
>>>> IDE support :P
>>>
>>> Again, others are more qualified than I am to comment, but it appears
>>> that GNAT (GNU Ada compiler) is available on MacOS.
>>>
>>
>> Yes, but is only for x86, does not builds for my M1.
>> Interrestingly except gforth (without extensions)
>> there is no forth for M1, as well.
>
> I think that is mainly due to Apple's determination to stop people using
> Apple devices for any development other than Apple applications using
> Apple's tools and paying Apple's fees (for whatever they can get away
> with). I can appreciate that an M1 machine gives you a lot of
> processing power in a small and low-power device, but they seem to be
> competing with Windows in their battle to make programmers' and small
> developers' lives as inconvenient as possible.
>
> Maybe they'll make an Ada front-end to clang, and call it "gnat" to
> confuse their users like they did with their C compiler.
>
>
Yes, I am aware of Apple politics, it's just that this CPU
I like too mutch :P
But they have crappy TCP stack :P

--

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

On 12/10/2021 07:23, Quadibloc wrote:
> On Saturday, October 9, 2021 at 7:02:42 PM UTC-6, victor....@gmail.com wrote:
>
>> Of course the paper doesn't make an argument anything like that nor does it make the assembler claims
>> you start with. It is hard to believe anyone could read the
>> paper and get such a weird take from it.
>
> Maybe such a one had been exposed to the posts
> of Anton Ertl, for example, and had just assumed,
> after reading part of the paper and throwing it
> down in disgust, that it represented a similar
> viewpoint?
>

Well, I have been exposed to some of Anton's posts (and while I disagree
with most of his opinions and beliefs - or misunderstandings - about C
and gcc, I have huge respect for him in other things). Did I misjudge
the paper, and make unjustified assumptions about it? Perhaps I did, to
at least some extent. Victor's responses to /my/ posts shows how easy
that is for anyone.

> Actually, that's not entirely fair to Anton Ertl, who
> is more reasonable than some representatives of
> that viewpoint.

For almost any viewpoint, there is always someone more extreme!

>
> It's a viewpoint to which I'm not altogether
> unsympathetic, since I see no need to spoil C
> by turning it into C++ when we already have
> C++.
>

One thing that annoys me - and many others - about this whole "compilers
should do what I say, and gcc is evil" attitude is that there is no
doubt there are /real/ issues with C, and /real/ issues with gcc (and
other toolchains). There are situations where design decisions have
been made that give only marginal benefit to careful, knowledgeable and
experienced developers but significantly increase the risk for the
careless or the less knowledgeable. There are situations where
different (stronger) semantics would be useful in the language. There
are points where compilers like gcc provide such features through
extensions (pragmas, flags, attributes, etc.), but there is no standard
or portable solution.

But these points are typically drowned in a soup of obsessions about how
C used to be different (meaning "better"), or how gcc is evil in how it
handles undefined behaviour (despite being pretty much the only compiler
giving you an option to choose semantics for integer overflow behaviour
or cross-type pointer accesses).

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.

The problem is not accessing memory through a cast pointer.
It is that according to C's rules for TBAA Typed Based Alias Analysis
the optimizer is not required to recognize that accesses through
different pointer types may be to the same memory location.
(Assuming the worst case would effectively eliminate most register
caching as every write could byte overlap and change everything.)

struct X
{ int x1;
int x2;
}

struct Y
{ int y1;
int y2;
}

int tmpY;
struct myX, *xP = &myX;
struct *yP = (struct Y*)xP;

xP->x1 = 3;
tmpY = yP->y1;
xP->x1 = 4;

The optimizer is not required to recognize that xP->x1 and yP->y1
are the same memory location because xP and yP are different types.
It could optimize away the store of 3 leaving yP->y1 uninitialized
and load garbage into tmpY and only later store 4 to xP->x1.

Unfortunately this is exactly the kind of things that OS and
similarly styled applications do: overlay memory with different
data structure, or cast between pointers to interior of structs
back to the containing structs.

For example, what such code does is things like cast a pointer to
an allocated object back to its parent container by masking the
low order bits because, by design, the parent container is always
page aligned. For example this could be used by a slab allocator:

#define PAGE_OFFSET_MASK (0xFFF)
containerPtr =
(struct Container_t*)((uintptr_t)objectPtr & (~PAGE_OFFSET_MASK));

There are lots of other examples, such as subtracting a field offset
from a pointer to a field in a struct to get back to the containing struct.
A binary buddy allocator can do XOR's on various address bits
to locate the buddy object.

However under strict C TBAA aliasing rules the optimizer is not required
to know that objectPtr and containerPtr refer to the same memory.

By the way, this is not an error prone programming style.
This can be done quite reliably because the code style which VMS and
WNT use, and which I sometimes use, is to put a unique data type
validity check markers as the first field of each major data structure.
The marker is set at struct initialization and cleared at finalization.
Also putting such pointer conversions in macros pretty much
eliminates errors.

containerPtr = ContainerFromObject (objectPtr);
TypMarkCheck (containerPtr->TypMark == TypMark_Container);

If a pointer cast gets buggered up, it immediately crashes.
Also catches stale references to deleted objects.

On 13/10/2021 14:35, Thomas Koenig wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> AFAIAA none of flags used in compiling programs like the Linux
>> kernel render the implementation non-conforming, and if the
>> implementation is conforming then by definition the language
>> being compiled is C.
>
> One of the weaker points of the C standard.
>
> I can with some justification claim that gfortran is a conforming
> C implementation. Let's test:
>
> $ cat hello.c
> #include <stdio.h>
>
> int main()
> {
> printf ("Hello, world!\n");
> return 0;
> }
> $ gfortran hello.c
> $ ./a.out
> Hello, world!
>
> Yet, gfortran also compiles this:
>
> $ cat hello.f
> PROGRAMME MAIN
> WRITE (*,1000)
> 1000 FORMAT (11HHELLO WORLD)
> END
> $ gfortran hello.f
> $ ./a.out
> HELLO WORLD
> $
>
> So, is the program hello.f C?
>

I heard that the determined Real Programmer can write FORTRAN in any
language, so perhaps hello.c is FORTRAN?

>> I'm fine with a C standard that says that which boolean is returned is
>> undefined (and I'm even willing to let it be not-quite-pure and not
>> always return the same value when called with the same two pointers),
>> but firing rockets is a bit excessive here, don't you think?
> I'm not really very keen on this "give me an answer, I don't care if it
> is right" idea.

I can agree in general, but when the alternative is "may fire rockets",
I find this option quite attractive.

> I am much happier, when possible, to get "I refuse to
> compile this program because you've made a mistake".

I do too, but it's not the way C was designed and is usually
implemented. But, yes, I'd be happier with a variant where UB either
causes a compilation error (when detected at compile time) or causes the
program to stops execution with an error at run-time.

Such a version of C would probably raise a fair number of eyebrows, tho,
since a lot of code would stop working ;-)

> Compilers don't usually fire rockets - contrary to what some people seem
> to imagine, they don't go out of their way to cause trouble when someone
> makes a mistake in their code.

They don't, indeed, but compilers routinely optimize the code under the
assumption that UB cannot happen. This can result in arbitrarily
bad outcomes.

>> There should also be a "quality of implementation" note stating that on
>> systems where it makes sense, `<` should be pure and obey the expect
>> rules like anti-symmetry etc...
> Why? When is it useful?

In Emacs we use it for example when sorting some objects where
pointer-comparison is used for objects which are otherwise
structurally equal.

This makes the result "stable" (the result may be different in
different executions of Emacs but they'll be identical in two different
calls in the same Emacs session).

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6830

Stefan

On 10/12/2021 7:57 PM, Branimir Maksimovic wrote:
> On 2021-10-12, BGB <cr88192@gmail.com> wrote:
>> On 10/12/2021 4:46 PM, MitchAlsup wrote:
>>> On Tuesday, October 12, 2021 at 1:18:42 PM UTC-5, BGB wrote:
>>>> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>>
>>>>>> Victor Yodaiken <victor....@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.
>>> <
>>> During my career I went to so many meetings about memory referencing
>>> and how this/that machine was good/bad, I stabilized my thinking about
>>> referencing memory into the camp of::
>>> a) memory is Inherently misaligned,
>>> b) you can't do anything about making that go away,
>>> c) you can make the HW capable of delivering near zero overhead to misalignment;
>>> THAT: you should simply design the machine as inherently misaligned.
>>> <
>>> And at this point, If you create/cast a pointer to something, you CAN
>>> dereference it. Whether it is profitable or not is up to the programmer.
>>
>> Granted.
>>
>> Nearly all access in BJX2 is misaligned-safe by default, with a few
>> partial exceptions which don't significantly effect code generation for
>> the most part (mostly effecting the handling of constant displacements
>> and MOV.X and similar).
>>
>>
>>>>
>>>> Requiring something like, say, using "memcpy()" to mash bits from one
>>>> format to another and hoping the compiler is smart and reliable enough
>>>> to make this "not suck" is a crap solution, IMHO.
>>> <
>>> Requiring a trip through memory to get from FP-register to int-register
>>> is similarly stupid !! {Note: my restrained hand, here.}
>>> <
>>> SIMD-register to int-register or FP-register probably remains necessary--
>>> because SIMD is not the same (or similar size) as int or FP.
>>
>> Granted, but these is no way to express this in (standard) C.
>> There are compiler intrinsics for this case in BGBCC.
>>
>> In effect, it is mostly how much extra overhead one wants to impose on
>> transferring a value from one register to another.
>>
>> Meanwhile, the ASM programmer can make use of both integer and FP
>> operations using GPRs.
>>
>>
>> This was also a partial incentive for building dynamic typing into
>> BGBCC, besides it being needed for my BS2 language: the compiler can do
>> all this a lot more efficiently than leaving it up to user code.
>>
>> In theory, it could also allows for a fairly lightweight JavaScript FFI
>> if C code can more directly access JS data and environments without
>> needing an awkward and convoluted wrapper API.
>>
>> Even if, yeah, one probably doesn't want to use dynamic typing when
>> avoidable for normal code, in my tests, the performance overhead of
>> using dynamic typing is actually surprisingly modest though (as-in,
>> "doesn't ruin performance quite as bad as one might intuitively expect
>> given it turns pretty much every operator into a runtime call").
>>
>>
>> Full hardware support is unlikely, but it is possible that a few special
>> cases can be useful, such as a combined "Morton shuffle and Logical
>> Shift Right" operator and similar, or a "Table-Switch with Unsigned
>> Saturate".
>>
>> Say:
>> ADD R4, -64, R3
>> BRUSS.L 180, R3
>> BRA4B .L_case_64
>> BRA4B .L_case_65
>> ...
>> BRA4B .L_case_242
>> BRA4B .L_case_243
>> BRA4B .L_case_default
>>
> Isnt it much better just to index into table
> and jump?
>

One still needs to make sure the index is in range...

But, yeah, in theory one could do this instead:
ADD R4, -64, R3
CMPHI 179, R3
BT .L_case_default
MOV jmptab, R2 // LEA.B (PC, disp), R2
MOV.W (R2, R3), R3
BRA R3
.jmptab:
.word .L_case_64 - .jmptab
.word .L_case_65 - .jmptab
...

But, in terms of clock-cycles, this will not win on my current core in
terms of clock cycles. May or may not save in terms of space.

Note that the second (constant) branch is, effectively, always
predictable. So, there isn't a large cost difference in terms of the
branch itself (slightly more expensive branch, but saves in terms of not
needing to do a LEA and memory load here).

On Wednesday, October 13, 2021 at 9:57:15 AM UTC-5, David Brown wrote:

>One thing that annoys me - and many others - about this whole "compilers
>should do what I say, and gcc is evil" attitude is that there is no

That's not a helpful or illuminating frame for any discussion - caricature doesn't get anywhere.

I think I understand why gcc/clang/ISO have evolved the way they did, I just disagree
with the basic design methodology. And I can do that without imagining K&R C was anywhere near
perfect.
I don't think people who disagree with me need to be evil. I could be wrong. They might be wrong. They might have different
objectives than I do. For example, I want a language to be able to write OS/Embedded/Cryptography and
some other applications in, but I don't particularly care if C competes with Fortran in HPC or whether some
optimization can shave 2% off a FAANG data center power bill for a massive C++ application without needing a rewrite. I would far prefer that FAANG companies
hire more C programmers to rewrite their code than that they push through a shaky optimization.
Other people can value those goals differently without me thinking that they are evil or stupid. In fact, goals can even change over time: we have
much more reason to worry about security now than we did in 1990 and we have much better tools to improve reliability.

The paper really focuses on the example of alias optimizations and Dennis Ritchie's strong - and prescient warnings. Again,
I don't have to believe that Ritchie was always right about everything to consider him one of the most brilliant CS researchers/programmers
and to find his arguments on this issue strong. And I don't even have to oppose all alias analysis - in fact, I think, the type based approach
taken by ISO reduces the expressive range of the language, creates complexity and murky semantics, AND leaves a lot of alias based
optimization on the table. And part of the reason is because sound alias analysis is much *harder* for compilers than alias assumptions.

>But these points are typically drowned in a soup of obsessions about how
> C used to be different (meaning "better"), or how gcc is evil in how it

That's you, not in anything I have seen from anyone serious.

Since you bring it up, for me the way C originally handled integer overflow was sloppy and sometimes dangerous - it was
an engineering tradeoff made to make fast code and simple compilation. BUT the ISO-C approach is mathematically
incoherent and even more dangerous - because semantics is unpredictable. Ironically, as C compilers muddied int arithmetic, processors
became much better about native signed arithmetic. Mod 2^k 2s complement, which is native on
the vast majority of modern processors is mathematically coherent even if it is hard to work with. But what we have in ISO C makes
arithmetic depend on vagaries of the optimizer and produces paradoxes. I don't think that is satisfactory. Feel free to disagree.

On Tue, 12 Oct 2021 14:31:42 -0500, BGB <cr88192@gmail.com> wrote:

>On 10/12/2021 12:31 PM, George Neuner wrote:
>
>> Actually, many semispace (moving) collectors are /much/ faster than
>> BDW which is a mark/sweep system.
>
>It depends. On targets which suffer from poor memory bandwidth, then
>mark/sweep is generally preferable.
>
>Compacting mostly makes more sense on machines with fast memory but slow
>computation (uncommon), rather than machines with fast computation but
>slower memory (more common).

Compacting conserves address space ... which still is important even
with 64 bits when you consider the contortions the system must go
through to map virtual addresses to real memory.

It is almost always advantageous to keep the /live/ object address
space as small as possible.

>Either way, still generally want precise GC rather than conservative GC,
>which means the compiler needs to be involved in the process.

No argument.

>Personally I don't feel that precise GC is entirely excluded from being
>doable in C, though whether or not doing so would be "worthwhile" is a
>bigger issue.

It's not doable without compiler assistance (or some kind of tagged
memory). Precise collction requires that the GC be able to positively
distinguish actual pointers from non-pointer values that happen to
resemble pointers.

>> Compilers for GC'd languages make sure that pointers can be located
>> definitively, and that head pointers to heap blocks are never lost or
>> obscured. In a well designed system, that means never having to look
>> at any non-pointer values.
>>
>
>Yeah, this is a major advantage to precise GC.
>
>A semi-precise strategy can also work, where in many locations pointers
>are marked by the compiler, object layouts specified, ...

This is the major stumbling block.

>But, then the system falls back to conservative collection for cases
>which fall outside the scope of the precise collector.

There are, in fact, GC for C++ which abuse the compiler's object
schemas to locate pointers. But for the most part, it only works on
the heap ... what is needed is a similar method which defines stack
frame formats so as to locate pointers on the stack.

Then "conservative" would only be necessary for handling unions.

>Absent language extensions, will require the compiler to perform some
>level of "arcane trickery" with malloc calls and similar, and the GC
>would effectively fall apart for user-managed allocators.

Right.

>Indirectly, this means trusting that the C library provided "malloc()"
>doesn't suck, but this issue (hit or miss quality, and by itself lacking
>features often needed by the applications) is why so many custom-rolled
>allocators exist in the first place.

>IME, the sweep process tends to be much faster than the mark process
>though, since it may only need to touch a tiny fraction as much memory.

No. If sweep is touching less than mark, you're either doing something
very wrong, or you're running it far more often than would be
considered "normal".

Typically a mark/* system is triggered when allocation fails for no
suitable blocks available. Obviously it also could be run
deliberately by the programmer, but that partly defeats the "auto" in
"automatic memory management" [ http://gchandbook.org/ ].

You can separate the marking flags so as not to have to /write/ to
objects during marking, but you must scan every live object.

Sweep has to touch, at minimum, every dead object. If you are using
the GC normally, there almost always will be far more dead objects
than live objects. [Obviously there are programs which are counter
examples, but they are the exception, not the rule.]

>One may find that a moving collector effectively needs to touch more
>than twice as many cache lines as a pure mark phase.

Of course ... but you also have to consider the sweep (or compact)
phase when comparing the methods. Semispace copying reads and writes
every live object once, but it doesn't touch dead objects at all.

Again, the assumption is that the live set is much smaller than the
dead set. Which IS the case for most programs in GC'd languages.

George

On 10/13/2021 1:26 PM, George Neuner wrote:
> On Tue, 12 Oct 2021 14:31:42 -0500, BGB <cr88192@gmail.com> wrote:
>
>> On 10/12/2021 12:31 PM, George Neuner wrote:
>>
>>> Actually, many semispace (moving) collectors are /much/ faster than
>>> BDW which is a mark/sweep system.
>>
>> It depends. On targets which suffer from poor memory bandwidth, then
>> mark/sweep is generally preferable.
>>
>> Compacting mostly makes more sense on machines with fast memory but slow
>> computation (uncommon), rather than machines with fast computation but
>> slower memory (more common).
>
> Compacting conserves address space ... which still is important even
> with 64 bits when you consider the contortions the system must go
> through to map virtual addresses to real memory.
>
> It is almost always advantageous to keep the /live/ object address
> space as small as possible.
>

Possible, though considering that the heap already tends to remain
relatively small and compact relative to the greater address space,
compacting is unlikely to make much difference at this scale.

The heap tends to expand incrementally, rather than being spread in
small pieces across the vastness of the address space.

ASLR may come into play to some extent, but isn't likely to matter much
unless the GC is also simultaneously allocating and freeing regions of
virtual memory as part of its GC process (would likely a bit more of an
issue for performance than anything due to range fragmentation in the
page tables).

>
>> Either way, still generally want precise GC rather than conservative GC,
>> which means the compiler needs to be involved in the process.
>
> No argument.
>
>> Personally I don't feel that precise GC is entirely excluded from being
>> doable in C, though whether or not doing so would be "worthwhile" is a
>> bigger issue.
>
> It's not doable without compiler assistance (or some kind of tagged
> memory). Precise collction requires that the GC be able to positively
> distinguish actual pointers from non-pointer values that happen to
> resemble pointers.
>

I am assuming a case here where a lot of the GC support machinery is
built into the C compiler.

>
>
>>> Compilers for GC'd languages make sure that pointers can be located
>>> definitively, and that head pointers to heap blocks are never lost or
>>> obscured. In a well designed system, that means never having to look
>>> at any non-pointer values.
>>>
>>
>> Yeah, this is a major advantage to precise GC.
>>
>> A semi-precise strategy can also work, where in many locations pointers
>> are marked by the compiler, object layouts specified, ...
>
> This is the major stumbling block.
>
>> But, then the system falls back to conservative collection for cases
>> which fall outside the scope of the precise collector.
>
> There are, in fact, GC for C++ which abuse the compiler's object
> schemas to locate pointers. But for the most part, it only works on
> the heap ... what is needed is a similar method which defines stack
> frame formats so as to locate pointers on the stack.
>
> Then "conservative" would only be necessary for handling unions.
>

Yeah. I am assuming also that the compiler preserves enough metadata to
determine the location of stack pointers, layout of stack frames, ...

This is sort of related to the existing issues with things like
implementing exception unwinding. At least with ELF, a subset of DWARF
metadata is used for a lot of this.

>
>> Absent language extensions, will require the compiler to perform some
>> level of "arcane trickery" with malloc calls and similar, and the GC
>> would effectively fall apart for user-managed allocators.
>
> Right.
>
>> Indirectly, this means trusting that the C library provided "malloc()"
>> doesn't suck, but this issue (hit or miss quality, and by itself lacking
>> features often needed by the applications) is why so many custom-rolled
>> allocators exist in the first place.
>
>
>> IME, the sweep process tends to be much faster than the mark process
>> though, since it may only need to touch a tiny fraction as much memory.
>
> No. If sweep is touching less than mark, you're either doing something
> very wrong, or you're running it far more often than would be
> considered "normal".
>
> Typically a mark/* system is triggered when allocation fails for no
> suitable blocks available. Obviously it also could be run
> deliberately by the programmer, but that partly defeats the "auto" in
> "automatic memory management" [ http://gchandbook.org/ ].
>
> You can separate the marking flags so as not to have to /write/ to
> objects during marking, but you must scan every live object.
>
> Sweep has to touch, at minimum, every dead object. If you are using
> the GC normally, there almost always will be far more dead objects
> than live objects. [Obviously there are programs which are counter
> examples, but they are the exception, not the rule.]
>

Mark has to touch nearly every byte of every live object.
Sweep only needs to touch object headers and/or cell bitmaps.

Actual object count is mostly irrelevant in this case, rather it is how
many cache lines one needs to touch.

This is more so in an allocator design where the object allocation
structures (object headers and cell bitmaps) are stored in a separate
location from the actual data-storage memory for the objects.

Say, for sake of argument:
Heap is mostly 4K objects, and 10% live, and 1M objects;
Header array is ~ 16B per object;
Mark needs to touch ~ 400MB (10% of 1M*4K);
Sweep needs to touch ~ 16MB (1M*16).

It is a little closer with cell bitmaps though.
Heap is mostly 256B objects, and 10% live, and 1M objects;
Cell bitmap is 3.125% constant-space;
Mark touches ~ 25MB;
Sweep touches ~ 8MB.

Granted, this does ignore things like running destructors, but this can
mostly be ignored.

>
>> One may find that a moving collector effectively needs to touch more
>> than twice as many cache lines as a pure mark phase.
>
> Of course ... but you also have to consider the sweep (or compact)
> phase when comparing the methods. Semispace copying reads and writes
> every live object once, but it doesn't touch dead objects at all.
>
> Again, the assumption is that the live set is much smaller than the
> dead set. Which IS the case for most programs in GC'd languages.
>

Granted, I assumed here a 10% heuristic.

(
Decides to leave off a thing where trying to justify the 10% heuristic
turned into a long tangent basically going over my life history. Not
sure how many people here would actually care about any of this anyways.
)

On 13 Oct 2021, Branimir Maksimovic wrote
(in article <_ox9J.87698$ol1.33401@fx42.iad>):

> On 2021-10-13, Stephen Fuld<sfuld@alumni.cmu.edu.invalid> wrote:
> > On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
> > > On 2021-10-13, Stephen Fuld<sfuld@alumni.cmu.edu.invalid> wrote:
> > > > To me, the big advantage of Ada (it's a woman's name, not an acronym -
> > > > hence not all caps) is that its syntax makes it easier to write correct
> > > > programs, and harder, though of course not impossible, to make the kind
> > > > of errors this thread has been talking about.
> > > >
> > > > But others here are far more qualified to discuss this than I am.
> > > OK, I'll try it, it, but on macOS I can't have compiler, let alone
> > > IDE support :P
> >
> > Again, others are more qualified than I am to comment, but it appears
> > that GNAT (GNU Ada compiler) is available on MacOS.
>
> Yes, but is only for x86, does not builds for my M1.

Does GNAT and / or its x86 object programs not run under Rosetta 2?

I ask as someone who has used Ada on Macs for more than a
quarter of a century, but who does not own an M1 Mac as yet.

I'd really like to know whether my projects run on M1 as they are.

--
Bill Findlay

On 2021-10-13, Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
> On 13 Oct 2021, Branimir Maksimovic wrote
> (in article <_ox9J.87698$ol1.33401@fx42.iad>):
>
>> On 2021-10-13, Stephen Fuld<sfuld@alumni.cmu.edu.invalid> wrote:
>> > On 10/12/2021 7:21 PM, Branimir Maksimovic wrote:
>> > > On 2021-10-13, Stephen Fuld<sfuld@alumni.cmu.edu.invalid> wrote:
>> > > > To me, the big advantage of Ada (it's a woman's name, not an acronym -
>> > > > hence not all caps) is that its syntax makes it easier to write correct
>> > > > programs, and harder, though of course not impossible, to make the kind
>> > > > of errors this thread has been talking about.
>> > > >
>> > > > But others here are far more qualified to discuss this than I am.
>> > > OK, I'll try it, it, but on macOS I can't have compiler, let alone
>> > > IDE support :P
>> >
>> > Again, others are more qualified than I am to comment, but it appears
>> > that GNAT (GNU Ada compiler) is available on MacOS.
>>
>> Yes, but is only for x86, does not builds for my M1.
>
> Does GNAT and / or its x86 object programs not run under Rosetta 2?
I'll Oh, try. Rosseta perhaps works.

> I ask as someone who has used Ada on Macs for more than a
> quarter of a century, but who does not own an M1 Mac as yet.
>
> I'd really like to know whether my projects run on M1 as they are.
>
OK, I'll try rosetta but download link does not works.
libre.adacore.com was down :(

--

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

According to David Brown <david.brown@hesbynett.no>:
>> I'm not getting the impression you've not done a lot of programming in assemblers
>> with strong macro languages. Someone else mentioned PDP-10 MACRO, but take a
>> look at HLASM ...

>This kind of thing is stretching the definition of what /I/ would call a
>"macro". I think "High Level Assembler" is probably more accurate.

Its predecessor was called Assembler F, with a macro language not a whole
lot less powerful.

>However, while this kind of thing makes it /hard/ to determine exactly
>what machine code you get in the end, it is still fully determined by
>the source code alone (including the definitions of the macros ...

That is literally true, but in practice everyone uses large macro libraries
provided by the vendor(s). Those libraries have been updated over the decades,
and I am sure there are cases where the code from one version wasn't the same
as the code from another version.

I realize this is largely a theological argument about where "macro" ends and
something else begins, but for fifty years we have had assemblers with macro
languages that approach Turing completeness.

For example, look at the example on page 33 of the PDP-6 macro assembler manual. It shows a macro
to compute the length of a vector which on the first call generates a callable routine to do the
calculation and a subroutine call to it, then redefines itself to generate just the subroutine call
on subsequent macro calls:

http://bitsavers.org/pdf/dec/pdp6/DEC-6-0-TP-MAC-LM-FP-ACT01_MACRO-6_Assembly_Language_Feb65.pdf

This was published in 1965.
--
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 2021-10-14, John Levine <johnl@taugh.com> wrote:
> According to David Brown <david.brown@hesbynett.no>:
>>> I'm not getting the impression you've not done a lot of programming in assemblers
>>> with strong macro languages. Someone else mentioned PDP-10 MACRO, but take a
>>> look at HLASM ...
>
>>This kind of thing is stretching the definition of what /I/ would call a
>>"macro". I think "High Level Assembler" is probably more accurate.
>
> Its predecessor was called Assembler F, with a macro language not a whole
> lot less powerful.
>
>>However, while this kind of thing makes it /hard/ to determine exactly
>>what machine code you get in the end, it is still fully determined by
>>the source code alone (including the definitions of the macros ...
>
> That is literally true, but in practice everyone uses large macro libraries
> provided by the vendor(s). Those libraries have been updated over the decades,
> and I am sure there are cases where the code from one version wasn't the same
> as the code from another version.
>
> I realize this is largely a theological argument about where "macro" ends and
> something else begins, but for fifty years we have had assemblers with macro
> languages that approach Turing completeness.
>
> For example, look at the example on page 33 of the PDP-6 macro assembler manual. It shows a macro
> to compute the length of a vector which on the first call generates a callable routine to do the
> calculation and a subroutine call to it, then redefines itself to generate just the subroutine call
> on subsequent macro calls:
>
> http://bitsavers.org/pdf/dec/pdp6/DEC-6-0-TP-MAC-LM-FP-ACT01_MACRO-6_Assembly_Language_Feb65.pdf
>
> This was published in 1965.
please take a look: https://flatassembler.net/fasmg.jg8x.zip
I think most advanced asssembler today, as it is
really not assembler, but macro compiler, that uses
macros to generate binary code for any CPU :P
I am plannning to translate it to aarch64 :P

--

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

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

> The paper really focuses on the example of alias optimizations
> and Dennis Ritchie's strong - and prescient warnings.

Dennis Ritchie was warning about a specific feature which did
not make it into the language.

[...]

> Again, I don't have to believe that Ritchie was always right
> about everything to consider him one of the most brilliant CS
> researchers/programmers and to find his arguments on this issue
> strong. And I don't even have to oppose all alias analysis -
> in fact, I think, the type based approach taken by ISO reduces
> the expressive range of the language, creates complexity and
> murky semantics, AND leaves a lot of alias based optimization on
> the table.

One of the design faults of C is the overuse of pointers,
specifically for array access (including pointer arithmetic),
dynamic memory allocation and for argument passing. While a
good design decision for the 1970s with limited resources for a
compiler, the very first high-level programming language, FORTRAN,
had already handled parts of this better.

Now, consider:

float *fp;
int *fp;
float a;

/* ... */

*fp = something;
*ip = something_else;
printf ("%f", *fp);

Assume that the value of *fp is held in a register. Should the
store to *ip make a reload of fp necessary before the printf?

> And part of the reason is because sound alias analysis is much
> *harder* for compilers than alias assumptions.

Which is why I like the Fortran model much better. In Fortran,

- if you have overlapping dummy arguments, you cannot store
a value through one and access it through another one
(which is rarely checked, unfortunately)

- variables which can be a target of a pointer must be
marked TARGET

- you have allocatable variables (which are automatically
deallocated when they go out of scope), which are not
TARGETs and which cannot alias anything else

- Pointers can also point to multi-dimensional arrays

(and teaching the somewhat C-centric gcc about optimizations
possible according to the Fortran language definition is an
ongoing process).

> Since you bring it up, for me the way C originally handled
> integer overflow was sloppy and sometimes dangerous - it was an
> engineering tradeoff made to make fast code and simple compilation.
> BUT the ISO-C approach is mathematically incoherent and even more
> dangerous - because semantics is unpredictable.

Signed integer overflow is an error, period (the same in
Fortran as in C).

> Ironically, as C compilers muddied int arithmetic, processors
> became much better about native signed arithmetic. Mod 2^k 2s
> complement, which is native on the vast majority of modern
> processors is mathematically coherent even if it is hard to
> work with.

Very hard, and a source of errors...

> But what we have in ISO C makes arithmetic depend on vagaries
> of the optimizer and produces paradoxes.

Ah, no. It means that an erroneous program gets random results,
which is not surprising. Would you also like to prosrcribe results
for array overruns? Ada does so, and both it and Fortran are
better languages if you want to have a lower error rate than for C.

You will not have much luck changing C.

On 2021-10-14, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>
>> The paper really focuses on the example of alias optimizations
>> and Dennis Ritchie's strong - and prescient warnings.
>
> Dennis Ritchie was warning about a specific feature which did
> not make it into the language.
>
> [...]
>
>> Again, I don't have to believe that Ritchie was always right
>> about everything to consider him one of the most brilliant CS
>> researchers/programmers and to find his arguments on this issue
>> strong. And I don't even have to oppose all alias analysis -
>> in fact, I think, the type based approach taken by ISO reduces
>> the expressive range of the language, creates complexity and
>> murky semantics, AND leaves a lot of alias based optimization on
>> the table.
>
> One of the design faults of C is the overuse of pointers,
> specifically for array access (including pointer arithmetic),
> dynamic memory allocation and for argument passing. While a
> good design decision for the 1970s with limited resources for a
> compiler, the very first high-level programming language, FORTRAN,
> had already handled parts of this better.
>
> Now, consider:
>
> float *fp;
> int *fp;
> float a;
>
> /* ... */
>
> *fp = something;
> *ip = something_else;
> printf ("%f", *fp);
>
> Assume that the value of *fp is held in a register. Should the
> store to *ip make a reload of fp necessary before the printf?
>
>> And part of the reason is because sound alias analysis is much
>> *harder* for compilers than alias assumptions.
>
> Which is why I like the Fortran model much better. In Fortran,
>
> - if you have overlapping dummy arguments, you cannot store
> a value through one and access it through another one
> (which is rarely checked, unfortunately)
>
> - variables which can be a target of a pointer must be
> marked TARGET
>
> - you have allocatable variables (which are automatically
> deallocated when they go out of scope), which are not
> TARGETs and which cannot alias anything else
>
> - Pointers can also point to multi-dimensional arrays
>
> (and teaching the somewhat C-centric gcc about optimizations
> possible according to the Fortran language definition is an
> ongoing process).
>
>> Since you bring it up, for me the way C originally handled
>> integer overflow was sloppy and sometimes dangerous - it was an
>> engineering tradeoff made to make fast code and simple compilation.
>> BUT the ISO-C approach is mathematically incoherent and even more
>> dangerous - because semantics is unpredictable.
>
> Signed integer overflow is an error, period (the same in
> Fortran as in C).
>
>> Ironically, as C compilers muddied int arithmetic, processors
>> became much better about native signed arithmetic. Mod 2^k 2s
>> complement, which is native on the vast majority of modern
>> processors is mathematically coherent even if it is hard to
>> work with.
>
> Very hard, and a source of errors...
>
>> But what we have in ISO C makes arithmetic depend on vagaries
>> of the optimizer and produces paradoxes.
>
> Ah, no. It means that an erroneous program gets random results,
> which is not surprising. Would you also like to prosrcribe results
> for array overruns? Ada does so, and both it and Fortran are
> better languages if you want to have a lower error rate than for C.
>
> You will not have much luck changing C.

Fortran is pre structured era, spagetti code. Good for
arrays, not mutch for anything else :P
Good luck with network code or parsing with FORTRAN :P

--

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

On 2021-10-14 14:05, Branimir Maksimovic wrote:
> On 2021-10-14, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:

...

>>> And part of the reason is because sound alias analysis is much
>>> *harder* for compilers than alias assumptions.
>>
>> Which is why I like the Fortran model much better. In Fortran,
>>
>> - if you have overlapping dummy arguments, you cannot store
>> a value through one and access it through another one
>> (which is rarely checked, unfortunately)
>>
>> - variables which can be a target of a pointer must be
>> marked TARGET
>>
>> - you have allocatable variables (which are automatically
>> deallocated when they go out of scope), which are not
>> TARGETs and which cannot alias anything else
>>
>> - Pointers can also point to multi-dimensional arrays
>>
>> (and teaching the somewhat C-centric gcc about optimizations
>> possible according to the Fortran language definition is an
>> ongoing process).
>>
>>> Since you bring it up, for me the way C originally handled
>>> integer overflow was sloppy and sometimes dangerous - it was an
>>> engineering tradeoff made to make fast code and simple compilation.
>>> BUT the ISO-C approach is mathematically incoherent and even more
>>> dangerous - because semantics is unpredictable.
>>
>> Signed integer overflow is an error, period (the same in
>> Fortran as in C).
>>
>>> Ironically, as C compilers muddied int arithmetic, processors
>>> became much better about native signed arithmetic. Mod 2^k 2s
>>> complement, which is native on the vast majority of modern
>>> processors is mathematically coherent even if it is hard to
>>> work with.
>>
>> Very hard, and a source of errors...
>>
>>> But what we have in ISO C makes arithmetic depend on vagaries
>>> of the optimizer and produces paradoxes.
>>
>> Ah, no. It means that an erroneous program gets random results,
>> which is not surprising. Would you also like to prosrcribe results
>> for array overruns? Ada does so, and both it and Fortran are
>> better languages if you want to have a lower error rate than for C.
>>
>> You will not have much luck changing C.
>
> Fortran is pre structured era, spagetti code.

Fortran has evolved. Look at current Fortran, not at something from over
half a century ago.

Branimir Maksimovic <branimir.maksimovic@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

On Thursday, October 14, 2021 at 1:40:35 AM UTC-5, Thomas Koenig wrote:
> Victor Yodaiken schrieb:
> > The paper really focuses on the example of alias optimizations
> > and Dennis Ritchie's strong - and prescient warnings.
> Dennis Ritchie was warning about a specific feature which did
> not make it into the language.
>

His warning - including his discussion of Fortran which you might want to read, is generally applicable.

>
> One of the design faults of C is the overuse of pointers,
> specifically for array access (including pointer arithmetic),

If you don't like C and don't appreciate its design basis, then your opinion of
what optimizations are reasonable may not be as insightful as you believe.
C pointers are extremely useful for some applications. But certainly other approaches
have advantages in other applications.

>
> Now, consider:
>
> float *fp;
> int *fp;
> float a;
>
> /* ... */
>
> *fp = something;
> *ip = something_else;
> printf ("%f", *fp);
>
> Assume that the value of *fp is held in a register. Should the
> store to *ip make a reload of fp necessary before the printf?

This depends on whether the pointers point to the same object.

> > And part of the reason is because sound alias analysis is much
> > *harder* for compilers than alias assumptions.
> Which is why I like the Fortran model much better. In Fortran,
>

I am happy for you and I agree that Fortran is well suited to certain types
of applications.

> - if you have overlapping dummy arguments, you cannot store
> a value through one and access it through another one
> (which is rarely checked, unfortunately)

Indeed. And why is that?
If I had known about Fortran's issues with alias analysis, I might have even included in a 6 page paper a reference
to Fortran alias analysis -something like this:

" Fortran has similar problems with similar assumptions: "anything may happen:
the program may appear to run normally, or produce incorrect answers, or behave unpredictably." [24]."

> > Since you bring it up, for me the way C originally handled
> > integer overflow was sloppy and sometimes dangerous - it was an
> > engineering tradeoff made to make fast code and simple compilation.
> > BUT the ISO-C approach is mathematically incoherent and even more
> > dangerous - because semantics is unpredictable.
> Signed integer overflow is an error, period (the same in
> Fortran as in C).
> > Ironically, as C compilers muddied int arithmetic, processors
> > became much better about native signed arithmetic. Mod 2^k 2s
> > complement, which is native on the vast majority of modern
> > processors is mathematically coherent even if it is hard to
> > work with.
> Very hard, and a source of errors...

Programming is hard. Some languages have runtime to catch those errrors,
and even in some C compilers we have an option for ftrapv. But there are tradeoffs.
This is why Fortran uses floating point arithmetic even though it is a notorious source
of errors.

> > But what we have in ISO C makes arithmetic depend on vagaries
> > of the optimizer and produces paradoxes.
> Ah, no. It means that an erroneous program gets random results,

With modular arithmetic, or even saturating as you have on some processors, you do not
get random results. You may not get the results you expect if you think 4 byte or even 8 or 16 byte "ints"
can represent all of Z.

If you adopt the axiom that overflow is programming error, than you will conclude it is a programming error, but
that's not super illuminating.

> which is not surprising. Would you also like to prosrcribe results
> for array overruns?

Indeed I would.

>Ada does so, and both it and Fortran are
> better languages if you want to have a lower error rate than for C.
>

What's fascinating for me is how many people who consider C to be a botched language from
the start are so interested in insisting on their ideas for C semantics. C is useful for
some applications, less for others. We have different languages for a reason. Fortran is not inferior to
Haskell because it does not offer bignumbers as default. One would not want to write finite element analysis
programs in Haskell. Similarly, I would not want to attempt operating systems or cryptography coding in Fortran.
> You will not have much luck changing C.

Perhaps.

On 13/10/2021 19:05, Victor Yodaiken wrote:
> On Wednesday, October 13, 2021 at 9:57:15 AM UTC-5, David Brown
> wrote:
>
>
>> One thing that annoys me - and many others - about this whole
>> "compilers should do what I say, and gcc is evil" attitude is that
>> there is no
>
> That's not a helpful or illuminating frame for any discussion -
> caricature doesn't get anywhere.
>

That is not a caricature - it is close to a direct quotation of some
people's posts (Anton Ertl has directly and explicitly accused the gcc
developers of being evil, corrupt, focused solely on timings of specific
benchmarks with no regard for users, and coding according to the demands
of big corporation employers who want to break code written by others.
And he is not the only one who has written such things).

You did not say such things in your paper, and I think your posts in
this thread have shown a more moderate and considered viewpoint than the
impression I got from your paper. That is good - it is usually easier
to change things in small steps than with radically different ideas.

> I think I understand why gcc/clang/ISO have evolved the way they
> did, I just disagree with the basic design methodology. And I can do
> that without imagining K&R C was anywhere near perfect. I don't think
> people who disagree with me need to be evil. I could be wrong. They
> might be wrong. They might have different objectives than I do.

Sounds reasonable.

A challenge in the C world is that the use-cases for the language are so
wide in scope that it is impossible for one language to be ideal for
them all.

The standard has to provide the lowest common denominator - the most
vague version of the language, with the most undefined behaviours and
implementation-defined behaviours. It is then up to implementations to
tighten these details as appropriate, or offer options for additional
semantics.

But programmers have to understand that the C language is what is
described by the standards, and this is the default for compilers - if
the C standards don't say what happens when you do X, then neither does
the compiler. And if old versions of the standards (including the more
formal descriptions in the K&R books) didn't say what happens when you
do X, then it was /never/ part of the language. It doesn't matter if a
book used X in an example, or if some compiler happened to generate
particular code for X, or if you think it would make more sense if the
language defined the behaviour for X, or if some other program uses X in
its code.

It is rare that newer versions of the C standards remove semantics from
the language - take things that used to work in a particular way, and
change them or make them undefined. There have been a few examples -
removing implicit int, changing the type of some integer constants,
removing the flexibility of implementations to choose rounding modes for
division of negative integers. It is, IME, even rarer for C
implementations to explicitly guarantee behaviours beyond those required
by the C standards.

> For
> example, I want a language to be able to write
> OS/Embedded/Cryptography and some other applications in, but I don't
> particularly care if C competes with Fortran in HPC or whether some
> optimization can shave 2% off a FAANG data center power bill for a
> massive C++ application without needing a rewrite. I would far prefer
> that FAANG companies hire more C programmers to rewrite their code
> than that they push through a shaky optimization. Other people can
> value those goals differently without me thinking that they are evil
> or stupid. In fact, goals can even change over time: we have much
> more reason to worry about security now than we did in 1990 and we
> have much better tools to improve reliability.
>

Security is always a challenge. As far as I have seen, many of the
issues people have seen with C and security have been a result of not
thinking enough about the consequences and true meaning of their code,
or expecting too much without giving the compiler the right source. You
have to understand the concept of "observable behaviour". Writing zeros
to a local array variable before returning from a function is not
observable behaviour - compilers can skip it. Using /volatile/ writes
/is/ observable behaviour, and compilers won't skip it. Changing tools,
changing needs, changing processors - there's a reason people say
security is a process, not a product!

> The paper really focuses on the example of alias optimizations and
> Dennis Ritchie's strong - and prescient warnings. Again, I don't have
> to believe that Ritchie was always right about everything to consider
> him one of the most brilliant CS researchers/programmers and to find
> his arguments on this issue strong. And I don't even have to oppose
> all alias analysis - in fact, I think, the type based approach taken
> by ISO reduces the expressive range of the language, creates
> complexity and murky semantics, AND leaves a lot of alias based
> optimization on the table. And part of the reason is because sound
> alias analysis is much *harder* for compilers than alias
> assumptions.
>

Indeed alias analysis is a hard problem, and it is the subject of much
research.

>
>> But these points are typically drowned in a soup of obsessions
>> about how C used to be different (meaning "better"), or how gcc is
>> evil in how it
>
> That's you, not in anything I have seen from anyone serious.
>

I've seen such words and phrases used by people who /were/ being
serious. I am, however, glad to hear that it does not apply to you.

> Since you bring it up, for me the way C originally handled integer
> overflow was sloppy and sometimes dangerous - it was an engineering
> tradeoff made to make fast code and simple compilation. BUT the
> ISO-C approach is mathematically incoherent and even more dangerous -
> because semantics is unpredictable. Ironically, as C compilers
> muddied int arithmetic, processors became much better about native
> signed arithmetic. Mod 2^k 2s complement, which is native on the vast
> majority of modern processors is mathematically coherent even if it
> is hard to work with. But what we have in ISO C makes arithmetic
> depend on vagaries of the optimizer and produces paradoxes. I don't
> think that is satisfactory. Feel free to disagree.
>

I do disagree in the case of signed integer overflow. Well, obviously I
don't disagree that two's complement wrapping is consistent and
mathematically definable, but I disagree that it is a useful definition.
To me, wrapping overflow pretty much guarantees incorrect results - and
I don't find that useful, regardless of how consistent it is. I am
concerned with three things here - being sure the answer is correct,
having tools help me get correct code, and having efficient results.
These are all improved by making signed integer overflow undefined
behaviour. The compiler and language is not going to encourage me to
accept incorrect answers (taking a pile of 2 ^ 31 - 1 apples, putting
another apple on the pile, and getting -2 ^ 31 apples - it's just
silly). If a tool can spot an overflow at compile time, it can tell me
- and I can fix it immediately. I can enable run-time checking, and it
will tell me at run-time if there is an overflow. If overflow were
defined behaviour, compilers would have to treat it as correct - no
error, so no static or run-time error detection. And I like that the
compiler can use clear and intuitive mathematical rules for optimisation
- the same rules that make sense to me as a programmer, such as the fact
that adding a positive number to another number gives you a bigger
value. That's natural, obvious and sensible to me. (And as I am
low-level programmer used to embedded systems, and an electronics
designer - I know how all this is implemented.)

On 2021-10-13 08:38, Thomas Koenig wrote:
[...]
>
> AFAIK, there will be M1 support in gcc 12. Interestingly enough,
> it was the lack of a Fortran compiler which mostly drove demand
> for this port.

Well, getting there... Configure accepts it but the next level down
spits out:
*** Configuration aarch64-apple-darwin20.4.0 not supported

N.

Branimir Maksimovic wrote:
> On 2021-10-14, John Levine <johnl@taugh.com> wrote:
>> According to David Brown <david.brown@hesbynett.no>:
>>>> I'm not getting the impression you've not done a lot of programming in assemblers
>>>> with strong macro languages. Someone else mentioned PDP-10 MACRO, but take a
>>>> look at HLASM ...
>>> This kind of thing is stretching the definition of what /I/ would call a
>>> "macro". I think "High Level Assembler" is probably more accurate.
>> Its predecessor was called Assembler F, with a macro language not a whole
>> lot less powerful.
>>
>>> However, while this kind of thing makes it /hard/ to determine exactly
>>> what machine code you get in the end, it is still fully determined by
>>> the source code alone (including the definitions of the macros ...
>> That is literally true, but in practice everyone uses large macro libraries
>> provided by the vendor(s). Those libraries have been updated over the decades,
>> and I am sure there are cases where the code from one version wasn't the same
>> as the code from another version.
>>
>> I realize this is largely a theological argument about where "macro" ends and
>> something else begins, but for fifty years we have had assemblers with macro
>> languages that approach Turing completeness.
>>
>> For example, look at the example on page 33 of the PDP-6 macro assembler manual. It shows a macro
>> to compute the length of a vector which on the first call generates a callable routine to do the
>> calculation and a subroutine call to it, then redefines itself to generate just the subroutine call
>> on subsequent macro calls:
>>
>> http://bitsavers.org/pdf/dec/pdp6/DEC-6-0-TP-MAC-LM-FP-ACT01_MACRO-6_Assembly_Language_Feb65.pdf
>>
>> This was published in 1965.
> please take a look: https://flatassembler.net/fasmg.jg8x.zip
> I think most advanced asssembler today, as it is
> really not assembler, but macro compiler, that uses
> macros to generate binary code for any CPU :P
> I am plannning to translate it to aarch64 :P

DEC did something similar in the VAX to Alpha port.
They and customers had a lot of VAX macro and rather than rewrite it all
DEC built a Macro-32 front end for their standard compiler back end.
This is more than a simple translation as the compiler has to model
a 32-bit VAX, its register conventions, flags, etc.
Also the Alpha 21064 had no byte or word load-store instructions
(but that's an own-goal on DEC).

Porting OpenVMS from VAX to Alpha AXP, 1992
http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art7.pdf

They also did VAX to Alpha binary translators which treat the binary
instructions as source code. Later they used similar techniques
for x86 binaries on Alpha WinNT.

I have no idea how well all of this worked.
Like most complicated things, I would imagine "mostly".

On Thursday, October 14, 2021 at 4:42:08 PM UTC+3, victor....@gmail.com wrote:
> On Thursday, October 14, 2021 at 1:40:35 AM UTC-5, Thomas Koenig wrote:
> > Victor Yodaiken schrieb:
> > > The paper really focuses on the example of alias optimizations
> > > and Dennis Ritchie's strong - and prescient warnings.
> > Dennis Ritchie was warning about a specific feature which did
> > not make it into the language.
> >
> His warning - including his discussion of Fortran which you might want to read, is generally applicable.
> >
> > One of the design faults of C is the overuse of pointers,
> > specifically for array access (including pointer arithmetic),
> If you don't like C and don't appreciate its design basis, then your opinion of
> what optimizations are reasonable may not be as insightful as you believe.
> C pointers are extremely useful for some applications. But certainly other approaches
> have advantages in other applications.
> >
> > Now, consider:
> >
> > float *fp;
> > int *fp;
> > float a;
> >
> > /* ... */
> >
> > *fp = something;
> > *ip = something_else;
> > printf ("%f", *fp);
> >
> > Assume that the value of *fp is held in a register. Should the
> > store to *ip make a reload of fp necessary before the printf?
> This depends on whether the pointers point to the same object.
> > > And part of the reason is because sound alias analysis is much
> > > *harder* for compilers than alias assumptions.
> > Which is why I like the Fortran model much better. In Fortran,
> >
> I am happy for you and I agree that Fortran is well suited to certain types
> of applications.
> > - if you have overlapping dummy arguments, you cannot store
> > a value through one and access it through another one
> > (which is rarely checked, unfortunately)
> Indeed. And why is that?
> If I had known about Fortran's issues with alias analysis, I might have even included in a 6 page paper a reference
> to Fortran alias analysis -something like this:
>
> " Fortran has similar problems with similar assumptions: "anything may happen:
> the program may appear to run normally, or produce incorrect answers, or behave unpredictably." [24]."

I don't think that it would be correct.
Not that I know Fortran, but I had read enough of posts of Nick McLaren and of Thomas Koenig to get the idea.
Fortran rules are, on one hand less surprising (==more consistent) then those of Standard C, but on the other hand they limit expressiveness of the language.
In Fortran, every array parameter to function assumed to not overlap with any other parameter, even of the same type.
In practice, it means that in Fortran you can't write a single procedure that accept either overlapped and non-overlapped arguments.

To explain my self better,
In C you can write

void foo(int bar1[], int bar2[]) {
for (int i = 0; i < 5; ++i)
bar1[i] += bar2[i];
} An then call it like:
int x[6], y[5];
// initialization code ommited
foo(x, y);
foo(x, &x[1]);

Both calls have defined semantic.

In Fortran, for a second (overlapped) case you'll have to write a second variant of foo(), for example, like that:
void fooOverlapped(int bar[], int idx1, int idx2) {
for (int i = 0; i < 5; ++i)
bar1[i+idx1] += bar2[i+idx2];
}

> > > Since you bring it up, for me the way C originally handled
> > > integer overflow was sloppy and sometimes dangerous - it was an
> > > engineering tradeoff made to make fast code and simple compilation.
> > > BUT the ISO-C approach is mathematically incoherent and even more
> > > dangerous - because semantics is unpredictable.
> > Signed integer overflow is an error, period (the same in
> > Fortran as in C).
> > > Ironically, as C compilers muddied int arithmetic, processors
> > > became much better about native signed arithmetic. Mod 2^k 2s
> > > complement, which is native on the vast majority of modern
> > > processors is mathematically coherent even if it is hard to
> > > work with.
> > Very hard, and a source of errors...
> Programming is hard. Some languages have runtime to catch those errrors,
> and even in some C compilers we have an option for ftrapv. But there are tradeoffs.
> This is why Fortran uses floating point arithmetic even though it is a notorious source
> of errors.
> > > But what we have in ISO C makes arithmetic depend on vagaries
> > > of the optimizer and produces paradoxes.
> > Ah, no. It means that an erroneous program gets random results,
> With modular arithmetic, or even saturating as you have on some processors, you do not
> get random results. You may not get the results you expect if you think 4 byte or even 8 or 16 byte "ints"
> can represent all of Z.
>
> If you adopt the axiom that overflow is programming error, than you will conclude it is a programming error, but
> that's not super illuminating.
> > which is not surprising. Would you also like to prosrcribe results
> > for array overruns?
> Indeed I would.
> >Ada does so, and both it and Fortran are
> > better languages if you want to have a lower error rate than for C.
> >
> What's fascinating for me is how many people who consider C to be a botched language from
> the start are so interested in insisting on their ideas for C semantics. C is useful for
> some applications, less for others. We have different languages for a reason. Fortran is not inferior to
> Haskell because it does not offer bignumbers as default. One would not want to write finite element analysis
> programs in Haskell. Similarly, I would not want to attempt operating systems or cryptography coding in Fortran.
> > You will not have much luck changing C.
> Perhaps.

On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:

> The standard has to provide the lowest common denominator - the most
> vague version of the language, with the most undefined behaviours and
> implementation-defined behaviours. It is then up to implementations to
> tighten these details as appropriate, or offer options for additional
> semantics.
>

I disagree. Overuse of UB degrades the semantics of the language and reduces its
utility. The overhead in dealing with unpredictable unsound optimizations is a serious
drag on the utility of C.

> But programmers have to understand that the C language is what is
> described by the standards, and this is the default for compilers - if

Not necessarily true.

> the C standards don't say what happens when you do X, then neither does
> the compiler. And if old versions of the standards (including the more

Also not true. For example, GCC says that you can use unions for type puns (which I find
awkward) although the standard does not.

> formal descriptions in the K&R books) didn't say what happens when you
> do X, then it was /never/ part of the language. It doesn't matter if a
> book used X in an example, or if some compiler happened to generate
> particular code for X, or if you think it would make more sense if the
> language defined the behaviour for X, or if some other program uses X in
> its code.

The Standard is just a document written by a committee. It is not a mathematical theorem
or law of physics. It is written in ISO bureaucratese, not specified mathematically.
The standard itself is often vague and contradictory and standards
experts disagree about fundamental issues - see the memory study group "provenance" paper.
Even though type alias rules were put in to the standard
in 1989 (and then repeatedly patched as problems appeared), they represent a significant
break with K&R C and one the most programmers were perfectly able to ignore for
decades. They are still only partially and spottily implemented by the compilers.
When people ask for changes in the standard, they are not asking for
a flat earth or for 1+1=3.

>
> It is rare that newer versions of the C standards remove semantics from
> the language - take things that used to work in a particular way, and
> change them or make them undefined. There have been a few examples -
> removing implicit int, changing the type of some integer constants,
> removing the flexibility of implementations to choose rounding modes for
> division of negative integers. It is, IME, even rarer for C
> implementations to explicitly guarantee behaviours beyond those required
> by the C standards.

Consider "asm" which is mentioned once in the standard and has no semantics at
all attached to it. It is vital to a lot of C code and the compilers guarantee behaviors for
it. Not the only example, but important.

Or consider the poorly designed concurrency/threading methods introduced in C11 ( The original Bell Labs C paper explicitly call out
putting thread/concurrency semantics into the language as an error.) and then
made optional in C18 but in such a way that chunks of the standard are written under the assumption
that the implementation does support the addition. The whole concept
of "data race" depends on the threading extension, although it never made much sense in the first place, and
makes even less sense without the extension. And this language is used to justify changing the order
of computations in the compilers.

Or consider the TBAA example I had in the paper. The original attempt in C89 inadvertently made it
a violation of the rules to read or write to allocated objects at all or, more likely, were intended by a majority of the
committee to allow easy escape which made
TBAA nearly always inapplicable. This resulted in the invention of
the concept of effective type and additional mechanisms for that in c99 which are still not particularly
coherent.

> > Since you bring it up, for me the way C originally handled integer
> > overflow was sloppy and sometimes dangerous - it was an engineering
> > tradeoff made to make fast code and simple compilation. BUT the
> > ISO-C approach is mathematically incoherent and even more dangerous -
> > because semantics is unpredictable. Ironically, as C compilers
> > muddied int arithmetic, processors became much better about native
> > signed arithmetic. Mod 2^k 2s complement, which is native on the vast
> > majority of modern processors is mathematically coherent even if it
> > is hard to work with. But what we have in ISO C makes arithmetic
> > depend on vagaries of the optimizer and produces paradoxes. I don't
> > think that is satisfactory. Feel free to disagree.
> >
> I do disagree in the case of signed integer overflow. Well, obviously I
> don't disagree that two's complement wrapping is consistent and
> mathematically definable, but I disagree that it is a useful definition.
> To me, wrapping overflow pretty much guarantees incorrect results - and
> I don't find that useful, regardless of how consistent it is. I am
> concerned with three things here - being sure the answer is correct,
> having tools help me get correct code, and having efficient results.
> These are all improved by making signed integer overflow undefined
> behaviour. The compiler and language is not going to encourage me to
> accept incorrect answers (taking a pile of 2 ^ 31 - 1 apples, putting
> another apple on the pile, and getting -2 ^ 31 apples - it's just
> silly). If a tool can spot an overflow at compile time, it can tell me
> - and I can fix it immediately.

But that is not the behavior of modern compilers under the ISO-C standard.
Gcc will "optimize" "(a*b)/b " so if I have code

input a and b //as non-negative signed integers
c = (a*b)/b;

with -O0 I will get the 2s complement mod 2^k value
with -O3 (no warning), I will get "a"

but if my code is

c = (a*b);
c = c/b;

With the optimizer on, I can get either value, depending on how the code is structured.

Worse, in C18 there is NO WAY for the programmer to check.
If I write

//assuming a>0 b > 0
c= a*b;
if( c =< 0 )handle_overflow();

the -03 optimizer will silently delete my check. (c23 will supposedly have a very awkward non-idiomatic
way of doing the same check).

Many C programmers discovered this interpretation of the standard when their checks for
overflow were silently deleted and the programs had errors.
This is not serious behavior.

>I can enable run-time checking, and it
> will tell me at run-time if there is an overflow. If overflow were
> defined behaviour, compilers would have to treat it as correct - no
> error, so no static or run-time error detection. And I like that the
> compiler can use clear and intuitive mathematical rules for optimisation
> - the same rules that make sense to me as a programmer, such as the fact
> that adding a positive number to another number gives you a bigger
> value. That's natural, obvious and sensible to me. (And as I am
> low-level programmer used to embedded systems, and an electronics
> designer - I know how all this is implemented.)

It's not intuitive to me, because I know the pigeonhole principle which I used to teach to 18 year olds. Some languages
have bignums as basic integer types and this has a lot of advantages. C does not for good reasons too. C++ allows
for more convenient use of bignums, if that is what you want.