On 24/03/2024 16:45, Tim Rentsch wrote:
> The C standard means what the ISO C group thinks it means.
> They are the ultimate and sole authority. Any discussion about what
> the C standard requires that ignores that or pretends otherwise is
> a meaningless exercise.

An intentionalist.
But when a text has come about by a process of argument, negotation and
compromise and votes, is that postion so easy to defend as it might
appear to be for a simpler text?

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 24/03/2024 15:53, Michael S wrote:
> On Sat, 23 Mar 2024 21:21:58 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 23/03/2024 16:51, David Brown wrote:
>>> On 23/03/2024 12:26, bart wrote:
>>>> On 23/03/2024 07:26, James Kuyper wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>>> On 22/03/2024 17:14, James Kuyper wrote:
>>>>> [...]
>>>>>>> If you want to tell a system not only what a program must do,
>>>>>>> but also how it must do it, you need to use a lower-level
>>>>>>> language than C.
>>>>>>
>>>>>> Which one?
>>>>>
>>>>> That's up to you. The point is, C is NOT that language.
>>>>
>>>> I'm asking which /mainstream/ HLL is lower level than C. So
>>>> specifically ruling out assembly.
>>>>
>>>> If there is no such choice, then this is the problem: it has to be
>>>> C or nothing.
>>>
>>> How much of a problem is it, really?
>>>
>>> My field is probably the place where low level programming is most
>>> ubiquitous.  There are plenty of people who use assembly - for good
>>> reasons or for bad (or for reasons that some people think are good,
>>> other people think are bad).  C is the most common choice.
>>>
>>> Other languages used for small systems embedded programming include
>>> C++, Ada, Forth, BASIC, Pascal, Lua, and Micropython.  Forth is the
>>> only one that could be argued as lower-level or more "directly
>>> translated" than C.
>>
>> Well, Forth is certainly cruder than C (it's barely a language IMO).
>> But I don't remember seeing anything in it resembling a type system
>> that corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in
>> current hardware. (Imagine trying to create a precisely laid out
>> struct.)
>>
>> It is just too weird. I think I'd rather take my chances with C.
>>
>> > BASIC, ..., Lua, and Micropython.
>>
>> Hmm, I think my own scripting language is better at low level than
>> any of these. It supports those low-level types for a start. And I
>> can do stuff like this:
>>
>> println peek(0x40'0000, u16):"m"
>>
>> fun peek(addr, t=byte) = makeref(addr, t)^
>>
>> This displays 'MZ', the signature of the (low-)loaded EXE image on
>> Windows
>>
>> Possibly it is even better than C; is this little program valid (no
>> UB) C, even when it is known that the program is low-loaded:
>>
>> #include <stdio.h>
>> typedef unsigned char byte;
>>
>> int main(void) {
>> printf("%c%c\n", *(byte*)0x400000, *(byte*)0x400001);
>> }
>>
>> This works on DMC, tcc, mcc, lccwin, but not gcc because that loads
>> programs at high addresses. The problem being that the address
>> involved, while belonging to the program, is outside of any C data
>> objects.
>>
>>
>
> #include <stdio.h>
> #include <stddef.h>
>
> int main(void)
> {
> char* p0 = (char*)((size_t)main & -(size_t)0x10000);
> printf("%c%c\n", p0[0], p0[1]);
> return 0;
> }
>
>
> That would work for small programs. Not necessarily for bigger
> programs.
>

I'm not sure how that works. Are EXE images always loaded at multiple of
64KB? I suppose on larger programs it could search backwards 64KB at a
time (although it could also hit on a rogue 'MZ' in program data).

My point however was whether C considered that p0[0] access UB because
it doesn't point into any C data object.

If so, it would make access to memory-mapped devices or frame-buffers,
or implementing things like garbage collectors, problematical.

On 24/03/2024 14:26, Michael S wrote:
> On Sat, 23 Mar 2024 11:26:03 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 23/03/2024 07:26, James Kuyper wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 22/03/2024 17:14, James Kuyper wrote:
>>> [...]
>>>>> If you want to tell a system not only what a program must do, but
>>>>> also how it must do it, you need to use a lower-level language
>>>>> than C.
>>>>
>>>> Which one?
>>>
>>> That's up to you. The point is, C is NOT that language.
>>
>> I'm asking which /mainstream/ HLL is lower level than C. So
>> specifically ruling out assembly.
>>
>> If there is no such choice, then this is the problem: it has to be C
>> or nothing.
>>
>>>> I don't think anyone seriously wants to switch to assembly for the
>>>> sort of tasks they want to use C for.
>>>
>>> Why not? Assembly provides the kind of control you're looking for; C
>>> does not. If that kind of control is important to you, you have to
>>> find a language which provides it. If not assembler or C, what
>>> would you use?
>>
>> Among non-mainstream ones, my own would fit the bill. Since I write
>> the implementations, I can ensure the compiler doesn't have a mind of
>> its own.
>>
>> However if somebody else tried to implement it, then I can't
>> guarantee the same behaviour. This would need to somehow be enforced
>> with a precise language spec, or mine would need to be a reference
>> implementation with a lot of test cases.
>>
>>
>> -----------------
>>
>> Take this program:
>>
>> #include <stdio.h>
>> int main(void) {
>> goto L;
>> 0x12345678;
>> L:
>> printf("Hello, World!\n");
>> }
>>
>> If I use my compiler, then that 12345678 pattern gets compiled into
>> the binary (because it is loaded into a register then discarded).
>> That means I can use that value as a marker or sentinel which can be
>> searched for.
>>
>
> Does it apply to your aarch64 compiler as well?

I don't support arm64 as a native C (only via intermediate C). Why, is
there something peculiar about that architecture?

I would expect that 0x12345678 pattern to still be in memory but
probably not in an immediate instruction field. So if wanted to mark a
location in the code, I might need a different approach.

If I ever do directly target that processor, I'll be able to tell you more.

On Sun, 24 Mar 2024 19:12:35 +0000
bart <bc@freeuk.com> wrote:

> On 24/03/2024 14:26, Michael S wrote:
> > On Sat, 23 Mar 2024 11:26:03 +0000
> > bart <bc@freeuk.com> wrote:
> >
> >> On 23/03/2024 07:26, James Kuyper wrote:
> >>> bart <bc@freeuk.com> writes:
> >>>> On 22/03/2024 17:14, James Kuyper wrote:
> >>> [...]
> >>>>> If you want to tell a system not only what a program must do,
> >>>>> but also how it must do it, you need to use a lower-level
> >>>>> language than C.
> >>>>
> >>>> Which one?
> >>>
> >>> That's up to you. The point is, C is NOT that language.
> >>
> >> I'm asking which /mainstream/ HLL is lower level than C. So
> >> specifically ruling out assembly.
> >>
> >> If there is no such choice, then this is the problem: it has to be
> >> C or nothing.
> >>
> >>>> I don't think anyone seriously wants to switch to assembly for
> >>>> the sort of tasks they want to use C for.
> >>>
> >>> Why not? Assembly provides the kind of control you're looking
> >>> for; C does not. If that kind of control is important to you, you
> >>> have to find a language which provides it. If not assembler or C,
> >>> what would you use?
> >>
> >> Among non-mainstream ones, my own would fit the bill. Since I write
> >> the implementations, I can ensure the compiler doesn't have a mind
> >> of its own.
> >>
> >> However if somebody else tried to implement it, then I can't
> >> guarantee the same behaviour. This would need to somehow be
> >> enforced with a precise language spec, or mine would need to be a
> >> reference implementation with a lot of test cases.
> >>
> >>
> >> -----------------
> >>
> >> Take this program:
> >>
> >> #include <stdio.h>
> >> int main(void) {
> >> goto L;
> >> 0x12345678;
> >> L:
> >> printf("Hello, World!\n");
> >> }
> >>
> >> If I use my compiler, then that 12345678 pattern gets compiled into
> >> the binary (because it is loaded into a register then discarded).
> >> That means I can use that value as a marker or sentinel which can
> >> be searched for.
> >>
> >
> > Does it apply to your aarch64 compiler as well?
>
> I don't support arm64 as a native C (only via intermediate C). Why,
> is there something peculiar about that architecture?
>

Nothing specific to ARM64 in this particular case. The same problem
would apply to any instruction set with maximal instruction width <= 32
bits.

For smaller immediates, ARM64 does have encoding rules that can be
surprising.

> I would expect that 0x12345678 pattern to still be in memory but
> probably not in an immediate instruction field.

Not necessarily. Compiler can use several strategies.
E.g. https://godbolt.org/z/vMcaxcs7G

> So if wanted to mark
> a location in the code, I might need a different approach.
>

Exactly.

> If I ever do directly target that processor, I'll be able to tell you
> more.
>
>

On 3/24/2024 9:02 AM, Kaz Kylheku wrote:
> On 2024-03-24, David Brown <david.brown@hesbynett.no> wrote:
>> On 24/03/2024 06:50, Kaz Kylheku wrote:
[...]
> In safety critical coding, we might want to conduct a code review of
> the disassembly of an object file (does it correctly implement the
> intent we believe to be expressed in the source), and then retain that
> exact file until wit needs to be recompiled.

Before C/C++ 11, I was really worried about a hyper aggressive LTO
messing around with my special ASM code for thread sync. So I would
examine the disassembly. One alteration could break it! The problem is
that it might not break right now... But a year from now wrt running for
extended periods of time. If a little shit LTO messed with my externally
assembled functions, assembled into an .o and linked in, will, it could
create a ticking time bomb of very subtle race conditions...

NOT GOOD!

[...]

On 24/03/2024 14:52, David Brown wrote:
> On 23/03/2024 22:21, bart wrote:

>> Well, Forth is certainly cruder than C (it's barely a language IMO).
>> But I don't remember seeing anything in it resembling a type system
>> that corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in
>> current hardware. (Imagine trying to create a precisely laid out struct.)
>
> Forth can be considered a typeless language - you deal with cells (or
> double cells, etc.), which have contents but not types.  And you can
> define structs with specific layouts quite easily.  (Note that I've
> never tried this myself - my Forth experience is /very/ limited, and you
> will get much more accurate information in comp.lang.forth or another
> place Forth experts hang out.)
>
> A key thing you miss, in comparison to C, is the type checking and the
> structured identifier syntax.
>
> In C, if you have :
>
>     struct foo {
>         int32_t x;
>         int8_t y;
>         uint16_t z;
>     };
>
>     struct foo obj;
>
>     obj.x = obj.y + obj.z;
>
> then you access the fields as "obj.x", etc.  Your struct may or may not
> have padding, depending on the target and compiler (or compiler-specific
> extensions).  If "obj2" is an object of a different type, then "obj2.x"
> might be a different field or a compile-time error if that type has no
> field "x".
>
>
> In Forth, you write (again, I could be inaccurate here) :
>
>     struct
>     4 field >x
>     1 field >y
>     2 field >z
>     constant /foo

<...>

Thanks. You've demonstrated perfectly why I would never use Forth. I'd
rather write in assembly.

But what people want are the conveniences and familiarity of a HLL,
without the bloody-mindedness of an optimising C compiler.

> And note that although Forth is often byte-compiled very directly to
> give you exactly the actions you specify in the source code, it is also
> sometimes compiled to machine code - using optimisations.
>
>>
>> It is just too weird. I think I'd rather take my chances with C.
>
> Forth does take some getting used to!
>
>>
>>  > BASIC, ..., Lua, and Micropython.
>>
>> Hmm, I think my own scripting language is better at low level than any
>> of these.
>
> These all have one key advantage over your language - they are real
> languages, available for use by /other/ programmers for development of
> products.

My language exists. Anyone is welcome to reimplement elements of the
design, since most script languages stink at low-level work or dealing
with FFIs.

It is not necessary for me to provide a concrete implementation for
others to use. But here's one expressed as C code for 64-bit Linux:

https://github.com/sal55/langs/blob/master/qu.c

Build using:

> gcc qu.c -oqu -lm -ldl -fno-builtin

or using:

> tcc qu.c -o qu -lm -ldl -fdollars-in-identifiers

Run it like this:

> ./qu -nosys hello

'hello.q' should contain something like like 'println "Hello, World"'.

The -nosys needed as it normally uses a WinAPI-based standard library.

It can't run the 'peek/MZ' example since EXE layouts on Linux are
different, and, if using gcc, 0x400000 is an illegal address.

For something else, try creating test.q:

type date = struct
byte d,m
u16 year
end

d := date(24,3,2024)

println d, date.bytes

Run as './qu -nosys test'. I don't have docs however. BTW here is your
Forth example:

type foo1 = struct
int32 x
int8 y
word16 z
end

type foo2 = struct $caligned
int32 x
int8 y
word16 z
end

println foo1.bytes
println foo2.bytes

There are two versions, one has no automatic padding, which is 7 bytes,
and the other is 8 bytes in size.

>> This works on DMC, tcc, mcc, lccwin, but not gcc because that loads
>> programs at high addresses. The problem being that the address
>> involved, while belonging to the program, is outside of any C data
>> objects.
>>
>
> I think you are being quite unreasonable in blaming gcc - or C - for
> generating code that cannot access that particular arbitrary address!

There were two separate points here. One is that a gcc-compiled version
won't work because exe images are not loaded at 0x40'0000. The other was
me speculating whether the access to 0x40'0000, even when valid memory
for this process, was UB in C.

bart <bc@freeuk.com> writes:
[...]
> But what people want are the conveniences and familiarity of a HLL,
> without the bloody-mindedness of an optimising C compiler.
[...]

Exactly which people want that?

The evidence suggests that, while some people undoubtedly want that (and
it's a perfectly legitimate desire), there isn't enough demand to induce
anyone to actually produce such a thing and for it to catch on.
Developers have had decades to define and implement the kind of language
you're talking about. Why haven't they?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 24/03/2024 21:49, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> But what people want are the conveniences and familiarity of a HLL,
>> without the bloody-mindedness of an optimising C compiler.
> [...]
>
> Exactly which people want that?
>
> The evidence suggests that, while some people undoubtedly want that (and
> it's a perfectly legitimate desire), there isn't enough demand to induce
> anyone to actually produce such a thing and for it to catch on.

I personally think (or speculate, if you feel the word is more
appropriate given that I have no real evidence) that a major part of
this is a lack of agreement on what optimisations these people want or
don't want. I expect Kaz and Bart would agree that they want C
compilers to be required to generate code that does what they mean it to
do, and be able to optimise within those requirements to do the required
job as efficiently as possible. But I expect they would disagree in
many ways in regard to what they mean by it all - what optimisations are
allowed, and what code /really/ means in their eyes.

The best we can reasonably hope for is for a carefully considered
document that describes minimum requirements, and for compilers to
provide flags to allow fine-tuning so that programmers can get the
results they want.

And that is /exactly/ what we have with C and quality C compilers.
Sure, none of this is perfect or an ideal fit for everyone and every
task - but it is good enough that you'd need to come up with something
quite extraordinary to make it attractive compared to C.

> Developers have had decades to define and implement the kind of language
> you're talking about. Why haven't they?
>

On Sun, 24 Mar 2024 13:49:43 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> bart <bc@freeuk.com> writes:
> [...]
> > But what people want are the conveniences and familiarity of a HLL,
> > without the bloody-mindedness of an optimising C compiler.
> [...]
>
> Exactly which people want that?
>
> The evidence suggests that, while some people undoubtedly want that
> (and it's a perfectly legitimate desire), there isn't enough demand
> to induce anyone to actually produce such a thing and for it to catch
> on.

Such things are produced all the time. A yes, they fail to catch on.
The most recent [half-hearted] attempt that didn't realize yet that it
has no chance is called zig.

> Developers have had decades to define and implement the kind of
> language you're talking about. Why haven't they?
>

Because C is juggernaut?

On 24/03/2024 20:56, bart wrote:
> On 24/03/2024 14:52, David Brown wrote:
>> On 23/03/2024 22:21, bart wrote:
>

>
>>> This works on DMC, tcc, mcc, lccwin, but not gcc because that loads
>>> programs at high addresses. The problem being that the address
>>> involved, while belonging to the program, is outside of any C data
>>> objects.
>>>
>>
>> I think you are being quite unreasonable in blaming gcc - or C - for
>> generating code that cannot access that particular arbitrary address!
>
> There were two separate points here. One is that a gcc-compiled version
> won't work because exe images are not loaded at 0x40'0000.

I think that is because your gcc toolchain is creating 64-bit Windows
binaries, while the others are creating 32-bit binaries. I could be
wrong here, of course.

> The other was
> me speculating whether the access to 0x40'0000, even when valid memory
> for this process, was UB in C.
>

Trying to access non-existent memory is UB, yes. I can't imagine a
language where such a thing would be anything else than undefined
behaviour, or defined as a hard run-time error.

But you can run something with UB if you want - at your own risk,
because C and the compiler give you no guarantees of what will happen.
But if you write "x = *(volatile uint8_t *) 0x400000;", then you can
guarantee that the code will at least /try/ to read that address. What
happens depends on the OS, memory protection systems, etc. But it is
not exactly difficult to do this kind of thing in C - that's why
"volatile" exists.

On 24/03/2024 20:49, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> But what people want are the conveniences and familiarity of a HLL,
>> without the bloody-mindedness of an optimising C compiler.
> [...]
>
> Exactly which people want that?
>
> The evidence suggests that, while some people undoubtedly want that (and
> it's a perfectly legitimate desire), there isn't enough demand to induce
> anyone to actually produce such a thing and for it to catch on.
> Developers have had decades to define and implement the kind of language
> you're talking about. Why haven't they?
>
Perhaps many settle for using C but using a lesser C compiler or one
with optimisation turned off.

The language still has the UBs of C, whereas people want it more
implementation-defined, but a weaker compiler is less likely to leverage
that UB to do unexpected things or to wreck somebody's expections of how
a piece of code will behave.

With the dominance of C it's hard to produce a competing language,
especially it it looks like C. And people still want all the
optimisations that are possible without taking advantage of UB of
needing to delete chunks of the user's code.

This is probably a similar discussion to that of makefiles; why isn't
there a competing build system?

C is often used as an intermediate language by compilers. There is a
source language where a lot of this stuff is well-defined by its spec.
There is a known target, or a small range of targets, on which the
behaviour is also well-defined.

However, in the middle you have C, where much of it isn't well-defined!
People want a language which is like the hypothetical one discussed, one
that doesn't get 'in the way' with its crazy ideas. But now it's either
going to be a lot work to generate C code that behaves as expected, or
they have to settle for a non-optimising compiler and cross their fingers.

On Sun, 24 Mar 2024 23:07:44 +0000
bart <bc@freeuk.com> wrote:

> On 24/03/2024 20:49, Keith Thompson wrote:
> > bart <bc@freeuk.com> writes:
> > [...]
> >> But what people want are the conveniences and familiarity of a HLL,
> >> without the bloody-mindedness of an optimising C compiler.
> > [...]
> >
> > Exactly which people want that?
> >
> > The evidence suggests that, while some people undoubtedly want that
> > (and it's a perfectly legitimate desire), there isn't enough demand
> > to induce anyone to actually produce such a thing and for it to
> > catch on. Developers have had decades to define and implement the
> > kind of language you're talking about. Why haven't they?
> >
> Perhaps many settle for using C but using a lesser C compiler or one
> with optimisation turned off.
>

What is "lesser C compiler"?
Something like IAR ? Yes, people use it.
Something like TI? People use it when they have no other choice.
20 years ago there were Diab Data, Kiel and few others. I didn't hear
about them lately.
Microchip, I'd guess, still has its own compilers for many of their
families, but that's because they have to. "Bigger" compilers dont want
to support this chips.
On the opposite edge of scale, IBM has compilers for their mainframes
and for POWER/AIX. The former are used widely. The later are quickly
losing to "bigger' compilers running on the same platform.
As to tcc, mcc, lccwin etc... those only used by hobbyists. Never by
pro. The only "lesser" PC-hosted PC-targeting C compilers that are used
by significant amount of pro developers are Intel and
Borland/Embarcadero, the later strictly for historical reasons.
Embarcadero switched their dev suits to "bigger" compiler quite a few
years ago, but some people like their old stuff. Well, may be, National
Instruments compiler still used? I really don't know.

On 24/03/2024 23:39, Michael S wrote:
> On Sun, 24 Mar 2024 23:07:44 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 24/03/2024 20:49, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>> But what people want are the conveniences and familiarity of a HLL,
>>>> without the bloody-mindedness of an optimising C compiler.
>>> [...]
>>>
>>> Exactly which people want that?
>>>
>>> The evidence suggests that, while some people undoubtedly want that
>>> (and it's a perfectly legitimate desire), there isn't enough demand
>>> to induce anyone to actually produce such a thing and for it to
>>> catch on. Developers have had decades to define and implement the
>>> kind of language you're talking about. Why haven't they?
>>>
>> Perhaps many settle for using C but using a lesser C compiler or one
>> with optimisation turned off.
>>
>
> What is "lesser C compiler"?
> Something like IAR ? Yes, people use it.
> Something like TI? People use it when they have no other choice.
> 20 years ago there were Diab Data, Kiel and few others. I didn't hear
> about them lately.
> Microchip, I'd guess, still has its own compilers for many of their
> families, but that's because they have to. "Bigger" compilers dont want
> to support this chips.
> On the opposite edge of scale, IBM has compilers for their mainframes
> and for POWER/AIX. The former are used widely. The later are quickly
> losing to "bigger' compilers running on the same platform.

> As to tcc, mcc, lccwin etc... those only used by hobbyists.

AFAIK lccwin can be used commercially.

And I would recommend tcc especially for transpiled code. Because it can
process it very quickly, but also because the code should already be
verified so it doesn't need deep analysis.

Further, it doesn't have warnings about obscure, irrelevant matters and
is unlikely to produce any surprises in the generated code.

While mcc is my private tool which is my first choice for C code that
/I/ write or generate.

The bigger compilers I'm aware of are gcc, clang, and MSVC. Only gcc
works on my Windows machine. For obscure but related reasons (as clang
piggybacks onto MSVC) neither of those two currently work. There is also
ZigCC, based around Clang I think, which at least works.

I've never heard of IAR, TI, Diab Data or Kiel. I've heard of DMC
(that's another I use, but it's 32-bit), Watcom, Borland, TurboC and Intel.

> Never by
> pro.

What's a 'pro'? I used to use my in-house languages and compilers for
commercial software; the customer paid for the application, not for the
language or compiler.

> The only "lesser" PC-hosted PC-targeting C compilers that are used
> by significant amount of pro developers are Intel and
> Borland/Embarcadero, the later strictly for historical reasons.
> Embarcadero switched their dev suits to "bigger" compiler quite a few
> years ago, but some people like their old stuff. Well, may be, National
> Instruments compiler still used? I really don't know.

I guess you mean companies using big tools and big ecosystems that need
equally big compilers to go with them.

I mainly use, and develop, small, nippy tools and would rate them above
above any of the big, glossy ones.

On 24/03/2024 23:42, Michael S wrote:
> On Sun, 24 Mar 2024 13:49:43 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> bart <bc@freeuk.com> writes:
>> [...]
>>> But what people want are the conveniences and familiarity of a HLL,
>>> without the bloody-mindedness of an optimising C compiler.
>> [...]
>>
>> Exactly which people want that?
>>
>> The evidence suggests that, while some people undoubtedly want that
>> (and it's a perfectly legitimate desire), there isn't enough demand
>> to induce anyone to actually produce such a thing and for it to catch
>> on.
>
> Such things are produced all the time. A yes, they fail to catch on.
> The most recent [half-hearted] attempt that didn't realize yet that it
> has no chance is called zig.
>

Languages like this are usually better in some ways than C (there's
plenty of scope for that with C - we can do a better job of designing a
language now than 50 years ago, not least because we can expect more
from tools than we could 50 years ago).

But they can never cover everything people want - people want
contradictory things. Thus for everyone (except perhaps the language
designers themselves) such new languages have big disadvantages as well
as big advantages, and they will be missing some key features, seen from
that person's perspective.

And their execution models are invariably either only vaguely defined,
or defined in terms of behaviour with an "as-if" rule to allow
optimisation. Which means they are no better than C for people who
think compilers should be blind translators. (And it also means that
they will be no worse than C for people who understand more about
programming languages and compilers, and for those that either don't
know or don't care.)

Zig is a language I've looked at, and it does have some nice things.
But it will be a /long/ time before it is something I could consider
using for my work, so it would be hobby only. And of course it has made
some design decisions that I think are wrong, and are a big step down
from the current leading alternative to C in many fields - C++.

>> Developers have had decades to define and implement the kind of
>> language you're talking about. Why haven't they?
>>
>
> Because C is juggernaut?
>

Yes, it has a /huge/ momentum. That means that even if a new language
comes along that is better than C in every way, it has to be /much/
better to make it worth the effort to change. Rust is making a fair
stab at this - it is no easy job.

On 25/03/2024 00:39, Michael S wrote:
> On Sun, 24 Mar 2024 23:07:44 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 24/03/2024 20:49, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>> But what people want are the conveniences and familiarity of a HLL,
>>>> without the bloody-mindedness of an optimising C compiler.
>>> [...]
>>>
>>> Exactly which people want that?
>>>
>>> The evidence suggests that, while some people undoubtedly want that
>>> (and it's a perfectly legitimate desire), there isn't enough demand
>>> to induce anyone to actually produce such a thing and for it to
>>> catch on. Developers have had decades to define and implement the
>>> kind of language you're talking about. Why haven't they?
>>>
>> Perhaps many settle for using C but using a lesser C compiler or one
>> with optimisation turned off.
>>
>
> What is "lesser C compiler"?
> Something like IAR ? Yes, people use it.

I am not sure how IAR's tools would count as a "lesser C compiler".
They make very solid C tools for specific embedded targets. And they
have lots of the optimisations that some people get worked up about -
including, IIRC, whole-program optimisations.

> Something like TI? People use it when they have no other choice.

TI's C tools are a bit more varied in quality over their range of
targets. They have a particular bizarre non-conformity that they do not
zero-initialise variables that have no explicit initialisation - a fact
that is documented as a small note in the middle of the manual (for the
two TI compiler manuals I have read).

> 20 years ago there were Diab Data, Kiel and few others. I didn't hear
> about them lately.

I tried out Diab Data for the 68k some 25 years ago. It was /way/
better than anything else around, but outside our budget at the time.
People sometimes complain that type-based alias analysis, or
optimisations based on the UB of signed integer overflow are somehow
"new" optimisations by "evil" gcc developers designed to "win
benchmarks" even though they "break" user code. Diab Data was doing
this kind of optimisation long before gcc.

I've never been a fan of Keil. Perhaps it's because their main target
was the 8051, an architecture that was outdated when it was introduced
in 1980 and that survived decades longer than it should have. But their
compiler is only a "lesser C compiler" in the sense that the target is
really bad for efficient C, so they have to have a lot of extra keywords
and extensions to let people get decent results. Thus you program in
"Keil 8051 C", not standard C. But the compiler does a /lot/ of
optimisation, including very advanced whole-program optimisation.

> Microchip, I'd guess, still has its own compilers for many of their
> families, but that's because they have to. "Bigger" compilers dont want
> to support this chips.

I think some of Microchip's old tools are the ones that I used that
really could be called "lesser C compilers". One I remember had support
for structs, and support for arrays, but not for arrays of structs or
structs containing arrays.

> On the opposite edge of scale, IBM has compilers for their mainframes
> and for POWER/AIX. The former are used widely. The later are quickly
> losing to "bigger' compilers running on the same platform.
> As to tcc, mcc, lccwin etc... those only used by hobbyists. Never by
> pro. The only "lesser" PC-hosted PC-targeting C compilers that are used
> by significant amount of pro developers are Intel and
> Borland/Embarcadero, the later strictly for historical reasons.
> Embarcadero switched their dev suits to "bigger" compiler quite a few
> years ago, but some people like their old stuff. Well, may be, National
> Instruments compiler still used? I really don't know.
>
>

On 25/03/2024 03:12, bart wrote:
> On 24/03/2024 23:39, Michael S wrote:
>> On Sun, 24 Mar 2024 23:07:44 +0000
>> bart <bc@freeuk.com> wrote:
>>
>>> On 24/03/2024 20:49, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> But what people want are the conveniences and familiarity of a HLL,
>>>>> without the bloody-mindedness of an optimising C compiler.
>>>> [...]
>>>>
>>>> Exactly which people want that?
>>>>
>>>> The evidence suggests that, while some people undoubtedly want that
>>>> (and it's a perfectly legitimate desire), there isn't enough demand
>>>> to induce anyone to actually produce such a thing and for it to
>>>> catch on. Developers have had decades to define and implement the
>>>> kind of language you're talking about.  Why haven't they?
>>> Perhaps many settle for using C but using a lesser C compiler or one
>>> with optimisation turned off.
>>>
>>
>> What is "lesser C compiler"?
>> Something like IAR ? Yes, people use it.
>> Something like TI? People use it when they have no other choice.
>> 20 years ago there were Diab Data, Kiel and few others. I didn't hear
>> about them lately.
>> Microchip, I'd guess, still has its own compilers for many of their
>> families, but that's because they have to. "Bigger" compilers dont want
>> to support this chips.
>> On the opposite edge of scale, IBM has compilers for their mainframes
>> and for POWER/AIX. The former are used widely. The later are quickly
>> losing to "bigger' compilers running on the same platform.
>
>> As to tcc, mcc, lccwin etc... those only used by hobbyists.
>
> AFAIK lccwin can be used commercially.

"/Can/ be used commercially" does not imply "/is/ used professionally".
I'm sure there are some people who use it in their work, but I would
expect that in any statistics about compiler usage, it would be in the
"Others < 0.1%" category.

> I guess you mean companies using big tools and big ecosystems that need
> equally big compilers to go with them.
>
> I mainly use, and develop, small, nippy tools and would rate them above
> above any of the big, glossy ones.
>

Then you use a different rating system than the vast majority of
professionals. That, of course, is your free choice to make - just
don't be surprised when others disagree with you.

On Sun, 24 Mar 2024 18:58:24 +0000
bart <bc@freeuk.com> wrote:

> On 24/03/2024 15:53, Michael S wrote:
> > On Sat, 23 Mar 2024 21:21:58 +0000
> > bart <bc@freeuk.com> wrote:
> >
> >> On 23/03/2024 16:51, David Brown wrote:
> >>> On 23/03/2024 12:26, bart wrote:
> >>>> On 23/03/2024 07:26, James Kuyper wrote:
> >>>>> bart <bc@freeuk.com> writes:
> >>>>>> On 22/03/2024 17:14, James Kuyper wrote:
> >>>>> [...]
> >>>>>>> If you want to tell a system not only what a program must do,
> >>>>>>> but also how it must do it, you need to use a lower-level
> >>>>>>> language than C.
> >>>>>>
> >>>>>> Which one?
> >>>>>
> >>>>> That's up to you. The point is, C is NOT that language.
> >>>>
> >>>> I'm asking which /mainstream/ HLL is lower level than C. So
> >>>> specifically ruling out assembly.
> >>>>
> >>>> If there is no such choice, then this is the problem: it has to
> >>>> be C or nothing.
> >>>
> >>> How much of a problem is it, really?
> >>>
> >>> My field is probably the place where low level programming is most
> >>> ubiquitous.  There are plenty of people who use assembly - for
> >>> good reasons or for bad (or for reasons that some people think
> >>> are good, other people think are bad).  C is the most common
> >>> choice.
> >>>
> >>> Other languages used for small systems embedded programming
> >>> include C++, Ada, Forth, BASIC, Pascal, Lua, and Micropython.
> >>> Forth is the only one that could be argued as lower-level or more
> >>> "directly translated" than C.
> >>
> >> Well, Forth is certainly cruder than C (it's barely a language
> >> IMO). But I don't remember seeing anything in it resembling a type
> >> system that corresponds to the 'i8-i64 u8-u64 f32-f64' types
> >> typical in current hardware. (Imagine trying to create a precisely
> >> laid out struct.)
> >>
> >> It is just too weird. I think I'd rather take my chances with C.
> >>
> >> > BASIC, ..., Lua, and Micropython.
> >>
> >> Hmm, I think my own scripting language is better at low level than
> >> any of these. It supports those low-level types for a start. And I
> >> can do stuff like this:
> >>
> >> println peek(0x40'0000, u16):"m"
> >>
> >> fun peek(addr, t=byte) = makeref(addr, t)^
> >>
> >> This displays 'MZ', the signature of the (low-)loaded EXE image on
> >> Windows
> >>
> >> Possibly it is even better than C; is this little program valid (no
> >> UB) C, even when it is known that the program is low-loaded:
> >>
> >> #include <stdio.h>
> >> typedef unsigned char byte;
> >>
> >> int main(void) {
> >> printf("%c%c\n", *(byte*)0x400000, *(byte*)0x400001);
> >> }
> >>
> >> This works on DMC, tcc, mcc, lccwin, but not gcc because that loads
> >> programs at high addresses. The problem being that the address
> >> involved, while belonging to the program, is outside of any C data
> >> objects.
> >>
> >>
> >
> > #include <stdio.h>
> > #include <stddef.h>
> >
> > int main(void)
> > {
> > char* p0 = (char*)((size_t)main & -(size_t)0x10000);
> > printf("%c%c\n", p0[0], p0[1]);
> > return 0;
> > }
> >
> >
> > That would work for small programs. Not necessarily for bigger
> > programs.
> >
>
> I'm not sure how that works.

Neither do I.

> Are EXE images always loaded at multiple
> of 64KB? I suppose on larger programs it could search backwards 64KB
> at a time (although it could also hit on a rogue 'MZ' in program
> data).
>
> My point however was whether C considered that p0[0] access UB
> because it doesn't point into any C data object.
>

Well, C does not even have to run on von Neumann computers. Harward or
even less obvious targets than Harward are both legal and used in
practice. So, of course, any use of code object as data object is UB.

The code below is not UB. IMHO. But it is not portable outside of
compilers based on gcc infrastructure. Probably, not portable outside of
Windows OS, too. But who needs to look for 'MZ' outside Windows?

#include <stdio.h>
extern char __image_base__[];
int main(void)
{ printf("%c%c\n", __image_base__[0], __image_base__[1]);
return 0;
}

> If so, it would make access to memory-mapped devices or
> frame-buffers, or implementing things like garbage collectors,
> problematical.

Implementation-defined linker tricks like the one above can be used
(or should I say "are used" ?) for implementing dynamic memory. I don't
see why they can't be used to implement GC. They are not portable, but
I don't believe that they are UB. At least not as long as one does not
consider data races.

On Sun, 24 Mar 2024 23:43:32 +0100
David Brown <david.brown@hesbynett.no> wrote:
>
> I could be wrong here, of course.
>

It seems, you are.

On Mon, 25 Mar 2024 13:04:50 +0200
Michael S <already5chosen@yahoo.com> wrote:

>
> extern char __image_base__[];
>

This symbol is a little more portable. It works both for 32b and
64b, both for gcc link infrastructure and for MSVC link infrastructure.

extern char __ImageBase[];

On 25/03/2024 12:16, Michael S wrote:
> On Sun, 24 Mar 2024 23:43:32 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> I could be wrong here, of course.
>>
>
> It seems, you are.
>

It happens - and it was not unexpected here, as I said. I don't have
all these compilers installed to test.

But it would be helpful if you had a /little/ more information. If you
don't know why some compilers generate binaries that have memory mapped
at 0x400000, and others do not, fair enough. I am curious, but it's not
at all important.

On Mon, 25 Mar 2024 13:26:01 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 25/03/2024 12:16, Michael S wrote:
> > On Sun, 24 Mar 2024 23:43:32 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
> >>
> >> I could be wrong here, of course.
> >>
> >
> > It seems, you are.
> >
>
> It happens - and it was not unexpected here, as I said. I don't have
> all these compilers installed to test.
>
> But it would be helpful if you had a /little/ more information. If
> you don't know why some compilers generate binaries that have memory
> mapped at 0x400000, and others do not, fair enough. I am curious,
> but it's not at all important.
>

I am not an expert, but it does not look like the problem is directly
related to compiler or linker. All 32-bit Windows compilers/linkers,
including gcc, clang and MSVC, by default put symbol ___ImageBase at
address 4 MB. However loader relocates it to wherever it wants,
typically much higher.
I don't know for sure why loader does it to images generated by gcc,
clang and MSVC and does not do it to images generated by lccwin and
others, but I have an educated guess: most likely, these other compilers
link by default with an option similar to Microsoft's /Fixed
https://learn.microsoft.com/en-us/cpp/build/reference/fixed-fixed-base-address?view=msvc-170

The option disables ASLR and thus can shorten app load time and make
performance just a little snappier. Still, I wouldn't make it default.

To get similar behavior with [32-bit] MSVC user can specify '/linker
/fixed' on the command line. I don't know how to do it with gcc variant
supplied with msys2. But, I'd guess, if you google for long enough, you
can find it.

On 25/03/2024 08:58, David Brown wrote:
> On 25/03/2024 03:12, bart wrote:
>> On 24/03/2024 23:39, Michael S wrote:
>>>
>>> As to tcc, mcc, lccwin etc... those only used by hobbyists.
>>
>> AFAIK lccwin can be used commercially.
>
> "/Can/ be used commercially" does not imply "/is/ used professionally".
> I'm sure there are some people who use it in their work, but I would
> expect that in any statistics about compiler usage, it would be in the
> "Others < 0.1%" category.
>

lccwin is used to compile C functions with an interface which maes them
callable from Matlab. Whilst I haven't written Matalb code commercially
and it would be rare to do so, I have written Matlab ocdoe
professionally, and that is quite common. I probably also made rather
heavier use of the C interfaces than was really justified.

My Matlab File Exchange submissions are still going strong. But the gem,
the faded bar chart, hasn't been valued, and hasn't attracted any stars.
Matlab users, download and give some love.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Mon, 25 Mar 2024 13:26:32 +0000
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> On 25/03/2024 08:58, David Brown wrote:
> > On 25/03/2024 03:12, bart wrote:
> >> On 24/03/2024 23:39, Michael S wrote:
> >>>
> >>> As to tcc, mcc, lccwin etc... those only used by hobbyists.
> >>
> >> AFAIK lccwin can be used commercially.
> >
> > "/Can/ be used commercially" does not imply "/is/ used
> > professionally". I'm sure there are some people who use it in their
> > work, but I would expect that in any statistics about compiler
> > usage, it would be in the "Others < 0.1%" category.
> >
>
> lccwin is used to compile C functions with an interface which maes
> them callable from Matlab.

On which platform?
By which percentage of people that write C functions callable from
Matlab?

> Whilst I haven't written Matalb code
> commercially and it would be rare to do so, I have written Matlab
> ocdoe professionally, and that is quite common. I probably also made
> rather heavier use of the C interfaces than was really justified.
>

Back in DOS days, I don't remember lccwin among compilers that
Mathworks recognized as allowed to build MEX modules. In fact, I don't
remember existence of lccwin.
On Win64 the point is mute, because there exist an unified platform ABI
that everybody follow. But back in DOS and Win32 days official
Mathworks blessing was important.

> My Matlab File Exchange submissions are still going strong. But the
> gem, the faded bar chart, hasn't been valued, and hasn't attracted
> any stars. Matlab users, download and give some love.
>

On 24/03/2024 19:58, bart wrote:
> On 24/03/2024 15:53, Michael S wrote:

>> #include <stdio.h>
>> #include <stddef.h>
>>
>> int main(void)
>> {
>>    char* p0 = (char*)((size_t)main & -(size_t)0x10000);
>>    printf("%c%c\n", p0[0], p0[1]);
>>    return 0;
>> }
>>
>>
>> That would work for small programs. Not necessarily for bigger
>> programs.
>>
>
> I'm not sure how that works. Are EXE images always loaded at multiple of
> 64KB? I suppose on larger programs it could search backwards 64KB at a
> time (although it could also hit on a rogue 'MZ' in program data).
>
> My point however was whether C considered that p0[0] access UB because
> it doesn't point into any C data object.

As it stands in the code, I believe it is undefined behaviour.

>
> If so, it would make access to memory-mapped devices or frame-buffers,
> or implementing things like garbage collectors, problematical.

As I wrote (more than once), the C way to handle this is "volatile".
Volatile accesses are implementation-defined, and are "observable
behaviour" - therefore the compiler generates code that makes exactly
the read and write accesses you ask for when they are done using a
volatile-qualified lvalue.

On 25/03/2024 14:11, Michael S wrote:
> On Mon, 25 Mar 2024 13:26:01 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 25/03/2024 12:16, Michael S wrote:
>>> On Sun, 24 Mar 2024 23:43:32 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> I could be wrong here, of course.
>>>>
>>>
>>> It seems, you are.
>>>
>>
>> It happens - and it was not unexpected here, as I said. I don't have
>> all these compilers installed to test.
>>
>> But it would be helpful if you had a /little/ more information. If
>> you don't know why some compilers generate binaries that have memory
>> mapped at 0x400000, and others do not, fair enough. I am curious,
>> but it's not at all important.
>>
>
> I am not an expert, but it does not look like the problem is directly
> related to compiler or linker. All 32-bit Windows compilers/linkers,

(I get the impression that at least some of the compilers in question
are 64-bit, but I can't be sure, especially as Bart is using them on
Windows while I mainly use Linux for development.)

> including gcc, clang and MSVC, by default put symbol ___ImageBase at
> address 4 MB. However loader relocates it to wherever it wants,
> typically much higher.

OK.

Is this a kind of address randomisation thing? That would make sense,
since such randomisation makes various kinds of attacks a good deal
harder, and hardening against attacks is something gcc and binutils (I'm
guessing that's the linker involved here) take seriously.

> I don't know for sure why loader does it to images generated by gcc,
> clang and MSVC and does not do it to images generated by lccwin and
> others, but I have an educated guess: most likely, these other compilers
> link by default with an option similar to Microsoft's /Fixed
> https://learn.microsoft.com/en-us/cpp/build/reference/fixed-fixed-base-address?view=msvc-170
>
> The option disables ASLR and thus can shorten app load time and make
> performance just a little snappier. Still, I wouldn't make it default.
>

Maybe it makes things easier for some kinds of code generation? It
might reduce the need for position-independent code.

Most of my work is in small-systems embedded programming, where you do
not normally have an MMU and addresses tend to be fixed. (There are
occasions when you want to be able to load code at different addresses,
but then you need to make sure it is generated as position-independent.)
So while I know more than most programmers about linking on those
systems, it is in a specific area of programming. It's not something I
have looked at for Windows at all.

> To get similar behavior with [32-bit] MSVC user can specify '/linker
> /fixed' on the command line. I don't know how to do it with gcc variant
> supplied with msys2. But, I'd guess, if you google for long enough, you
> can find it.
>

It is presumably a linker flag, rather than a gcc flag. And I don't
know if Bart's gcc setup is using the common binutils linker, or
something else.

Thanks for the information, anyway.