New version of PropGCC for P2 posted on Google Code
David Betz
Posts: 14,516
I've posted a new Windows build of PropGCC for P1 and P2 on Google Code. This version merges in some performance improvements that Eric has been working on in another branch and also adds support for using gdb to debug LMM and XMM programs on P1 and LMM programs on P2. This is a build of the "p2test" branch of the PropGCC repository at tag "p2test-2013-02-26" in case anyone wants to download the sources and build them for either Linux or Mac OS X. Please let me know if you'd like to run this on Linux or the Mac and don't have the ability to build from sources.
Here is a link to the Windows download:
http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-2013-02-26.zip&can=2&q=
We would very much appreciate any help any of you can give in testing this on P1 especially. We'd like to verify that we haven't broken any of the P1 features while adding support for P2.
Thanks in advance for your help in testing!!
Here is a link to the Windows download:
http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-2013-02-26.zip&can=2&q=
We would very much appreciate any help any of you can give in testing this on P1 especially. We'd like to verify that we haven't broken any of the P1 features while adding support for P2.
Thanks in advance for your help in testing!!
Comments
That made me cringe I'd hate for some subtle bug to creep into my project. Still, I have a suite of unit tests for most of the basic functionality so I'll make sure that those run with my current PropGCC code (from November?), and then try it with the new code. And PropGCC has been very solid so far.
And it looks like spin2cpp is now part of the PropGCC project, and it's source is included there as well?
I'm excited to try out GDB. So far, I haven't really had a need to use it, but it should be fun and it's nice to have. I wonder if I can get it to work with Code::Blocks?
Cody, we need you on March 15th for a beta test of our PropGCC efforts in education. There's so much cool stuff that I saw today in a demo from Andy, and I know you'd really like to use his work. I can't wait to let you in on his work!
If I install the this version can I use it with SimpleIDE by just adding the appropriate -mp2 option?
C.W.
I've been working on some bug fixes in Binutils (the Assembler seems to botch up any instruction with an immediate parameter that's a cog address), and I use SimpleIDE to do my testing on, so yes it can be done.
To build PropGCC under Windows, you need MinGW (there are build instructions at http://code.google.com/p/propgcc/wiki/PropGccBuild). When you follow the instructions, the programs get built in /opt/parallax as seen from the MinGW prompt, and you can copy that entire directory to /c/PropGCC to make SimpleIDE work with it too (make a backup first, obviously).
I'll try to update the build instructions later today to clarify things.
[Edit: Now I see you're asking if -mp2 can be added from SimpleIDE: Yes it can.]
===Jac
PS I use P1 only at this time
Well, the only compter I have for the weekend is an old Acer Travelmate that gets very hot after a few minutes of serious compiling work and then goes into thermal shutdown.
Ha ha, had you going there for a minute. But seriously anyone know of a way to get this thing to throttle back and give my old laptop a chance to finish?
I'll post a message in the PropGCC forum, otherwise this will go off-topic in a bad way.
===Jac
I'll give it a go without the SimpleIDE "safety net" this evening...
C.W.
I downloaded it yesterday, and will try it today.
Is there a demo with a makefile in the zip?
Also, how do I embed something I assemble with PNut so I can launch it as a cog?
You should be able to use PNut code through PropGCC by just using the image file that PNut creates. I haven't tried that yet though. At this point, I'm mostly concerned to verify the functioning of P1 code using these new tools. Of course, P2 testing is also welcome though. I'll try to put together an example of using PNut files with PropGCC soon but it may not be until the weekend.
Thanks for offering to help test!
As far as I know, I still have access to Google Code - have not checked for quite a while.
I'll be happy to take a peek at your next Windows zip file :-) and will greatly appreciate your example of using PNut files with PropGCC for p2.
Since Spin2 is not usable yet, I was hoping I might be able to use the early p2 support in PropGCC to be the "glue" between the cog code I am building for some P2 projects I am working on for some future products.
I guess PNut support is probably pretty important. It is actually pretty much as easy to do as what we do for P1 with extracting .dat files with COG images. I'll try to work up an example over the weekend.
Right now, for my experiments, I just run Chip's monitor in another cog, and coding everything in PASM - including test code for cog drivers. Quite feasible, but a bit slower to do than I like. The extra features of the DE2-115 are awesome!
I think the rebuild.sh script should have a check at the beginning for bison.
Anyway, I upgraded from v0_3_5_1758 to v0_3_5_1920. This is correct? It still says GCC 4.6.1
The first time I compile, I get this error: (note: the single line compile command is above, and the relevant bit of it's output below).
main.ld is a custom linker script used to help facilitate garbage collection (as started, but not finished for all code, here). I also updated the script to the newest version (via the default). Unfortunately, this is the dreaded error that occurs when there is cog assembly code assembled with GCC, and the magic __load_start_* label is created. I haven't figured out how to overcome this yet in garbage collection (essential for the Propeller), so for me this new version of PropGCC is broken.
The other features of PropGCC seem to be working, however: I ran 230 unit tests over a variety of problems in both CMM mode and LMM mode, and they all passed (if they fit in memory without garbage collection).
So, that's my conclusion: the new build breaks current garbage collection, but works otherwise.
Thanks very much for all of your help in testing!!!! If Ken does offer and incentive to help, you will certainly qualify!!
Just to clarify: the garbage collection of __load_start_* labels is not new: it's been doing that since I started looking into the subject. The new part is that label __load_start_memory_kerext: this did not exist in the previous versions. So as long as no user code (in previous versions) had any __load_start_* labels garbage collection worked fine.