Enhancement request: operator methods
ManAtWork
Posts: 2,176
in Propeller 2
I think it would be a big advantage if the C and spin compilers for the P2 would support operator methods.
For those who are not familiar with C++, operator methods work like this:
You declare a function, for example
As the method calls are only "syntactical aliases" no extra code generation or byte codes for the interpreter are needed. It would just require some extension to the parser.
Because there are no structs or classes in spin user defined operators would require some special calling conventions. Also, the above example (originally C++ code) would not work in FlexC because there is no new() and no constructor/destructor methods. Creating "res" on the stack would probably work for a single call but not if (a+b) is part of a longer formula. The result would be overwritten by the next function call.
Probably we could use the multiple return value mechanism for this. We could restrict the data types used for operator methods to small arrays which would still allow the implementation of 64 bit integers, doubles, vectors and matrices.
For those who are not familiar with C++, operator methods work like this:
You declare a function, for example
Vector3D operator+ (const Vector3D& a, const Vector3D& b);
{
Vector3D res;
res.x= a.x + b.x;
res.y= a.y + b.y;
res.z= a.z + b.z;
return res
}
Now, every time you write "c = a + b;" (all variables are of type Vector3D) the compiler translates this to a call to the function as if you wrote "c = operator+ (a, b);". This not only makes the code much more readable but would allow that data types like 64 bit integers or double precision floats don't have to be implemented in the compiler itself but could be built in normal code by any user. By using inline assembler it could be even done very efficiently, I think.As the method calls are only "syntactical aliases" no extra code generation or byte codes for the interpreter are needed. It would just require some extension to the parser.
Because there are no structs or classes in spin user defined operators would require some special calling conventions. Also, the above example (originally C++ code) would not work in FlexC because there is no new() and no constructor/destructor methods. Creating "res" on the stack would probably work for a single call but not if (a+b) is part of a longer formula. The result would be overwritten by the next function call.
Probably we could use the multiple return value mechanism for this. We could restrict the data types used for operator methods to small arrays which would still allow the implementation of 64 bit integers, doubles, vectors and matrices.
Comments
However, in C it should be no big problem to implement operators as a subset of the C++ language. Is I said previously, in propeller C there are no constructors/destructors so it should be avoided to create new instances. Therefore I think it would be better to declare binary operators like "+" without a result but with refernce parameters (pointers).
So Vector3D c = a + b; would be translated to a call to
As nobody has commented on my sugestions so far, does this mean that...
1) nobody finds the idea interesting enough?
2) the compiler developpers (Chip, Eric?) are too busy at the moment?
3) nobody unerstands what I'm saying?
I recall seeing two attempts at getting the GCC tool chain to produce code for the P2. This was furthest along:
https://github.com/totalspectrum/riscvp2
Like anything else it needs a user base, otherwise these projects die on the vine so to speak.
The P2 has that special functionality to interpret byte code quickly and compactly.
Much like how Chip has created unique codes for interpreted spin2, Eric wrote an interpreter that for the most part executes Risc V instructions, with some custom codes (as allowed by Risc V).
Fire up a Linux VM and give it a shot if you want C++. Fork his project since if you're a C++ master, you're totally capable of doing it. Long road ahead for sure, but have to start somewhere.
Seem to be more and more enhancement type requests among others.
I think its hard enough for the limited number of people putting time into Spin, C, compilers, etc, already.
It just occurred to me that we could make a program that goes into the 8-pin flash which could turn a few pins into a USB pair and do the same thing as the MicroBit. The compiler could be inside and it could write the compiler status out to a file that you could open from the same virtual file system. Kind of restricted, but would work on any platform without development tools.
Exactly. The operator methods would not only make that code much shorter and more readable. It would also make it possible that anyone could build his own abstract data type and also use the elegant formula-like syntax.
Or in other words, it's a bit of extra work for the compiler developper. However, it would save him much more extra work of implementing those data types "hardcoded" into the compiler.
Hmm, I have some doubts that starting another project and adding another language to the pool that nearly nobody is using is a good idea. It's hard to convince people to use a different language or a different compiler. I think Spin is the most widely used language in the propeller community followed by forth and C, probably. If the feature would be added to FlexC (not all but) many users could immediately benefit from it.
I know, it's always easier to point at somone else instead of doing the work by myself. If Eric can't do it I'll try to help him.
Unfortunatelly, I have no idea at the moment how operator methods could be added to Spin or if it makes sense at all.
And I don't like GCC at all. It's OK for developping software for PCs but not for embedded systems. It's just to complex. I have so many problems with it on ARM systems. It generates awfully inefficient code if optimization is switched off. A simple assignment to set a bit in a register compiles to >10 assembler instructions. And if I switch on optimization it deletes all of my code because it thinks that results of calculations are not output. Even declaring all variables volatile doesn't help. You spend all your time struggeling with compiler options instead of real work.
Thanks for the suggestion though, and it's good to discuss things like this. It'd be really nice to come up with a way to do this in Spin, but given Spin's lack of type checking I can't think of any obvious way right now
I was looking at the smars robot (basically a 3d printed 4 wheel vehicle with tracks). Uses 2 small GA12-N20 (3-3.5mm dia shaft!!) dc motors typically driven with a pair of L293. Thought I would take a pair of these to my 5yo grandsons in the UK in July (probably not going now tho). I do want to use a P1 or P2 to drive it rather than an Arduino mini or similar
Also been looking for 3d printed robot arms similar to what Phil (PhiPi) has laser cut over on the BlocklyProp thread.
Thanks David. I think most of the C99 language features are supported by FlexC now except for 64 bit values (doubles and long long). The C libraries still need some work and that's what I was working on when I got sick. There is support for a limited number of C++ features, including references, default parameter values, and yes, classes (but only a subset of what C++ offers; there is no subclassing yet, no private/public distinction, and methods must be declared inline).