Shop OBEX P1 Docs P2 Docs Learn Events
Thoughts on propeller from arduino side - Page 3 — Parallax Forums

Thoughts on propeller from arduino side

135

Comments

  • RossHRossH Posts: 5,336
    edited 2014-04-24 17:47
    jazzed wrote: »
    If you want to cooperate great, if not you'll be left out again.

    Still bugged that I refused to join your PropGCC team then? :lol:

    Ross.
  • jazzedjazzed Posts: 11,803
    edited 2014-04-24 18:32
    RossH wrote: »
    Still bugged that I refused to join your PropGCC team then? :lol:
    Not at all - never was.

    Still bugged that Parallax never called you back about 5 years ago? I had nothing to do with it.
  • RossHRossH Posts: 5,336
    edited 2014-04-24 18:47
    jazzed wrote: »
    Still bugged that Parallax never called you back about 5 years ago? I had nothing to do with it.

    No, I never thought you did - from memory, you weren't even working with Parallax at that time. I do know a bit about what happened, and I think it was mainly just an unfortunate turn of events.

    It was your behavior after that which made me decide to have nothing to do with the PropGCC team while ever you were associated with it.

    Ross.
  • jazzedjazzed Posts: 11,803
    edited 2014-04-24 18:55
    Often people get the benefit of a doubt. Too bad I never gave you that. I've concluded that most of the issues were inabilities to communicate.

    Anyway our choices were made long ago right or wrong. I have no problem living with the way things turned out.

    RossH wrote: »
    No, I never thought you did - from memory, you weren't even working with Parallax at that time. I do know a bit about what happened, and I think it was mainly just an unfortunate turn of events.

    It was your behavior after that which made me decide to have nothing to do with the PropGCC team while ever you were associated with it.

    Ross.
  • RamonRamon Posts: 484
    edited 2014-04-24 19:19
    "Why Propeller architecture is not in the official GCC repository?"

    I made this question before (the big thread, post #6644):

    Is there any plan to include Propeller into the official gcc repository?
  • jazzedjazzed Posts: 11,803
    edited 2014-04-24 20:06
    @Ramon,

    We've been waiting to finish support for the new chip before trying to merge with the GCC mainline.

    Sorry, but it is impossible for me to keep up with "the big thread".
  • RossHRossH Posts: 5,336
    edited 2014-04-24 20:54
    RossH wrote: »
    Well, I suppose I could be convinced of its utility if there were enough real-world examples, and adding it is fairly easy, so I may do it. But I've looked through all the objects I routinely use, and I can find only two or three (out of dozens) that could possibly be re-coded in C, and even then the result would simply be larger executable sizes and slower objects.

    I can't see any actual benefit.

    Ross.

    Ok. I've just written a code generator for Catalina that generates COG mode C - i.e. C code compiled to execute stand-alone within a single cog, including the stack and all variables. Seems to work for simple C code, but obviously it will need more testing.

    This first cut supports only 32 bit integer types. I could add 8 bit types if anyone thought they would be useful, but I doubt I would bother with 16 bit types. Also, there is currently no library or plugin support, so COG mode will really only be useful for writing low-level stand-alone cog objects (such as a driver). Of course, those cog objects can be used by Catalina, but they will not themselves be able to make use of any other Catalina facilities.

    I may add this to the next release of Catalina if I get time. Since COG code requires no support from any other part of Catalina, if I do add it I'll arrange to make it possible to spit out the output as a simple binary "blob", much the same way the spinc utility currenty does - these "blobs" can then be used from any language.

    Not sure exactly when the next release of Catalina will be - I'm currently in the middle of re-plumbing Catalina's internals to make it possible to support the P16X32B, and I'm also testing a version of the graphics library that works in ALL memory modes (currently it works only in COMPACT, TINY and SMALL modes - LARGE mode was broken).

    Ross.
  • jmgjmg Posts: 15,140
    edited 2014-04-24 21:18
    RossH wrote: »
    Well, I suppose I could be convinced of its utility if there were enough real-world examples, and adding it is fairly easy, so I may do it. But I've looked through all the objects I routinely use, and I can find only two or three (out of dozens) that could possibly be re-coded in C, and even then the result would simply be larger executable sizes and slower objects.

    I can't see any actual benefit.

    Perhaps, but "and even then the result would simply be larger executable sizes and slower objects. " is pretty much true of almost any HLL vs ASM, but I can still see many advantages.

    * It is inherently portable between P1 and P2 (and more loosely to/from other applicaitons)
    * Properly done, with Source-commented PASM generated, it can be a great way to learn PASM
    * If the Code is still too slow, in GOG mode, users can fine-tune the Assembly and use that.

    Ideally the code-generators improve over time, so the final step is needed less and less.
    Faster & Smarter Silicon also helps do more, without needing to step into PASM.
  • Heater.Heater. Posts: 21,230
    edited 2014-04-24 22:28
    RossH,
    ...I could be convinced of its utility if there were enough real-world examples...
    That's a bit of a chickens and eggs problem isn't it? Especially in the case of Catalina which so far does not generate native code, so of course your users have not come up with any examples.

    But which ever compiler I get the feeling it's still early days for C on the Propeller. So I would not expect to see many examples. I'm sure that will change with the PII.

    Aside: I do love these compiler wars. It's great for the Prop user community to have choice and it seems to spur innovation in both.

    Just wait till the Clang guys turn up and create a Propeller back end for LLVM :)
  • RamonRamon Posts: 484
    edited 2014-04-24 23:48
    jazzed wrote: »
    We've been waiting to finish support for the new chip before trying to merge with the GCC mainline.

    Good news ! The merge will be started only after real ICs are shipped? Or can a beta version be released after Chip announces the new FPGA image?
  • Heater.Heater. Posts: 21,230
    edited 2014-04-24 23:57
    Ramon,

    The merging of propgcc code back to the main line GCC project is not really of any concern or benefit to us the propgcc users at this point. We can just use the propgcc releases or build it ourselves from the source repository.

    It becomes a concern in the long term when we would like to see GCC support the Propeller well into the future, perhaps after all the current propgcc team has moved on to other more interesting things.

    I imagine this all depends on the GCC maintainers accepting propgcc changes back into their code base. They may not want even want to unless the Propeller becomes a lot more widely adopted.

    I can't imagine the GCC team has any interest in adopting support for a chip that does not exist yet.

    I'm confident that a propgcc supporting the P2 will emerge well before the actual P2 goes into production. Especially if Chip can promise to stop messing with the instruction set soon.
  • RamonRamon Posts: 484
    edited 2014-04-25 00:19
    You are wrong. The GCC compiler already supports architectures that doesn't exist as IC (MMIX): http://gcc.gnu.org/backends.html

    The inclusion of the propeller architecture into the official version has benefits to both users and Parallax itself.
  • Brian FairchildBrian Fairchild Posts: 549
    edited 2014-04-25 00:26
    Ramon wrote: »
    Y
    ...architectures that doesn't exist as IC (MMIX): http://gcc.gnu.org/backends.html

    But some of those are in there for historical reasons rather than pragmatic reasons.
  • RamonRamon Posts: 484
    edited 2014-04-25 00:51
    But some of those are in there for historical reasons rather than pragmatic reasons.

    That is precisely my point: "pragmatic reasons". I think that support of the current P1 and future Propeller into the official gcc has a lot of benefits for both users and parallax itself.

    Am I the only one here that sees benefits in having the propeller architecture into the GCC mainline?
  • Heater.Heater. Posts: 21,230
    edited 2014-04-25 00:54
    Ramon,
    You are wrong. The GCC compiler already supports architectures that doesn't exist as
    Very true. I have no idea how many such "virtual" architectures are supported. However MIX is a very special case I believe. Devised decades ago by the famous Donald Knuth for pedagogical purposes in his famous books.

    As a counter example there is GCC for things like the 6809 microprocessor that are not in the GCC mainline and I imagine never will be. And that is a real chip that has sold millions more than the Propeller. It would be asking a bt much for the GCC project to support everything.
  • Heater.Heater. Posts: 21,230
    edited 2014-04-25 00:59
    I think that support of the current P1 and future Propeller into the official gcc has a lot of benefits for both users and parallax itself.


    Am I the only one here that sees benefits in having the propeller architecture into the GCC mainline?
    No. We don't disagree with you.


    However having the propgcc folded into the mainline is not up to the propgcc team or Parallax. It's up to the GCC project. It's their project right?


    The best we can hope is that propgcc is done very well and the Propellers sell well and become well known and then the GCC project sees it as a valuable addition.


    Meanwhile, we can happily continue with what we have with no practical downside.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-04-25 02:52
    jazzed wrote: »
    Propeller GCC is getting plenty of use. Don't assume too much Ross.

    I'm just saying that there is an opportunity. If you want to cooperate great, if not you'll be left out again.
    Unfortunately, it is precisely your attitude which has kept some of us away!
  • Heater.Heater. Posts: 21,230
    edited 2014-04-25 03:43
    What attitude? Jazzed has been doing sterling work and always been very helpful.
  • Heater.Heater. Posts: 21,230
    edited 2014-04-25 03:57
    potatohead,
    And for me C is verbose.
    Amazing! Most people who turn to C point the finger at ADA, Pascal, Cobol, Java etc etc as being "too verbose". This must be the first time I have heard C being accused of verbosity.

    Now, I do see where you are coming from given that Spin does away with the curly brackets and some parenthesis.

    However I see that as an illusion. That dependency on white space for block delimiting is "verbosity", only it's hard to see. Besides Spin is a lot less expressive language.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-25 10:25
    There should be nothing amazing about that.

    I'm not saying one is better than the other. I am sharing what impacts me and how I see things. Sometimes why.

    SPIN does not require a person to know or track as many things to author programs. Additionally, it's one with PASM. Finally, it's simple nature, lack of type checks, and many nice ways to express data make building projects simple, productive. Yes, one can get into trouble with those things, but hey. One can just get into trouble no matter what. Non issue for me.

    I particularly like all of the options SPIN has in the DAT section for how data is represented. It's easy to read, very expressive in that way, and I never did like the whole 0x thing.

    In SPIN we get all kinds of stuff! Just type it in, label it, specify an alignment if desired and go! I really like that. Probably my favorite feature, mostly because I can input data, literals, whatever in basically the form I'm thinking about it in, conversions optional nearly all the time. Second favorite feature is all the nice operators, shifts, assignments, booleans, and so on, making for concise expressions that do a lot, and that do them in mostly the same way one would do them in PASM, though that's not required at all. Can improve speed when well understood and applied.

    I have to do extra stuff in C in these areas that I don't have to do in SPIN. And then again, with higher level constructs, there are things one has to do, or just can't do or must hack in SPIN, one can do easily in C. I don't care about these differences. What I do care is that we have the options so that when tasks come up or make sense, people can get tools that they find optimal without having to worry about the politics of it all.

    And of course SPIN is missing a ton of stuff! Maybe we can add some of those things and improve it for larger projects. Of course, we may also get simple inline PASM too, which will be awesome!

    IMHO, it's much better to understand why we are doing what we are doing, and have options for those things. The way I see it, we should maximize SPIN+PASM for the things it does well. And we should maximize C for the things it does well.

    From there, people do what they do, no worries, until there are. And at that point, people seek better options. There isn't one unified "best" and there never will be. so why worry about it at all? Maximize stuff, do things, worry less.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-25 10:26
    As for the illusion comment...

    It's like "dark matter", in that if we look at the guts of things, like physics people do about the nature of the world, that matters and the illusion is broken.

    From a real basic, what do I have to know, what do I have to type, what do I have to read, SPIN is considerably leaner and easier to operate with than C and a lot of other stuff is. Illusion or not, that just is, whatever we call it.
  • jazzedjazzed Posts: 11,803
    edited 2014-04-25 12:37
    Spin is a novice language as is PBasic.

    Chip hit a home run with PBasic because it was very simple and timely in a world without easy MCU solutions. With Spin he got a base-hit ... or whatever depending on who you ask ... in a world of great competition.

    A goal of business is to have as many customers as possible. That is achieved many ways of course. Some languages like C exclude many customers. The great irony of course is that not having C also excludes many customers. One quote I remember is (paraphrased and uncited so I don't get splattered with yellow juice) "well, maybe those aren't the customers you want."

    Spin and PASM were designed for Propeller according to Chip's minimalist philosophy which is attractive. Unfortunately that's not what everyone needs especially with so many other simple and well paved options.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-25 13:08
    I agree with all of that.

    Good news is C is there and improving. In the end it's about users. (customers, but I think of them as users for a lot of subtle reasons)

    Maybe we will maximize users going forward.

    Another goal of business is to maximize revenue per user. This sometimes runs in conflict with having the most possible. Depends on what is worth what and who spends and why.

    Having a robust, simple environment is a good thing. As for novice, maybe. I know some people with considerable skill, who enjoy SPIN for it's basic nature.

    Whether or not it's novice really depend on context. And whether it's a good start for a novice also depends. No one size fits all here, just people and options.

    One thing I am sure of is less ugly surrounding these things = more, better and happy users.
  • jazzedjazzed Posts: 11,803
    edited 2014-04-25 13:17
    potatohead wrote: »
    One thing I am sure of is less ugly surrounding these things = more, better and happy users.

    +1

    Less ugly would be more positive contributions.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-25 13:53
    Yep.

    I think we will see this continue to improve as the tools do. And I say improve because the C tools are good now. I'm happy with the state of things now and will be contributing IN C, SPIN and PASM on the new chip. Looking forward to it.

    For me currently, I have some mentoring in progress that I don't share here, and some projects that do not contain generally sharable things.

    Others have their reasons too.

    Look at what Roy might bring to the table, and Ross just added COG code. :) Not that those two are special, just came to mind on this discussion. SRLM has made some good ones, and you have your own too.

    When we get to building a PropGCC on the new chip, I'll have some things to do there as well. (thank you for tagging me for contributor access)

    This time around on our language wheel of pain and punishment, I thought just framing it as options makes more sense. There is some history and it's gonna be there, but we can always add options. Maybe just doing that for a while will improve things over all.
  • David BetzDavid Betz Posts: 14,511
    edited 2014-04-25 20:25
    potatohead wrote: »
    I particularly like all of the options SPIN has in the DAT section for how data is represented. It's easy to read, very expressive in that way, and I never did like the whole 0x thing.

    In SPIN we get all kinds of stuff! Just type it in, label it, specify an alignment if desired and go! I really like that. Probably my favorite feature, mostly because I can input data, literals, whatever in basically the form I'm thinking about it in, conversions optional nearly all the time.
    Can you give some examples of this? Certainly the difference between 0x1234 and $1234 is not great. You may prefer one over the other but I doubt it's a show stopper.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-04-26 03:47
    We really live in a world where standards quickly get abused, more so than every before.

    So supporting the phyical plug-in of Arduino shields seems like a good thing, maybe even a no-brainer.
    But I just don't feel that Parallax should be too vested in porting all and everything from the Arduino to the Propeller. It becomes a complex, high-overhead task to do so, and time might be better spent demonstrating better ways to run the device on the Propeller.

    But I do suspect there are going to be boxes and boxes of Arduino shields sitting around in closets for years to come. And whenever someone clears their closet and passes on a box of Arduino shields, there is an opportunity to have the new user explore Propellers as a valid alternative to Arduino.

    So... the PropellerASC+ is a an important first step. But the Propeller1+ might need to have 16 ADC and more i/o involved. Please see the attached interface diagram.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-26 11:10
    @David, yes I will today.
  • rjo__rjo__ Posts: 2,114
    edited 2014-04-26 14:57
    IMNSHO (in theory) the new Propeller chip will provide an economical, easy, and open alternative to Arduino users who need more bandwidth, memory and determinism. In reality, since the corporate bias is heavily tilted toward Broadcom, fairly competing in that market is an uphill battle, certainly not one that Parallax should directly attempt. If there is an opportunity, then Parallax should support a third party effort. Even a fraction of that market is worth something.

    I like the idea of the new Propeller being placed on a very tiny module(with SDRAM:) and micro SD card slot. (with a cheap connector for the I/O.)

    Rich
  • jmgjmg Posts: 15,140
    edited 2014-04-26 15:39
    rjo__ wrote: »
    I like the idea of the new Propeller being placed on a very tiny module(with SDRAM:) and micro SD card slot. (with a cheap connector for the I/O.)

    There is a good example of a compact module, with cheap IO expansion here, which would be a good 'standard' to follow.

    http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/
Sign In or Register to comment.