Suggested changes, firmware part 3: languages
- mwm
- Topic Author
- Offline
Less
More
31 Mar 2016 21:16 #45513
by mwm
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Suggested changes, firmware part 3: languages was created by mwm
Almost done - this one actually affects what I do next. Bottom line question is whether adding a language to the two already being used - and upping the total number of compilers for a release from two to three - is at all acceptable. Reasons for wanting to do that follow.
One of the interesting developments in programming languages is the emergence of languages designed to do what C does well, but incorporating some of the last four or five decades of work in the area.
For deviation, the most interesting seems to be Rust. For one thing, there is only one compiler, and it generates code for all supported CPUs. So only one compiler needs to be added to build both the firmware and the emulators. A stated goal is the ability to run well on bare metal, so it has no runtime overhead making it really nice for embedded projects.
Another is that the compiler will catch as many error as possible. This means they have algebraic data types, which have been in use in production functional languages for ~25 years, and are frankly great stuff. The type system allows the programmer to capture metadata about variables, turning logic errors into type errors. For instance, there's a type for pointers, and then there's a type for pointers that might be null. If you get the latter from a function and try and dereference it without checking for that null value, it's a type error.
Given no runtime, they have no GC. So to catch trying to use free'd variables, the compiler implements "lifetime tracking". AFAIK, this hasn't been used in a production language before, but looks like a great idea for embedded platforms. It means you get a "lifetime error" if you try and return a reference to a value that won't be available after the function exits, etc.
One of the interesting developments in programming languages is the emergence of languages designed to do what C does well, but incorporating some of the last four or five decades of work in the area.
For deviation, the most interesting seems to be Rust. For one thing, there is only one compiler, and it generates code for all supported CPUs. So only one compiler needs to be added to build both the firmware and the emulators. A stated goal is the ability to run well on bare metal, so it has no runtime overhead making it really nice for embedded projects.
Another is that the compiler will catch as many error as possible. This means they have algebraic data types, which have been in use in production functional languages for ~25 years, and are frankly great stuff. The type system allows the programmer to capture metadata about variables, turning logic errors into type errors. For instance, there's a type for pointers, and then there's a type for pointers that might be null. If you get the latter from a function and try and dereference it without checking for that null value, it's a type error.
Given no runtime, they have no GC. So to catch trying to use free'd variables, the compiler implements "lifetime tracking". AFAIK, this hasn't been used in a production language before, but looks like a great idea for embedded platforms. It means you get a "lifetime error" if you try and return a reference to a value that won't be available after the function exits, etc.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
Time to create page: 0.030 seconds
- Home
- Forum
- Development
- Development
- Suggested changes, firmware part 3: languages