The Imperium programming language - IPL

[Kalvin]

I asked ChatGPT

Better get a job in avionics.

Really, you are thinking that good design practices are beneficial only in avionics? If you have done any commercial software design and implementation, you should know by now that debugging and fixing programming errors is very time consuming and expensive. Preventing the common programming errors in the first place will be much cheaper. Therefore, the programming language should be designed such that it helps preventing making typical programming errors and blunders.

Maintaining existing code base and keeping it in good shape over multiple changes will also benefit from any help the programming language has to offer.

[DiTBho]

Really, you are thinking that good design practices are beneficial only in avionics?

No, I think real life problems need real life training, while putting a list of things taken from Wikipedia (never seen in action) is... frankly not even close to learning anything useful.

[magic]

I asked ChatGPT "Let's assume that you need to design a new programming language for embedded systems that will be targeted for safety-critical and mission-critical embedded systems, and provide safe memory handling and safe array operators. What would it be like?"

I don't know if AI will replace programmers anytime soon, but it will be a godsend for producing marketing materials

[JPortici]

Also, make sure that the new programming language will meet requirements 5 and 18.

 

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

impossible, everyone in the community will soon be in the ignore list

===============================================

By the way, Even though there is no rotate operator in C, compilers that target actitectures that have rotate instructions usually recognize particular constructs and translate them into rotate instructions

Rotate operations can be performed in your code, despite the C language not including a rotate operator.
The compiler will detect expressions that implement rotate operations using shift and logical operators and compile
them efficiently.
For the following code:
c = (c << 1) | (c >> 7);
if c is unsigned and non-volatile, the compiler will detect that the intended operation is a rotate left of 1 bit and will
encode the output using the PIC MCU rotate instructions. A rotate left of 2 bits would be implemented with code like:
c = (c << 2) | (c >> 6);
This code optimization will also work for integral types larger than a char. If the optimization cannot be applied, or
this code is ported to another compiler, the rotate will be implemented, but typically with shifts and a bitwise OR
operation.

or provide a builtin that map to the dedicated instruction (but you usually want to use the rotate in algorythms you are already writing in assembly sooooo.....)

[Kalvin]

Also, make sure that the new programming language will meet requirements 5 and 18.

 

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

impossible, everyone in the community will soon be in the ignore list

 

I read that item 18 as follows: The new programming language needs to be able to attract enough critical mass so that it will be known & accepted, stay maintained and developed (like the popular programming languages have evolved over the years), get support from the existing and new tools, and will survive many years to come without becoming extinct.

[Kalvin]

I asked ChatGPT "Let's assume that you need to design a new programming language for embedded systems that will be targeted for safety-critical and mission-critical embedded systems, and provide safe memory handling and safe array operators. What would it be like?"

I don't know if AI will replace programmers anytime soon, but it will be a godsend for producing marketing materials

I think ChatGPT gave pretty good answer, considering the fact it took only few minutes to get that list. I would consider the current state of AI as an assisting technology, and the user needs to be able to evaluate the answers for sanity, correctness and usefulness.

[DiTBho]

my HC12 book reports things in a very nice way

Logical Shift
Shift Left (Memory,A,B,D), {LSL,LSLA,LSLB,LSLD }
Shift Right (Memory,A,B,D), { LSR,LSRA,LSRB,LSRD }

Arithmetic Shift
(Similar to a Logical shift, but the sign bit remains unchanged)
Shift Left (Memory,A,B,D), { ASL,ASLA,ASLB,ASLD }
Shift Right (Memory,A,B,D), { ASR,ASRA,ASRB }

Cyclic Shift
Left (Memory,A,B), { ROL, ROLA,ROLB }
Right (Memory,A,B), { ROR, RORA,RORB }

Just, it calls "Cyclic Shift" what we call "bit Rotation", but it's the same.

I'd like to see what ICC12 (C compiler for Motorola 68HC12) would produce on a C piece of blow-fish algorithm

[Kalvin]

Really, you are thinking that good design practices are beneficial only in avionics?

No, I think real life problems need real life training, while putting a list of things taken from Wikipedia (never seen in action) is... frankly not even close to learning anything useful.

If you think about C and C++ languages for example, there are many recommendations and guidelines for producing maintainable and less buggy software (I am not talking about naming conventions and formatting here). For example MISRA-C and C++ contain a lot of recommendations that are result of a poor language design in the first place.

MISRA C/C++ recommendations are not publicly available, but similar kind of set of recommendations can be found online from ESCR: Embedded System development Coding Reference guide for C and C++languages, respectively:
https://www.ipa.go.jp/files/000065271.pdf
https://www.ipa.go.jp/files/000055042.pdf

[magic]

I think ChatGPT gave pretty good answer, considering the fact it took only few minutes to get that list. I would consider the current state of AI as an assisting technology, and the user needs to be able to evaluate the answers for sanity, correctness and usefulness.

It gave you the answers you wanted to hear, which is its whole purpose

The holy grail of marketing is here. But ask it to actually design something new and then

[Kalvin]

I think ChatGPT gave pretty good answer, considering the fact it took only few minutes to get that list. I would consider the current state of AI as an assisting technology, and the user needs to be able to evaluate the answers for sanity, correctness and usefulness.

It gave you the answers you wanted to hear, which is its whole purpose

The holy grail of marketing is here. But ask it to actually design something new and then

And, what would be your answer to that same question then? According to your reply, you have some other properties that are more important in a programming language.

[Siwastaja]

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

impossible, everyone in the community will soon be in the ignore list

This, was quite hilarious seeing the OP rage-ignoring the few world class experts who happen to hang on this forum . (You know who you are, of course.)

I can totally see in my mind where OP's "experience" is coming from: working as a middle manager who simply fires everybody who says "no" to his absolutely stupid ideas, and collects a bunch of so called "yes men" ( https://www.urbandictionary.com/define.php?term=yes%20men ) around him. And there is no shortage of yes men.

This is the classic pattern of destroying the productivity of a business, ignoring those who do understand, and spending all the time discussing the color and construction materials of the bike shed and micromanaging this discussion. And the business can appear to still run, based on buying out smaller companies with their product lines which are profitable for some time before getting destroyed. And/or outsourcing projects that need to be done, to smaller companies with different mindset.

[DiTBho]

Nice to see the MIPS.Inc SDE assembly on my copy of MIPS Architecture For Programmers

"Rotate" is a real instruction that was introduced in the MIPS32R2 revision(1) of the MIPS Architecture

Code: [Select]

//Rotate Word Right                (SmartMIPS Crypto engine)
//The contents of the low-order 32-bit word of GPR rt are rotated right
//the word result is placed in GPR rd.
//The bit-rotate amount is specified by sa

        ROTR rd, rt, sa
but if you tell your assemble that your CPU is MIPS3 (.cpu MIPS3) then assembler compiler will accept it as "pseudoinstruction" that will replace with a sequence.

LOL, funny low level 

(1) 2002/Release2
added+={ DI, EHB, EI, EXT, INS, JALR.HB, JR.HB, MFHC1, MFHC2, MTHC1, MTHC2, RDHWR, RDPGPR, ROTR, ROTRV, SEB, SEH, SYNCI, WRPGPR, WSBH }

ROTR Rotate Word Right (Release 2 Only)
ROTRV Rotate Word Right Variable (Release 2 Only)
SLL Shift Word Left Logical
SLLV Shift Word Left Logical Variable
SRA Shift Word Right Arithmetic
SRAV Shift Word Right Arithmetic Variable
SRL Shift Word Right Logical
SRLV Shift Word Right Logical Variable

[Siwastaja]

I think ChatGPT gave pretty good answer, considering the fact it took only few minutes to get that list. I would consider the current state of AI as an assisting technology, and the user needs to be able to evaluate the answers for sanity, correctness and usefulness.

It gave you the answers you wanted to hear, which is its whole purpose

The holy grail of marketing is here. But ask it to actually design something new and then

And, what would be your answer to that same question then? According to your reply, you have some other properties that are more important in a programming language.

It's a good list. A language model AI like that is pretty good in combining and summarizing widely accepted and widely known ideas, so basically a much more effective version of Google. It is also mostly correct, as it finds some kind of consensus. But all that information is something we already know (we, as in people who would be tasked with such safety critical embedded project, or designing a new language for such purpose). Possibly very helpful for someone who is trying to learn the basics of the subject, for example to understand what their team is doing, or building a team. If a designer completely ignores some of the points, or does the opposite, then it warrants a question: "why?"

[DiTBho]

If you think about C and C++ languages for example, there are many recommendations and guidelines for producing maintainable and less buggy software (I am not talking about naming conventions and formatting here). For example MISRA-C and C++ contain a lot of recommendations that are result of a poor language design in the first place.
MISRA C/C++

Sure, but ... MISRA is *ONLY* about the code 

In avionics it's DO178B level { A .. E }, so it's MISRA integrated with ICE + Eng + test-report + QA, all applied to the whole software lifecycle.

Wiki pages and university courses can simply list concepts that you can also consider separately, it doesn't make any problem, but real life avionics has to consider all the specific know-how here and there, but all reflected among both developers and testers.

So, you understand WHY you have to write your C or Ada code in a specific way. Usually, because it's useful for your ICE-AI, and/or for testers, or something that is not *MISRA* specific, but actually helps a lot with the software life-cycle.

It's like The Matrix: talking about that is not like living it. You need to see yourself.

(o'man, am I really red-pilling? or something?
Why do I feel like Morpheus? Goshh  )

[Kalvin]

If you think about C and C++ languages for example, there are many recommendations and guidelines for producing maintainable and less buggy software (I am not talking about naming conventions and formatting here). For example MISRA-C and C++ contain a lot of recommendations that are result of a poor language design in the first place.
MISRA C/C++

Sure, but ... MISRA is *ONLY* about the code 

In avionics it's DO178B level { A .. E }, so it's MISRA integrated with ICE + Eng + test-report + QA, all applied to the whole software lifecycle.

Wiki pages and university courses can simply list concepts that you can also consider separately, it doesn't make any problem, but real life avionics has to consider all the specific know-how here and there, but all reflected among both developers and testers.

So, you understand WHY you have to write your C or Ada code in a specific way. Usually, because it's useful for your ICE-AI, and/or for testers, or something that is not *MISRA* specific, but actually helps a lot with the software life-cycle.

It's like The Matrix: talking about that is not like living it. You need to see yourself.

(o'man, am I really red-pilling? or something?
Why do I feel like Morpheus? Goshh  )

I wanted to limit my writings mostly into programming language-domain, as this thread is about a [new] programming language. Of course designing and implementing an embedded system is much more than just writing code with a specific programming language.

Since we are talking about a [new] programming language, I just wanted to list a few things that should take into a consideration when designing a new language. Of course the author of a programming language is free to make his/her own design decisions.

We have already 70+ years worth of experience of different programming languages. A new programming language should take the good parts of the existing languages, and leave out or fix the bad parts. It is not a very clever idea to repeat the errors and faults of existing and past programming languages, if they could be prevented in the first place with some careful planning.

[Sherlock Holmes]

I asked ChatGPT "Let's assume that you need to design a new programming language for embedded systems that will be targeted for safety-critical and mission-critical embedded systems, and provide safe memory handling and safe array operators. What would it be like?"

A programming language for embedded systems that is targeted for safety-critical and mission-critical systems would likely have the following features:

1. Memory safety: The language would have built-in mechanisms to prevent common memory-related errors such as buffer overflows, use-after-free, and null pointer dereferences.

2. Type safety: The language would have a strong type system that helps prevent type-related errors, such as type casting errors and implicit type conversions.

3. Array bounds checking: The language would have built-in array bounds checking to prevent out-of-bounds errors when accessing arrays.

4. Automatic memory management: The language would have a garbage collector or other mechanism for automatic memory management, which would help prevent memory leaks and other related errors.

5. Strict syntax and semantics: The language would have a strict syntax and semantics, in order to minimize the chances of introducing new errors.

6. Formal verification: The language would have formal verification tools that could be used to prove the absence of certain types of errors, such as data races.

7. Strong error handling: The language would have strong error handling, in order to prevent errors from propagating and causing further issues.

8. Support for concurrency: The language would have built-in support for concurrency, in order to make it easier to write multi-threaded code that is also safe.

9. Support for functional programming: The language would support functional programming features such as immutable variables, closures, and higher-order functions, which would help make the code more predictable and less error-prone.

10. Support for hardware-level control: The language would have support for interacting with low-level hardware, in order to allow for the precise control that is often required in embedded systems.

11. Support for real-time constraints: The language would have built-in support for real-time constraints, such as hard real-time and soft real-time, allowing developers to specify time constraints and deadlines for specific operations.

12. Interoperability: The language would have the ability to interoperate with other languages, such as C and C++, which are commonly used in embedded systems. This would allow for the use of existing libraries and codebases, and make it easier to integrate the new language with existing systems.

13. Standard libraries: The language would have a comprehensive set of standard libraries, including data structures and algorithms, for use in embedded systems.

14. Compact and efficient: The language would be designed to be compact and efficient, in order to minimize memory and processing requirements, which are important considerations in embedded systems.

15. Security features: The language would have built-in security features such as secure data handling and encryption to protect against common security threats.

16. Tooling and debugging: The language would have a robust set of tooling and debugging options, allowing developers to easily locate and fix errors.

17. Documentations: The language would have comprehensive and up-to-date documentation, including tutorials, guides, and reference material, to help developers get started quickly and become proficient with the language.

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

Overall, the language would be designed with safety and reliability in mind, with a focus on preventing errors and ensuring that the code is predictable and easy to understand. It would also be efficient and flexible enough to meet the specific requirements of embedded systems.

19. Certification: The language would be designed to meet industry standards and certifications for safety-critical systems, such as ISO 26262 for automotive systems and DO-178C for avionics systems.

20. Safety-critical libraries: The language would have a set of libraries specifically designed for safety-critical systems that provide functionality such as fault-tolerance and redundancy.

21. Safety-critical constructs: The language would have constructs such as assertions and monitors that can be used to express safety properties and to check them at runtime.

22. Model-based development: The language would support model-based development, which allows for the design, verification, and validation of safety-critical systems using formal methods.

23. Traceability: The language would have traceability features that allow developers to trace requirements, design, and implementation, which is critical for safety-critical systems.

24. Auditing and logging: The language would have built-in support for auditing and logging which allows to check and trace the actions of the system and detect malfunctions that could cause safety hazards.

25. Testability: The language would be designed with testability in mind, allowing developers to easily create and execute unit tests, integration tests, and system tests to verify the correct functioning of the system.

Overall, the new programming language for embedded systems would be designed to meet the specific needs of safety-critical and mission-critical systems, providing a combination of safety, reliability, and efficiency, while at the same time meeting industry standards and certifications.

26. Design by Contract: The language would support Design by Contract (DbC) paradigm, which allows developers to express preconditions, postconditions, and class invariants that specify the expected behavior of the functions and classes, making it easier to understand and reason about the code.

27. Static analysis: The language would have built-in static analysis tools that can analyze the code and detect potential errors, such as null pointer dereferences, race conditions, and buffer overflows, before the code is even run.

28. Code review: The language would have tools and processes in place to support formal code reviews, where code is reviewed by other developers, in order to catch errors and improve the quality of the code.

29. Built-in safety mechanisms: The language would have built-in safety mechanisms such as watchdog timers, which can automatically reset the system if it becomes unresponsive, and fail-safe modes, which can be activated if a critical error is detected.

30. Support for formal verification: The language would support formal verification using tools such as model checkers, theorem provers, and static analyzers, which can be used to prove that the code meets certain safety properties.

31. Support for safety standards: The language would be designed to support safety standards such as IEC 61508 and ISO 26262, which provide guidelines for the development of safety-critical systems.

Overall, the new programming language for embedded systems would provide a comprehensive set of features for safety-critical and mission-critical systems, including memory safety, type safety, array bounds checking, automatic memory management, strict syntax and semantics, formal verification, strong error handling, support for concurrency, functional programming, and hardware-level control. Additionally, it would have features to support real-time constraints, interoperability, standard libraries, compact and efficient, security, tooling and debugging, documentation, community support and safety-critical libraries, constructs, model-based development, traceability, auditing and logging, testability, Design by Contract, static analysis, code review, built-in safety mechanisms, support for formal verification and safety standards.

This is a good list to keep in mind when designing a new programming language. Take existing programming languages used in safety-critical embedded systems (such as C, C++, Ada and Rust), implement their good features, and leave out and fix their problematic features. Also, make sure that the new programming language will meet requirements 5 and 18.

That's a superb list, very interesting indeed, I will indeed absorb this, exactly the kind of thing I'm looking for!

[Sherlock Holmes]

Also, make sure that the new programming language will meet requirements 5 and 18.

This is a requirement I value hugely. I want to reduce implementation defined and undefined behaviors as much as possible. In that regard this has been noted as likely an essential feature: order of evaluation of arguments in procedure/function calls being strictly left-to-right (as done in Java and C# and perhaps other langauges).

[tggzzz]

I wanted to limit my writings mostly into programming language-domain, as this thread is about a [new] programming language. Of course designing and implementing an embedded system is much more than just writing code with a specific programming language.
...
We have already 70+ years worth of experience of different programming languages. A new programming language should take the good parts of the existing languages, and leave out or fix the bad parts. It is not a very clever idea to repeat the errors and faults of existing and past programming languages, if they could be prevented in the first place with some careful planning.

Precisely.

Your ChatGPT post illustrates the problems society is going to have in the near future. Currently ChatGPT seems to make at least as much sense as some of the posters on this forum

We know how poorly other conversational AI systems perform in real life, often allowing themselves to be perverted (and in at least case that word was very apt) by their training sets

[magic]

I think ChatGPT gave pretty good answer, considering the fact it took only few minutes to get that list. I would consider the current state of AI as an assisting technology, and the user needs to be able to evaluate the answers for sanity, correctness and usefulness.

It gave you the answers you wanted to hear, which is its whole purpose

The holy grail of marketing is here. But ask it to actually design something new and then

And, what would be your answer to that same question then? According to your reply, you have some other properties that are more important in a programming language.

Sure, here are my two most desirable features of any software product:

1. It should be possible to develop.
2. It should solve customer's problem.

This chatbot fails at it by generating a long laundry list of features which inevitably conflict with one another and having not even a slightest idea what to compromise and how to make something useful out of it. You won't have much memory safety with C interoperability and deep integration with legacy codebases, gonna need to find some way to carefully isolate these two worlds. Garbage collection may be tricky too, what if the C code stashes references to your objects? GC also complicates the requirements for compactness and efficiency and realtime guarantees.

Collecting a list of desirable features is the easiest 1% of the job of designing software, often already done for you by others. The hard part is knowing what can't be done, what must be compromised and how to realize customer's goals while staying within the annoying limits of reality. Also, the customer is usually having an XY problem and it's better to realize it sooner than later.

These chatbots are good at collecting and summarizing Internet memes relevant to your prompt, but that's all they really do. They sound smart because they repeat the same talking points you hear everyday and everywhere from everyone - they are getting very good at picking that up. But you could get about the same results by reading some Wikipedia article or starting a thread on the orange forum. These (plus writing marketing drivel) are likely the first human provided services which will get automated away by AI


And speaking of the concrete output from the bot, I am personally quite far from anything really safety critical, but here's my $.02:
- I don't think functional programming is common practice in embedded, but the bot picked it up because f.p. fanboys surely talk about it a lot
- formal verification is a hell difficult problem being worked on since the field's inception, show us your concrete ideas, please, because anyone can simply name-drop it
- not sure what "built-in encryption to protect against common security threats" means in a programming language
- what sort of "tools and processes" you need in a language to support code review?
- watchdog timers built into a programming language - I think it got carried away a little

[tggzzz]

Collecting a list of desirable features is the easiest 1% of the job of designing software, often already done for you by others.
The hard part is knowing what can't be done, what must be compromised and how to realize customer's goals while staying within the annoying limits of reality.
Also, the customer is usually having an XY problem and it's better to realize it sooner than later.

Thus spake someone with real-world experience Too true on all counts.

[Kalvin]

And speaking of the concrete output from the bot, I am personally quite far from anything really safety critical, but here's my $.02:
- I don't think functional programming is common practice in embedded, but the bot picked it up because f.p. fanboys surely talk about it a lot
- formal verification is a hell difficult problem being worked on since the field's inception, show us your concrete ideas, please, because anyone can simply name-drop it
- not sure what "built-in encryption to protect against common security threats" means in a programming language
- what sort of "tools and processes" you need in a language to support code review?
- watchdog timers built into a programming language - I think it got carried away a little

Yes, I decided to use raw, unedited ChatGPT output and leave those into the list* although they are not really related to a programming language per se. Like I wrote before: "I would consider the current state of AI as an assisting technology, and the user needs to be able to evaluate the answers for sanity, correctness and usefulness.".

Edit: *If someone runs the same phrase, ChatGPT would spit probably a similar kind of list those items in the list anyway.

[Sherlock Holmes]

Also, make sure that the new programming language will meet requirements 5 and 18.

 

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

impossible, everyone in the community will soon be in the ignore list

===============================================

By the way, Even though there is no rotate operator in C, compilers that target actitectures that have rotate instructions usually recognize particular constructs and translate them into rotate instructions

Rotate operations can be performed in your code, despite the C language not including a rotate operator.
The compiler will detect expressions that implement rotate operations using shift and logical operators and compile
them efficiently.
For the following code:
c = (c << 1) | (c >> 7);
if c is unsigned and non-volatile, the compiler will detect that the intended operation is a rotate left of 1 bit and will
encode the output using the PIC MCU rotate instructions. A rotate left of 2 bits would be implemented with code like:
c = (c << 2) | (c >> 6);
This code optimization will also work for integral types larger than a char. If the optimization cannot be applied, or
this code is ported to another compiler, the rotate will be implemented, but typically with shifts and a bitwise OR
operation.

or provide a builtin that map to the dedicated instruction (but you usually want to use the rotate in algorythms you are already writing in assembly sooooo.....)

I've only explicitly ignored posters who are demonstrably insulting. I don't mind someone disagreeing, in fact I value disagreement but only from someone I can respect, someone who argues impersonally, I really am surprised at the ease with which some people want to descend into abuse and bickering, I have no time for that.

Now regarding rotate operators. It is absolutely right to question whether these are a good or bad idea in a new language, there are numerous potential operators one can devise - especially given the rare freedom to define a language and grammar from scratch with no externally imposed constraints.

The way to do that is to accumulate a list of potential operators that can be implemented and then sift, filter that list perhaps, remove any dead wood and so on, but to say "this is just stupid" is not the way to handle such a challenge.

Now consider this that C++ has (can) offer "_rotl" and "_rotr" and consider that Microsoft also offer rotations as part of .Net in their BitOperations static class.

I simply took the step of advocating symbolic operators for these rather than intrinsics (which use method call syntax) for two reasons, 1. Operators are universal, not tied to a particular written/spoken language and 2. They are inherently "overloaded" so to speak, whereas method call syntax demands multiple methods for multiple argument types (unless one permits overloading in the language, which is a distinct possibility).

I do perform some degree of due diligence here, I don't make up an operator just because one can, I did it because it seemed logical, it complimented the shift operators, it lends symmetry to the language, whether they be worth keeping is an open question, but it isn't "stupid" to consider the possibilities.

[Sherlock Holmes]

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

impossible, everyone in the community will soon be in the ignore list

This, was quite hilarious seeing the OP rage-ignoring the few world class experts who happen to hang on this forum . (You know who you are, of course.)

I can totally see in my mind where OP's "experience" is coming from: working as a middle manager who simply fires everybody who says "no" to his absolutely stupid ideas, and collects a bunch of so called "yes men" ( https://www.urbandictionary.com/define.php?term=yes%20men ) around him. And there is no shortage of yes men.

This is the classic pattern of destroying the productivity of a business, ignoring those who do understand, and spending all the time discussing the color and construction materials of the bike shed and micromanaging this discussion. And the business can appear to still run, based on buying out smaller companies with their product lines which are profitable for some time before getting destroyed. And/or outsourcing projects that need to be done, to smaller companies with different mindset.

Here we go again, you actually want me to ignore you, another rude insulting rant (emphasis added by me) where you attack demons of your own making. You're ignored for abusive and demeaning  language.

[Sherlock Holmes]

I asked ChatGPT "Let's assume that you need to design a new programming language for embedded systems that will be targeted for safety-critical and mission-critical embedded systems, and provide safe memory handling and safe array operators. What would it be like?"

A programming language for embedded systems that is targeted for safety-critical and mission-critical systems would likely have the following features:

1. Memory safety: The language would have built-in mechanisms to prevent common memory-related errors such as buffer overflows, use-after-free, and null pointer dereferences.

2. Type safety: The language would have a strong type system that helps prevent type-related errors, such as type casting errors and implicit type conversions.

3. Array bounds checking: The language would have built-in array bounds checking to prevent out-of-bounds errors when accessing arrays.

4. Automatic memory management: The language would have a garbage collector or other mechanism for automatic memory management, which would help prevent memory leaks and other related errors.

5. Strict syntax and semantics: The language would have a strict syntax and semantics, in order to minimize the chances of introducing new errors.

6. Formal verification: The language would have formal verification tools that could be used to prove the absence of certain types of errors, such as data races.

7. Strong error handling: The language would have strong error handling, in order to prevent errors from propagating and causing further issues.

8. Support for concurrency: The language would have built-in support for concurrency, in order to make it easier to write multi-threaded code that is also safe.

9. Support for functional programming: The language would support functional programming features such as immutable variables, closures, and higher-order functions, which would help make the code more predictable and less error-prone.

10. Support for hardware-level control: The language would have support for interacting with low-level hardware, in order to allow for the precise control that is often required in embedded systems.

11. Support for real-time constraints: The language would have built-in support for real-time constraints, such as hard real-time and soft real-time, allowing developers to specify time constraints and deadlines for specific operations.

12. Interoperability: The language would have the ability to interoperate with other languages, such as C and C++, which are commonly used in embedded systems. This would allow for the use of existing libraries and codebases, and make it easier to integrate the new language with existing systems.

13. Standard libraries: The language would have a comprehensive set of standard libraries, including data structures and algorithms, for use in embedded systems.

14. Compact and efficient: The language would be designed to be compact and efficient, in order to minimize memory and processing requirements, which are important considerations in embedded systems.

15. Security features: The language would have built-in security features such as secure data handling and encryption to protect against common security threats.

16. Tooling and debugging: The language would have a robust set of tooling and debugging options, allowing developers to easily locate and fix errors.

17. Documentations: The language would have comprehensive and up-to-date documentation, including tutorials, guides, and reference material, to help developers get started quickly and become proficient with the language.

18. Community support: The language would have a strong and active community of developers, providing support and contributing to the language's development and maintenance.

Overall, the language would be designed with safety and reliability in mind, with a focus on preventing errors and ensuring that the code is predictable and easy to understand. It would also be efficient and flexible enough to meet the specific requirements of embedded systems.

19. Certification: The language would be designed to meet industry standards and certifications for safety-critical systems, such as ISO 26262 for automotive systems and DO-178C for avionics systems.

20. Safety-critical libraries: The language would have a set of libraries specifically designed for safety-critical systems that provide functionality such as fault-tolerance and redundancy.

21. Safety-critical constructs: The language would have constructs such as assertions and monitors that can be used to express safety properties and to check them at runtime.

22. Model-based development: The language would support model-based development, which allows for the design, verification, and validation of safety-critical systems using formal methods.

23. Traceability: The language would have traceability features that allow developers to trace requirements, design, and implementation, which is critical for safety-critical systems.

24. Auditing and logging: The language would have built-in support for auditing and logging which allows to check and trace the actions of the system and detect malfunctions that could cause safety hazards.

25. Testability: The language would be designed with testability in mind, allowing developers to easily create and execute unit tests, integration tests, and system tests to verify the correct functioning of the system.

Overall, the new programming language for embedded systems would be designed to meet the specific needs of safety-critical and mission-critical systems, providing a combination of safety, reliability, and efficiency, while at the same time meeting industry standards and certifications.

26. Design by Contract: The language would support Design by Contract (DbC) paradigm, which allows developers to express preconditions, postconditions, and class invariants that specify the expected behavior of the functions and classes, making it easier to understand and reason about the code.

27. Static analysis: The language would have built-in static analysis tools that can analyze the code and detect potential errors, such as null pointer dereferences, race conditions, and buffer overflows, before the code is even run.

28. Code review: The language would have tools and processes in place to support formal code reviews, where code is reviewed by other developers, in order to catch errors and improve the quality of the code.

29. Built-in safety mechanisms: The language would have built-in safety mechanisms such as watchdog timers, which can automatically reset the system if it becomes unresponsive, and fail-safe modes, which can be activated if a critical error is detected.

30. Support for formal verification: The language would support formal verification using tools such as model checkers, theorem provers, and static analyzers, which can be used to prove that the code meets certain safety properties.

31. Support for safety standards: The language would be designed to support safety standards such as IEC 61508 and ISO 26262, which provide guidelines for the development of safety-critical systems.

Overall, the new programming language for embedded systems would provide a comprehensive set of features for safety-critical and mission-critical systems, including memory safety, type safety, array bounds checking, automatic memory management, strict syntax and semantics, formal verification, strong error handling, support for concurrency, functional programming, and hardware-level control. Additionally, it would have features to support real-time constraints, interoperability, standard libraries, compact and efficient, security, tooling and debugging, documentation, community support and safety-critical libraries, constructs, model-based development, traceability, auditing and logging, testability, Design by Contract, static analysis, code review, built-in safety mechanisms, support for formal verification and safety standards.

This is a good list to keep in mind when designing a new programming language. Take existing programming languages used in safety-critical embedded systems (such as C, C++, Ada and Rust), implement their good features, and leave out and fix their problematic features. Also, make sure that the new programming language will meet requirements 5 and 18.

At first pass these points strike me as being more fundamental than the others and much thought has gone into these too:

1. Memory safety: The language would have built-in mechanisms to prevent common memory-related errors such as buffer overflows, use-after-free, and null pointer dereferences.

Under that general heading I've included inability to "calculate" pointers/addresses, abolish pointer arithmetic. Also to include the "offset" as a type complimentary to "pointer" where an offset acts as a relative address rather than an absolute address, able to use the same -> notation though. Additional support fixed and varying length strings, no null terminated pseudo-strings.

3. Array bounds checking: The language would have built-in array bounds checking to prevent out-of-bounds errors when accessing arrays.

Here I think we can support two modes, fast and slow. The fast simply ensures that the referenced element lies inside the array, it might be accessed with illegal subscripts, be the wrong element, but it is inside the array. The slow verifies each subscript against the arrays defined bounds. In a 10x10 array for example accessing [2,12] is wrong but won't corrupt system memory (only user data memory). These checks are not hard to do and some CPUs even offer instructions to assist. This capability could also be enabled/disabled at runtime, perhaps even on a per-array basis...

5. Strict syntax and semantics: The language would have a strict syntax and semantics, in order to minimize the chances of introducing new errors.

Well the syntax is pretty formal, derived from PL/I which was more formal, more systematic than C and its derivatives. For example the grammar contains no ambiguities unlike C and C++ which can greatly complicate parsing, stuff like "X * Y;" is common in C and C++ but a parser cannot tell if it's a declaration of a pointer to a type X or a multiplication, it needs to do semantic analysis as part of parsing (i.e. these are not context free languages so cannot be parsed by context free parsing), this is undesirable and so grammars based on C have been rejected.

7. Strong error handling: The language would have strong error handling, in order to prevent errors from propagating and causing further issues.

Exception support is needed here. Again this first appeared as a language capability in PL/I, (where they called it "conditions" PL/I was written by expert IBM mainframe assembler programmers and that has a "condition code register" but I digress). So yes, this is a must IMHO.

10. Support for hardware-level control: The language would have support for interacting with low-level hardware, in order to allow for the precise control that is often required in embedded systems.

This needs better definition IMHO. The language does offer "bit" as a data type and supports declaring arrays of bits and various alignment options too. But is there more too this? What does "low level" really mean? I can see scope for abstract access to the stack, some operations that might allow stack walking perhaps but we soon get to target specific stuff which is undesirable.

27. Static analysis: The language would have built-in static analysis tools that can analyze the code and detect potential errors, such as null pointer dereferences, race conditions, and buffer overflows, before the code is even run.

This is good, I've not thought much about this though, so this needs more definition perhaps...

Thoughts???

[DiTBho]

I've only explicitly ignored posters who are demonstrably insulting

demonstrably insulting, an insult to the insult itself