Are data type compiler-dependent or target dependent

[ledtester]

...
You have a piece of C code where you see "uint16_t ", the compiler won't accept it and returns

"sorry, this target doesn't support 16 bit datatype"
...

gcc has the "unavailable" attribute which will emit an error message when a type is used "anywhere in the source file" (see docs for specifics):

https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes

This code generated the unavailable error:

Code: [Select]

#include <stdint.h>

typedef uint16_t uint16_t __attribute((unavailable("sorry, this target doesn't support 16 bit datatype")));

int main()
{
    uint16_t foo;
}

I tested it at https://gcc.godbolt.org/ which uses gcc 12.1.

Types like unit16_t are defined in stdint.h, so you could also modify that file for your target to add that attribute.

[DiTBho]

gcc has the "unavailable" attribute which will emit an error message when a type is used "anywhere in the source file" (see docs for specifics):

this can be useful for a patch for the main file of gcc for a specific architecture (so, when you are compiling the cross-compiler) rather than in an header somewhere that someone usually messes up.

nice to have! nice to know 

[Nominal Animal]

Designing a better C (I happened to have opened a thread dedicated to this a while ago and it unexpectedly got nowhere) is almost a lost cause. I know it sounds corny, but we now have 50 years to back this up.

Yup.  However, what we can kinda-sorta do, is replace the standard C library with something else.  (Which is something I've discussed in another thread.)
There are some house-sized warts to deal with, like the compiler emitting calls to memcpy() and memmove()), reserved names, implementation defined details in the standard regarding freestanding C, and they only grow bigger if you want it to be compilable with a C++ compiler also, but they're annoyances, not showstoppers.

What one cannot do, is change the base semantics and rules.  The compiler needs to support the ABI you choose.  You can set additional rules, like POSIX C does, if there is a way to tell the C compiler to abide by those rules.  You will end up having some compiler dependencies, especially function and variable attributes, but you can choose them from the set already supported by the main C compilers: GCC and clang already have a large common set.

It is also impossible to stop other developers from shooting themselves in the foot.  You can only make the robust, sensible ways easier, but you cannot idiot-proof anything based on top of C.

This is where my view diverges from e.g. DiTBho's.  I see things like MISRA C (and Annex K in ISO C11) as futile, and definitely do not want to work under such rules, because I see them as fundamentally flawed in their purpose: that they try to fix a perceived problem at the wrong complexity level.
I can accept the abstractions the (freestanding) C standard does, because to change those would be to fundamentally change the language, and as mentioned by SiliconWizard, none of the alternatives have fared as well as C has for the last half century or so.  Thus, while they are far, far from optimal, I see them as workable; and instead of fighting against them, I try to create interfaces and patterns that take advantage of them.

One of the details I've thought about a lot, and repeatedly see being a crucial piece in many embedded appliances (especially those with limited RAM), is memory allocation.  I've discussed arena-based allocators, but fact is, the separate arenas are not the reason why: the reason is, with arena-based allocators you can set practical, reliable run-time limits on any sub-task using a specific arena for allocations.

In a separate thread, peter-f is currently wrestling with a HTTP/HTTPS server running on an STM32 microcontroller.  Because the environment does not support arena-based or inheritably-limited allocations, memory use is a critical and hard part of the puzzle to solve.  Even with a single heap, if each allocation, reallocation, and free are done with respect to a context, with such contexts themselves forming a tree hierarchy, one can assign reasonable but dynamic limitations for each logical operation/task –– like responding to a HTTP request –– with nothing but standard C.  (You can even use a chain of longjmp()-based handlers, so that if a new allocation in a context cannot be fulfilled, the execution context reverts to the creation of the context failing, with a suitable error.  You'll most likely want to add cleanup handlers, closures, too, but it is all quite straightforward to implement.  It is the API design, the interface for others to use, that is hard to get right.)

As I hinted and DiTBho confirmed, he actually likes Ada and would apparently like to use it more, his problem being that there is no Ada compiler for some of the platforms he targets. He doesn't need a "better C", he needs Ada.

While I haven't done any serious programming in Ada, I can see its roots, and do believe it – or a strict subset or derivative like SPARK – would be better suited to the tasks MISRA C is usually applied.  (However, from outside, it looks like the big companies using Ada tend to hoover all the Ada developers, so that there isn't that big of a free/open source community around it.  In particular, what the hell is "GNAT Pro"?  Is it just a repeat of what Microchip did to GCC, to be able to hoodwink its customers into paying for a free compiler?)

It is for these reasons, that I firmly, but friendly , believe that it is wrong to blame the features of C.  It just isn't the right tool for the job here.

[westfw]

Designing a better C ... is almost a lost cause. ...  we now have 50 years to back this up.

But C HAS "gotten better" in that 50 years.
Maybe some of the original warts that are particularly horrible to modern eyes have turned out to be important features that can not be changed.  But still. I'd say it's gotten "much better."

[brucehoult]

Designing a better C (I happened to have opened a thread dedicated to this a while ago and it unexpectedly got nowhere) is almost a lost cause. I know it sounds corny, but we now have 50 years to back this up.

My main complaint against the C language as such (rather than the standard library) is the syntax, especially the declaration syntax. I prefer something along Modula-2 / Ada lines.

However there is 30 or 40 years of experience of any language daring to ask people to type "end" instead of "}" failing in the market, while anything that copies C syntax is wildly successful, no matter how different the semantics are (Perl, Java, JavaScript, Go, Rust, ...).

I don't like it, but that's how it is.

As I hinted and DiTBho confirmed, he actually likes Ada and would apparently like to use it more, his problem being that there is no Ada compiler for some of the platforms he targets. He doesn't need a "better C", he needs Ada.

So his prefered language has already been designed. No need to try and design another one, for which there wouldn't be any more compiler available anyway.

As I understand it, Ada (GNAT) has long been available anywhere gcc is available, and there is also GNAT front-end combined with LLVM back end.

So Ada should be available pretty much everywhere except 6502, z80, 8051, PIC. And I wouldn't bet against 8051, actually.

I personally find C pretty usable. For any advanced use, I definitely recommend reading the standard for whatever revision you're going to use. It's a must. And reading the latest revisions (C11, and even the C23 draft) could also give you a couple ideas and show you what "modern C" can bring to the table.

C isn't my ideal language, certainly not for high-level programming in large programs. My preference is the Lisp family, and especially Dylan, as being expressive, efficient, garbage-collected, and with better macros, object systems, and exception handling than C/C++/Java.

But for small simple programs, especially things running on microcontrollers and other constrained systems, C gets the job done, and with a better mix of performance and portability than anything else.

[tggzzz]

Designing a better C ... is almost a lost cause. ...  we now have 50 years to back this up.

But C HAS "gotten better" in that 50 years.
Maybe some of the original warts that are particularly horrible to modern eyes have turned out to be important features that can not be changed.  But still. I'd say it's gotten "much better."

That's debatable.

K&R C was a reasonable match to PDP-11 era machines with simple caches and a single core. That meant the ambiguities were easily understandable (e.g. The C Puzzle Book) and the explicit lack of support for threading was acceptable.

Time has marched on and brought much more complex hardware. C responded by trying to be both a low-level and a high-level (for want of a better term) language. The response made C vastly more complex with many arcane rules that few programmers using the language and compilers fully understand. The consequence is that C has become a poorer match for many of today's applications and architectures.

In that practical sense, C has become worse, not better.

[DiTBho]

As I understand it, Ada (GNAT) has long been available anywhere gcc is available, and there is also GNAT front-end combined with LLVM back end.

You need a bootstrapper to compiler Gnat.
No bootstrap no party. A large part of Gnat is written in Ada.

Gnat is anywhere Gcc-compiled-with-ada-support  is available.

Code: [Select]

[2] hppa64-unknown-linux-gnu-4.9.4-gnat2016
[3] hppa64-unknown-linux-gnu-6.5.0
[4] hppa64-unknown-linux-gnu-7.3.1-gnat2018
[5] hppa64-unknown-linux-gnu-7.5.0
[6] hppa64-unknown-linux-gnu-8.3.1-gnat2019
[7] hppa64-unknown-linux-gnu-8.4.0
[8] hppa64-unknown-linux-gnu-9.3.0-gnat2021 *
[9] hppa64-unknown-linux-gnu-10.2.0

2,4,6,8 have this

Code: [Select]

--enable-languages=c,c++,fortran,ada
and they can be used to bootstrap gnat

It looks simple, but it was not, and it's not, it's pretty difficult to obtain.

[DiTBho]

I see things like MISRA C as futile, and definitely do not want to work under such rules

Years ago I thought the same. MISRA? Wtf!?!
Then I professionally met things like DO178B and DO178C, which require ICE-sessions.
And ICE-sessions became the reason why MISRA makes sense.

[DiTBho]

there is also GNAT front-end combined with LLVM back end.

LLVM doesn't have any support on HPPA and SH, and it has several problems on MIPS.
One things is LLVM on mainstream architectures { x86, arm }, one things is LLVM elsewhere.

[westfw]

Quote

Ada (GNAT) has long been available anywhere gcc is available, and there is also GNAT front-end combined with LLVM back end.

My impression is that with C, you can get away with very little in the way of "runtime library support", while most other modern languages require a lot more, and more that is architecture and OS-specific.  So that while you can release a "C compiler for Padauk" without even "libc", and a lot of people will be happy, the equivalent for Ada is much more difficult.
And I think there is less "portable" run-time library code as well.  (Although the portable C libraries are sometimes not much to write home about...)
Certainly "old" languages (Fortran, PL/1, Pascal) were very explicit about including massive amount of "IO" capabilities in the language itself (C has NOTHING at the language level!)  I haven't paid enough attention to "new" languages to see if any have been careful to separate the language from the OS and runtime environment, or even whether it's possible to do so and still have the improvements that people want.

[DiTBho]

the explicit lack of support for threading was acceptable.

With modern hardware threading and tr-memory is one of the problem today.

"Threads Cannot be Implemented as a Library" has been known since 2004, but very little has been done to address the problem.

[DiTBho]

So that while you can release a "C compiler for Padauk" without even "libc", and a lot of people will be happy, the equivalent for Ada is much more difficult.
And I think there is less "portable" run-time library code as well. 

Yes, this is problem n2, once you somehow get a working Ada compiler - you need a working Ada runtime library.

The first run on HPPA was a bloody hell not only for adding "ada" to the gcc-enabled-language, but also to get a working run-time library.

With C you need only "cc1", and It will enough to obtain an assembly file from a C file; you can just create a crt0.S and some small libc.S, assembling them to .o files so linking them all together will be a runnable application.

That's indeed how "myC" works 

[tggzzz]

the explicit lack of support for threading was acceptable.

With modern hardware threading and tr-memory is one of the problem today.

"Threads Cannot be Implemented as a Library" has been known since 2004, but very little has been done to address the problem.

K&R C in ~1982 is explicit that multithreading is a library problem, and that the language does not provide primitives. In other words multithreading had to be a machine+compiler specific hack in a library.

The 2004 papers were necessary, remarkably, because youngsters had forgotten the foundations, and the foundations were obscured by all the baroque complexity.

[brucehoult]

there is also GNAT front-end combined with LLVM back end.

LLVM doesn't have any support on HPPA and SH, and it has several problems on MIPS.
One things is LLVM on mainstream architectures { x86, arm }, one things is LLVM elsewhere.

It's not mainstream vs non-mainstream. LLVM support for RISC-V is now better than gcc support for RISC-V.

The distinction is current ISAs vs legacy ISAs.

New work on new ISAs is now almost always done (or done first) in LLVM because more people can understand how to work with the LLVM source code than with the GCC source code, and because LLVM's more liberal licensing is easier for companies to deal with, and because it is much easier to upstream new and experimental code into LLVM than into GNU.

Old dead ISAs got GCC support in the 90s or 00s before LLVM existed.

Old inactive ISAs: use gcc, therefore GNAT

New and active ISAs: use llvm, therefore GNAT-on-LLVM

Disclaimer: I haven't used ADA since 1984 on a VAX. I seem to recall the compiler was from New York University and was written in SETL.

[Nominal Animal]

I see things like MISRA C as futile, and definitely do not want to work under such rules

Years ago I thought the same. MISRA? Wtf!?!
Then I professionally met things like DO178B and DO178C, which require ICE-sessions.
And ICE-sessions became the reason why MISRA makes sense.

For me, it boils down to using the language that is most appropriate for the task.  I know C well enough to see that it is impossible to make it "safe" like MISRA and the various aeronautical etc. rules try to; it is futile.

The fact that there aren't toolchains available for the languages that would be much more appropriate for the task at hand, isn't the fault of an unrelated programming language, is my point.

If I wanted to work on something as safety critical as aeronautics or medical appliances, I for sure would like to use a programming language that can be statically verified and proven.  If that means porting the toolchain first, well, that would be the cost I'd have to accept, or not do it at all.  But that is just me, and my own personal quirks.

[brucehoult]

the explicit lack of support for threading was acceptable.

With modern hardware threading and tr-memory is one of the problem today.

"Threads Cannot be Implemented as a Library" has been known since 2004, but very little has been done to address the problem.

I feel this paper is misrepresented.  It's not the library part that is the problem.  As soon as you have two CPU cores running two threads there may well be no more library calls, ever, after the initial spawning of the 2nd thread.

The problem was that C, at that time, didn't have a concept of memory model or things such as acquire and release semantics. Neither did any other language pretty much, other than Java.

Heck, most ISAs at the time didn't even have a formal notion of memory model.

[tggzzz]

the explicit lack of support for threading was acceptable.

With modern hardware threading and tr-memory is one of the problem today.

"Threads Cannot be Implemented as a Library" has been known since 2004, but very little has been done to address the problem.

I feel this paper is misrepresented.  It's not the library part that is the problem.  As soon as you have two CPU cores running two threads there may well be no more library calls, ever, after the initial spawning of the 2nd thread.

The problem was that C, at that time, didn't have a concept of memory model or things such as acquire and release semantics. Neither did any other language pretty much, other than Java.

Heck, most ISAs at the time didn't even have a formal notion of memory model.

Yes, the lack of a memory model was the key issue - and I believe the reason Boehm wrote the paper was to force people to realise it. I still find it remarkable and noteworthy that the general ignorance in the (supposedly) expert community meant he had to write the paper.

People seem to have forgotten that K&R C stated both threading was a library issue and that the language specifically omitted the features required to allow it to be implemented in a library. That was acceptable in the 70s, but ridiculous a professional lifetime (>30 years) later.

Java was ahead of its time in many ways, and behind the times in good ways. If you look at Gosling's original whitepaper he give reasons why historic experience showed all the language features are beneficial and play well together, plus why he omitted features that experience showed were problematic - especially multiple inheritance of implementations (not traits/interfaces)). Gosling showed extreme good taste, as I would have expected from someone that created my first favourite editor: Unipress Emacs.

[westfw]

K&R C in ~1982 is explicit that multithreading is a library problem, and that the language does not provide primitives. In other words multithreading had to be a machine+compiler specific hack in a library.

I just skimmed it, but didn’t the paper say that threading couldn’t be implemented in a library, even IF the library implemented machine and compiler specific hacks?


That’s not how I interpreted the claim the first time I heard it, through.

[DiTBho]

multithreading and try-memory need language support otherwise you can only workaround machine+compiler specific hack in a library, this is particularly problematic with powerpc and power due to pipeline specific instructions on ooo load store which make things even worse

So you usually have critical code implemented in assembly to manage the shared memory ... but it is an ugly workaround

myC has built-in tr-memory support, dead lock free

[DiTBho]

I know C well enough to see that it is impossible to make it "safe" like MISRA and the various aeronautical etc. rules try to; it is futile.

My point is that MISRA does it make it safer as consequence of making it easier to be automatically debugged.

Easier to be debugged => safer

DO178 is about life cycle, life cycle is also about debugging sessions and test cases, and debugging sessions are about AI-assisted debuggers; what I usually call "ICEs" are smart devices with a super fast optic link (48Mbps) and a strong MMA processors able to understand C at the language level, but you have to help them, that is the purpose of MISRA

myC is more AI-ICE friendly than common C

So, what do you want to achieve, how to verify it, help the ICE AI to help you

Does not sound so terrible ... It is not "dark side", but rather simply collaboration between humans and AI

[tggzzz]

...what I usually call "ICEs" ...

To me  in the context of an embedded system an "ICE" is an In Circuit Emulator, https://en.wikipedia.org/wiki/In-circuit_emulation

That appears, at a glance, different to your definition. A "Humpty Dumpty" situation, I suppose.

[Nominal Animal]

I know C well enough to see that it is impossible to make it "safe" like MISRA and the various aeronautical etc. rules try to; it is futile.

My point is that MISRA does it make it safer

safer ≢safe.

Wearing rubber boots while standing under a tree in a thunderstorm is also safer than not wearing rubber boots, but you can still die from lightning hitting the tree.

myC is more AI-ICE friendly than common C

Sure, but that just proves that C is simply the wrong tool for the job!

And is precisely my point why you should not blame C for not being suitable for your task at hand –– do not forget, you yourself claimed that it is somehow C that is at blame here; that C should be "fixed".

Our difference in opinion is that I believe that C is unsuitable at your task –– and any task for which MISRA etc. act as band-aids ––, and you have argued that no, C itself should be changed and "fixed" because it is so hard to apply to your task at hand and MISRA etc. do help applying it somewhat better to the task; that it is C's fault for not being more amenable to the task at hand.

I could just as well blame my $25 cordless drill for its poor CNC capabilities, and demand the manufacturer adds at least DRO's, gyroscopic stabilizers, and a few servo motors to control it better.  Do you see my point? 

[tggzzz]

I could just as well blame my $25 cordless drill for its poor CNC capabilities, and demand the manufacturer adds at least DRO's, gyroscopic stabilizers, and a few servo motors to control it better.  Do you see my point? 

Isn't that what's happened, especially with C++ 

[DiTBho]

To me  in the context of an embedded system an "ICE" is an In Circuit Emulator, https://en.wikipedia.org/wiki/In-circuit_emulation
That appears, at a glance, different to your definition. A "Humpty Dumpty" situation, I suppose.

Well, ICE is also a term used in cyberpunk literature to refer to security programs which protect computerized data from being accessed by hackers.

ICE
Intrusion
Countermeasures
Electronics

Gibson 

Among avionics testers and developers, "ICE" for a "hardware debugger" is considered common special "jargon".
And here you are right, jargon is when you talk by words or expressions that are used by you particular profession and are they difficult for others to understand.

I mean, like "legal jargon" or "math jargon" ... only lawyers and mathematicians fully understand it 


Anyway, I do "ICEs", I mean I do physically design and build debuggers, from the firmware belt up, so for me it's automatic association that an "in circuit emulator" nowadays is more like TAP interface (BDM, nexus, ejtag, jtag, etc) able to talk to the host via an interface for reading/writing registers, therefore indirectly also the memory.

In my case, I tend to forget to mention that it is paired with a smart device that can perform analysis directly on the target

• coverage
• performance
• testcases

To perform them, code instrumentation is always required, but the ICE helps because it provides an instrumenting tool (on the host side) plus the in-circuit capability to map test-points to a specific piece of C code that it only needs to query from the host, and here it's where MISRA helps. The host replies by sending the source code and the testing-plan, the "ICE" parses the C source (on the target side, the ICE is smart), and applies the testing points to verify them.

Everything is automatic, AI supervision-ed, unless you require "manual override" operation.

MISRA helps because it makes those testing points explicit, and makes life easy to the human being that has to "instrument" the ICE.

Practically
- you write MISRA && DO178 compliant C code
- you pair the C code to the instrumenting engine
- the skeleton of the basic test-cases is automatically generated, you can add more test-cases
- you modify/approve the test-cases
- once approved, the instrumenting engines compiles it
- a DWARF binary is generated, and an instrumentation file IIF
- DWARF and IIF are uploaded to the ICE (here is where a fast link helps)
- the ICE automatically starts analysis

[DiTBho]

safer ≢safe.

sure, but "safer" is a step forward in progress to achieve my purpose (see below)

just proves that C is simply the wrong tool for the job!

myC demonstrates that even C89 can be modified to help debuggers. Which makes it a better tool, not perfect, but better.

For my point of view, ADA is difficult to be supported at the language-bootstrapping and run-time level (and, talking about supporting new-targets, it'salso extremely hard to pass certifications), while a compiler like myC is as easy as bootstrapping a C compiler for a target.

You see, get { CC1, crt0.s, libc.s } and you get a compiler with tr-memory support! Already ICE-friendly!

Purpose fully achieved 

Unfortunately, I'm not good enough with compilers to push a dominant change into Gcc or LLvm or something; myC is 60% based on lcc-v4, I am not able to write a C compiler from scratch, and the result requires people to adapt their coding style, that is *the* serious problem because most C programmers won't.

So, for me, I have the feeling that it's more an ideological problem, especially for those who don't care about debuggers.