My only critique might be for jazzed to set a more inclusive, rather than exclusive, tone. Frankly, some of his comments of late seem a bit imperious. (Sorry, man, but I had to say it.) As Parallax's front man for this effort, diplomacy has to trump everything else.
It's ok Phil I understand. Here's what happened when I accepted the role:
1) I stated that I would be diplomatic and I was to a point of getting a brown nose.
2) I was told "to be myself."
3) So I stopped being so "diplomatic."
I've been on this forum for almost 4 years. Parallax has obviously seen my posting behavior in that time.
Why was I chosen to "front" the project given that knowledge?
I'll never know for sure, but I think it has something to do with my being straight up (to a fault).
RE: The old Cisco Systems logo.
The Cisco logo in my avatar was the last "detailed bridge" logo used when I voluntarily left the company to pursue other things like "simple" micro-controller projects. I was going to scan the old red one from my 15 year old nameplate, but haven't bothered.
Why is the white/green bridge important? It marks a turning point from the successful company to the train-wreck of the last decade. I found that the day they announced a 6000 person staff reduction. I see the new logo has not done them much good except for making the new Marketing VP happy from the time of that transition.
Considering some of the confusion the avatar has caused, I will be looking for a new one soon.
Prop 2 stuff isn't being released because there would be too many cooks in the kitchen. Parallax... has to sell prop chips... and survive. It takes resources to document chips. Right now they are still developing the propeller 2. So... would it make sense to halt design and completely document the chip? Engineering notes and specs don't make good reading for a public release.
Here's the rub too... if Parallax were to document the chip before having the final fully tested version they might release information to the public that was incorrect. What that be the worse?
Hey, I totally understand. If I were required to be diplomatic, I'd shrivel and die. Fortunately for me (less so for Parallax, I suppose), I don't have to front the company line; although, given my dependence on Parallax for most of my business, I probably should. There are a lot of egos afoot here, some fragile, some acutely pronounced, but all with a vested interest in whatever the Prop/GCC "consortium" comes up with. That's why we hang with bated breath on your every (hopefully measured) word.
BTW, after reading today's headlines about Cisco's involvement with China's web censorship, I'm glad to hear that your involvement with them is yesterday's news. Your decision to drop the Cisco avatar posthaste is most welcome -- the sooner the better.
if Parallax were to document the chip before having the final fully tested version they might release information to the public that was incorrect.
They released incorrect info for the Prop 1 after product release, and we managed to survive that! (Yeah, okay, I know: that wasn't a good thing, and I'm glad to see a more cautious approach being taken now.)
I haven't made the time to read this thread lately, which I regret at this point. I wish I could bring every one of you inside Parallax to show you what's going on in the office - from R&D, manufacturing, supporting some unique new customers, all surrounded by a positive energy from 47 people who have combined to make the company move to our next step. Nearly every person in the company is involved one way or another with these projects. For this reason we've really not paid too much attention to these forums (our most important communication and support tool), and we're looking [like it is] as if we're a bit "closed" on the GCC project. It's mostly my responsibility for not putting enough Parallax resources forward.
As controversial as he may seem, jazzed is in place to (a) match each GCC consultant with the right scope of work without overlap; (b) to create a project schedule; (c) to see that our efforts are supporting the goal; (d) to identify the engineering team and (e) to bring the group together in our planning meetings. His opinions are just his, not those of Parallax Semiconductor. Our FAE Daniel Harris is up to speed and will now be representing Parallax as a single voice. With Daniel's involvement I'm expecting that we put the project on track quickly. This will complement jazzed's efforts.
There's absolutely an appreciation and a need for people who want to get involved in this project. You need to tell us of your desire (PM jazzed) and we will add you to the private GCC Developer's Forum. The only reason it is "private" is because it is much easier to maintain the debate to a group of 10 or fewer than a group of 20K people. Transparency is important, so jazzed is to post updates on this thread. Still, nobody with a particular interest will be locked out of the GCC Developer's Forum.
Managing this project is really complex. Not only is the GCC suite new to us, the team is spread out all over the country (and Canada). The stakes are high for Parallax Semiconductor since the cost is truly significant. We'll have one chance to get this right. The team members have worked together on GCC in the past.
I guess I'm a bit concerned about the negative tone. We have a few design/approach issues on the developer's team, but I expect that from a group of engineers. If everybody were compliant and overly cooperative we'd have a mushy result.
Help us move this in the right direction, please. Designing and selling chips requires significant infrastructure, resources and carefully made decisions about the tools. Success is important for our customers, for the company, and our team. So far, the customers who use the Propeller in volume are happy with the results, but it's the ones we're not reaching that we also aim to attract.
Ken Gracey
P.S. I always support a fairly unmoderated forum, but we're getting closer to adding a bit more moderation on language, keeping threads on topic, etc. Some of the metaphors above are cutting it a bit close.
My only critique might be for jazzed to set a more inclusive, rather than exclusive, tone. Frankly, some of his comments of late seem a bit imperious.
Right, which was why I was asking if it was Parallax policy. Just curious. I don't have a dog in this fight, though I didn't like the way Sapieha was practically mocked for not being a C/C++ guy. Sheesh.
Alright people, back to work. Diplomacy is a complete waste of engineering talent. We're even distracting Kye now.
Yeah, that's what I am trying to convey in a sense, Lachlan. If our engineers are flat-liners opinion-wise then they may have no engineering passion. Many of the more colorful characters on these forums work for Parallax: OBC, Phil Pilgrim, Andre' LaMothe (even started another XMOS thread), jazzed, Bill Henning, Sometimes we even get to hire them on our staff (Kye). I'm not going to spend much time asking them to reduce their noise or keep their opinions to themselves, but I'm on the lookout for any lack of respect towards others. And they have an unwritten obligation to welcome all new members.
Ken,
I apologize if I got out of line. I was just annoyed with the hostility I was seeing. I should have waited for you to come in with the proper reply.
I'm looking very much forward to this. To me there seems to be good progress - it wasn't that long since the whole thing was announced, was it? Hopefully you have enough testers and the like. In case you run short for some reason (vacations?) I have partial experience to offer. I'm not familiar with the inner workings of GCC, despite that I was on the dev. mailing list for some years. I have however been compiling / building my own gcc for half a dozen different architectures since 1989-1990, and I started building cross-compilers some four or five years later. I have not built the latest 4.x series though. I'm obviously a die-hard C programmer too of course.
Hi,
I would like to know the technical difference between using GCC for propeller and other C compiler like Catalina or ICCV7. I'm not interested in knowing which is the best, only looking to know why different C compilers are made for the Prop.
I guess I'm a bit concerned about the negative tone. We have a few design/approach issues on the developer's team, but I expect that from a group of engineers. If everybody were compliant and overly cooperative we'd have a mushy result.
We don't have a negative tone in the developer's team. However, we do have discussions about some approaches that are a little animated. Over all, we have good chemistry because we all have skills that match the project, we all understand the goals, and we are enthusiastic about the mission. The chemistry of the team is a stark contrast to what you find here on these public forums.
Hi,
I would like to know the technical difference between using GCC for propeller and other C compiler like Catalina or ICCV7. I'm not interested in knowing which is the best, only looking to know why different C compilers are made for the Prop.
@FredBlais, you have a very good question. Would you mind if that is discussed in another thread in the Propeller forum? I'll be happy to start it for you.
Tor, we will be starting an independent test group once we have more progress. You will be welcome to that group. Most likely we will expand the current developers forum to include testers once we're ready.
Some of the metaphors above are cutting it a bit close.
Ken, I removed some stuff from my post that I feel fit this description, and I apologize if this was the case. I honestly meant nothing more than to say "Let Parallax do their thing and not worry about it". But I can see how my metaphor may have been taken as something else. Again, I apologize to you and your faimily.
I would like to know the technical difference between using GCC for propeller and other C compiler like Catalina or ICCV7. I'm not interested in knowing which is the best, only looking to know why different C compilers are made for the Prop.
I think that ImageCraft was the first to develop a C compiler for the Propeller. They already had C compilers available for for other mcus, so they were able to leverage their code base and port it to the Propeller. Somewhere in there RossH began working on Catalina, which I believe is based on lcc (see http://sites.google.com/site/lccretargetablecompiler/). I'm pretty sure that RossH's main purpose in developing Catalina was to have an open-source tool available. Now Parallax is sponsoring the GCC port, which will give users access to a tool-chain that they may already be familiar with from other projects.
My understanding of ICC and Catalina is that both only compile code to an LMM kernel, not to native PASM or byte-code. However, each targets a different LMM Kernel, but I'm not sure what the differences are. I believe that Catalina has added support for calling Spin/PASM objects, which ICC doesn't have. The GCC effort is still new, but is currently producing native PASM with a hub-based stack. This has it's limitations wrt cog memory, but it allows drivers to written in C. I'm guessing that doing something similar to PropBasic, which can produce cog PASM or LMM PASM, will be the goal.
Well, at least "colorful" is a step up from "chief of crankiness", my prior title. Either way, Ken, my apologies for any unwarranted negativity here or elsewhere.
The GCC effort is still new, but is currently producing native PASM with a hub-based stack. This has it's limitations wrt cog memory, but it allows drivers to written in C. I'm guessing that doing something similar to PropBasic, which can produce cog PASM or LMM PASM, will be the goal.
High level goals of GCC (and the tool-chain) are:
GCC will compile/link C and/or C++ programs
GCC will produce PASM COG code
Device drivers may also be written in PASM and combined with C/C++ programs
GCC will produce LMM (Large Memory Model) code programs
GCC will allow running programs on external memory platforms
GCC will allow debugging via GDB over the console serial port
GCC will allow generate optimized code based on size/speed
A flexible loader application will be used to program Propeller
GCC will allow users to specify loader parameters in a simple way
GCC will allow users to define their own drivers in a simple way
GCC will allow users to specify linker controlled memory areas
GCC will run on popular operating systems - Mac, Linux, and Windows
GCC should work with Code::Blocks, Eclipse, NetBeans, and other GUI programs
There will be limited versions of some C libraries because of Propeller constraints
GCC will be free and open source according to GNU licensing terms
MIT licensed demonstration programs will be provided
Volunteer tester application efforts will be supported and highlighted for achievement
I would like to add to the history of Propeller C a little.
[LIST=#]
[*]The first C compiler effort that I know of was the retargetable Small C by Peter Verkaik
[*]Heater wrote a Propeller emulation for Z80. That allowed using K&R C
[*]ImageCraft (a commercial venture) invested in ICCV7
[*]Hippy ported LCC to Propeller
[*]Ross started his version of LCC with Catalina
[*]Heater wrote the ZOG Propeller emulation for Zylin for building GCC C/C++ programs for Propeller
[*]David Hein created a C to Spin translator
[*]Heater's ZOG was expanded to use external memory for C3 and SDRAM
[*]Parallax "commissioned" the Propeller GCC project for P1/P2
[/LIST]
Thanks, jazzed; that amount of detail is most appreciated! Now, for those of us who, like me, are not at all GCC-literate, a couple questions:
1. I used to think that one of the C's in "GCC" referred to the C language, but it does not, apparently. And above, you state that PASM device drivers will be accommodated somehow in the GCC tool chain. Extrapolating a bit, how do future plans for Spin fit into the GCC strategy, if at all?
2. Will the resulting tools run natively under OS/X and Windows, or will they necessarily require their own Linux-compatible sandbox, such as X11 under OS/X or Cygwin under Windows?
And above, you state that PASM device drivers will be accommodated somehow in the GCC tool chain. Extrapolating a bit, how do future plans for Spin fit into the GCC strategy, if at all?
I see 2 questions there:
1. PASM driver accomodation with 3 variations a,b,c.
2. SPIN plans.
1.a. Back in 2008 I devised a way to extract PASM from spin binary files for use with ICC. That is the basis for the C drivers currently in the OBEX. Later I made a C program that automatically extracted the PASM. That code is being used in Catalina and has recently been updated by Ross -- more on that later. The same approach is used with ZOG and David's xBasic and can be used with propgcc.
1.b. With the GCC tool-chain, the GNU Assembler or "GAS" (my favorite Heater inside-joke) will be supporting PASM instruction syntax for the most part (not sure if RES makes sense in that context). GAS is a macro-assembler and has lots of extra features by default that programmers enjoy. The spin macros like "|<" will likely not be supported however. A Propeller version of GAS should be familiar to most of the independent and managed professional software engineers.
1.c. Since GAS will be using PASM syntax. C programs written for COGs will emit the GAS version of PASM assembly that you can use however you like.
2. I referred to this obliquely at the end of 1.a. above. The original spinc.[ch] module I wrote has been updated by Ross to include infrastructure for this feature. Ross realized that all you have to do to start a spin program from C is to provide byte-code, an interface, an interpreter, and a cognew to get things running. He has not claimed any exclusive rights on the spinc.[ch] module code which is probably our most productive collaboration. I proudly include the files in a .zip below for your inspection.
...
No offense if you don't like it or decide not to use it.
You're kidding right?
There is only one problem with it according to music theory which I will ignore from now on:
The bottom of the treble cleft's body is supposed to circle the G line; there it circles the B line.
Cheers
--Steve
Now off to do that landscaping job I've been regretting ....
Thanks for the additional detail. And I'm flattered that you decided to adopt the new avatar. May I suggest, however, that you use the slightly larger version embedded in my post instead of the thumbnail?
Yep, but it used to stand for GNU C Compiler (the Unix C compiler was, and is, called 'cc', for C Compiler. Thus GNU C Compiler, gcc). But then other frontends arrived, particularly after the 2.0 version. So now there's C, C++, Fortran, Ada, D, Java, Objective C, and Go which I think must be the newest. Plus some non-official frontends. When the diverse frontends appeared GCC changed meaning to GNU Compiler Collection. It was fortunate that the name change was so easy! :-)
Ideally, we will set the Propeller GCC compiler up in such a way where you can download the compiler "plugins" for the Propeller, set a few flags in GCC to compile to the Propeller as the target processor, and then just point Eclipse to invoke the GCC compiler. I think as long as you already have GCC and it's supporting libraries installed, the bits to get it to compile for the Propeller will be relatively small. GCC itself is a pretty big animal, already requiring hundreds of megabytes. If you don't already have it installed, then I believe the whole package will be a significant download.
jazzed, Phil:
Another potential option is using the existing spin/pasm compiler to produce a binary blob that the gcc toolchain could embed into the binary it produces and then launch with a simple cognew/coginit. I've been unable to work on the conversion project in a while, but I will be back on track again soon. It'll be trivial to make it usable or provide extra functions for the gcc toolchain.
Comments
It's ok Phil I understand. Here's what happened when I accepted the role:
1) I stated that I would be diplomatic and I was to a point of getting a brown nose.
2) I was told "to be myself."
3) So I stopped being so "diplomatic."
I've been on this forum for almost 4 years. Parallax has obviously seen my posting behavior in that time.
Why was I chosen to "front" the project given that knowledge?
I'll never know for sure, but I think it has something to do with my being straight up (to a fault).
RE: The old Cisco Systems logo.
The Cisco logo in my avatar was the last "detailed bridge" logo used when I voluntarily left the company to pursue other things like "simple" micro-controller projects. I was going to scan the old red one from my 15 year old nameplate, but haven't bothered.
Why is the white/green bridge important? It marks a turning point from the successful company to the train-wreck of the last decade. I found that the day they announced a 6000 person staff reduction. I see the new logo has not done them much good except for making the new Marketing VP happy from the time of that transition.
Considering some of the confusion the avatar has caused, I will be looking for a new one soon.
Here's the rub too... if Parallax were to document the chip before having the final fully tested version they might release information to the public that was incorrect. What that be the worse?
This fourm thread went way south...
Hey, I totally understand. If I were required to be diplomatic, I'd shrivel and die. Fortunately for me (less so for Parallax, I suppose), I don't have to front the company line; although, given my dependence on Parallax for most of my business, I probably should. There are a lot of egos afoot here, some fragile, some acutely pronounced, but all with a vested interest in whatever the Prop/GCC "consortium" comes up with. That's why we hang with bated breath on your every (hopefully measured) word.
BTW, after reading today's headlines about Cisco's involvement with China's web censorship, I'm glad to hear that your involvement with them is yesterday's news. Your decision to drop the Cisco avatar posthaste is most welcome -- the sooner the better.
Thanks,
-Phil
-Phil
No, wait, Stop the presses! Bad, bad idea........
PLEASE IGNORE THIS POSTING!!!
There's nothing to see here, just move on to the next item........Hey, how about those Mets??
I haven't made the time to read this thread lately, which I regret at this point. I wish I could bring every one of you inside Parallax to show you what's going on in the office - from R&D, manufacturing, supporting some unique new customers, all surrounded by a positive energy from 47 people who have combined to make the company move to our next step. Nearly every person in the company is involved one way or another with these projects. For this reason we've really not paid too much attention to these forums (our most important communication and support tool), and we're looking [like it is] as if we're a bit "closed" on the GCC project. It's mostly my responsibility for not putting enough Parallax resources forward.
As controversial as he may seem, jazzed is in place to (a) match each GCC consultant with the right scope of work without overlap; (b) to create a project schedule; (c) to see that our efforts are supporting the goal; (d) to identify the engineering team and (e) to bring the group together in our planning meetings. His opinions are just his, not those of Parallax Semiconductor. Our FAE Daniel Harris is up to speed and will now be representing Parallax as a single voice. With Daniel's involvement I'm expecting that we put the project on track quickly. This will complement jazzed's efforts.
There's absolutely an appreciation and a need for people who want to get involved in this project. You need to tell us of your desire (PM jazzed) and we will add you to the private GCC Developer's Forum. The only reason it is "private" is because it is much easier to maintain the debate to a group of 10 or fewer than a group of 20K people. Transparency is important, so jazzed is to post updates on this thread. Still, nobody with a particular interest will be locked out of the GCC Developer's Forum.
Managing this project is really complex. Not only is the GCC suite new to us, the team is spread out all over the country (and Canada). The stakes are high for Parallax Semiconductor since the cost is truly significant. We'll have one chance to get this right. The team members have worked together on GCC in the past.
I guess I'm a bit concerned about the negative tone. We have a few design/approach issues on the developer's team, but I expect that from a group of engineers. If everybody were compliant and overly cooperative we'd have a mushy result.
Help us move this in the right direction, please. Designing and selling chips requires significant infrastructure, resources and carefully made decisions about the tools. Success is important for our customers, for the company, and our team. So far, the customers who use the Propeller in volume are happy with the results, but it's the ones we're not reaching that we also aim to attract.
Ken Gracey
P.S. I always support a fairly unmoderated forum, but we're getting closer to adding a bit more moderation on language, keeping threads on topic, etc. Some of the metaphors above are cutting it a bit close.
Right, which was why I was asking if it was Parallax policy. Just curious. I don't have a dog in this fight, though I didn't like the way Sapieha was practically mocked for not being a C/C++ guy. Sheesh.
Yeah, that's what I am trying to convey in a sense, Lachlan. If our engineers are flat-liners opinion-wise then they may have no engineering passion. Many of the more colorful characters on these forums work for Parallax: OBC, Phil Pilgrim, Andre' LaMothe (even started another XMOS thread), jazzed, Bill Henning, Sometimes we even get to hire them on our staff (Kye). I'm not going to spend much time asking them to reduce their noise or keep their opinions to themselves, but I'm on the lookout for any lack of respect towards others. And they have an unwritten obligation to welcome all new members.
Ken Gracey
I apologize if I got out of line. I was just annoyed with the hostility I was seeing. I should have waited for you to come in with the proper reply.
I'm looking very much forward to this. To me there seems to be good progress - it wasn't that long since the whole thing was announced, was it? Hopefully you have enough testers and the like. In case you run short for some reason (vacations?) I have partial experience to offer. I'm not familiar with the inner workings of GCC, despite that I was on the dev. mailing list for some years. I have however been compiling / building my own gcc for half a dozen different architectures since 1989-1990, and I started building cross-compilers some four or five years later. I have not built the latest 4.x series though. I'm obviously a die-hard C programmer too of course.
-Tor
I would like to know the technical difference between using GCC for propeller and other C compiler like Catalina or ICCV7. I'm not interested in knowing which is the best, only looking to know why different C compilers are made for the Prop.
We don't have a negative tone in the developer's team. However, we do have discussions about some approaches that are a little animated. Over all, we have good chemistry because we all have skills that match the project, we all understand the goals, and we are enthusiastic about the mission. The chemistry of the team is a stark contrast to what you find here on these public forums.
@FredBlais, you have a very good question. Would you mind if that is discussed in another thread in the Propeller forum? I'll be happy to start it for you.
Tor, we will be starting an independent test group once we have more progress. You will be welcome to that group. Most likely we will expand the current developers forum to include testers once we're ready.
Ken, I removed some stuff from my post that I feel fit this description, and I apologize if this was the case. I honestly meant nothing more than to say "Let Parallax do their thing and not worry about it". But I can see how my metaphor may have been taken as something else. Again, I apologize to you and your faimily.
I think that ImageCraft was the first to develop a C compiler for the Propeller. They already had C compilers available for for other mcus, so they were able to leverage their code base and port it to the Propeller. Somewhere in there RossH began working on Catalina, which I believe is based on lcc (see http://sites.google.com/site/lccretargetablecompiler/). I'm pretty sure that RossH's main purpose in developing Catalina was to have an open-source tool available. Now Parallax is sponsoring the GCC port, which will give users access to a tool-chain that they may already be familiar with from other projects.
My understanding of ICC and Catalina is that both only compile code to an LMM kernel, not to native PASM or byte-code. However, each targets a different LMM Kernel, but I'm not sure what the differences are. I believe that Catalina has added support for calling Spin/PASM objects, which ICC doesn't have. The GCC effort is still new, but is currently producing native PASM with a hub-based stack. This has it's limitations wrt cog memory, but it allows drivers to written in C. I'm guessing that doing something similar to PropBasic, which can produce cog PASM or LMM PASM, will be the goal.
-Phil
High level goals of GCC (and the tool-chain) are:
I would like to add to the history of Propeller C a little.
[LIST=#]
[*]The first C compiler effort that I know of was the retargetable Small C by Peter Verkaik
[*]Heater wrote a Propeller emulation for Z80. That allowed using K&R C
[*]ImageCraft (a commercial venture) invested in ICCV7
[*]Hippy ported LCC to Propeller
[*]Ross started his version of LCC with Catalina
[*]Heater wrote the ZOG Propeller emulation for Zylin for building GCC C/C++ programs for Propeller
[*]David Hein created a C to Spin translator
[*]Heater's ZOG was expanded to use external memory for C3 and SDRAM
[*]Parallax "commissioned" the Propeller GCC project for P1/P2
[/LIST]
2. Will the resulting tools run natively under OS/X and Windows, or will they necessarily require their own Linux-compatible sandbox, such as X11 under OS/X or Cygwin under Windows?
-Phil
http://gcc.gnu.org/
GNU is a recursive acronym for GNU's Not Unix.
'Looks like you need a new avatar. Here is a jazzy "GCC bridge" of a different sort.
No offense if you don't like it or decide not to use it.
-Phil
1. PASM driver accomodation with 3 variations a,b,c.
2. SPIN plans.
1.a. Back in 2008 I devised a way to extract PASM from spin binary files for use with ICC. That is the basis for the C drivers currently in the OBEX. Later I made a C program that automatically extracted the PASM. That code is being used in Catalina and has recently been updated by Ross -- more on that later. The same approach is used with ZOG and David's xBasic and can be used with propgcc.
1.b. With the GCC tool-chain, the GNU Assembler or "GAS" (my favorite Heater inside-joke) will be supporting PASM instruction syntax for the most part (not sure if RES makes sense in that context). GAS is a macro-assembler and has lots of extra features by default that programmers enjoy. The spin macros like "|<" will likely not be supported however. A Propeller version of GAS should be familiar to most of the independent and managed professional software engineers.
1.c. Since GAS will be using PASM syntax. C programs written for COGs will emit the GAS version of PASM assembly that you can use however you like.
2. I referred to this obliquely at the end of 1.a. above. The original spinc.[ch] module I wrote has been updated by Ross to include infrastructure for this feature. Ross realized that all you have to do to start a spin program from C is to provide byte-code, an interface, an interpreter, and a cognew to get things running. He has not claimed any exclusive rights on the spinc.[ch] module code which is probably our most productive collaboration. I proudly include the files in a .zip below for your inspection.
We will have binary distributions for the major operating systems: Mac OS/X, Linux, and Windows. Cygwin will not be required.
Very clever Phil!
C.W.
There is only one problem with it according to music theory which I will ignore from now on:
The bottom of the treble cleft's body is supposed to circle the G line; there it circles the B line.
Cheers
--Steve
Now off to do that landscaping job I've been regretting ....
Thanks for the additional detail. And I'm flattered that you decided to adopt the new avatar. May I suggest, however, that you use the slightly larger version embedded in my post instead of the thumbnail?
-Phil
Use this one, not the smaller thumbnail below. -P.
We will need to install hundreds of megabytes or just a plugin for use with a current installation of Eclipse?
Thank you.
-Tor
Ideally, we will set the Propeller GCC compiler up in such a way where you can download the compiler "plugins" for the Propeller, set a few flags in GCC to compile to the Propeller as the target processor, and then just point Eclipse to invoke the GCC compiler. I think as long as you already have GCC and it's supporting libraries installed, the bits to get it to compile for the Propeller will be relatively small. GCC itself is a pretty big animal, already requiring hundreds of megabytes. If you don't already have it installed, then I believe the whole package will be a significant download.
Thanks,
Daniel
Amazing service!
Another potential option is using the existing spin/pasm compiler to produce a binary blob that the gcc toolchain could embed into the binary it produces and then launch with a simple cognew/coginit. I've been unable to work on the conversion project in a while, but I will be back on track again soon. It'll be trivial to make it usable or provide extra functions for the gcc toolchain.
Roy