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.
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.
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 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?
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?
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.
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?
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.
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).
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.
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
CONST
(* led(s) connected to pin P0.13, P0.14 and P0.15 *)
ledBits = {13..15};
... and an infinite main loop: WHILE TRUE DO
SYSTEM.PUT(LPC.IOCLR, ledBits);
Timer.MSecDelay(500);
SYSTEM.PUT(LPC.IOSET, ledBits);
Timer.MSecDelay(500)
END
IOCLR and IOSET are absolute memory addresses declared as constants in a separate, imported, LPC module: IOSET* = 0E0028004H;
IODIR* = 0E0028008H;
IOCLR* = 0E002800CH;
The asterisk indicates that the values are exported from the module.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.
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.
That is rather neat. It beats ( 1<<13 | 1<<14 | 1<<15 ) for conciseness
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?
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 similarExactly. IOSET is the name used in the LPC2xxx microcontroller manual. The Blinker example module has a constant declaration:Code: [Select]CONST
... and an infinite main loop:
(* led(s) connected to pin P0.13, P0.14 and P0.15 *)
ledBits = {13..15};Code: [Select]WHILE TRUE DO
IOCLR and IOSET are absolute memory addresses declared as constants in a separate, imported, LPC module:
SYSTEM.PUT(LPC.IOCLR, ledBits);
Timer.MSecDelay(500);
SYSTEM.PUT(LPC.IOSET, ledBits);
Timer.MSecDelay(500)
ENDCode: [Select]IOSET* = 0E0028004H;
The asterisk indicates that the values are exported from the module.
IODIR* = 0E0028008H;
IOCLR* = 0E002800CH;
dcl interrupt_control bit(45); // usual PL/I syntax
interrupt_control = {}; // set all bits OFF
interrupt_control = {0..4,19..30}; // Wirthian notation
flags = {0..5, 7..9};
flags = flags - {3};
dcl control_reg bit(32);
control_reg = get_reg(X);
control_reg(4) = ON;
control_reg(19) = ON;
control_reg(28) = OFF;
dcl control_reg bit(32);
control_reg = get_reg(X);
control_reg = control_reg + {4,19} - {28};
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.
procédé French (X)
déclarer counter binaire(15);
si counter > 0 ensuite
appeler escaper;
autre
retour;
fin;
fin;
procedure English (X)
declare counter binary(15);
if counter > 0 then
call escaper;
else
return;
end;
end;
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;
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;