Development tools - two concurrent efforts are under consideration right now. One of them is a GCC approach for Propeller 2. We're regularly collecting the R&D team up with the FAEs to discuss the plan and preparing to act. Before we go too far we will consult with all of you.
I suggest that you forget GCC's existence, unless you all want to turn bald very, very soon. Use LLVM. There's a good reason why both XMOS and Apple are going that route. LLVM's code base is much easier to grok, and is much more modern. I beg you to ignore gcc, you won't regret it.
There are a couple of people on the GCC team that know their way around the GCC code. They were able to produce useable PASM code in just a few weeks. However, I agree that we would be lost without having experience GCC people on the team. I'm confident that GCC is the right approach.
There is something called llvm-gcc, apparently, which XMOS used for the C and C++ compilers.
llvm-gcc is the C language front-end only. The LLVM code generator/optimizer infrastructure is used to generate assembly/machine code output. It's this back-end that makes all the difference.
There are a couple of people on the GCC team that know their way around the GCC code. They were able to produce useable PASM code in just a few weeks. However, I agree that we would be lost without having experience GCC people on the team. I'm confident that GCC is the right approach.
I guess we'll have to agree to disagree, then. Of course if you hire gcc developers, that's a whole different ballgame. In the long term I think that LLVM is a much more maintainable and modern code base. My pet peeve: you can easily have a few instances of the compiler running within one process -- no deadly global variables peppered everywhere.
If you dislike clang front-end for any reason, you can still use llvm-gcc as the front-end. Something is to be said for LLVM's clarity if a total noob could produce useable assembly (for eZ8) in two weekends. And I'm really no star programmer of any sort, I'm sure the GCC folks would run circles around me in their sleep, and that after a gallon of beer, too. I'm very worried that it took the gcc folk "just a few weeks" for PASM output -- maybe it was exceptionally good PASM output, though, I wouldn't know. Or maybe they weren't working on it full time.
I'm very worried that it took the gcc folk "just a few weeks" for PASM output -- maybe it was exceptionally good PASM output, though, I wouldn't know. Or maybe they weren't working on it full time.
They aren't working full time. From what I can tell, one person developed the initial code. It may have taken him only a few days to do it. The calender time was a few weeks.
Comments
I can confirm this - just look what it did to me
Ross.
http://llvm.org/devmtg/2009-10/Osborne_TargetingXCoreResources.pdf
http://clang.llvm.org/
If you dislike clang front-end for any reason, you can still use llvm-gcc as the front-end. Something is to be said for LLVM's clarity if a total noob could produce useable assembly (for eZ8) in two weekends. And I'm really no star programmer of any sort, I'm sure the GCC folks would run circles around me in their sleep, and that after a gallon of beer, too. I'm very worried that it took the gcc folk "just a few weeks" for PASM output -- maybe it was exceptionally good PASM output, though, I wouldn't know. Or maybe they weren't working on it full time.
They decided to use GCC.
Parallax listens to all input and they filter it according to their needs/goals.
That's all I have to say about it.