Shop OBEX P1 Docs P2 Docs Learn Events
PropGCC Propeller 2 Bug Fixes - and your chance for first-release Propeller hardware! — Parallax Forums

PropGCC Propeller 2 Bug Fixes - and your chance for first-release Propeller hardware!

Ken GraceyKen Gracey Posts: 7,386
edited 2013-03-27 07:04 in Propeller 2
Hello there,

David Betz, Eric Smith and Steve Denson have made significant progress on porting PropGCC to Propeller 2. Internally, we're progressing nicely on using PropGCC on Propeller 1 for a new educational program. These guys really warrant significant testing support from the rest of us for locating bugs. We're interested in both Propeller 1 PropGCC testing (you can pretty much use any board) and with the DE0-Nano and the DE2-115 boards for Propeller 2. The -mp2 command line option builds for P2 code. Again, Propeller 1 testing is just as important as Propeller 2.

The Windows build is here:

http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-2013-02-26.zip&can=2&q=#makechanges

The reason we want P1 verification is that the developers want to merge their p2tgest branch into the default branch without breaking any P1 support.

There is no Linux of Mac release yet, but request it here if you need one and David Betz will jump in and take care of it for us. Or, you can check out the code and build the "p2test-2013-02-26" tag of the "p2test" branch of the code currently in the Google Code repository:

http://code.google.com/p/propgcc/


What about that Propeller 2 hardware you mentioned, Ken?

That's right! Produce some substantive bug huts for us and we shall reward you! There's no legal agreement, no formality to this offer - I'll just comb the forums and check with a few GCC gurus about who has provided help. And when we have Propeller 2 boards in hand I shall promise to get them to you first, right off the production line and ahead of all other backorders!

We want to release Propeller 2 with a fully-tested multicore C compiler. The whole C toolchain will be open source, multilingual and multi-platform with your help!

Thank you to everybody, ahead of time!

Ken Gracey

«1345

Comments

  • KyeKye Posts: 2,200
    edited 2013-03-14 11:34
    I'll be testing the GCC compiler really soon with a new library I'm developing... I won't have any news to report until August or so however.
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2013-03-14 13:41
    Kye wrote: »
    I'll be testing the GCC compiler really soon with a new library I'm developing... I won't have any news to report until August or so however.

    Kwabbers - anytime is fine. We appreciate your involvement.

    Ken
  • pedwardpedward Posts: 1,642
    edited 2013-03-14 22:45
    Since I can see where this is going, I have just included a complete and tested user space interface for TCP/IP communications. This is written in C++ and does all of the heavy lifting of using the runtime library functions that implement a TCP stack.

    You could look at it like this: Here is some code that shows you what is actually needed in a runtime to get TCP/IP support.

    I have a variety of other interfaces built on top of it for FTP, SMTP, and POP that I will release as well.

    I would really like to be involved in developing a network stack for the P2 and I think C is probably the best environment to make that happen, since you can leverage a lot of existing code and it makes the stack more accessible to professionals.
  • potatoheadpotatohead Posts: 10,253
    edited 2013-03-14 23:23
    And Chip just mentioned 32Mb RAM too. :)
  • Heater.Heater. Posts: 21,230
    edited 2013-03-14 23:57
    32MB RAM, This thing is going to be running Linux soon....Na, that's impossible.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 03:50
    Heater. wrote: »
    32MB RAM, This thing is going to be running Linux soon....Na, that's impossible.
    Of course it's possible to run Linux on the Propeller 2. I'm sure you could even run it on P1 with Steve's SDRAM module. PropGCC could get there pretty easily by having its "cache COG" implement a TLB and page tables. The performance would be horrible though at least on P1. How many weeks are you willing to wait for your Linux system to boot? Anyway, with P2 it would be far less horrible. It certainly isn't impossible though.

    So, if I say "it is not impossible" does that mean that it won't ever get done? :-)
  • Heater.Heater. Posts: 21,230
    edited 2013-03-15 04:39
    David,

    Ouch, don't go round say things are possible, we'll never get anything done:)

    Some lunatic managed to get Linux booted on an 8 bit AVR running an ARM emulation. It took, shall we say a short while, to get to the command prompt. So we do have some competition in this area.

    What might be more interesting is getting something more reasonable running, like Contiki or FreeRTOS.
  • RS_JimRS_Jim Posts: 1,751
    edited 2013-03-15 07:24
    Mabe this is my time to Be drug kicking and screaming into learning C!
    Jim
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 07:26
    RS_Jim wrote: »
    Mabe this is my time to Be drug kicking and screaming into learning C!
    Jim
    It's not that bad and there are fewer cryptic operators to learn. :-)
  • RaymanRayman Posts: 13,805
    edited 2013-03-15 08:08
    This is pretty motivating... First dibs on an extra shuttle run chip would be more motivating, but this is good :)

    I didn't really think about using PropGCC because I only have the DE0 setup and one cog.
    But, I guess LMM will work with just one cog, right? I suppose cog mode would work too...
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 08:42
    Rayman wrote: »
    This is pretty motivating... First dibs on an extra shuttle run chip would be more motivating, but this is good :)

    I didn't really think about using PropGCC because I only have the DE0 setup and one cog.
    But, I guess LMM will work with just one cog, right? I suppose cog mode would work too...
    Yes, LMM will work on the DE0-Nano with a single COG. That's what I used to do the port of PropGCC to the P2. I didn't have the DE2-115 board until much later. Either LMM or CMM should work as well as COG mode but I doubt that's very useful for a single COG system.
  • jazzedjazzed Posts: 11,803
    edited 2013-03-15 08:54
    The newlib standard library needs to be ported for Linux to compile. Newlib is just too big for P1.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 08:56
    jazzed wrote: »
    The newlib standard library needs to be ported for Linux to compile. Newlib is just too big for P1.
    It's not too big for P1 using xmm-single mode with your 32mb SDRAM board. However, the performance would probably be horrible.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 08:58
    David Betz wrote: »
    It's not too big for P1 using xmm-single mode with your 32mb SDRAM board. However, the performance would probably be horrible.
    Sorry for commenting on my own message but what is really likely to hinder porting Linux to either P1 or P2 using the existing PropGCC is that we currently put the stack in hub memory no matter which memory model is selected. A 32k stack may be insufficient on the P1 and even a 126k stack may be too small on the P2. Moving the stack to external memory is likely to be really bad for performance at least on the P1.
  • gergtechgergtech Posts: 7
    edited 2013-03-15 09:04
    Hi Ken,

    Is this a hint that I should stop using SPIN and start using PropGCC? Will PropGCC be the same language for both Prop 1 and Prop 2 chips?

    Other than Basic, Spin is the only other language I'm learning?

    Thanks

    Gerg
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 09:04
    Rayman wrote: »
    This is pretty motivating... First dibs on an extra shuttle run chip would be more motivating, but this is good :)

    I didn't really think about using PropGCC because I only have the DE0 setup and one cog.
    But, I guess LMM will work with just one cog, right? I suppose cog mode would work too...

    Maybe we can get Ken to sweeten the deal by having Chip sign the boards. :-)

    I have a board signed by Steve Wozniak that I built at a Vintage Computer Festival a while back.
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2013-03-15 09:06
    Rayman wrote: »
    This is pretty motivating... First dibs on an extra shuttle run chip would be more motivating, but this is good :)

    I didn't really think about using PropGCC because I only have the DE0 setup and one cog.
    But, I guess LMM will work with just one cog, right? I suppose cog mode would work too...

    Rayman, should we have positive test results on P2 shuttle this remains a strong possibility for our trusted circle of developers. Chip has spoken of this idea already, and you know that I'd support this concept as well. If it's a possibility you could count on us providing this as a form of appreciation for bug hunters.

    I do have an extra DE2 board in my office that I could share in exchange for some extensive testing. Then, you could test both P1 and P2. Let me know if this would be of interest to you. As a strong long-term supporter of the Propeller I would be pleased to lend this board to you if you could make productive use of it.

    Sincerely,

    Ken Gracey
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2013-03-15 09:11
    gergtech wrote: »
    Hi Ken,

    Is this a hint that I should stop using SPIN and start using PropGCC? Will PropGCC be the same language for both Prop 1 and Prop 2 chips?

    Other than Basic, Spin is the only other language I'm learning?

    Thanks

    Gerg

    Gerg, you will be able to use either Spin/ASM or C/ASM. PropGCC will be the same language for both chips, but likely with some additional library support for P2-only functions. The compiler base code is the same, using a switch to choose which processor.

    Chip has designed Propeller 2 to have a far more supportive architecture for C. In addition to more memory, higher speed, there's also no Spin interpreter in ROM. This means both language users (Spin or C) will be able to download their own interpreter or kernel to use the language of their choice. I'm certain that both languages are going to be developed to their highest potential since Chip's heart and brain lies with Spin and ASM, yet we've also got a first-class PropGCC team (David Betz, Eric Smith and Steve Denson) developing the C resources. And our internal educational staff has amazing C resources in development. From my point of view, their work has made C almost as easy as PBASIC for the BASIC Stamp, and in some ways easier than Spin (especially for limited, high-level programs).

    The tools will also diverge, with two sets.

    We will have the Propeller Tool for Windows, supporting Spin. For C we will have Simple IDE (open-source, multi-platform and multilingual). I'm sure the many people on these forums will proceed to develop open tools for Spin, and that we might see it in Simple IDE as well.
  • Ken GraceyKen Gracey Posts: 7,386
    edited 2013-03-15 09:13
    David Betz wrote: »
    Maybe we can get Ken to sweeten the deal by having Chip sign the boards. :-)

    I have a board signed by Steve Wozniak that I built at a Vintage Computer Festival a while back.

    Of course I could do this, too. Chip doesn't showboat well, but I could get him to sign some boards for our contributors.
  • blindstarblindstar Posts: 12
    edited 2013-03-15 09:17
    I have a couple of projects running that I built using SimpleIDE 0-8-5 running on a iMac (OSX 10.8.2). I would be more than happy to test them if there was a Mac version available.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 09:19
    blindstar wrote: »
    I have a couple of projects running that I built using SimpleIDE 0-8-5 running on a iMac (OSX 10.8.2). I would be more than happy to test them if there was a Mac version available.
    I don't believe that SimpleIDE knows how to build code for the P2 yet but I think Steve may be close to adding that. At least he was asking questions about building for P2 the other day.
  • jazzedjazzed Posts: 11,803
    edited 2013-03-15 09:47
    David Betz wrote: »
    I don't believe that SimpleIDE knows how to build code for the P2 yet but I think Steve may be close to adding that. At least he was asking questions about building for P2 the other day.

    Builds fine with -mp2 in compiler options.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 09:51
    jazzed wrote: »
    Builds fine with -mp2 in compiler options.
    Cool! That's great news! Thanks Steve.
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-03-15 09:54
    jazzed wrote: »
    Builds fine with -mp2 in compiler options.

    Excellent!!! For an old guy, I really do love my IDEs and building without make files!!
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 09:58
    mindrobots wrote: »
    Excellent!!! For an old guy, I really do love my IDEs and building without make files!!
    I like to use IDEs for simple builds too but some things really benefit from the power of makefiles or some similar build system. I particularly like the Visual Studio and Xcode IDEs.
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-03-15 10:05
    David Betz wrote: »
    I like to use IDEs for simple builds too but some things really benefit from the power of makefiles or some similar build system. I particularly like the Visual Studio and Xcode IDEs.

    I can only write code that builds simply! :lol:
  • SRLMSRLM Posts: 5,045
    edited 2013-03-15 10:39
    mindrobots wrote: »
    Excellent!!! For an old guy, I really do love my IDEs and building without make files!!

    From what I can tell, the main strength (and biggest challenge) of a makefile is to compile each class/file into an object, then link them together. This is, apparently, done for performance reasons. With the relatively small projects that PropGCC is tailored for, I've found it better to simply get rid of all that intermediate stuff and just do a complete compile, every time. Then, all you need to do is something like this:
    propeller-elf-g++ [OPTIONS] *.cpp *.h
    

    I still use a makefile, but not for intermediate compilation. I use it so that I can have different targets, so that I don't forget all the flags that I want, and so on. Once you get rid of the compilation-to-object stuff, the makefile becomes much more like a bash script.
  • RaymanRayman Posts: 13,805
    edited 2013-03-15 10:55
    Ken Gracey wrote: »
    I do have an extra DE2 board in my office that I could share in exchange for some extensive testing. Then, you could test both P1 and P2. Let me know if this would be of interest to you. As a strong long-term supporter of the Propeller I would be pleased to lend this board to you if you could make productive use of it.

    Well, that's an offer that's very hard to refuse! There are some things I'd like to try that need more than 1 cog...
    Thanks Ken.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2013-03-15 11:10
    Ken Gracey wrote: »
    David Betz, Eric Smith and Steve Denson have made significant progress on porting PropGCC to Propeller 2. Internally, we're progressing nicely on using PropGCC on Propeller 1 for a new educational program. These guys really warrant significant testing support from the rest of us for locating bugs. We're interested in both Propeller 1 PropGCC testing (you can pretty much use any board) and with the DE0-Nano and the DE2-115 boards for Propeller 2. The -mp2 command line option builds for P2 code. Again, Propeller 1 testing is just as important as Propeller 2.

    Hi Ken,

    I really love PropGCC and how Eric, David and Steve made it so easy to program a Propeller in C. I really wanted to use it for my project because the inline assembly makes it really easy to combine PASM with a higher language on the same cog. My project (http://www.propeddle.com) has educational intentions and would really like to not have to ask people to learn Spin -- it's not that I don't like Spin (I do) but while the Propeller plays an important role in my project, I want users to be able to concentrate on the 6502 part of it, so being a processor-specific language, Spin is a distraction.

    However, I want to get my project ready in time for the Parallax Conference in May and the bug in GAS that makes it miscalculate immediate operands that refer to Cog memory locations, is a show stopper. Apparently the GCC compiler never generates code that requires this -- you can't get an address of a cog variable from C code so you can't do calculations on those pointers either. Also, it's possible to work around it by adding extra instructions but unfortunately because my code is too time-critical in some places to allow the workarounds. Anyway, I'm forced to (temporarily) convert my project back to Spin and spin-based PASM.

    I'm definitely planning on looking into the bug in GAS; I'm thinking of forking Binutils and rewriting some of Eric's code to fix the problem. I'm just running out of time :-(

    Edit: Note, this is not intended as a complaint, but to show that I intend to put effort into this. I'm still committed to writing a version of my project in C with inline assembly.

    ===Jac
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-15 11:17
    Hi Ken,

    I really love PropGCC and how Eric, David and Steve made it so easy to program a Propeller in C. I really wanted to use it for my project because the inline assembly makes it really easy to combine PASM with a higher language on the same cog. My project (http://www.propeddle.com) has educational intentions and would really like to not have to ask people to learn Spin -- it's not that I don't like Spin (I do) but while the Propeller plays an important role in my project, I want users to be able to concentrate on the 6502 part of it, so being a processor-specific language, Spin is a distraction.

    However, I want to get my project ready in time for the Parallax Conference in May and the bug in GAS that makes it miscalculate immediate operands that refer to Cog memory locations, is a show stopper. Apparently the GCC compiler never generates code that requires this -- you can't get an address of a cog variable from C code so you can't do calculations on those pointers either. Also, it's possible to work around it by adding extra instructions but unfortunately because my code is too time-critical in some places to allow the workarounds. Anyway, I'm forced to (temporarily) convert my project back to Spin and spin-based PASM.

    I'm definitely planning on looking into the bug in GAS; I'm thinking of forking Binutils and rewriting some of Eric's code to fix the problem. I'm just running out of time :-(

    Edit: Note, this is not intended as a complaint, but to show that I intend to put effort into this. I'm still committed to writing a version of my project in C with inline assembly.

    ===Jac
    I guess I need to go back and read your messages on this topic. I can't remember why the hack of doing #foo>>2 won't work or even using the .cog_ram directive. Does your assembly have to be inline or can you put it all in a separate .S file? Will that even help?
Sign In or Register to comment.