This is gold, if it will actually work.
I will cross my fingers, and try it.
ZZ is a modern formally provable dialect of C
41–50 of 157 posts
Re: ZZ is a modern formally provable dialect of C
#42> where we still program C out of desperation I agree it's the standard and the only thing that actually works (author's words), but it's still a pleasure for me to write and have to deal with C (for embedded). I'd be desperate if I have to be forced to deal with huge different paradigms because pointer problems or insert-your-C-rant-here . C is not going to be replaced on embedded any moment soon.
I hope that with IoT we get some commoditization and standardization in this space. Though ARM doesn't give me much hope. I don't get why there couldn't be 1-2-3-5 standard architectures and 10-20-50-100 hardware configurations that cover the full spectrum of embedded configurations. We've had 32 bit x86 CPUs since 1985, surely we could produce a 100Mhz one for cheap enough that nobody would need to use 8 bit ones in…
ESP32 is a very good example.
We already had plenty of high level languages running on CP/M, MS-DOS, Amiga, Atari, ... class hardware.
Those languages would already fly on ESP32.
Re: ZZ is a modern formally provable dialect of C
#43> where we still program C out of desperation I agree it's the standard and the only thing that actually works (author's words), but it's still a pleasure for me to write and have to deal with C (for embedded). I'd be desperate if I have to be forced to deal with huge different paradigms because pointer problems or insert-your-C-rant-here . C is not going to be replaced on embedded any moment soon.
> C is not going to be replaced on embedded any moment soon. Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced in embedded.
The issue is social, not technical.
There are several alternatives to C, when a team is open minded.
Re: ZZ is a modern formally provable dialect of C
#44Earlier quoted context omitted.
> Every embedded/kernel/driver developer know what they are doing. Yet we still see security issues in all of those. I'm not saying that everything should be re-written in a different language, but C developers saying "I'm a good developer, all those safety mechanisms would hold me back" doesn't hold water considering all the security vulnerabilities we see that would have been prevented if they had used a language w…
> Yet we still see security issues in all of those That's the typical excuse. That's the FUD I mentioned about. Bugs will keep existing and so security issues, no matter the language you use.
We need regulation to make companies liable for CVEs, then this will stop being FUD, easy.
Re: ZZ is a modern formally provable dialect of C
#45Earlier quoted context omitted.
The answer is size, power consumption and most of all, price. I know I can do a wrist watch with a Raspberry Pi, but will it be profitable/convenient?
Well, let's say I take the Intel P54 ( https://en.wikipedia.org/wiki/List_of_Intel_microprocessors#... ) as an example. So basically an Intel Pentium from 1994, so from 26 (!) years ago. Size: 90 mm2, maximum power consumption: 10W, price at launch: $699. Buuuut: production process 600nm. Today every Intel CPU uses a 14nm production process, but let's go for a cheaper option and "use" the 22nm. So the gate size is ~3…
Then you need external RAM, storage, a video card or companion chip for a display, a chip for holding the BIOS and a power supply (if not many) for all that. x86 as is, is not good enough for my wrist watch.
You can use a small ARM with integrated flash, RAM and LCD controller. Does it need MMU for Linux? There is family of products for that. Or use another family for bare-metal systems.
You can see how the thing starts to complicate regarding architectures/platforms.
Re: ZZ is a modern formally provable dialect of C
#46> where we still program C out of desperation I agree it's the standard and the only thing that actually works (author's words), but it's still a pleasure for me to write and have to deal with C (for embedded). I'd be desperate if I have to be forced to deal with huge different paradigms because pointer problems or insert-your-C-rant-here . C is not going to be replaced on embedded any moment soon.
> but it's still a pleasure for me to write and have to deal with C But wouldn't you love a C with things like first class support for arrays and support for namespaces / modules, etc.
There is a language called D
Re: ZZ is a modern formally provable dialect of C
#47> where we still program C out of desperation I agree it's the standard and the only thing that actually works (author's words), but it's still a pleasure for me to write and have to deal with C (for embedded). I'd be desperate if I have to be forced to deal with huge different paradigms because pointer problems or insert-your-C-rant-here . C is not going to be replaced on embedded any moment soon.
> C is not going to be replaced on embedded any moment soon. Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced in embedded.
Rust is not mature, and people don't like Mozilla now
Re: ZZ is a modern formally provable dialect of C
#48Earlier quoted context omitted.
Well, let's say I take the Intel P54 ( https://en.wikipedia.org/wiki/List_of_Intel_microprocessors#... ) as an example. So basically an Intel Pentium from 1994, so from 26 (!) years ago. Size: 90 mm2, maximum power consumption: 10W, price at launch: $699. Buuuut: production process 600nm. Today every Intel CPU uses a 14nm production process, but let's go for a cheaper option and "use" the 22nm. So the gate size is ~3…
Then you need external RAM, storage, a video card or companion chip for a display, a chip for holding the BIOS and a power supply (if not many) for all that. x86 as is, is not good enough for my wrist watch. You can use a small ARM with integrated flash, RAM and LCD controller. Does it need MMU for Linux? There is family of products for that. Or use another family for bare-metal systems. You can see how the thing sta…
Well, I just used the Pentium example because it was easy to source the data :-)
But my main point was to dump super old and limited architectures when these days we can economically use modern architectures we use everywhere else (x86/ARM/MIPS, whatever). If we wanted to, we could literally hoist designs from 20+ years ago and use newer production technologies to make them embeddable.
Using mainstream tech stacks is very empowering. Updated compilers everywhere, many programming languages and stacks with huge communities everywhere, modern debugging tools at low/no cost, fast debug cycles, etc.
But there's little interest in this because which self-respecting hardware maker would commoditize its own products? :-D
Re: ZZ is a modern formally provable dialect of C
#49Earlier quoted context omitted.
> but it's still a pleasure for me to write and have to deal with C But wouldn't you love a C with things like first class support for arrays and support for namespaces / modules, etc.
With years you get to put together a swiss-army toolset of libraries to deal with all that (like arrays, strings, etc.). You know how they work, how far you can push them, the overhead, and all. Do I really know how much cycles/stack it takes to do std::sort(a.begin(), a.end()); in that specific platform? No, so I cannot trust it. I know it's reinventing the wheel, but I am sure that there are known simple libraries…
>Do I really know how much cycles/stack it takes to do std::sort(a.begin(), a.end()); in that specific platform? No, so I cannot trust it.
I also don't know how many cycles it takes for my implementation of quicksort apart from checking the output of a specific compiler and counting instructions. C is not, was not and will never be a portable assembler.