@FredBlais said:
@RossH
I've got a working port of the Berry Language working on the Propeller 2 compiled using Catalina. See https://berry-lang.github.io
>
Great! I don't know Berry, but I'll look it up tomorrow.
Berry looks interesting. I immediately saw that it's very "Lua like". And when I read further, I found this was exactly the intent. The author of Berry says:
I used to pay more attention to Lua because it is a very compact embedded scripting language, and its design goal is to be embedded in the host program. However, for the microcontroller, the Lua interpreter may not be small enough, and I cannot run it on a 32-bit microcontroller with a relatively small memory. To this end, I started to read Lua code and developed my own scripting language-Berry on this basis.
On the Propeller 2, the overhead of full embedded Lua is about 180kb of code. The author of Berry says the minimum memory required to run "full" Berry is about 128kb of EEPROM (which I interpret to mean about 128kb of code) so it looks quite promising. I'll have a play and see what its performance is like compared to Lua.
Berry may not replace Lua as my preferred Propeller language but thanks for bringing it to my attention. The more languages we get working on the Propeller, the better!
I managed to get your port of Berry to build on Linux easily enough, but I have to load it manually. Here is the payload command I use (assumes the Propeller is on port /dev/ttyUSB0):
No luck with Windows - I had to modify py -3 to python3 in the scripts, but when bash executes catalina, it cannot locate clcc, which indicate that either the LCCDIR environment variable or the path is not being set. In bash (and assuming Catalina is installed in /C/users/rossh/Catalina), you need to do:
I managed to get your port of Berry to build on Linux easily enough, but I have to load it manually. Here is the payload command I use (assumes the Propeller is on port /dev/ttyUSB0):
No luck with Windows - I had to modify py -3 to python3 in the scripts, but when bash executes catalina, it cannot locate clcc, which indicate that either the LCCDIR environment variable or the path is not being set. In bash (and assuming Catalina is installed in /C/users/rossh/Catalina), you need to do:
Yesterday I started to work on a way to make Berry lunch a new berry instance on another cog to execute the closure I give it.
This looks to be similar to Catalina's multi-processing Lua extensions. What mechanism do you intend to use to synchronize and communicate between instances? I see references to mailboxes in your code - that is a reasonable choice for a communication mechanism but it looks like you use them only for passing arguments to the function - is there a facility to return data as well?
And 3 synchronization mechanisms:
1. condition variables (as per Posix)
2. mutexes (as per Posix)
3. Propeller locks
Plus, if the instances are executing on same Propeller (they may not be) then you can also just use shared memory (Catalina's eLua client/server programs use this mechanism).
This is probably overkill - one of each type of mechanism is probably sufficient, but these choices are partly historical (i.e. inherited from the original luaproc package). See the documents Lua on the Propeller 2 with Catalina and Aloha from Lua for more details.
Catalina 8.8.8 has been released on GitHub and SourceForge. If you believe in Chinese numerology, this should be a very, very, very lucky release!
This is a full release. It updates Cake to 0.13.14, which adds support for C bit-fields, and also contains minor enhancements, bug fixes and documentation updates.
Here is the relevant extract from the README.TXT:
New Functionality
-----------------
1. Cake updated (to 0.13.14). This version has support for C bit-fields.
2. Catalina has a new command line option '-Y' (i.e. minus capital Y)
which tells Catalina to preprocess the C sources but not to compile them.
The preprocessed output files will be written into a 'catalina' subfolder
in the current directory. Since there may be more than one source file,
any '-o' option is ignored, and the output files will have the same names
as the input files. For example:
catalina -Y hello.c bye.c
will generate two output files - 'catalina/hello.c' and 'catalina/bye.c'.
3. Catalina now accepts debug options (i.e. -g or -g3) in conjunction
with C standards other than -C89 or -C90, but issues a warning that
the options may be incompatible. While Catalina's version of Cake now
generates #line directives (which allow the Catalina debugger to display
the line being debugged) debugger support is still very experimental.
Cake changes the source so much that some debugger commands may not
work as expected - e.g. Cake may remove, rename or add new variables,
and also remove, modify, re-arrange or add new lines of source code.
Another option is to first use Cake to translate C99 (or later) source
files to C89, and then compile and debug THOSE files. To do this, add the
new -Y command-line option to a catalina command, which tells Catalina to
preprocess the source files but not compile them. It is important to add
all the correct compile-time options (e.g. libraries and other options)
so that the file will be pre-processed correctly. Any -o option will be
ignored - instead, since there may be more than one source file, the
preprocessed files will be written to a 'catalina' subfolder created in
the current directory, with the same names as the original files.
For example, if the command used to compile %LCCDIR%\demos\hello_99.c
WITHOUT debugging is:
catalina hello_99.c -p2 -C99 -lci -C P2_EDGE -C VGA
Then to generate the C89 version, first add -Y to that command:
catalina hello_99.c -p2 -C99 -lci -C P2_EDGE -C VGA -Y
Then the file catalina\hello_99.c can be compiled for debugging,
loaded and debugged as follows:
catalina catalina\hello_99.c -p2 -lci -C P2_EDGE -C VGA -g3
payload -o2 catalina\hello_99
blackbox catalina\hello_99
Other Changes
-------------
1. Document 'Lua on the Propeller with Catalina' updated.
2. Document 'Catalina Optimizer Reference Manual' updated.
3. The notes in CATALINA.TXT in the demos/coremark directory have been
updated to remove the references to 'force_rebuild' (which is not
implemented in the coremark makefile!) and also add that faster
single-threaded coremark results can be obtained by defining the
Catalina symbols NO_INTERRUPTS and FAST_SAVE_RESTORE - this speeds
up coremark by about 25%
4. Fixed a bug in the Catalina Optimizer, which means that Optimizing
programs that contained inline PASM could cause the program to fail.
The Optimizer now skips all code contained in inline PASM statements,
because (a) such code does not necessarily use the same memory model as
the code generated by LCC (which the Optimizer assumed was always the
case), and (b) because optimizing code can change code size and timing,
which could be critical in hand-coded PASM.
Affected the Propeller 1 and 2, on Windows and Linux.
5. Fixed a bug in the Catalina Optimizer, which means that Optimizing
COMPACT programs could cause the program to fail, because the Optimizer
was not retaining some "alignl" statements that were REQUIRED for the
code to execute correctly (e.g. after an I16B_CALI instruction).
Affected the Propeller 1 and 2, on Windows and Linux.
6. Fixed a bug in the inline PASM demo inline_pasm/test_inline_pasm_5.c,
which did not correct for pin numbers >= 32 (i.e. accessed via Port B).
Affected the Propeller 2 only, on Windows. Linux and Catalyst.
7. Fixed a bug in the Blackbox source level debugger, which was sometimes
assigning breakpoint addresses to the wrong source line. The debugger
executed the breakpoints correctly, but may have displayed the wrong
source line when the breakpoint address was reached.
Comments
>
Great! I don't know Berry, but I'll look it up tomorrow.
Ross.
Berry is pretty much like Python, but does not require indentation.
You can see the difference here : https://berry.readthedocs.io/en/latest/source/en/Berry-in-20-minutes.html#extra
you can try it online too https://berry-lang.github.io/try-online/
First released binary sits here https://github.com/speccy88/berry/releases/
with relevant information on the release page
@FredBlais
Berry looks interesting. I immediately saw that it's very "Lua like". And when I read further, I found this was exactly the intent. The author of Berry says:
On the Propeller 2, the overhead of full embedded Lua is about 180kb of code. The author of Berry says the minimum memory required to run "full" Berry is about 128kb of EEPROM (which I interpret to mean about 128kb of code) so it looks quite promising. I'll have a play and see what its performance is like compared to Lua.
Berry may not replace Lua as my preferred Propeller language
but thanks for bringing it to my attention. The more languages we get working on the Propeller, the better!
Ross.
Hmm, trying to compile Berry on Windows, I get a gcc internal compiler error:
I'll try Linux.
Ok! Thanks. Your version works.
And my Windows version of gcc is now working again - just one of those mysteries of Windows 11, which occasionally does all kinds of odd things.
I got my quickly hacked version to compile ok, but not run yet. I'll have a look at what changes you made.
Ross.
@FredBlais
I managed to get your port of Berry to build on Linux easily enough, but I have to load it manually. Here is the payload command I use (assumes the Propeller is on port /dev/ttyUSB0):
No luck with Windows - I had to modify
py -3topython3in the scripts, but when bash executes catalina, it cannot locate clcc, which indicate that either the LCCDIR environment variable or the path is not being set. In bash (and assuming Catalina is installed in /C/users/rossh/Catalina), you need to do:I also see references to macOS in your scripts. Do you use Catalina on a Mac?
Ross.
Actually, my build system spin up a Ubuntu image in Docker to use Catalina
DEFAULT_BASE_IMAGE="ubuntu:24.04"
DOCKER_IMAGE="${CATALINA_DOCKER_IMAGE:-berry-p2-catalina-builder:ubuntu24.04}"
To do this port, I used Codex from OpenAI. The tool is pretty smart, it will figure out a way on its own to make that work.
Yesterday I started to work on a way to make Berry lunch a new berry instance on another cog to execute the closure I give it.
Not totally working yet be here is the base code : https://github.com/speccy88/berry/commit/cf1ee553957222fb2374ede0e92a880ba53cecf6
@FredBlais
Ah! That explains a few things.
@FredBlais
This looks to be similar to Catalina's multi-processing Lua extensions. What mechanism do you intend to use to synchronize and communicate between instances? I see references to mailboxes in your code - that is a reasonable choice for a communication mechanism but it looks like you use them only for passing arguments to the function - is there a facility to return data as well?
Catalina offers 2 communication mechanisms:
1. message channels
2. shared variables
And 3 synchronization mechanisms:
1. condition variables (as per Posix)
2. mutexes (as per Posix)
3. Propeller locks
Plus, if the instances are executing on same Propeller (they may not be) then you can also just use shared memory (Catalina's eLua client/server programs use this mechanism).
This is probably overkill - one of each type of mechanism is probably sufficient, but these choices are partly historical (i.e. inherited from the original luaproc package). See the documents Lua on the Propeller 2 with Catalina and Aloha from Lua for more details.
Ross.
Catalina 8.8.8 has been released on GitHub and SourceForge. If you believe in Chinese numerology, this should be a very, very, very lucky release!
This is a full release. It updates Cake to 0.13.14, which adds support for C bit-fields, and also contains minor enhancements, bug fixes and documentation updates.
Here is the relevant extract from the README.TXT:
New Functionality ----------------- 1. Cake updated (to 0.13.14). This version has support for C bit-fields. 2. Catalina has a new command line option '-Y' (i.e. minus capital Y) which tells Catalina to preprocess the C sources but not to compile them. The preprocessed output files will be written into a 'catalina' subfolder in the current directory. Since there may be more than one source file, any '-o' option is ignored, and the output files will have the same names as the input files. For example: catalina -Y hello.c bye.c will generate two output files - 'catalina/hello.c' and 'catalina/bye.c'. 3. Catalina now accepts debug options (i.e. -g or -g3) in conjunction with C standards other than -C89 or -C90, but issues a warning that the options may be incompatible. While Catalina's version of Cake now generates #line directives (which allow the Catalina debugger to display the line being debugged) debugger support is still very experimental. Cake changes the source so much that some debugger commands may not work as expected - e.g. Cake may remove, rename or add new variables, and also remove, modify, re-arrange or add new lines of source code. Another option is to first use Cake to translate C99 (or later) source files to C89, and then compile and debug THOSE files. To do this, add the new -Y command-line option to a catalina command, which tells Catalina to preprocess the source files but not compile them. It is important to add all the correct compile-time options (e.g. libraries and other options) so that the file will be pre-processed correctly. Any -o option will be ignored - instead, since there may be more than one source file, the preprocessed files will be written to a 'catalina' subfolder created in the current directory, with the same names as the original files. For example, if the command used to compile %LCCDIR%\demos\hello_99.c WITHOUT debugging is: catalina hello_99.c -p2 -C99 -lci -C P2_EDGE -C VGA Then to generate the C89 version, first add -Y to that command: catalina hello_99.c -p2 -C99 -lci -C P2_EDGE -C VGA -Y Then the file catalina\hello_99.c can be compiled for debugging, loaded and debugged as follows: catalina catalina\hello_99.c -p2 -lci -C P2_EDGE -C VGA -g3 payload -o2 catalina\hello_99 blackbox catalina\hello_99 Other Changes ------------- 1. Document 'Lua on the Propeller with Catalina' updated. 2. Document 'Catalina Optimizer Reference Manual' updated. 3. The notes in CATALINA.TXT in the demos/coremark directory have been updated to remove the references to 'force_rebuild' (which is not implemented in the coremark makefile!) and also add that faster single-threaded coremark results can be obtained by defining the Catalina symbols NO_INTERRUPTS and FAST_SAVE_RESTORE - this speeds up coremark by about 25% 4. Fixed a bug in the Catalina Optimizer, which means that Optimizing programs that contained inline PASM could cause the program to fail. The Optimizer now skips all code contained in inline PASM statements, because (a) such code does not necessarily use the same memory model as the code generated by LCC (which the Optimizer assumed was always the case), and (b) because optimizing code can change code size and timing, which could be critical in hand-coded PASM. Affected the Propeller 1 and 2, on Windows and Linux. 5. Fixed a bug in the Catalina Optimizer, which means that Optimizing COMPACT programs could cause the program to fail, because the Optimizer was not retaining some "alignl" statements that were REQUIRED for the code to execute correctly (e.g. after an I16B_CALI instruction). Affected the Propeller 1 and 2, on Windows and Linux. 6. Fixed a bug in the inline PASM demo inline_pasm/test_inline_pasm_5.c, which did not correct for pin numbers >= 32 (i.e. accessed via Port B). Affected the Propeller 2 only, on Windows. Linux and Catalyst. 7. Fixed a bug in the Blackbox source level debugger, which was sometimes assigning breakpoint addresses to the wrong source line. The debugger executed the breakpoints correctly, but may have displayed the wrong source line when the breakpoint address was reached.