The Lua compile command (luac) has a really annoying syntax, requiring you to constantly enter long-winded commands like luac -o xxx.lux xxx.lua - and you can't even have the Lua filename before the -o option or it spits the dummy.
I was planning to rewrite it but decided to just add a clua wrapper instead. I just uploaded it to github, but for SourceForge users, it is also in the attached in zip file.
Just put clua.lua on your Catalyst SD card (I put it in the bin directory) and now you can just say clua xxx (or try clua -? for help).
@FredBlais said:
Is it possible to prevent "illegal statement termination" while compiling a function that the declaration of a variable is done after a statement?
No. ANSI C does not allow declarations after statements, unless they appear in a new block.
The simplest solution is to just move the offending declaration before any statements in the block.
For example, the code:
#include <stdio.h>
void main() {
printf("hello world\n");
int i = 1;
printf("i = %d\n", i);
}
will generate:
hello.c:4: illegal statement termination
The preferred solution wold be to simply move the declaration - i.e. change the code to:
#include <stdio.h>
void main() {
int i = 1;
printf("hello world\n");
printf("i = %d\n", i);
}
However, sometimes this is not so easy (e.g. if the initialization of i requires values calculated later). So another solution (which is always possible) is to introduce a new block to make the declaration appear before any statements that need it - for example:
#include <stdio.h>
void main() {
printf("hello world\n");
{
int i = 1;
printf("i = %d\n", i);
}
}
In this case, either solution will fix the problem.
Sorry for bothering you about this repeatedly, but is there a reason you still only support ANSI C when the rest of the world has moved on? Your compiler has lots of neat features, but I'm not using a language that forces me to declare variables up-front before I'm ready to assign real values to them, as it's really bad coding practice. Even the ancient DSP compilers they make me use at work at least attempt to support basic C99 features like declarations after statements; at this point, most of them are GCC-based and support all the current standards. When's the last time you did a survey of what compilers that are still relevant in 2025 don't support declarations after statements even as an optional feature?
That code appears to be using the GCC "labels as values" extension to create a computed goto, as described here .
This is not standard C and would probably not compile with any other C compiler. Add the -pedantic option to gcc to detect all such instances - there may be others and you will need to fix them all.
In this particular case, you can convert that code to a C switch statement. A fairly clear comparison of the two ways of building a VM in C is given here. The gcc extension makes the code more efficient, but it is not portable.
@FredBlais Catalina is a great compiler, but restricted to the C89 dialect of C. To compile later C dialects you'll need to back-port to C89 (which usually isn't too hard) and/or use another compiler. For code that uses C++ or some compiler-specific features you'll have to use a different compiler completely. There are several for the P2; all have their pluses and minuses, and it might be worth posting a question on the general C/C++ forum here.
@Electrodude said:
Sorry for bothering you about this repeatedly, but is there a reason you still only support ANSI C when the rest of the world has moved on? Your compiler has lots of neat features, but I'm not using a language that forces me to declare variables up-front before I'm ready to assign real values to them, as it's really bad coding practice. Even the ancient DSP compilers they make me use at work at least attempt to support basic C99 features like declarations after statements; at this point, most of them are GCC-based and support all the current standards. When's the last time you did a survey of what compilers that are still relevant in 2025 don't support declarations after statements even as an optional feature?
Catalina was originally intended to meet my own need for a C compiler for the Propeller 1, for a project that I completed long ago. I keep Catalina going because there is still no other compiler for the Propeller (1 or 2) that does everything I want. And Catalina is so simple that whenever I do find something else I want to be able to do, I can just add it. I could not do that with any other compiler.
@Electrodude said:
Sorry for bothering you about this repeatedly, but is there a reason you still only support ANSI C when the rest of the world has moved on? Your compiler has lots of neat features, but I'm not using a language that forces me to declare variables up-front before I'm ready to assign real values to them, as it's really bad coding practice. Even the ancient DSP compilers they make me use at work at least attempt to support basic C99 features like declarations after statements; at this point, most of them are GCC-based and support all the current standards. When's the last time you did a survey of what compilers that are still relevant in 2025 don't support declarations after statements even as an optional feature?
Catalina was originally intended to meet my own need for a C compiler for the Propeller 1, for a project that I completed long ago. I keep Catalina going because there is still no other compiler for the Propeller (1 or 2) that does everything I want. And Catalina is so simple that whenever I do find something else I want to be able to do, I can just add it. I could not do that with any other compiler.
For the specific issue of "declaring variables like C99": this is a nice convenience feature to have. It's very nice to be able to type
for (int i = 0; i < n; i++)
rather than having to go back and add a new variable i (or to try to remember what variable names are free in the current scope). It's absolutely not necessary, of course -- it adds nothing but some "syntactic sugar" -- but it does make your life a little bit easier. And of course it'll also make your life easier when you want to port programs from other compilers. Adding this to Catalina would be of benefit to you, personally, as well as to your users.
It's rather like // comments, which are also a C99 feature (not in C89) and yet are supported by Catalina. They add no new capability to the language and are easily emulated by /* comments. But they're handy to have for various reasons.
If changing the Catalina parser to handle in-line variable declarations is a huge pain, then of course it may not be worth it. You'll have to make that determination for yourself. I see that some other lcc forks (like Pelles C and lcc-win32) have done this, so possibly their code could be re-used.
@Electrodude said:
Sorry for bothering you about this repeatedly, but is there a reason you still only support ANSI C when the rest of the world has moved on? Your compiler has lots of neat features, but I'm not using a language that forces me to declare variables up-front before I'm ready to assign real values to them, as it's really bad coding practice. Even the ancient DSP compilers they make me use at work at least attempt to support basic C99 features like declarations after statements; at this point, most of them are GCC-based and support all the current standards. When's the last time you did a survey of what compilers that are still relevant in 2025 don't support declarations after statements even as an optional feature?
Catalina was originally intended to meet my own need for a C compiler for the Propeller 1, for a project that I completed long ago. I keep Catalina going because there is still no other compiler for the Propeller (1 or 2) that does everything I want. And Catalina is so simple that whenever I do find something else I want to be able to do, I can just add it. I could not do that with any other compiler.
But if GCC suits your needs better, use that.
Ross.
Sorry, I'm not trying to be discouraging. I'm just saying that there's a few C99 features that I think you could probably add without too much difficulty that would make it a lot easier for people to compile modern code with your compiler. C is supposed to be easily portable, but that's lost nowadays on Catalina because it can't actually compile anything resembling modern C without first editing the code to be significantly less maintainable. On the other hand, since flexprop supports all the parts of modern C that people actually tend to use, I can just write normal, clean, modern C and test it on my laptop using x86-64 GCC and then compile the exact same code for either Propeller using flexprop and be confident that it will work correctly.
Parallax needs better official tools, but more competing unofficial tools that are good is the second-best thing to that, and I think you're significantly hurting your own project by not allowing C99 declarations.
GCC, which is great on architectures it properly supports, most certainly does not suit my needs better on the P1 because the implementation we have does an abysmal job of dealing with the P1's memory model, and I'm not aware of any complete native P2 ports.
It really comes down to a choice of where I want to spend my time. I'd much prefer to be be spending my time building Propeller applications than compilers, but there still isn't a C compiler available (other then Catalina) than can do what I need it do do, so unfortunately I still have to spend more of my time time on the compiler itself than I would like. But I try to minimize that so I can maximize the time I can spend on applications.
And most often these days, those applications are in Lua and not C anyway. Lua is a much more interesting language than C, and one better suited to self-hosted development. And it's a lot more fun besides. And I think the "fun" part is missing from a lot of Propeller development these days.
I spend time on the actual C compiler only when I have to. For instance, when I find bugs in the code generator - but that is quite rare now. More often, it is because I find a need for some language feature that requires compiler support - a good example is the recently added "alloca" function. That can't be done any other way.
Also, there is a bunch of stuff waiting to be added to Catalina that I would much rather spend my time on than syntactic sugar such as inline declarations, which adds no actual functionality and is fairly trivial to rectify when porting C code. About the only one that I agree would be a real "nice to have" is the ability to declare "for" loop variables inline ** - I might spend some time on that one day, once I have finished everything else I have on my "todo" list.
For instance, at the moment, I am in the middle of adding WiFi support to Catalina, because I have an application for it. Is being able to declare "for" loop variables inline really more important than that? I suppose it might be to some people, but it is not to me.
However, Catalina is 100% open source, and I am aware that other derivatives of LCC have added that particular enhancement. So anyone who wants to work on the parser (which is all that would be required to be modified in this particular case) is welcome to do so. You don't even need Catalina for this - it could be done on any LCC-based compiler and I promise to integrate the results into Catalina.
Fair?
Ross.
** However, don't forget that a "for" loop that includes an in-line declaration that won't work in C89 like:
for (int i = 0; i < MAX; i++) {
/* do stuff with i here */
}
Can be re-written as an equivalent one that will work in any variant of C:
{
int i;
for (i = 0; i < MAX; i++) {
/* do stuff with i here */
}
}
I did puzzle over why I only recently saw that syntax. Now I know why, it's only modern C programs that would use it. I'd only ever learnt ANSI C myself. And even that was only up to as much as I needed at the time.
Hi,
from my perspective of a "maker-user" of the language tools, I have the impression that while for language developers details of language naturally make big difference, for users like me their importance is very much less. Instead besides documentation libraries become much much more interesting!!! The reason is, that I need a week or more, if I have to rewrite or port a I2C device. (For example, I have bought keypads with MPR121, which could be very useful, if I would bring myself to start writing the code for Taqoz....) I have used libraries, which are very much beyond my understanding, I was not forced to try to understand them. So what I still think would give P2 a real boost, would be full blown easy direct support of Arduino libraries out of the box. If possible in the Arduino IDE. As far as I understand, this is just too much work for a non-payed project. (And probably not enough fun.) If this is not possible, then K&R Standard seems to be sufficient. There is good description of this available. I must admit, that I don't even know the differences between the different C (and C++) standards.
@RossH I like your efforts about Lua! Yes, this language could be fun!
If it is possible, it would be very interesting to see, for what and how you use it?
Cheers Christof
@RossH I like your efforts about Lua! Yes, this language could be fun!
If it is possible, it would be very interesting to see, for what and how you use it?
Cheers Christof
Yes, Lua is fun. My current project is probably a bit like the PLC project currently being discussed on another thread here - I want to build a distributed home/farm automation system for off-grid applications, consisting of a cluster of WiFi connected Propellers. And of course, they will all be programmed in Lua. I could use Arduinos - I even bought a couple to try - but I decided against them. They would be cheaper, but are not nearly as much fun!
I used to work on large centralized control systems where a single computer managed thousands of I/O points. For applications like SCADA, power stations, fire control systems or building management. But these days we can dedicate more processing power per I/O point than we used to have available for the entire system. Also, those systems were very "dense", where each I/O unit typically had dozens or hundreds of I/O points. In the system I need, the I/O is very "sparse" - it may have just a few I/O points to monitor or control in each physical location - possibly even just one (e.g. a pump, a tank, a rain gauge, a solar inverter, a generator, a gate, an ultrasonic sensor etc). And these points will be widely distributed geographically.
To connect the I/O units to the central computer we mostly used hardwired serial links (e.g. RS-422) for shorter distances and radio links for longer distances - but these days WiFi can do it more easily and cheaply over both short and long distances. A WiFi repeater can reach up to 5km (or so it says on the box - actually, I only need about 1km - that's the size of our property).
The hardware components I can buy - my work is just the software. I now have nearly all the things I need. I can already use Lua to make remote procedure calls between a cluster of hardwired Propellers, and I'm working on replacing that with WiFi connectivity now.
Sure, I could just buy the entire system "off the shelf" - but where's the fun in that?
In the system I need, the I/O is very "sparse" - it may have just a few I/O points to monitor or control in each physical location - possibly even just one (e.g. a pump, a tank, a rain gauge, a solar inverter, a generator, a gate, an ultrasonic sensor etc). And these points will be widely distributed geographically.
That is an interesting project. Do you plan on documenting the progress in another thread/place possibly ?
In the system I need, the I/O is very "sparse" - it may have just a few I/O points to monitor or control in each physical location - possibly even just one (e.g. a pump, a tank, a rain gauge, a solar inverter, a generator, a gate, an ultrasonic sensor etc). And these points will be widely distributed geographically.
That is an interesting project. Do you plan on documenting the progress in another thread/place possibly ?
Maciek
Yes, I can do, once it advances enough to be distinct from just a Catalina update.
Comments
Something I've been meaning to do for a while ...
The Lua compile command (luac) has a really annoying syntax, requiring you to constantly enter long-winded commands like
luac -o xxx.lux xxx.lua- and you can't even have the Lua filename before the -o option or it spits the dummy.I was planning to rewrite it but decided to just add a clua wrapper instead. I just uploaded it to github, but for SourceForge users, it is also in the attached in zip file.
Just put clua.lua on your Catalyst SD card (I put it in the bin directory) and now you can just say
clua xxx(or tryclua -?for help).Ross.
Is it possible to prevent "illegal statement termination" while compiling a function that the declaration of a variable is done after a statement?
No. ANSI C does not allow declarations after statements, unless they appear in a new block.
The simplest solution is to just move the offending declaration before any statements in the block.
For example, the code:
#include <stdio.h> void main() { printf("hello world\n"); int i = 1; printf("i = %d\n", i); }will generate:
hello.c:4: illegal statement terminationThe preferred solution wold be to simply move the declaration - i.e. change the code to:
#include <stdio.h> void main() { int i = 1; printf("hello world\n"); printf("i = %d\n", i); }However, sometimes this is not so easy (e.g. if the initialization of i requires values calculated later). So another solution (which is always possible) is to introduce a new block to make the declaration appear before any statements that need it - for example:
#include <stdio.h> void main() { printf("hello world\n"); { int i = 1; printf("i = %d\n", i); } }In this case, either solution will fix the problem.
Ross.
I'm trying to compile the MicroBlocks VM for the Propeller 2 (https://microblocks.fun/), I fixed a lot of the illegal statement termination but now I'm stuck at the code below
source code : https://bitbucket.org/john_maloney/smallvm/src/dev/vm/
static void *jumpTable; // initialize jump table void jumpTable[] = { &&halt_op, // stop this task &&stopAll_op, // stop all tasks except this one &&pushImmediate_op, // true, false, and ints that fit in 8 bits [-64..63] &&pushLargeInteger_op, // ints that fit in 24 bits &&pushHugeInteger_op, // ints that need > 24 bits &&pushLiteral_op, // string constant from literals frame ... suspend: // save task state task->ip = ip - (int16 *) task->code; task->sp = sp - task->stack; task->fp = fp - task->stack; return; RESERVED_op: halt_op: codeEnd_op: sendTaskDone(task->taskChunkIndex); task->status = unusedTask; if (unusedTask == tasks[taskCount - 1].status) taskCount--; goto suspend; noop_op: comment_op: POP_ARGS_COMMAND(); DISPATCH(); pushImmediate_op: STACK_CHECK(1); *sp++ = (OBJ) arg; DISPATCH(); ...Sorry for bothering you about this repeatedly, but is there a reason you still only support ANSI C when the rest of the world has moved on? Your compiler has lots of neat features, but I'm not using a language that forces me to declare variables up-front before I'm ready to assign real values to them, as it's really bad coding practice. Even the ancient DSP compilers they make me use at work at least attempt to support basic C99 features like declarations after statements; at this point, most of them are GCC-based and support all the current standards. When's the last time you did a survey of what compilers that are still relevant in 2025 don't support declarations after statements even as an optional feature?
That code appears to be using the GCC "labels as values" extension to create a computed goto, as described here .
This is not standard C and would probably not compile with any other C compiler. Add the -pedantic option to gcc to detect all such instances - there may be others and you will need to fix them all.
In this particular case, you can convert that code to a C switch statement. A fairly clear comparison of the two ways of building a VM in C is given here. The gcc extension makes the code more efficient, but it is not portable.
Ross.
@FredBlais Catalina is a great compiler, but restricted to the C89 dialect of C. To compile later C dialects you'll need to back-port to C89 (which usually isn't too hard) and/or use another compiler. For code that uses C++ or some compiler-specific features you'll have to use a different compiler completely. There are several for the P2; all have their pluses and minuses, and it might be worth posting a question on the general C/C++ forum here.
Catalina was originally intended to meet my own need for a C compiler for the Propeller 1, for a project that I completed long ago. I keep Catalina going because there is still no other compiler for the Propeller (1 or 2) that does everything I want. And Catalina is so simple that whenever I do find something else I want to be able to do, I can just add it. I could not do that with any other compiler.
But if GCC suits your needs better, use that.
Ross.
For the specific issue of "declaring variables like C99": this is a nice convenience feature to have. It's very nice to be able to type
rather than having to go back and add a new variable
i(or to try to remember what variable names are free in the current scope). It's absolutely not necessary, of course -- it adds nothing but some "syntactic sugar" -- but it does make your life a little bit easier. And of course it'll also make your life easier when you want to port programs from other compilers. Adding this to Catalina would be of benefit to you, personally, as well as to your users.It's rather like
//comments, which are also a C99 feature (not in C89) and yet are supported by Catalina. They add no new capability to the language and are easily emulated by/*comments. But they're handy to have for various reasons.If changing the Catalina parser to handle in-line variable declarations is a huge pain, then of course it may not be worth it. You'll have to make that determination for yourself. I see that some other lcc forks (like Pelles C and lcc-win32) have done this, so possibly their code could be re-used.
Sorry, I'm not trying to be discouraging. I'm just saying that there's a few C99 features that I think you could probably add without too much difficulty that would make it a lot easier for people to compile modern code with your compiler. C is supposed to be easily portable, but that's lost nowadays on Catalina because it can't actually compile anything resembling modern C without first editing the code to be significantly less maintainable. On the other hand, since flexprop supports all the parts of modern C that people actually tend to use, I can just write normal, clean, modern C and test it on my laptop using x86-64 GCC and then compile the exact same code for either Propeller using flexprop and be confident that it will work correctly.
Parallax needs better official tools, but more competing unofficial tools that are good is the second-best thing to that, and I think you're significantly hurting your own project by not allowing C99 declarations.
GCC, which is great on architectures it properly supports, most certainly does not suit my needs better on the P1 because the implementation we have does an abysmal job of dealing with the P1's memory model, and I'm not aware of any complete native P2 ports.
It really comes down to a choice of where I want to spend my time. I'd much prefer to be be spending my time building Propeller applications than compilers, but there still isn't a C compiler available (other then Catalina) than can do what I need it do do, so unfortunately I still have to spend more of my time time on the compiler itself than I would like. But I try to minimize that so I can maximize the time I can spend on applications.
And most often these days, those applications are in Lua and not C anyway. Lua is a much more interesting language than C, and one better suited to self-hosted development. And it's a lot more fun besides. And I think the "fun" part is missing from a lot of Propeller development these days.
I spend time on the actual C compiler only when I have to. For instance, when I find bugs in the code generator - but that is quite rare now. More often, it is because I find a need for some language feature that requires compiler support - a good example is the recently added "alloca" function. That can't be done any other way.
Also, there is a bunch of stuff waiting to be added to Catalina that I would much rather spend my time on than syntactic sugar such as inline declarations, which adds no actual functionality and is fairly trivial to rectify when porting C code. About the only one that I agree would be a real "nice to have" is the ability to declare "for" loop variables inline ** - I might spend some time on that one day, once I have finished everything else I have on my "todo" list.
For instance, at the moment, I am in the middle of adding WiFi support to Catalina, because I have an application for it. Is being able to declare "for" loop variables inline really more important than that? I suppose it might be to some people, but it is not to me.
However, Catalina is 100% open source, and I am aware that other derivatives of LCC have added that particular enhancement. So anyone who wants to work on the parser (which is all that would be required to be modified in this particular case) is welcome to do so. You don't even need Catalina for this - it could be done on any LCC-based compiler and I promise to integrate the results into Catalina.
Fair?
Ross.
** However, don't forget that a "for" loop that includes an in-line declaration that won't work in C89 like:
for (int i = 0; i < MAX; i++) { /* do stuff with i here */ }Can be re-written as an equivalent one that will work in any variant of C:
{ int i; for (i = 0; i < MAX; i++) { /* do stuff with i here */ } }I did puzzle over why I only recently saw that syntax. Now I know why, it's only modern C programs that would use it. I'd only ever learnt ANSI C myself. And even that was only up to as much as I needed at the time.
Hi,
from my perspective of a "maker-user" of the language tools, I have the impression that while for language developers details of language naturally make big difference, for users like me their importance is very much less. Instead besides documentation libraries become much much more interesting!!! The reason is, that I need a week or more, if I have to rewrite or port a I2C device. (For example, I have bought keypads with MPR121, which could be very useful, if I would bring myself to start writing the code for Taqoz....) I have used libraries, which are very much beyond my understanding, I was not forced to try to understand them. So what I still think would give P2 a real boost, would be full blown easy direct support of Arduino libraries out of the box. If possible in the Arduino IDE. As far as I understand, this is just too much work for a non-payed project. (And probably not enough fun.) If this is not possible, then K&R Standard seems to be sufficient. There is good description of this available. I must admit, that I don't even know the differences between the different C (and C++) standards.
@RossH I like your efforts about Lua! Yes, this language could be fun!
If it is possible, it would be very interesting to see, for what and how you use it?
Cheers Christof
Yes, Lua is fun. My current project is probably a bit like the PLC project currently being discussed on another thread here - I want to build a distributed home/farm automation system for off-grid applications, consisting of a cluster of WiFi connected Propellers. And of course, they will all be programmed in Lua. I could use Arduinos - I even bought a couple to try - but I decided against them. They would be cheaper, but are not nearly as much fun!
I used to work on large centralized control systems where a single computer managed thousands of I/O points. For applications like SCADA, power stations, fire control systems or building management. But these days we can dedicate more processing power per I/O point than we used to have available for the entire system. Also, those systems were very "dense", where each I/O unit typically had dozens or hundreds of I/O points. In the system I need, the I/O is very "sparse" - it may have just a few I/O points to monitor or control in each physical location - possibly even just one (e.g. a pump, a tank, a rain gauge, a solar inverter, a generator, a gate, an ultrasonic sensor etc). And these points will be widely distributed geographically.
To connect the I/O units to the central computer we mostly used hardwired serial links (e.g. RS-422) for shorter distances and radio links for longer distances - but these days WiFi can do it more easily and cheaply over both short and long distances. A WiFi repeater can reach up to 5km (or so it says on the box - actually, I only need about 1km - that's the size of our property).
The hardware components I can buy - my work is just the software. I now have nearly all the things I need. I can already use Lua to make remote procedure calls between a cluster of hardwired Propellers, and I'm working on replacing that with WiFi connectivity now.
Sure, I could just buy the entire system "off the shelf" - but where's the fun in that?
Ross.
That is an interesting project. Do you plan on documenting the progress in another thread/place possibly ?
Maciek
Yes, I can do, once it advances enough to be distinct from just a Catalina update.