Although forth require BIOS. Try writing forth when there is no forth interpreter or any BIOS. By 8K, that includes everything. I'd like to see a 64-bit 4th program compete. I highly doubt it would. In my case there is no BIOS since this bootloader is the very first thing that executes once the chip exits reset.
Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
Unless, of course, you have multiple registers with ordering constraints between them (e.g. write some data into one register, toggle a flag in another), because the volatile keyword in C does not give any guarantees of ordering between accesses to different volatile objects and the compiler is completely free to reorder the write to the flag before the write to the data.
That is what barriers are for to guarantee the ordering or the use of accessor functions. I'm not saying that volatile is a cure-all since it is not. It is a tool that needs to be understood. On many architectures one also needs to understand that a write to memory may not actually write to memory. For example, on MIPS a SYNC instruction is needed to flush the write buffer to guarantee that the data has been written to cache memory. On processors that are not cache coherent a cache flush is also required for data structures stored in memory that are accessed via DMA by hardware and a cache invalidate is needed before the hardware updates the memory before the CPU can read it.
Things like interrupt handlers are fairly trivial to code in C.
As long as someone else is writing the assembly code that preserves state for the interrupted context, prevents the interrupt handler from being interrupted, and so on, and then calls into the C code. And with those constraints, pretty much any compiled language is equivalent.
In C the context is usually fairly small compared to many other languages.
One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts
That's pretty much true for any compiled language.
Not really. Many compiled languages need a lot of support to handle things like memory management which C does not.
There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
The flip side of this is that you either do the bounds checking yourself (and often get it wrong, leading to security vulnerabilities) and end up passing it through a compiler that isn't designed to aggressively elide bounds checks that it can prove are not needed.
Languages that do bounds checking and other hand holding generally don't work well on bare metal and in low-level (i.e. device drivers) environments. If you're relying on the language to catch your bugs then you have no business writing code in this sort of an environment. In this sort of environment a pointer often needs to be a pointer with no hand holding or the compiler or runtime trying to second guess the programmer. Compilers and languages do not understand hardware.
Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
I can't tell from the Internet. Did you actually say that with a straight face? Even moving between different versions of the same C toolchain can cause C programs that depend on undefined or implementation-defined behaviour (i.e. basically all C programs - including yours given that several of the things that you listed in another post in this thread as really nice features of C are undefined behaviour, such as casting from a long to a pointer) are now optimised into something that doesn't do what the programmer intended.
My definition of clean is that you don't have to completely re-write assembly code when moving from 32-bit to 64-bit. On many other architectures, i.e. AArch64/X86_64 you do.
I'm not saying that MIPS is perfect. I'm not saying that there's anything wrong with AARCH64, but that it is radically different than 32-bit ARM, and I agree, the changes were very badly needed for the reasons you specify. In no way can you say that the transition from ARM32 to AARCH64 is clean, however. The code needs to be completely rewritten.
As for GCC extensions, to the best of my knowledge all of the Cavium MIPS extensions have been upstreamed and have been for quite some time. Unlike most MIPS vendors we actually have a sizeable compiler and toolchain team which has also been very active with AARCH64.
As for bitfield manipulation instructions they are there. Look up the ins (insert), ext (extract), bbit1 (branch if bit 1) and bbit0 (branch if bit 0) instructions. I use them extensively in my code. I know AARCH64 has similar instructions that are even more powerful.
Cavium actually had to teach ARM about atomic instructions, hence their addition in ARMv8.1 because the load linked/store conditional instructions don't scale. As far as I know we're still trying to get ARM to add transactional memory support (something we support in our MIPS chips) which is better than atomics on pairs. A big reason why they have the atomic instructions was because Cavium pushed hard for them because of our experience with chips with a large number of cores and scaling.
Also, the branch likely instructions had been deprecated for a very long time. Patching a binary is actually pretty trivial since the instructions just need to be replaced with the non-likely equivalent.
As for your hi/lo registers, that was done because the result exceeds what could be held in a single register. There's always the mul/dmul instructions introduced in MIPSv6 which does not use the hi/lo registers when you don't care about overflowing the target register. The hi/lo come mostly from the 32-bit days in order to handle a 64-bit result and the effect it had on the pipeline.
In this particular case it was taking advantage of polymorphism in the main data path of a network driver (ATM networking, LAN emulation). The inheritance tree was quite short and kept to a minimum. This was because it could emulate different types of networks. Overall I don't think there was any additional overhead from C++ vs the same functionality written in C which would have needed function pointers instead of virtual functions.
While most of my work is for chips that are vastly more powerful than what is found in IoT devices I work on bootloaders and bare-metal programming. In some cases memory is a premium. With only a couple of exceptions, all of the work I have done has always been with C. Most small micros are programmed in C almost exclusively with a sprinkling of assembly.
C is very good for working closely with the hardware and in memory constrained environments. C code does exactly what it says. There is no hidden overhead. The runtime needed to run C code is pretty minimal. All it really needs to get going is often a few registers initialized and a stack and it's ready to go.
It works beautifully with memory mapped registers and data structures which are extremely common in this environment. There's even a keyword designed for this, volatile, that is not present in most other languages (or it does not do the same thing).
I can use a bitfield to define hardware registers and just map a pointer to the address of that register and use it. Mixing in assembly code is easy if it's needed, though generally I find that assembly code isn't needed very often.
It's also easy to generate a binary blob using C, a linker script and a tool like objcopy.
My experience has mostly been with 64-bit MIPS and some ARMV8 but it applies to most embedded processors. The output of the C compiler when optimizing for size (with the right options set) is pretty close to hand optimized assembly and often even better because the compiler does things that would make the code otherwise hard to read or maintain. The runtime overhead of C is minimal.
C's flexibility with pointers is also a huge plus. I can easily convert between a pointer and an unsigned long (or unsigned long long) and back as needed, or typecast to a different data type and pointer arithmetic is trivial. There is no hidden bounds checking or pointer checking to worry about. Many people say that's a bad thing, but when you're working close to the metal it can really turn into a major pain in the you know what. Master pointers and know how and when to typecast them. I've seen too many times where people screw up pointer arithmetic. I once spent several weeks tracking down a bug that showed up in one of my large data structures where I saw corruption. It turned out that some totally unrelated code written by somebody else in a totally different module was written by someone who didn't understand pointer arithmetic and was spewing data all over the place other than where it should be. He also didn't realize that when you get data from a TCP stream you don't always get the amount of data you ask for, it could be less.
I have been writing low-level device drivers and bootloaders for over 20 years and while programming has changed significantly for more powerful systems in userspace, for low level programming it has changed very little. My advice is to learn C and learn it well. Know what some of those keywords mean like static and volatile. Anyone who interviews in my group damned well better know what volatile means and how to use it.
C isn't a very complicated language but it takes time to properly master. It also doesn't hold your hand like many modern languages, which is why you often hear it is easy to have things like buffer overflows or stack overflows and it's also easy to shoot yourself in the foot. It doesn't have many of the modern conveniences, but those conveniences often come at a cost in terms of memory and performance.
The best book I've seen on the language was written by the authors of the language. It's not very long but it is concise and well written.
I have also worked on C++ device drivers. While the overhead of C++ itself is generally minimal, it depends that you use only a subset of C++ and you have to know what C++ is doing behind the sce
He is absolutely correct. There are some aspects where the two languages diverge. The way you program in C tends to be very different compared to the way C++ code is written. I have worked with both extensively for low-level projects (i.e. bare metal device drivers).
Rust handles things like low-level bare metal poorly. What happens when you don't have a nice operating system underneath you? What happens when you're dealing with bitfields and memory mapped hardware registers? C is very well designed for this, and even has a keyword, volatile, for just such occurrences. Rust hand-holding becomes a major hinderance and gets in the way. C is very efficient with minimal language overhead. I can have C code running from the reset vector with only a page or two of assembly code on the 64-bit MIPS processors I deal with, and that includes stack. The output from the compiler with the right optimization features rivals hand tuned assembly and often beats it in terms of space requirements. C doesn't require any external libraries. I've written plenty of bare metal bootloaders in C with minimal assembly that do an incredible amount of stuff with very limited memory.
I have a bootloader that includes drivers for SD cards, embedded MMC (managed flash memory chips frequently found on embedded devices, phones and tablets), FAT filesystem support (FAT16 and FAT32), partitioning support and serial drivers in under 8K, and this is for a 64-bit 48-core network processor running in 64-bit mode that happens to run Linux.
There are a lot of things C can do that Rust cannot, and in many cases, the safety and hand holding of Rust just gets in the way. I need pointers to specific memory addresses, for example, and I don't want bounds checking or thread support.
Try writing an interrupt handler in Rust. Good luck with that.
I love MIPS assembly. I actually have a page of MIPS assembly open at this very moment. In terms of programming, it's beautifully designed. The extension from 32-bit to 64-bit is pretty seamless. The only real gotchas are the branch delay slots, but I actually find it to be a nice challenge to fill those slots. (I always have.set noreorder set).
MIPS assembly is extremely clean, far cleaner than ARM, for example, and the online documentation is superb. I like the MIPS Architecture for Programmers Volume II. Volumes 1 and 3 are also useful. I have yet to find as clean of a document covering ARMv8.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
MIPS is still used in many Internet appliances and home routers, though things are quickly moving to ARM. One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM. The differences are bigger IMO than the switch from X86 to X86_64. Another advantage of MIPS is that the licensing costs are quite a bit lower than for ARM.
Actually most modern languages fall apart since you need a certain feature set at the low level that high-level languages try and protect you from. Many languages have significant overhead required just to use the language and thus don't work well in low memory situations.
I have written a number of bootloaders that have to fit in 8K of RAM. There is absolutely no way I could write them in anything other than C and a minimal amount of assembly. C code can be very efficient with modern compilers optimized for size. I'd put them close to carefully coded assembly. Often the C code is smaller than assembly because the compiler will make choices that the assembly programmer will avoid just for readability and maintainability.
Most higher level languages do hand holding with things like pointers and memory management which get in the way and consume a lot of resources. C is very good for low level bare metal programming. All that pointer checking and other features have a cost in terms of size and performance.
Properly written C++ actually has fairly minimal overhead from my experience, though in this case you want to limit what features you use in C++ and how you use it. Like you say, though, it's easy to get carried away and get a lot of bloat.
I have worked in one such environment. While C++ was nice there was still a lot of work needed to make it work properly, though this was 20 years ago for a large 100K C++ driver for OS/2 that ran in kernel space. The main thing was to not go overboard with C++ features and for performance reasons to keep the class hierarchy short (non performance-critical code didn't have this issue). This seems to be the exception rather than the rule though. Other than that project, everything else I have dealt with was in C and I don't really consider Arduino C++.
Properly written, the overhead from C++ was pretty minimal. The driver binary was around 1MB. The interesting part was that we had an equivalent driver for Windows NT written in C that was 360K lines of code with a significantly larger binary and the C code was much buggier and harder to work with. Compilers have improved significantly since that time but I recall that with the C++ code only one specific version of the compiler could be used, Watcom 10.0b as I recall. 10.0c, the updated version, could not be used.
Implementing the assembly code to support C is trivial compared to the minimal code required to support C++.
I work at a company that makes chips for IoT, though in this case the chips are targeted at things like routers, switches, network security appliances and highly intelligent network cards. While C++ is supported, all of the stuff I work on is C. Our SDK is C. All of the vendor SDKs I've come across for dealing with different devices are written in C. Interfacing to C is fairly simple and well understood compared to introducing C++ in an embedded environment. Now the environment I deal with is either the Linux kernel or lower, usually lower since I work with bare metal most of the time.
C is used for a number of reasons. 1. The generated code is quite fast and fairly compact. With my experience with MIPS the output of the compiler is pretty close to hand-tuned assembly in most cases. 2. It's easy to deal with hardware registers in C. Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them. 3. There is no unintended overhead or hidden behavior. With C it is very much what you see is what you get. It doesn't do stuff under the covers. 4. Memory mapping data structures and things like that are very easy in C. 5. One is not dependent on things like a certain standard library. The amount of code needed for basic C support is fairly minimal. All you really need is a stack. I have plenty of code that does not have a heap. 6. Things like interrupt handlers are fairly trivial to code in C. 7. One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts. 8. There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way. 9. Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much. 10. C seems to resist bloat better than other languages, in part because it does exactly what you tell it to and nothing more.
Much of this can apply to C++ as well, though C++ requires a lot more overhead in order to properly support it due to some of the language features and C++ can hide certain things if you aren't careful.
That's not to say that things can't be written in high-level languages. There is plenty of flexibility once you get to something like a Raspberry Pi user-space program.
Arduino uses a subset of C++ but it's such a small subset that it might as well be C.
I write this as someone who has been writing embedded C code and assembly (98% C) for the last 20 years, though I have also worked on a few C++ projects as well. Most of this was device drivers, Vx Works, bootloaders (U-Boot and custom), bare metal applications and SDKs (dealing with high speed networking, 1, 2.5, 5, 10, 25 and 40Gbps) and some Linux kernel work and Arduino. I've worked with a variety of different CPU architectures (Intel, MIPS, ARM, PowerPC and more) including one that ran a functional programming language natively in hardware (the processor was physically incapable of running C code).
Sadly I run into that a lot, and I've interviewed a lot of people for low-level (i.e. bare metal) programming. Generally speaking, C is a fairly simple language, but in my line of work you better know damned well what various keywords mean and how they behave (like volatile) and know pointers backwards and forwards.
I agree. I write bootloaders for multi-core 64-bit processors. I've mostly been working on MIPS. C is very easy to get running. In one of my bootloaders which boots off of a SD card or eMMC chip all of the assembly code fits inside the 512-byte boot sector, and that includes the partition table and some UART functions because I had extra space. Most code is written in C. The C compiler does close to hand-tuned assembly code in terms of code density and the compiler often makes decisions that only a well seasoned assembly programmer would think of. C code provides a lot of flexibility but it also keeps the overhead to a minimum. You know exactly what the code will do. There is no hidden garbage collection or anything else. A pointer is just that, an actual address. You can easily convert them to an unsigned long or other numerical representation. You can also easily do things like have bitfields that map directly to hardware registers.
On the processors I work with we have scripts that parse the hardware design and generate bitfields and addresses for all of the hardware registers (and there are many thousands of them on the chips I work with). C is the language to use when you want to get down and dirty with the hardware. On top of that, with gcc and many other compilers it is easy to incorporate inline assembly where needed since there are instructions and things that the compiler will not know how to properly deal with. It's also easy to call C code from assembly or assembly code from C.
Working down at the hardware level you have to know what the language is doing and C does this very well and has all the constructs to do this. For example, the volatile keyword is perfect for mapping a pointer to a memory-mapped hardware register since that tells the compiler that the value can change at any time and not to cache it.
That's not to say that other languages can't also be used. At one point I worked on a large (100K lines of code) kernel-level device driver that was written almost entirely in C++. There was a huge amount of work that was needed to make it work. The drawback was that only one particular version of the Watcom compiler could be used. It had to be 10.1b (I don't remember the exact version but it was 10 something b). Revision C could not be used. There was all sorts of magic that had to be implemented in order to support some of the memory magic that went on due to C++. This was also before exceptions. While the driver worked great and was easy to maintain once all the magic had been implemented, it also required a lot more skill to work with compared to C since one had to know all the caveats involved.
From my initial reading of Rust, it would have major problems due to the way it deals with pointers. If the language is holding your hand to be "memory safe" then there's a good chance it won't work well when dealing with low-level stuff.
Another advantage of C is that there is minimal overhead. C isn't going to do crap behind the scenes. If you assign an array it's just a block of indexed memory with minimal overhead.
Things like pointer arithmetic and typecasting are extremely useful. I can't count the number of times I need to map between a pointer and a unsigned long (or unsigned long long) and it's easy to switch between them.
Features like the volatile keyword in C are extremely useful, and most higher-level languages don't support that (C++ does). Java and C# have the keyword but it doesn't mean the same thing. In C one can also implement things like read and write barriers which are needed for drivers that talk to the hardware.
She earns $11/hour as a teaching assistant (and often doesn't get 40 hours/week) and requires a medication that cost $5000/month to stay alive, on top of needing Epipens. Her medicine is (surprisingly), not one being gouged by the pharmaceutical industry either, it's just really expensive to obtain. Her work insurance doesn't cover her medication and the deductible is so high there's no way she could afford it. With the ACA she was able to get a plan that covers her needed medicine.
I also know several people that are actually able to get insurance because of the ACA. They work jobs that don't offer medical benefits and aren't paid very much.
And insurance rates were going up quickly long before Obamacare. If anything, it slowed the rate of increase. I'm not saying it's perfect, far from that, but it is generally much better than what we had before. I had a self-employed friend who in the 2000s had a stroke and her insurance company declared it a pre-existing condition and refused to cover it, despite being fully insured. It bankrupted her since her hospital stay was several months long and after having a stroke she was in no condition to fight it (it took months for her to regain speech). If the ACA had been in place then this would not have happened. The whole thing destroyed her and she later died in part because of that.
Another friend of mine was in a bad motorcycle accident. Without the ACA he'd be either dead or completely bankrupt. The insurance company tried to claim he should be discharged from the hospital to fend for himself with two badly broken arms and a broken leg. He couldn't even feed himself. If they had cut him off like they tried he would have lost the use of his dominant arm completely. Because of the ACA he was able to fight it because without it he would have hit their maximum. Today he's one of the top engineers at a company that makes products you'd recognize in just about every hardware store. His code runs on a product any geek or construction worker would instantly recognize. He likes to bitch and moan about the ACA, but at the end of the day it is what kept him out of bankruptcy and kept him from being a complete cripple for the rest of his life.
Obamacare is far from perfect, but it is far better than what we had before. Ideally I'd like to see Medicare opened to all and have private insurance be supplemental insurance. Before the ACA, if you had a cheap plan and you really needed to use your insurance for something expensive you'd likely be sol. Death panels? The insurance industry already had those. They could declare you hit the limit or that you had a preexisting condition and not cover you. And premiums were increasing at an insane rate before the ACA. 2014-2015 were artificially low for the ACA since the insurance industry was still trying to get a handle on things. 2016 is actually where the OMB predicted it would be.
It depends on the car. I drove a Dodge Challenger which had a very touchy accelerator. It was difficult to maintain a constant speed in that car. My model S P85, by comparison, has a fairly gradual acceleration curve, though if I mash it there's no hesitation. In general, my Model S is very forgiving considering the massive torque and high horsepower. The traction and stability control work very well, though if you're not used to it, the acceleration is basically instantaneous without hesitation.
One difference is that the Tesla generally handles quite well under hard acceleration. The car was not in ludicrous mode since that requires prep and a standing start. The traction and stability control in the Tesla is quite good. My P85 is quite forgiving and from everything I've heard the all wheel drive models are quite a bit better yet. A lot of this is probably due to the fact that the electric motor reacts virtually instantaneously and the traction control has millisecond accuracy.
It still makes sense to respect a vehicle with a lot of horsepower and know how your vehicle will respond.
Even as far as muscle cars go the Tesla is pretty forgiving. I drive a P85. It's harder than one might think to fuck up and the all-wheel drive improves the handling quite a bit. Of course you have to respect the acceleration but its ability to maintain control under acceleration is quite good. The traction control is far more responsive than what is possible with an ICE vehicle.
While I don't have the new P90D or P100D I can attest that my Tesla P85 does accelerate quite nicely, even at highway speeds and it reacts nearly instantaneously. It's not the car's fault that the drunk driver lost control. When you have a performance car, you have to respect it. As far as performance cars go, my model S seems to be quite forgiving with it easy to maintain control even under hard acceleration. I can't comment on the newer all-wheel drive P models, but from what I've heard they're even better.
I've read about a number of very bad accidents with the model S where people walked away unharmed such as this accident where a 40 ton big-rig rear-ended a 5000-pound model S at 40MPH. Here's another one. The most interesting part is where he says, “I was pushed off road a good 100 ft. Initially, I was thinking I wouldn’t be able to get the car out But with some assistance from the tow truck driver & firemen I was able to drive it back on the road and eventually home.”
Pb lead acid batteries suck for cycling, though, and they do require temperature monitoring to maintain proper charge. The AGM batteries in my UPSes die after 3-4 years with very light usage. The laptop batteries are not designed to last very long and they're typically charged to100% and drained to zero, both of which are very hard on the cells. The Li-ion batteries in my Tesla are doing just fine after 4 years and 50K miles. I haven't noticed much drop in range nor any change in performance compared to when I bought the car 4 years ago. Laptop batteries are optimized for capacity and not for lifetime. The batteries in my car are optimized to be a lot more rugged and long-lived. Cell phone batteries are optimized for capacity, longevity be damned because they want you to buy a new phone every two years.
It all depends on how well the batteries are maintained and how they're used. The quickest way to kill a Pb battery is to cycle it, i.e. actually use it.
The cost of Li-ion cells has dropped radically. It's estimated that the battery packs Tesla uses cost under $190/kwh and they have an excellent lifetime and they generally have a good safety record. At $190/KWh, a 50KWh pack would cost around $9500. Their cells also seem to be quite reliable. I have 50K miles on my model S and have not noticed any drop in range or performance compared to when I bought it 4 years ago.
They do that near my house. They installed inflatable dams on Alameda Creek where they pump the water from behind those dams into disused quarry pits so the water goes directly into the aquifer. After decades of pumping out the water for quarrying the aquifer has been refilled, at least before the drought.
There's only so much they can do. In my area they actually do this. As water drains from the Calaveras reservoir, inflatable dams on Alameda creek near my home catch the water which is then pumped into abandoned quarry pits to refill the aquifer. They've been doing this for decades and actually raised the water table quite a bit. The problem is that so much water has been pumped out that in many places the land has sunk. Pumping water back in won't make the land rise back up again so some capacity is lost forever. Before the drought local aquifer was much higher than it has been for many decades, in part because the quarrys were pumping water out. California generally does quite well with water management compared to much of the country. What about the Ogallala aquifer in the mid-west that's being drained far faster than it fills up? California has the world's largest and most productive water system that manages over 40,000,000 acre feet (49km^3) of water per year..
Climate change predicts a lot of things such as more extreme weather events becoming more common. The California drought is the worst that's happened in the state in the last 1000 years. If anything, many of the predictions were overly conservative. In 2001 the IPCC predicted that sea level would rise 2mm/year. It's actually rising 3.3mm/year. They predicted that the arctic ice sheet would melt in 50-70 years in 2006. It's now predicted to melt by 2052.
Slashdot Mirror
Although forth require BIOS. Try writing forth when there is no forth interpreter or any BIOS. By 8K, that includes everything. I'd like to see a 64-bit 4th program compete. I highly doubt it would. In my case there is no BIOS since this bootloader is the very first thing that executes once the chip exits reset.
Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
Unless, of course, you have multiple registers with ordering constraints between them (e.g. write some data into one register, toggle a flag in another), because the volatile keyword in C does not give any guarantees of ordering between accesses to different volatile objects and the compiler is completely free to reorder the write to the flag before the write to the data.
That is what barriers are for to guarantee the ordering or the use of accessor functions. I'm not saying that volatile is a cure-all since it is not. It is a tool that needs to be understood. On many architectures one also needs to understand that a write to memory may not actually write to memory. For example, on MIPS a SYNC instruction is needed to flush the write buffer to guarantee that the data has been written to cache memory. On processors that are not cache coherent a cache flush is also required for data structures stored in memory that are accessed via DMA by hardware and a cache invalidate is needed before the hardware updates the memory before the CPU can read it.
Things like interrupt handlers are fairly trivial to code in C.
As long as someone else is writing the assembly code that preserves state for the interrupted context, prevents the interrupt handler from being interrupted, and so on, and then calls into the C code. And with those constraints, pretty much any compiled language is equivalent.
In C the context is usually fairly small compared to many other languages.
One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts
That's pretty much true for any compiled language.
Not really. Many compiled languages need a lot of support to handle things like memory management which C does not.
There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
The flip side of this is that you either do the bounds checking yourself (and often get it wrong, leading to security vulnerabilities) and end up passing it through a compiler that isn't designed to aggressively elide bounds checks that it can prove are not needed.
Languages that do bounds checking and other hand holding generally don't work well on bare metal and in low-level (i.e. device drivers) environments. If you're relying on the language to catch your bugs then you have no business writing code in this sort of an environment. In this sort of environment a pointer often needs to be a pointer with no hand holding or the compiler or runtime trying to second guess the programmer. Compilers and languages do not understand hardware.
Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
I can't tell from the Internet. Did you actually say that with a straight face? Even moving between different versions of the same C toolchain can cause C programs that depend on undefined or implementation-defined behaviour (i.e. basically all C programs - including yours given that several of the things that you listed in another post in this thread as really nice features of C are undefined behaviour, such as casting from a long to a pointer) are now optimised into something that doesn't do what the programmer intended.
Yes I did and on
My definition of clean is that you don't have to completely re-write assembly code when moving from 32-bit to 64-bit. On many other architectures, i.e. AArch64/X86_64 you do.
I'm not saying that MIPS is perfect. I'm not saying that there's anything wrong with AARCH64, but that it is radically different than 32-bit ARM, and I agree, the changes were very badly needed for the reasons you specify. In no way can you say that the transition from ARM32 to AARCH64 is clean, however. The code needs to be completely rewritten.
As for GCC extensions, to the best of my knowledge all of the Cavium MIPS extensions have been upstreamed and have been for quite some time. Unlike most MIPS vendors we actually have a sizeable compiler and toolchain team which has also been very active with AARCH64.
As for bitfield manipulation instructions they are there. Look up the ins (insert), ext (extract), bbit1 (branch if bit 1) and bbit0 (branch if bit 0) instructions. I use them extensively in my code. I know AARCH64 has similar instructions that are even more powerful.
Cavium actually had to teach ARM about atomic instructions, hence their addition in ARMv8.1 because the load linked/store conditional instructions don't scale. As far as I know we're still trying to get ARM to add transactional memory support (something we support in our MIPS chips) which is better than atomics on pairs. A big reason why they have the atomic instructions was because Cavium pushed hard for them because of our experience with chips with a large number of cores and scaling.
Also, the branch likely instructions had been deprecated for a very long time. Patching a binary is actually pretty trivial since the instructions just need to be replaced with the non-likely equivalent.
As for your hi/lo registers, that was done because the result exceeds what could be held in a single register. There's always the mul/dmul instructions introduced in MIPSv6 which does not use the hi/lo registers when you don't care about overflowing the target register. The hi/lo come mostly from the 32-bit days in order to handle a 64-bit result and the effect it had on the pipeline.
In this particular case it was taking advantage of polymorphism in the main data path of a network driver (ATM networking, LAN emulation). The inheritance tree was quite short and kept to a minimum. This was because it could emulate different types of networks. Overall I don't think there was any additional overhead from C++ vs the same functionality written in C which would have needed function pointers instead of virtual functions.
While most of my work is for chips that are vastly more powerful than what is found in IoT devices I work on bootloaders and bare-metal programming. In some cases memory is a premium. With only a couple of exceptions, all of the work I have done has always been with C. Most small micros are programmed in C almost exclusively with a sprinkling of assembly.
C is very good for working closely with the hardware and in memory constrained environments. C code does exactly what it says. There is no hidden overhead. The runtime needed to run C code is pretty minimal. All it really needs to get going is often a few registers initialized and a stack and it's ready to go.
It works beautifully with memory mapped registers and data structures which are extremely common in this environment. There's even a keyword designed for this, volatile, that is not present in most other languages (or it does not do the same thing).
I can use a bitfield to define hardware registers and just map a pointer to the address of that register and use it. Mixing in assembly code is easy if it's needed, though generally I find that assembly code isn't needed very often.
It's also easy to generate a binary blob using C, a linker script and a tool like objcopy.
My experience has mostly been with 64-bit MIPS and some ARMV8 but it applies to most embedded processors. The output of the C compiler when optimizing for size (with the right options set) is pretty close to hand optimized assembly and often even better because the compiler does things that would make the code otherwise hard to read or maintain. The runtime overhead of C is minimal.
C's flexibility with pointers is also a huge plus. I can easily convert between a pointer and an unsigned long (or unsigned long long) and back as needed, or typecast to a different data type and pointer arithmetic is trivial. There is no hidden bounds checking or pointer checking to worry about. Many people say that's a bad thing, but when you're working close to the metal it can really turn into a major pain in the you know what. Master pointers and know how and when to typecast them. I've seen too many times where people screw up pointer arithmetic. I once spent several weeks tracking down a bug that showed up in one of my large data structures where I saw corruption. It turned out that some totally unrelated code written by somebody else in a totally different module was written by someone who didn't understand pointer arithmetic and was spewing data all over the place other than where it should be. He also didn't realize that when you get data from a TCP stream you don't always get the amount of data you ask for, it could be less.
I have been writing low-level device drivers and bootloaders for over 20 years and while programming has changed significantly for more powerful systems in userspace, for low level programming it has changed very little. My advice is to learn C and learn it well. Know what some of those keywords mean like static and volatile. Anyone who interviews in my group damned well better know what volatile means and how to use it.
C isn't a very complicated language but it takes time to properly master. It also doesn't hold your hand like many modern languages, which is why you often hear it is easy to have things like buffer overflows or stack overflows and it's also easy to shoot yourself in the foot. It doesn't have many of the modern conveniences, but those conveniences often come at a cost in terms of memory and performance.
The best book I've seen on the language was written by the authors of the language. It's not very long but it is concise and well written.
The C Programming Language by Brian W. Kernighan and Dennis M. Richie.
I have also worked on C++ device drivers. While the overhead of C++ itself is generally minimal, it depends that you use only a subset of C++ and you have to know what C++ is doing behind the sce
The overhead of javascript is still significant compared to C.
He is absolutely correct. There are some aspects where the two languages diverge. The way you program in C tends to be very different compared to the way C++ code is written. I have worked with both extensively for low-level projects (i.e. bare metal device drivers).
BS.
Rust handles things like low-level bare metal poorly. What happens when you don't have a nice operating system underneath you? What happens when you're dealing with bitfields and memory mapped hardware registers? C is very well designed for this, and even has a keyword, volatile, for just such occurrences. Rust hand-holding becomes a major hinderance and gets in the way. C is very efficient with minimal language overhead. I can have C code running from the reset vector with only a page or two of assembly code on the 64-bit MIPS processors I deal with, and that includes stack. The output from the compiler with the right optimization features rivals hand tuned assembly and often beats it in terms of space requirements. C doesn't require any external libraries. I've written plenty of bare metal bootloaders in C with minimal assembly that do an incredible amount of stuff with very limited memory.
I have a bootloader that includes drivers for SD cards, embedded MMC (managed flash memory chips frequently found on embedded devices, phones and tablets), FAT filesystem support (FAT16 and FAT32), partitioning support and serial drivers in under 8K, and this is for a 64-bit 48-core network processor running in 64-bit mode that happens to run Linux.
There are a lot of things C can do that Rust cannot, and in many cases, the safety and hand holding of Rust just gets in the way. I need pointers to specific memory addresses, for example, and I don't want bounds checking or thread support.
Try writing an interrupt handler in Rust. Good luck with that.
I love MIPS assembly. I actually have a page of MIPS assembly open at this very moment. In terms of programming, it's beautifully designed. The extension from 32-bit to 64-bit is pretty seamless. The only real gotchas are the branch delay slots, but I actually find it to be a nice challenge to fill those slots. (I always have .set noreorder set).
MIPS assembly is extremely clean, far cleaner than ARM, for example, and the online documentation is superb. I like the MIPS Architecture for Programmers Volume II. Volumes 1 and 3 are also useful. I have yet to find as clean of a document covering ARMv8.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
MIPS is still used in many Internet appliances and home routers, though things are quickly moving to ARM. One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM. The differences are bigger IMO than the switch from X86 to X86_64. Another advantage of MIPS is that the licensing costs are quite a bit lower than for ARM.
Actually most modern languages fall apart since you need a certain feature set at the low level that high-level languages try and protect you from. Many languages have significant overhead required just to use the language and thus don't work well in low memory situations.
I have written a number of bootloaders that have to fit in 8K of RAM. There is absolutely no way I could write them in anything other than C and a minimal amount of assembly. C code can be very efficient with modern compilers optimized for size. I'd put them close to carefully coded assembly. Often the C code is smaller than assembly because the compiler will make choices that the assembly programmer will avoid just for readability and maintainability.
Most higher level languages do hand holding with things like pointers and memory management which get in the way and consume a lot of resources. C is very good for low level bare metal programming. All that pointer checking and other features have a cost in terms of size and performance.
Properly written C++ actually has fairly minimal overhead from my experience, though in this case you want to limit what features you use in C++ and how you use it. Like you say, though, it's easy to get carried away and get a lot of bloat.
I have worked in one such environment. While C++ was nice there was still a lot of work needed to make it work properly, though this was 20 years ago for a large 100K C++ driver for OS/2 that ran in kernel space. The main thing was to not go overboard with C++ features and for performance reasons to keep the class hierarchy short (non performance-critical code didn't have this issue). This seems to be the exception rather than the rule though. Other than that project, everything else I have dealt with was in C and I don't really consider Arduino C++.
Properly written, the overhead from C++ was pretty minimal. The driver binary was around 1MB. The interesting part was that we had an equivalent driver for Windows NT written in C that was 360K lines of code with a significantly larger binary and the C code was much buggier and harder to work with. Compilers have improved significantly since that time but I recall that with the C++ code only one specific version of the compiler could be used, Watcom 10.0b as I recall. 10.0c, the updated version, could not be used.
Implementing the assembly code to support C is trivial compared to the minimal code required to support C++.
I work at a company that makes chips for IoT, though in this case the chips are targeted at things like routers, switches, network security appliances and highly intelligent network cards. While C++ is supported, all of the stuff I work on is C. Our SDK is C. All of the vendor SDKs I've come across for dealing with different devices are written in C. Interfacing to C is fairly simple and well understood compared to introducing C++ in an embedded environment. Now the environment I deal with is either the Linux kernel or lower, usually lower since I work with bare metal most of the time.
C is used for a number of reasons.
1. The generated code is quite fast and fairly compact. With my experience with MIPS the output of the compiler is pretty close to hand-tuned assembly in most cases.
2. It's easy to deal with hardware registers in C. Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
3. There is no unintended overhead or hidden behavior. With C it is very much what you see is what you get. It doesn't do stuff under the covers.
4. Memory mapping data structures and things like that are very easy in C.
5. One is not dependent on things like a certain standard library. The amount of code needed for basic C support is fairly minimal. All you really need is a stack. I have plenty of code that does not have a heap.
6. Things like interrupt handlers are fairly trivial to code in C.
7. One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts.
8. There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
9. Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
10. C seems to resist bloat better than other languages, in part because it does exactly what you tell it to and nothing more.
Much of this can apply to C++ as well, though C++ requires a lot more overhead in order to properly support it due to some of the language features and C++ can hide certain things if you aren't careful.
That's not to say that things can't be written in high-level languages. There is plenty of flexibility once you get to something like a Raspberry Pi user-space program.
Arduino uses a subset of C++ but it's such a small subset that it might as well be C.
I write this as someone who has been writing embedded C code and assembly (98% C) for the last 20 years, though I have also worked on a few C++ projects as well. Most of this was device drivers, Vx Works, bootloaders (U-Boot and custom), bare metal applications and SDKs (dealing with high speed networking, 1, 2.5, 5, 10, 25 and 40Gbps) and some Linux kernel work and Arduino. I've worked with a variety of different CPU architectures (Intel, MIPS, ARM, PowerPC and more) including one that ran a functional programming language natively in hardware (the processor was physically incapable of running C code).
Sadly I run into that a lot, and I've interviewed a lot of people for low-level (i.e. bare metal) programming. Generally speaking, C is a fairly simple language, but in my line of work you better know damned well what various keywords mean and how they behave (like volatile) and know pointers backwards and forwards.
I agree. I write bootloaders for multi-core 64-bit processors. I've mostly been working on MIPS. C is very easy to get running. In one of my bootloaders which boots off of a SD card or eMMC chip all of the assembly code fits inside the 512-byte boot sector, and that includes the partition table and some UART functions because I had extra space. Most code is written in C. The C compiler does close to hand-tuned assembly code in terms of code density and the compiler often makes decisions that only a well seasoned assembly programmer would think of. C code provides a lot of flexibility but it also keeps the overhead to a minimum. You know exactly what the code will do. There is no hidden garbage collection or anything else. A pointer is just that, an actual address. You can easily convert them to an unsigned long or other numerical representation. You can also easily do things like have bitfields that map directly to hardware registers.
On the processors I work with we have scripts that parse the hardware design and generate bitfields and addresses for all of the hardware registers (and there are many thousands of them on the chips I work with). C is the language to use when you want to get down and dirty with the hardware. On top of that, with gcc and many other compilers it is easy to incorporate inline assembly where needed since there are instructions and things that the compiler will not know how to properly deal with. It's also easy to call C code from assembly or assembly code from C.
Working down at the hardware level you have to know what the language is doing and C does this very well and has all the constructs to do this. For example, the volatile keyword is perfect for mapping a pointer to a memory-mapped hardware register since that tells the compiler that the value can change at any time and not to cache it.
That's not to say that other languages can't also be used. At one point I worked on a large (100K lines of code) kernel-level device driver that was written almost entirely in C++. There was a huge amount of work that was needed to make it work. The drawback was that only one particular version of the Watcom compiler could be used. It had to be 10.1b (I don't remember the exact version but it was 10 something b). Revision C could not be used. There was all sorts of magic that had to be implemented in order to support some of the memory magic that went on due to C++. This was also before exceptions. While the driver worked great and was easy to maintain once all the magic had been implemented, it also required a lot more skill to work with compared to C since one had to know all the caveats involved.
From my initial reading of Rust, it would have major problems due to the way it deals with pointers. If the language is holding your hand to be "memory safe" then there's a good chance it won't work well when dealing with low-level stuff.
Another advantage of C is that there is minimal overhead. C isn't going to do crap behind the scenes. If you assign an array it's just a block of indexed memory with minimal overhead.
Things like pointer arithmetic and typecasting are extremely useful. I can't count the number of times I need to map between a pointer and a unsigned long (or unsigned long long) and it's easy to switch between them.
Features like the volatile keyword in C are extremely useful, and most higher-level languages don't support that (C++ does). Java and C# have the keyword but it doesn't mean the same thing. In C one can also implement things like read and write barriers which are needed for drivers that talk to the hardware.
Let me see, Obamacare is keeping my sister alive.
She earns $11/hour as a teaching assistant (and often doesn't get 40 hours/week) and requires a medication that cost $5000/month to stay alive, on top of needing Epipens. Her medicine is (surprisingly), not one being gouged by the pharmaceutical industry either, it's just really expensive to obtain. Her work insurance doesn't cover her medication and the deductible is so high there's no way she could afford it. With the ACA she was able to get a plan that covers her needed medicine.
I also know several people that are actually able to get insurance because of the ACA. They work jobs that don't offer medical benefits and aren't paid very much.
And insurance rates were going up quickly long before Obamacare. If anything, it slowed the rate of increase. I'm not saying it's perfect, far from that, but it is generally much better than what we had before. I had a self-employed friend who in the 2000s had a stroke and her insurance company declared it a pre-existing condition and refused to cover it, despite being fully insured. It bankrupted her since her hospital stay was several months long and after having a stroke she was in no condition to fight it (it took months for her to regain speech). If the ACA had been in place then this would not have happened. The whole thing destroyed her and she later died in part because of that.
Another friend of mine was in a bad motorcycle accident. Without the ACA he'd be either dead or completely bankrupt. The insurance company tried to claim he should be discharged from the hospital to fend for himself with two badly broken arms and a broken leg. He couldn't even feed himself. If they had cut him off like they tried he would have lost the use of his dominant arm completely. Because of the ACA he was able to fight it because without it he would have hit their maximum. Today he's one of the top engineers at a company that makes products you'd recognize in just about every hardware store. His code runs on a product any geek or construction worker would instantly recognize. He likes to bitch and moan about the ACA, but at the end of the day it is what kept him out of bankruptcy and kept him from being a complete cripple for the rest of his life.
Obamacare is far from perfect, but it is far better than what we had before. Ideally I'd like to see Medicare opened to all and have private insurance be supplemental insurance. Before the ACA, if you had a cheap plan and you really needed to use your insurance for something expensive you'd likely be sol. Death panels? The insurance industry already had those. They could declare you hit the limit or that you had a preexisting condition and not cover you. And premiums were increasing at an insane rate before the ACA. 2014-2015 were artificially low for the ACA since the insurance industry was still trying to get a handle on things. 2016 is actually where the OMB predicted it would be.
It depends on the car. I drove a Dodge Challenger which had a very touchy accelerator. It was difficult to maintain a constant speed in that car. My model S P85, by comparison, has a fairly gradual acceleration curve, though if I mash it there's no hesitation. In general, my Model S is very forgiving considering the massive torque and high horsepower. The traction and stability control work very well, though if you're not used to it, the acceleration is basically instantaneous without hesitation.
One difference is that the Tesla generally handles quite well under hard acceleration. The car was not in ludicrous mode since that requires prep and a standing start. The traction and stability control in the Tesla is quite good. My P85 is quite forgiving and from everything I've heard the all wheel drive models are quite a bit better yet. A lot of this is probably due to the fact that the electric motor reacts virtually instantaneously and the traction control has millisecond accuracy.
It still makes sense to respect a vehicle with a lot of horsepower and know how your vehicle will respond.
Even as far as muscle cars go the Tesla is pretty forgiving. I drive a P85. It's harder than one might think to fuck up and the all-wheel drive improves the handling quite a bit. Of course you have to respect the acceleration but its ability to maintain control under acceleration is quite good. The traction control is far more responsive than what is possible with an ICE vehicle.
While I don't have the new P90D or P100D I can attest that my Tesla P85 does accelerate quite nicely, even at highway speeds and it reacts nearly instantaneously. It's not the car's fault that the drunk driver lost control. When you have a performance car, you have to respect it. As far as performance cars go, my model S seems to be quite forgiving with it easy to maintain control even under hard acceleration. I can't comment on the newer all-wheel drive P models, but from what I've heard they're even better.
I've read about a number of very bad accidents with the model S where people walked away unharmed such as this accident where a 40 ton big-rig rear-ended a 5000-pound model S at 40MPH. Here's another one. The most interesting part is where he says, “I was pushed off road a good 100 ft. Initially, I was thinking I wouldn’t be able to get the car out But with some assistance from the tow truck driver & firemen I was able to drive it back on the road and eventually home.”
Pb lead acid batteries suck for cycling, though, and they do require temperature monitoring to maintain proper charge. The AGM batteries in my UPSes die after 3-4 years with very light usage. The laptop batteries are not designed to last very long and they're typically charged to100% and drained to zero, both of which are very hard on the cells. The Li-ion batteries in my Tesla are doing just fine after 4 years and 50K miles. I haven't noticed much drop in range nor any change in performance compared to when I bought the car 4 years ago. Laptop batteries are optimized for capacity and not for lifetime. The batteries in my car are optimized to be a lot more rugged and long-lived. Cell phone batteries are optimized for capacity, longevity be damned because they want you to buy a new phone every two years.
It all depends on how well the batteries are maintained and how they're used. The quickest way to kill a Pb battery is to cycle it, i.e. actually use it.
The cost of Li-ion cells has dropped radically. It's estimated that the battery packs Tesla uses cost under $190/kwh and they have an excellent lifetime and they generally have a good safety record. At $190/KWh, a 50KWh pack would cost around $9500. Their cells also seem to be quite reliable. I have 50K miles on my model S and have not noticed any drop in range or performance compared to when I bought it 4 years ago.
They do that near my house. They installed inflatable dams on Alameda Creek where they pump the water from behind those dams into disused quarry pits so the water goes directly into the aquifer. After decades of pumping out the water for quarrying the aquifer has been refilled, at least before the drought.
There's only so much they can do. In my area they actually do this. As water drains from the Calaveras reservoir, inflatable dams on Alameda creek near my home catch the water which is then pumped into abandoned quarry pits to refill the aquifer. They've been doing this for decades and actually raised the water table quite a bit. The problem is that so much water has been pumped out that in many places the land has sunk. Pumping water back in won't make the land rise back up again so some capacity is lost forever. Before the drought local aquifer was much higher than it has been for many decades, in part because the quarrys were pumping water out. California generally does quite well with water management compared to much of the country. What about the Ogallala aquifer in the mid-west that's being drained far faster than it fills up? California has the world's largest and most productive water system that manages over 40,000,000 acre feet (49km^3) of water per year..
Climate change predicts a lot of things such as more extreme weather events becoming more common.
The California drought is the worst that's happened in the state in the last 1000 years.
If anything, many of the predictions were overly conservative.
In 2001 the IPCC predicted that sea level would rise 2mm/year. It's actually rising 3.3mm/year. They predicted that the arctic ice sheet would melt in 50-70 years in 2006. It's now predicted to melt by 2052.
Here are some predictions that came true:
1. The sea level is rising in most places, though at the high end (or higher) than original predictions (3.2mm/year vs 2mm).
2. The sea level fell near Greenland as predicted due to the loss of mass and the gravitational pull of that mass.
3. Extreme weather events were predicted to become more common with climate change. This is happening as "about 25% of moderate daily hot extremes can be attributed to warming.".
4. The predicted radiative forcing effect from CO2 has been observationally confirmed.