The Imperium programming language - IPL

[Sherlock Holmes]

FYI - The language has a name now, it has been named "Imperium" after the Latin term for "control", source files are suffixed .ipl - Imperium Programming Language.

Usually the name is chosen to reflect a language's principal characteristics and behaviour.

Congratulations on making this important advance which will, no doubt about it, speed up progress.

There were practical reasons for selecting a name, many files are named after the language, the Antlr4 grammar has a name, the tools I use to build the grammar, the generated parser etc, it was a bit messy just having it name "lang". Documentation too needs to refer to the name, so although it might seem superficial to you it was not, like all not trivial software projects organization and consistency are important.

Since this language will give one greater, more refined control over a machine and its resources than crippled antiquated "C" it's an appropriate name, control is important, no more of this praying as we deliver code, praying that some buffer overrun doesn't crash the car or some array out of bounds doesn't reset the heart monitor or some unanticipated evaluation order does not shutdown the air conditioning.

[cfbsoftware]

Here's a condensed list of important goals for a new language suitable for writing code for MCUs:

1. Extensible grammar (new keywords easily added over time, 100% backward compatibility guaranteed)
2. Elimination of pointer arithmetic.
3. Multidimensional arrays with variable upper/lower bounds.
4. An advanced preprocessor.
5. Support true 'offsets' in addition to conventional 'pointers'.
6. Supported nested procedures.
7. Support exceptions/conditions
8. Support 'builtin' and 'intrinsic' as fundamental language concepts.
9. Abstraction of interop - use a declarative means of interfacing to code written by other languages.
10. Support 'bit' as a data type.
11. Support flexible alignment, padding and ordering of structure/array members.
12. Support endianness operations for converting a contiguous memory block from big/little to little/big endian.
13. Support multiple 'heaps' and facilitate the freeing of all allocations within a heap by simply resetting the heap.
14. Innate support for coroutines.
15. Support decimal, octal, binary and hex numeric literals.
16. Support fixed point arithmetic in decimal/binary base.
17. Remain vigilante, aware of other old and new languages like Ada, Rust, Zig, Hare, Odin etc, where are these weak? where are they strong?

Is there anything fundamental missing from this list ? (I recognize that some want to talk about threading, synchronization and multiple cores, these are important but perhaps best set aside for now, to be revisited later).

It would be interesting to also examine various examples of C based solutions to certain MCU problems to see how a new language could improve the implementation of that code.

I'd like to also remind some here that all/any of these topics are up for discussion, I am not only concerned with grammar, if anyone wants to discuss any of these aspects then please be my guest, lets explore and move forward...

I have been promoting and supporting the use of Oberon-07 as a language for programming ARM microcontrollers since 2008. The compiler and IDE is called Astrobe. I have checked it against your list of required features as follows:

1. Yes. See my previous post in this discussion.
2. Yes.
3. Partial. Multidimensional arrays, but fixed lower bounds of zero.
4. No.
5. Absolute addressing is implemented using builtin functions ADR, GET, and PUT.
6. Yes.
7. Yes.
8. No.
9. No.
10. The datatype SET allows bit manipulation as described in Niklaus Wirth's 2007 paper:
SET: A neglected data type, and its compilation for the ARM
11. No. Unpacking / packing of structures where alignment is an issue is facilitated by builtin bitfield insert and extract inline functions.
12. No.
13. Single heap with customisable allocation / deallocation.
14. Not a language feature (unlike Oberon's predecessor Modula-2)
15. Decimal, hex and char numeric literals.
16. IEEE Floating point only.

[DiTBho]

I have been promoting and supporting the use of Oberon-07 as a language for programming ARM microcontrollers since 2008. The compiler and IDE is called Astrobe.

Frankly I think you have to write some real-life complex applications for the industry before you can say a single word with rational pearl of wisdom.

What have you seen written in Oberon?

[Sherlock Holmes]

Here's a condensed list of important goals for a new language suitable for writing code for MCUs:

1. Extensible grammar (new keywords easily added over time, 100% backward compatibility guaranteed)
2. Elimination of pointer arithmetic.
3. Multidimensional arrays with variable upper/lower bounds.
4. An advanced preprocessor.
5. Support true 'offsets' in addition to conventional 'pointers'.
6. Supported nested procedures.
7. Support exceptions/conditions
8. Support 'builtin' and 'intrinsic' as fundamental language concepts.
9. Abstraction of interop - use a declarative means of interfacing to code written by other languages.
10. Support 'bit' as a data type.
11. Support flexible alignment, padding and ordering of structure/array members.
12. Support endianness operations for converting a contiguous memory block from big/little to little/big endian.
13. Support multiple 'heaps' and facilitate the freeing of all allocations within a heap by simply resetting the heap.
14. Innate support for coroutines.
15. Support decimal, octal, binary and hex numeric literals.
16. Support fixed point arithmetic in decimal/binary base.
17. Remain vigilante, aware of other old and new languages like Ada, Rust, Zig, Hare, Odin etc, where are these weak? where are they strong?

Is there anything fundamental missing from this list ? (I recognize that some want to talk about threading, synchronization and multiple cores, these are important but perhaps best set aside for now, to be revisited later).

It would be interesting to also examine various examples of C based solutions to certain MCU problems to see how a new language could improve the implementation of that code.

I'd like to also remind some here that all/any of these topics are up for discussion, I am not only concerned with grammar, if anyone wants to discuss any of these aspects then please be my guest, lets explore and move forward...

I have been promoting and supporting the use of Oberon-07 as a language for programming ARM microcontrollers since 2008. The compiler and IDE is called Astrobe. I have checked it against your list of required features as follows:

1. Yes. See my previous post in this discussion.
2. Yes.
3. Partial. Multidimensional arrays, but fixed lower bounds of zero.
4. No.
5. Absolute addressing is implemented using builtin functions ADR, GET, and PUT.
6. Yes.
7. Yes.
8. No.
9. No.
10. The datatype SET allows bit manipulation as described in Niklaus Wirth's 2007 paper:
SET: A neglected data type, and its compilation for the ARM
11. No. Unpacking / packing of structures where alignment is an issue is facilitated by builtin bitfield insert and extract inline functions.
12. No.
13. Single heap with customisable allocation / deallocation.
14. Not a language feature (unlike Oberon's predecessor Modula-2)
15. Decimal, hex and char numeric literals.
16. IEEE Floating point only.

Thanks for posting this, I'm definitely going to explore this, SETS looks very interesting, I'll talk about this soon...

[Sherlock Holmes]

I have been promoting and supporting the use of Oberon-07 as a language for programming ARM microcontrollers since 2008. The compiler and IDE is called Astrobe.

Frankly I think you have to write some real-life complex applications for the industry before you can say a single word with rational pearl of wisdom.

What have you seen written in Oberon?

This illogical reasoning needs to be dispelled, the validity of propositions about the world DOES NOT DEPEND on the experiences, skills, personality of the person stating said proposition.

He can only be shown to be wrong by you proving him wrong, so present concrete source code, evidence, PROOF else your claims are without substance.

You must prove him wrong, with facts, logic, proof otherwise we end up bickering over anecdotes, considering were in an engineering thread, discussing formal rule based systems, the regularity with which some here post emotionally or vindictively is incredible, lets have more rigor and act like the professional thinkers we strive to be.

[DiTBho]

I am willing to re-write all MPC860 firmware in Oberon. Then I will try to re-write some driver for ucOS/2 in Oberon. To check how a language is good/bad for your business needs.

[Sherlock Holmes]

Programming languages are not simply something we express our ideas and thoughts in, they directly influence how we think and structure solutions to problems, there is a mutual "feedback" loop present between our minds and the language.

If one uses C daily for years and years then that repeated mental activity, over and over and over begins to define how we think about our problems, this is well demonstrated by taking any experienced imperative language programmer and teaching them a functional language, it's often hard, a struggle not because the person is a dummy but because they've unwittingly conditioned their minds to see things through some narrow window, armed with a functional language they feel constrained, tied down, like they were trying to mend a watch while wearing boxing gloves.

This is because they need to think differently when using the functional language, it is therefore not the language they struggle with but themselves, their own minds.

Every seasoned experienced C programmer here who's never really used a functional language to write non-trivial code, should spend some time looking at say Haskell or F# not because its "better than C" but because it is the best way to see how conditioned their minds have become.

People don't like change by nature, but fear of change is a huge roadblock to intellectual progress, one cannot improve things without changing things.

[Sherlock Holmes]

I have been promoting and supporting the use of Oberon-07 as a language for programming ARM microcontrollers since 2008. The compiler and IDE is called Astrobe.

Frankly I think you have to write some real-life complex applications for the industry before you can say a single word with rational pearl of wisdom.

What have you seen written in Oberon?

See page 30: https://www.xilinx.com/publications/archives/xcell/Xcell91.pdf

[Sherlock Holmes]

Here's a condensed list of important goals for a new language suitable for writing code for MCUs:

1. Extensible grammar (new keywords easily added over time, 100% backward compatibility guaranteed)
2. Elimination of pointer arithmetic.
3. Multidimensional arrays with variable upper/lower bounds.
4. An advanced preprocessor.
5. Support true 'offsets' in addition to conventional 'pointers'.
6. Supported nested procedures.
7. Support exceptions/conditions
8. Support 'builtin' and 'intrinsic' as fundamental language concepts.
9. Abstraction of interop - use a declarative means of interfacing to code written by other languages.
10. Support 'bit' as a data type.
11. Support flexible alignment, padding and ordering of structure/array members.
12. Support endianness operations for converting a contiguous memory block from big/little to little/big endian.
13. Support multiple 'heaps' and facilitate the freeing of all allocations within a heap by simply resetting the heap.
14. Innate support for coroutines.
15. Support decimal, octal, binary and hex numeric literals.
16. Support fixed point arithmetic in decimal/binary base.
17. Remain vigilante, aware of other old and new languages like Ada, Rust, Zig, Hare, Odin etc, where are these weak? where are they strong?

Is there anything fundamental missing from this list ? (I recognize that some want to talk about threading, synchronization and multiple cores, these are important but perhaps best set aside for now, to be revisited later).

It would be interesting to also examine various examples of C based solutions to certain MCU problems to see how a new language could improve the implementation of that code.

I'd like to also remind some here that all/any of these topics are up for discussion, I am not only concerned with grammar, if anyone wants to discuss any of these aspects then please be my guest, lets explore and move forward...

I have been promoting and supporting the use of Oberon-07 as a language for programming ARM microcontrollers since 2008. The compiler and IDE is called Astrobe. I have checked it against your list of required features as follows:

1. Yes. See my previous post in this discussion.
2. Yes.
3. Partial. Multidimensional arrays, but fixed lower bounds of zero.
4. No.
5. Absolute addressing is implemented using builtin functions ADR, GET, and PUT.
6. Yes.
7. Yes.
8. No.
9. No.
10. The datatype SET allows bit manipulation as described in Niklaus Wirth's 2007 paper:
SET: A neglected data type, and its compilation for the ARM
11. No. Unpacking / packing of structures where alignment is an issue is facilitated by builtin bitfield insert and extract inline functions.
12. No.
13. Single heap with customisable allocation / deallocation.
14. Not a language feature (unlike Oberon's predecessor Modula-2)
15. Decimal, hex and char numeric literals.
16. IEEE Floating point only.

I was reading this doument: https://www.astrobe.com/OberonGuide.pdf

In there it defines SET to be "The sets of integers between 0 and 31".

What does this actually mean? does it mean that: 0100 0000 0000 0000 0010 1011 1101 0101 implements a set that contains the integers {0,2,4,6,7,8,9,11,13,30}?

(assuming the LSB is the rightmost bit).

[Sherlock Holmes]

Should anyone be curious the Github repository for this work is here - imperium repository.

The formal grammar and tooling now facilitate support for multiple cultures, it is trivial to now create keyword sets for other cultures providing tokens can be defined for them in that language. There's obviously English and also recently Dutch (kindly contributed by the lead engineer of the Citrine programming language), French is something I expect to add very soon too.

I'm also very interested in some of the stuff from earlier "Wirthian" languages, specifically the concept of "SETS" as seen in Oberon and earlier languages that have recently been brought to my attention.

Oberon itself is proving to be very interesting, here's a 2015 in-depth technical article from Xilinx about an FPGA implementation of Oberon by Nicklaus Wirth for those interested (jump to page 30).

[cfbsoftware]

Frankly I think you have to write some real-life complex applications for the industry before you can say a single word with rational pearl of wisdom.

What have you seen written in Oberon?

I am continually surprised by what some of our Astrobe users are managing to do with Oberon. Here are a couple of comments:

Making good progress with the EFM32 parts. I've started using the internal EFM32 DMA controllers to manage up to 4 streams of parallel data at 2 mbit / sec plus all the other card io that goes on.

The GD32F130s are working out well for the smaller simple modules where we use many at a time ( Could be anywhere from 50 to 500 or more in a console ). The GD32F130s all have 485 data ports. A custom bootloader can update run-time firmware using the 485 data ports ( @ 2 mbit / sec ). Program update data sent from the EFM32 controllers. Can update similar type modules in parallel that way, so don't have to update them one at a time. The bootloader is installed during initial card test using a Segger & Tag-Connect footprint on the card. The bootloader is written in Oberon as well. Bootloader is under 16K, so leaves 48K for application which is lots for those modules.

Our systems are now installed at six nursing homes. This Thursday, we will install a system at a home for severe mental disability patient. Four more nursing homes want a pilot installation. It seems we have struck a nerve, especially with the younger nurses, who really embrace the support that this system is providing them.

[cfbsoftware]

I was reading this doument: https://www.astrobe.com/OberonGuide.pdf

In there it defines SET to be "The sets of integers between 0 and 31".

What does this actually mean? does it mean that: 0100 0000 0000 0000 0010 1011 1101 0101 implements a set that contains the integers {0,2,4,6,7,8,9,11,13,30}?

(assuming the LSB is the rightmost bit).

Correct. Some time ago Elektor Magazine published an article I wrote titled: Easy Sceptre Programming with Oberon-07. The Sceptre was an ARM LPC2148 microcontroller development board designed by Elektor staff. I described one use of SETs there:

The SET data type: testing, setting and clearing bits
Much of the low-level programming of the Sceptre’s LPC2148 involves testing, setting and clearing specific bits of the memory-mapped registers. This is where Oberon’s built-in SET data type is very useful.

For example, if you have LEDs connected to pins P0.13, P0.14 and P0.15 you can light them the traditional way using hexadecimal notation:

SYSTEM.PUT (LPC.IOSET, 0E000H)

Alternatively, if you prefer, using a SET constant you can say:

SYSTEM.PUT (LPC.IOSET, { 13..15 })

The ARM7 instructions generated are identical for both cases.

To help you when working from examples using hexadecimal constants, the Astrobe menu item “Tools > Convert Hex to SET” converts hem to the equivalent Oberon-07 SET constant ready to be pasted into your code.

[SiliconWizard]

The SET type of Oberon is certainly a nice way of defining binary constants, much more readable than writing in binary such as 0b001010111001

[SiliconWizard]

Frankly I think you have to write some real-life complex applications for the industry before you can say a single word with rational pearl of wisdom.

What have you seen written in Oberon?

I am continually surprised by what some of our Astrobe users are managing to do with Oberon.

As Wirth said, complex systems should be designed with simple tools. He also added that he was aware of his opinion not being very popular.

[MIS42N]

The SET data type: testing, setting and clearing bits
Much of the low-level programming of the Sceptre’s LPC2148 involves testing, setting and clearing specific bits of the memory-mapped registers. This is where Oberon’s built-in SET data type is very useful.

For example, if you have LEDs connected to pins P0.13, P0.14 and P0.15 you can light them the traditional way using hexadecimal notation:

SYSTEM.PUT (LPC.IOSET, 0E000H)

Alternatively, if you prefer, using a SET constant you can say:

SYSTEM.PUT (LPC.IOSET, { 13..15 })

That is rather neat. It beats ( 1<<13 | 1<<14 | 1<<15 ) for conciseness, and even more readable as long as one recognises the curly braces as bit numbers. I assume the use of SET to define bits and the use of SET in IOSET is just coincidental. I could imagine a different architecture with LPC.IOCLR, { 13..15 } or similar

[SiliconWizard]

It's a set, so you can mix bit intervals such as: { 0, 3, 5..7, 12..13, 15 }, that's sweet indeed.

[cfbsoftware]

That is rather neat. It beats ( 1<<13 | 1<<14 | 1<<15 ) for conciseness, and even more readable as long as one recognises the curly braces as bit numbers. I assume the use of SET to define bits and the use of SET in IOSET is just coincidental. I could imagine a different architecture with LPC.IOCLR, { 13..15 } or similar

Exactly. IOSET is the name used in the LPC2xxx microcontroller manual. The Blinker example module has a constant declaration:

Code: [Select]

  CONST
    (* led(s) connected to pin P0.13, P0.14 and P0.15 *)
    ledBits = {13..15};
... and an infinite main loop:

Code: [Select]

  WHILE TRUE DO
    SYSTEM.PUT(LPC.IOCLR, ledBits);
    Timer.MSecDelay(500);
    SYSTEM.PUT(LPC.IOSET, ledBits);
    Timer.MSecDelay(500)
  ENDIOCLR and IOSET are absolute memory addresses declared as constants in a separate, imported, LPC module:

Code: [Select]

  IOSET* = 0E0028004H;
  IODIR* = 0E0028008H;
  IOCLR* = 0E002800CH;The asterisk indicates that the values are exported from the module.

[cfbsoftware]

Frankly I think you have to write some real-life complex applications for the industry before you can say a single word with rational pearl of wisdom.

What have you seen written in Oberon?

I am continually surprised by what some of our Astrobe users are managing to do with Oberon.

As Wirth said, complex systems should be designed with simple tools. He also added that he was aware of his opinion not being very popular.

Yes indeed. I should also have mentioned that Wirth's Oberon compilers are entirely written in Oberon. They make good regression test cases

[DiTBho]

Some time ago Elektor Magazine published an article I wrote titled: Easy Sceptre Programming with Oberon-07. The Sceptre was an ARM LPC2148 microcontroller development board designed by Elektor staff.

is it possible, somehow, to get a copy?

[Siwastaja]

That is rather neat. It beats ( 1<<13 | 1<<14 | 1<<15 ) for conciseness

But you can write (0b111<<13), this is something I do all the time.

[DiTBho]

half technology, half religion 

[DC1MC]

Some time ago Elektor Magazine published an article I wrote titled: Easy Sceptre Programming with Oberon-07. The Sceptre was an ARM LPC2148 microcontroller development board designed by Elektor staff.

is it possible, somehow, to get a copy?

Sure:
https://www.elektormagazine.de/labs/easy-sceptre-programming-with-oberon-07

https://www.astrobe.com/Oberon.htm

[Sherlock Holmes]

That is rather neat. It beats ( 1<<13 | 1<<14 | 1<<15 ) for conciseness, and even more readable as long as one recognises the curly braces as bit numbers. I assume the use of SET to define bits and the use of SET in IOSET is just coincidental. I could imagine a different architecture with LPC.IOCLR, { 13..15 } or similar

Exactly. IOSET is the name used in the LPC2xxx microcontroller manual. The Blinker example module has a constant declaration:

Code: [Select]

  CONST
    (* led(s) connected to pin P0.13, P0.14 and P0.15 *)
    ledBits = {13..15};
... and an infinite main loop:

Code: [Select]

  WHILE TRUE DO
    SYSTEM.PUT(LPC.IOCLR, ledBits);
    Timer.MSecDelay(500);
    SYSTEM.PUT(LPC.IOSET, ledBits);
    Timer.MSecDelay(500)
  ENDIOCLR and IOSET are absolute memory addresses declared as constants in a separate, imported, LPC module:

Code: [Select]

  IOSET* = 0E0028004H;
  IODIR* = 0E0028008H;
  IOCLR* = 0E002800CH;The asterisk indicates that the values are exported from the module.

This is a great notation, I'm very interested in adopting this into the IPL grammar. This is exactly the kind of hardware "friendly" stuff I've been seeking, stuff that helps in real life problems, pragmatic. In IPL (taken from PL/I) there are "bit strings", arbitrary length sequences of bits (either aligned or not) that could be manipulated by this "set" notation, it's very attractive.

There's no reason too, why one could not have this arbitrarily defined, no need to be concerned that it's 32 bits or 64 or anything:

Code: [Select]


dcl interrupt_control bit(45); // usual PL/I syntax

interrupt_control = {}; // set all bits OFF

interrupt_control = {0..4,19..30}; // Wirthian notation


IPL does not yet use { or } or .. either and so this is pretty straightforward to add to the grammar, it seems to me that this is primarily a notation, its implementation, semantics are relatively simple.

I have questions though, look:

Code: [Select]


flags = {0..5, 7..9};


That effectively sets bits 0, 1, 2, 3, 4, 5 and 7, 8, 9 to "on". How would I express "turn off bit 3 in flags"?

Code: [Select]


flags = flags - {3};


would that be it? (in Oberon anyway).

PL/I and Imperium too, support the ability to access a "bit string" via a subscript:

Code: [Select]


dcl control_reg bit(32);

control_reg = get_reg(X);

control_reg(4) = ON;
control_reg(19) = ON;
control_reg(28) = OFF;


But setting several ON/OFF at once isn't really supported, there's no short notation for it anyway.

With Wirth's notation we could code:

Code: [Select]


dcl control_reg bit(32);

control_reg = get_reg(X);

control_reg = control_reg + {4,19} - {28};


So I'm seeing this as an additional notation for setting and unsetting bits, not a change or alternative way to implement bit strings (as they are termed) but a very neat additional notation one can use.

[SiliconWizard]

That is rather neat. It beats ( 1<<13 | 1<<14 | 1<<15 ) for conciseness

But you can write (0b111<<13), this is something I do all the time.

Yes, that's clearer.
And if you define your bits as macros, admittedly writing '(THISBIT | THISOTHERBIT)' or '{THISBIT , THISOTHERBIT}' is not a lot different.

[Sherlock Holmes]

After much painstaking testing I have proven the multilingual support for this, it was very confusing to test and debug due to the way different editors store accented characters and Unicode, it was almost maddening but is absolutely fine now.

These two code fragments generate the same logical parse tree, one parsed in English mode, the other in French mode:

Code: [Select]


procédé French (X)

déclarer counter binaire(15);

si counter > 0 ensuite
   appeler escaper;
autre
   retour;
fin;

fin;

and

Code: [Select]

procedure English (X)

declare counter binary(15);

if counter > 0 then
   call escaper;
else
   return;
end;

end;

This was actually small engineering effort (but a struggle due to the confusion that can come up when working with UTF-8 and various different editors etc) and is something that can be routinely included going forward, sets of keywords can be added for any language (within reason) and the code using those keywords guaranteed to parse, this is one of the benefits of having no reserved words.

Source code can be transformed from one language into another easily by a utility that alters only keywords, then any user defined name that might just happen to be a keyword in that target language, are fine, they do not and cannot break the parse!

So auto converting this:

Code: [Select]



procedure English (X)

declare counter binary(15);

if counter > 0 then
   call retour; // Call the retour module to review the map's touring data.
else
   return;
end;

end;

into French:

Code: [Select]

procédé French (X)

déclarer counter binaire(15);

si counter > 0 ensuite
   appeler retour; // Call the retour module to review the map's touring data.
autre
   retour;
fin;

fin;

Works, it parses fine (in French mode), even though the English developer that created the original code unknowingly used an identifier "retour" (for the name of some procedure) that just so happens to be a French keyword (for "return"). This is an extremely powerful capability potentially, and no conventional programming language you're likely to encounter will have this ability.