The Imperium programming language - IPL

[Sherlock Holmes]

Rotates are a very small step away from shifts, very very small difference

They are not though. Shifts have the same meaning for various word lengths. Rotates are dependent on the type of the underlying value, so the result depends on how abstract machine and types are implemented.  And that also poorly maps on most hardware.

And what you are doing is really bike-shedding. None of what you are doing is important in a language design.

What about XOR? what symbols (if any!) would one use for that in a new language striving to be more helpful than C on hardware programming?

C has XOR.

And you calling people to look at things is just funny. It is good that you are discovering all those things and all, but it just looks really funny from outside.

Not as I'm currently defining these operations. I define rotate exactly as it is defined here:

Rotate right (immediate) provides the value of the contents of a register rotated by a variable number of bits. The bits that are rotated off the right end are inserted into the vacated bit positions on the left.

Right C uses the symbol ^ for exclusive or, but Imperium uses that that for arithmetic exponentiation. So try again, what symbol could you suggest for exclusive OR if ^ is not available?

As for "funny" what's funny is that Mr. Halt claimed almost no processors support rotate yet I showed him that ARM actually does, and you claiming that rotate is not very close to shift until I - just now - showed you that it is.

[ataradov]

Not as I'm currently defining these operations. I define rotate exactly as it is defined here:

That ARM operation is only defined for 32-bit words. What if I want to rotate a byte?

As for "funny" what's funny is that Mr. Halt claimed almost no processors support rotate yet I showed him that ARM actually does, and you claiming that rotate is not very close to shift until I - just now - showed you that it is.

LOL

[Sherlock Holmes]

Rotates are a very small step away from shifts, very very small difference

They are not though. Shifts have the same meaning for various word lengths. Rotates are dependent on the type of the underlying value, so the result depends on how abstract machine and types are implemented.  And that also poorly maps on most hardware.

And what you are doing is really bike-shedding. None of what you are doing is important in a language design.

What about XOR? what symbols (if any!) would one use for that in a new language striving to be more helpful than C on hardware programming?

C has XOR.

And you calling people to look at things is just funny. It is good that you are discovering all those things and all, but it just looks really funny from outside.

You're being ignored.

[Sherlock Holmes]

Knowing why that is the case would require that the OP understood the evolution that occurred then.

I'm curious what combination of characters he is planning to use for:

- CRC32 instruction

- DES and AES instructions

- SHA

- bit reversal in a word

- byte reversal

- selecting bits from one or another source based on a mask

I could go on. There is an infinity of operations, and even hundreds of operations that have been implemented as instructions in some ISA or another. Each very handy and performance-enhancing when needed -- which might be exactly once on the whole machine, in one function in the (hand-written) standard library.

You're being ignored.

[ataradov]

Sure ignore all you want. BTW, modern ISA (RISC-V) don't have rotate. It is not necessary and poorly maps on the high level code due to that register size vs variable size issue.

And that's why if you look at the intrinsic functions provided by the compilers, you will see a mess like __rolb/__rorb for 8-bit, __rolw/__rorw (16-bit), __rold/__rord (32-bit), __rolq/__rorq (64-bit). There is no one universal rotate. And if you do the "manual" rotate from the code, optimizing compiler will recognize the pattern and automatically generate appropriate rotate code, which in many cases will not involve hardware rotate instruction.

In case of RISC-V recently ratified B extension does add rotates, but it is just a minor part of a massive set of actually useful bit manipulation extensions.

[tggzzz]

And what you are doing is really bike-shedding. None of what you are doing is important in a language design.

Nor to someone using a language to drain a swamp.

But it is important to someone principally interested in exploring the internal components in a compiler.

And you calling people to look at things is just funny. It is good that you are discovering all those things and all, but it just looks really funny from outside.

It does. And sad.

It is always sad when someone doesn't understand what is driving them to a particular course of action.

[tggzzz]

You're being ignored.

Not quite. The multiple people you have put in that category are not being ignored. They are being being listened to by all but one person.

If there is no body that you are listening to, why are you continuing to post in this thread?

[Sherlock Holmes]

It's fine, absolutely fine to disagree with someone. That someone might be right, they might be wrong, or it might be a matter of opinion, hard to decide.

What's not fine is rudeness, accusations of stupidity and other insults and hurtful remarks, which some here seem to perversely enjoy, seem to know no other way to disagree.

If you spoke to someone in person, in a professional meeting with others present or as a visitor to a company, the way you express yourselves here then you'd risk being fired. Anyone who relies on insults and belittling language to communicate with people they disagree with is likely a huge liability in a management role, an HR accident waiting to happen.

But it matters not to me, if you disagree and expect me to respect your opinion, your expertise, to listen to and consider your views then that will never happen when you begin by insulting me, when that happens I stop listening, so any value you might have had is gone, lost.

If that's your objective then you've achieved it.

[westfw]

Quote

ISAs that aren't legacy from 8/16 bit machines from the 70s/80s often don't even HAVE a rotate instruction anyway (or a carry flag).

That seems like a bit of an exaggeration.  MIPS, Alpha, and RISC-V lack carry flags, but ARM, Sparc, and PPC all have one (but sparc doesn't have Rotate.)

(Carry seems like a lot to give up.  If the CC register is a potential bottleneck, how come you don't see it implemented by adding an extra bit to each register?)

[brucehoult]

And what you are doing is really bike-shedding. None of what you are doing is important in a language design.

Triviality of the issue being discussed is one aspect of it. The other is not being competent to understand and discuss the more important issues.

"Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bicycle shed"

[brucehoult]

Quote

ISAs that aren't legacy from 8/16 bit machines from the 70s/80s often don't even HAVE a rotate instruction anyway (or a carry flag).

That seems like a bit of an exaggeration.  MIPS, Alpha, and RISC-V lack carry flags, but ARM, Sparc, and PPC all have one (but sparc doesn't have Rotate.)

I said "often" not "always".

(Carry seems like a lot to give up.  If the CC register is a potential bottleneck, how come you don't see it implemented by adding an extra bit to each register?)

Using 63 bits per limb in your bignum code instead of 64 gives the same effect.

[SiliconWizard]

Adding an extra bit per register as carry is something I suggested a while ago in my thread about RISC-V.

The whole question, as always, is whether it's worth adding that in general use, rather than making it an ISA extension.

Unless you're dealing with "big integers", arithmetic operations with carry are not that useful, especially on a 64-bit CPU. (But even on a 32-bit CPU which is a MCU, that's not often that useful.) So that's kind of a niche (albeit a nice to have if you are dealing with that.)

As to bitwise rotate, it's already in an extenson for RISC-V (bitmanip). It doesn't require a "carry" bit, as the carry does not stick after the operation is completed.

[ataradov]

It was probably debated to death elsewhere, but it is important to differentiate instruction set from the microarchitecure. Typical RISC-V add/sltu pairs may be more code than ARM's add/adc. but they don't have to take more time to execute if performance matters. Those instructions may be fused and executed together. But symmetrical register-only architecture is potentially easier to implement in heavily pipelined and OOO designs. It is hard to tell which one is really better.

X86 is pretty bad ISA, yet until recently its implementations absolutely destroyed everything else. Then Apple managed to optimize ARM quite well. I'm not sure if someone would manage to get anything close from RISC-V. We'll have to wait and see.

[westfw]

Quote

Unless you're dealing with "big integers", arithmetic operations with carry are not that useful

I guess.  But aren't "big integer" operations become more common, what with assorted crypto stuff?
Quote

Using 63 bits per limb in your bignum code instead of 64 gives the same effect.

I guess.  I was imagining a small number of instructions that would access the 65th bit, so that the normal instruction set could be used while being blissfully unaware that  the 65th bit was there.

[SiliconWizard]

It was probably debated to death elsewhere, but it is important to differentiate instruction set from the microarchitecure. Typical RISC-V add/sltu pairs may be more code than ARM's add/adc. but they don't have to take more time to execute if performance matters. Those instructions may be fused and executed together. But symmetrical register-only architecture is potentially easier to implement in heavily pipelined and OOO designs. It is hard to tell which one is really better.

Yep. And yes this has been debated a lot. Instruction fusing may be costly to implement depending on your architecture indeed. I would personally go for the extra bit per register option myself as an extension for my own core. But since its main benefit would be for pretty specific stuff (such as big ints/"arbitrary precision" computation), designing a specific "accelerator" may be a better option anyway rather than trying to stuff more instructions and get only marginal performance increase in the end.

X86 is pretty bad ISA, yet until recently its implementations absolutely destroyed everything else. Then Apple managed to optimize ARM quite well. I'm not sure if someone would manage to get anything close from RISC-V. We'll have to wait and see.

x86 is pretty bad as an instruction set, but modern Intel CPUs are very far away from the direct map to microachitecture that was the case for early x86 CPUs. Nowadays they are RISC machines with complex translation units.

What Apple did with the M1/M2 is remarkable - the missing market for ARM was precisely that of the desktop, and it's now wide open. Now the top of the line Intel CPUs still crush the Apple CPUs by a large margin, but that's already a great achievement.

[ataradov]

I would personally go for the extra bit per register option myself as an extension for my own core.

This only works as long as you are not using it in any other context. As soon as you want to branch on that carry bit, you are screwed again. And the add/adc use seems pretty limited to bother.

I just downloaded Armv9-A ARM and holy crap, it is 12000 pages long. Good luck implementing that.

[Nominal Animal]

Carry is much less useful than one would initially think.  I used to think it important, until discussing the exact details (of architectures without flags) with brucehoult, and looking carefully at the machine code generated on different ISAs for my typical use cases and patterns.  It turns out I just want ABIs that can pass more than one scalar value in registers, like SysV on x86-64.

For example, when converting IEEE 754 floating-point numbers to octal/decimal/hexadecimal exactly correctly, it turns out that using 28-bit limbs in 32-bit registers (or 60-bit limbs in 64-bit registers on 64-bit architectures) is much more efficient than full 32-bit limbs, because most operations involve just one digit (in base 8/10/16) at a time.  The difference is definitely significant, so much so that I fully believe the 14.3% extra memory use is worth it.

This is exactly why I believe it is so important to examine what kind of machine code one wants a compiler to produce.
Basic assumptions (like "condition codes are necessary for efficient code doing X") tend not to hold under close scrutiny.

[westfw]

The last thing I really liked having Carry and ADC for was an efficient implementation of the IP checksum.
It's probably pretty academic if you have 64bit math, but it was nice on 8 and 16bit CPUs. (half the size and twice the speed for an AVR.)

[DiTBho]

If there is no body that you are listening to, why are you continuing to post in this thread?

must be the new fashion web hit: write-only mode 
(null pipein, flow pipeout, dunno pipeerr
like Facebook, I mean)

[DiTBho]

The last thing I really liked having Carry and ADC for was an efficient implementation of the IP checksum.

I did the same on a 68hc11 board with CS8900 10Mbits
Add with Carry to A ADCA
Add with Carry to B ADCB

great trick, found an old article on a UK magazine about that

[DiTBho]

This is exactly why I believe it is so important to examine what kind of machine code one wants a compiler to produce.

Yup, assolutely.

I mean, at least one should know that "grammar" is only a part of the puzzle. Then you have to deal with the "machine layer", and matching them on purpose (for which purpose?) is not as easy as one thinks.

[DiTBho]

Typical RISC-V add/sltu pairs may be more code than ARM's add/adc

I have { add, sltu } pairs on my MIPS-5++ Atlas board
Sounds good choice, good pairs!

[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?"

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.

[DiTBho]

I was imagining a small number of instructions that would access the 65th bit, so that the normal instruction set could be used while being blissfully unaware that  the 65th bit was there.

On my MIPS32 router, I am playing with a Crypto processor made by Soekris; it does all the math, block-in, does crypt/uncrypt, block-out. All DMA driven with a large buffer. A piece of cake, and it off-loads the CPU.

I think all the BIG-numbers and all the crypto stuff (VPN?) should be done this way!

I mean, by a dedicated Co-Processor, so you won't even care if { ADC, ROL, ROR, &C ... } is supprted in your CPU-ISA

[DiTBho]

I asked ChatGPT

Better get a job in avionics.