Shop OBEX P1 Docs P2 Docs Learn Events
Enhancement request: operator methods — Parallax Forums

Enhancement request: operator methods

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
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

  • Hmm, I fear I missed something. In Spin this is not possible beacuse there is no type checking. There is no way for the compiler to find out which method to call. So we would have to write something like
    OBJ
      dm: "DoubleMath"
    
    ...
    c = a dm.+ b
    
    Which is only a shortcut of dm.Add (c, a, b). Doesn't really make sense. So I think for Spin it's not worth the effort.

    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
    void operator+ (Vector3D &c, const Vector3D &a, const Vector3D &b);
    

    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 like the idea, if I understand it correctly. I've been wanting a way to implement more complex math in spin for ages. Some cases I run into that use floating point math are easily solved using one of the floating point objects, or fixed-point math...no problem. But there are others that are already a paragraph or more in size in natural form (a + b * c / d) that quickly start to become too difficult to reliably match up parentheses using a float object, and/or scale numbers up or back down if using fixed-point. The solutions I've asked for in the past I think are probably a lot of work (either float support, which is probably the hardest, or a 64-bit size support... long long?) - not sure how this solution compares.
  • whickerwhicker Posts: 749
    edited 2020-03-22 15:07
    I say if you want the syntactical power of C++, then use that language.

    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.
  • I'd have to agree.

    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.

  • cgraceycgracey Posts: 14,133
    I was just talking to Ken and we were mulling over a cheap robotics platform for education. We've made adapters for mating MicroBit (Python) boards to our standard robot chassis, but we could fabricate something less expensive, yet. The MicroBit is easy to deploy because it just plugs into USB and looks like a file system. You drop a source code file onto it and it loads it internally and executes it. Kind of limited, but very easy to get running.

    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.
  • avsa242 wrote: »
    ... in natural form (a + b * c / d) that quickly start to become too difficult to reliably match up parentheses using a float object,

    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.
    whicker wrote: »
    I say if you want the syntactical power of C++, then use that language.
    ...riscvp2

    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.

  • Operator functions is something I've definitely thought about for FlexC, but it requires quite a few changes in the parser and in type deduction code. So it's on the long term roadmap, but there are a lot of other things that'll probably have to be done first.

    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 :(.
  • ersmith wrote: »
    Operator functions is something I've definitely thought about for FlexC, but it requires quite a few changes in the parser and in type deduction code. So it's on the long term roadmap, but there are a lot of other things that'll probably have to be done first.

    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 :(.
    Hi Eric. I'm glad to see you're back and on your way to recovery. What is the current state of FlexC? Is it pretty much stable at least as far as supporting ANSI C? I think you've mentioned adding some limited support for classes too.

  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    I was just talking to Ken and we were mulling over a cheap robotics platform for education. We've made adapters for mating MicroBit (Python) boards to our standard robot chassis, but we could fabricate something less expensive, yet. The MicroBit is easy to deploy because it just plugs into USB and looks like a file system. You drop a source code file onto it and it loads it internally and executes it. Kind of limited, but very easy to get running.

    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.

    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.
  • David Betz wrote: »
    ersmith wrote: »
    Operator functions is something I've definitely thought about for FlexC, but it requires quite a few changes in the parser and in type deduction code. So it's on the long term roadmap, but there are a lot of other things that'll probably have to be done first.

    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 :(.
    Hi Eric. I'm glad to see you're back and on your way to recovery. What is the current state of FlexC? Is it pretty much stable at least as far as supporting ANSI C? I think you've mentioned adding some limited support for classes too.

    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).
  • ersmith wrote: »
    David Betz wrote: »
    ersmith wrote: »
    Operator functions is something I've definitely thought about for FlexC, but it requires quite a few changes in the parser and in type deduction code. So it's on the long term roadmap, but there are a lot of other things that'll probably have to be done first.

    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 :(.
    Hi Eric. I'm glad to see you're back and on your way to recovery. What is the current state of FlexC? Is it pretty much stable at least as far as supporting ANSI C? I think you've mentioned adding some limited support for classes too.

    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).
    That's enough of C++ to make it interesting. Subclassing would be a very nice addition. It would be nice to add it to Spin as well.

Sign In or Register to comment.