Comment by ErikCorry
3 years ago
> for platforms without file systems, or operating systems or where bytes aren't 8 bits, that doesn't use ASCI or Unicode, where NULL isn't on address 0 and so on.
This seems totally misconceived to me as a basis for standardizing a language in 2022. You are optimizing for the few at the expense of the many.
I get that these strange architectures need a language. Why does it have to be C or C++? They can use a nonstandardized variant of C, but why hobble the language that is 99% used on normal hardware with misfeatures that are justified by trule obscure platforms.
It doesn't have to be C, but as of today there is no other option. No one is coming up with new languages with these kinds of features so C it is. People should, but language designers today are more interested in memory safety and clever syntax, than portability.
I would like to caution you against thinking that these weird platforms are old machines from the 60s that only run in museums. For instance many DSPs have 32bit bytes (smallest memory unit that can be individually addressed), so if you have a pair of new fancy noise canceling headphones, then its not unlikely you are wearing a platform like that on your head everyday.
Unusual platforms like DSPs usually have specific (usually proprietary) toolchains. Why can't those platforms implement extensions to support 32-bit bytes? Why must everyone else support them? In practice ~no C code is portable to machines with 32-bit bytes. That's okay! You don't choose a DSP to run general purpose code. You choose it to run DSP code, usually written for a specific purpose, often in assembly.
"Weird" platforms often do have their own tool-chains but they do have the ability to leverage LLVM, MISRA, and an array of common tools and analyses that exists for C. One of the reason we got new platforms like RISC-V is that today its possible to use existing OSS software to build a platform with a working OS and Development environment, that common basic libraries can be built for is that all this software is written in C and can be targeted towards a new platform.
6 replies →
Because C already does this, and has from the beginning. C was designed to be portable in an era where there were significant differences in fundamental CPU design decisions between platforms. C is widely used to write software for all kinds of weird platforms. Changing that would be far more work than just making a new language.
They also tend to be non-standard for a variety of reasons anyway! C bends backwards to support odd architectures but is often also insufficient (or at least the vendors cannot justify the effort to achieve full compliance and their customers don't care significantly anyway).
Perhaps Carbon is the first in a series of new low level languages that free us from the impossible tensions of C/C++ having to be all things to all (low level) programmers.
I would love a new language for implementing high level languages. I've worked on several of these projects and we use mostly unstandardized dialects of C++ and it's really not fit for purpose.
While at it, I should mention Zig.
6 replies →
> It doesn't have to be C, but as of today there is no other option
Isn’t C99 an option? Why can’t more advanced things go into newer C and people who genuinely need something more basic can use C99.
We can! Many of us still use c89.(c99 has problems, like variable length arrays).
The reality however is that you cant escape never versions entirely. Not all code you interact with was written in the subset you want, so when your favorite OS or library starts using header files with newer features you need to run that version of the language too.
Another less appreciated detail, is that a lot of WG14 work is not about adding new features but clarifying how existing features are meant to work. When the text is clarified this gets back-ported to all previous versions of C in major compilers. An example of this is "provenance". This is a concept that implicitly been standard since the first ISO standard, but only now is becoming formalized. This means that if you want to adhere to the C89 standard, you will find a lot of clarifications about how things should work in the C23 standard.
3 replies →
If it were to focus on stability, it would probably be LLVM IR. That said, there's plenty of C++ being written for these applications. And Ada.
> so if you have a pair of new fancy noise canceling headphones, then its not unlikely you are wearing a platform like that on your head everyday.
Chip shortage aside, the likelihood of these devices using obscure hardware like discrete DSPs is going down as cheaper low power architectures are becoming commoditized.
LLVM IR isn’t stable or even portable. It’s just a compiler IR, not a language.
3 replies →
> This seems totally misconceived to me as a basis for standardizing a language in 2022. You are optimizing for the few at the expense of the many.
Sure, but it's the same line of reasoning that made C relevant in the first place, and keeps it relevant today - some library your dad wrote for a PDP-whatever is still usable today on your laptop running Windows 10.
Because it's antiquated, it's also extremely easy to support, and to port to new and/or exotic platforms.
The library my dad wrote (lol) for the PDP-11 is probably full of undefined behaviour and won't work now that optimizers are using any gap in the standard to miscompile code.
> using any gap in the standard to miscompile code
For code to be miscompiled, there has to be a definition of what correctly compiling it would mean, and if there were, it would not be undefined behavior.
5 replies →
What a useless and jaded assumption that code written in the past is bad.
6 replies →
> PDP-whatever is still usable today on your laptop running Windows 10
No, it isn't. Go on. Go ahead and try
See it break in a million weird ways. (Or, for a start, it will have the K&R C format, which is a pain to maintain)
"If your computer doesn't have 8-bit bytes" at this day and age? It belongs in a dumpster, sorry.
(I think the only "modern" arch that does this is PIC, and even only for program data - where you're not running anything "officially" C89 or later)
When I first learned C, it was K&R, pre-ANSI with old style function parameters. It is trivial to convert to ANSI C. The truth is C has barely changed in decades.
You should take a look at plan9port - a bunch of userspace tools from Plan 9, carefully ported to Linux with few changes. Maybe that's not PDP-whatever, but it is Sun-whatever. Either way, it's code that was written decades ago for a dead architecture.
C is pretty much the only language in common use for programming microcontrollers. Microntrollers seldomly have filesystems. To break the language on systems without filesystems or terminals means to break the software of pretty much every electronics manufacturer out there.
Thinking of it, JavaScript is a language that target mainly browser, which also doesn't have a filesystem.
Web requests are its filesystem.
Sure, but you don’t typically run the compiler on the microcontroller! It’s the host that needs a filesystem, not the target.
Of course, I can't see a reason why #embed wouldn't be useful for microcontrollers. In fact, I imagine it's a key target market for a feature like that, resource managers are complex and tools like bin2c have always felt like a terrible back.
I was solely replying to the commenter who said that all reasonable modern systems have filesystems so I put one in for the embedded software developers.
It may have no filesystem but it's extremely likely it has 8 bit bytes
CHAR_BIT != 8 on a lot of systems: https://stackoverflow.com/q/2098149/7509065
1 reply →
But you don't run the compiler on a computer without a file system. How would #include works otherwise?
This feature is precisely very useful when you don't have a filesystem to read data from at runtime. Embedding it to the binary to flash it is so much simpler with this.
As the GP post comments, if you want those features there are plenty of other languages to choose from.
I don’t even like programming in C but I respect what the committee is trying to do, and yes I do sometimes write C code.
I'll flip that around if you want to serve on a language standards commit there are a lot of other languages to choose from. Why be on the C standards committee with the express purpose of blocking progress?
Because it's one of the very few -- almost only -- languages with this objective.
1 reply →
I would say that one should be pretty cautious when baking in assumptions snouty such a fleeting thing as hardware into such a lasting thing as a language.
C itself carries a lot of assumptions about computer architecture from the PDP-9 / PDP-11 era, and this does hold current hardware back a bit: see how well the cool nonstandard and fast Cell CPU fared.
A language standard should assume as little about the hardware as possible, while also, ideally, allowing to describe properties of the hardware somehow. C tries hard, but the problem is not easy at all.
Can you explain what aspect of C from PDP-11 was problematic for Cell?
All memory is uniform, for instance. There is one scalar data processing unit that finishes a previous operation and then issues the next: no way to naturally describe SIMD, for instance. No way to speak about asynchronous things that happen on a Cell CPU all the time, as much as I can judge. (I never programmed it, but I remember that people who did said they had to use assembly extensively.)
OTOH you can write stuff like `*src++ = *dst++`, and it would neatly compile into something like `movb (R1)+, (R2)+`, a single opcode on a PDP-11.
It’s worse—-almost all of them already use a nonstandard variant of C. The committee is bending over backwards to accommodate them, but they literally _do not care what the standard says_, so this doesn’t even benefit them. Most will keep using a busted C89 toolchain with a haphazard mix of extensions no matter what the standard does.
Even if they fork the language, standard still provides the common baseline for all, which is useful.
This is purely compiler side and usually those esoteric hosts are not running the compiler, being cross compiled but cross compiled, aren't they?
Well and studiously not talking to the few about their actual needs.