Q. When will we have a requirements document?
A. Requirements document is a WHAT "work product" that is produced by/for and reviewed/approved by the customer. Part of the WHAT in this case depends on some studies by key contributors. Other parts of WHAT come from Parallax staff. In this case, the user community has lots of input.
I'm afraid That it was TO small KEY contributors amount that review/approve That had only Theirs NEED's as agenda NOT total usability for PROPELLER's - BE else NOT to BE.
And that can impact on entire Propeller II Hardware/Software line - Very bad way to Go.
Only difference between traditional Bin linker and Ross Code linker are that -- In traditional Bin linker You can build BIN Library's that You can sell without NEED to show Code.
In Ross version -- You always need Code.
Hi Sapieha,
Actually, that's not the case. As I responded to David Betz earlier, the "code" is compiler generated PASM (no comments, no C code). You would end up with much the same output if you disassembled any object file. So you are not really revealing any more of your source code than you would be doing by releasing an object version of the same library.
Actually, that's not the case. As I responded to David Betz earlier, the "code" is compiler generated PASM (no comments, no C code). You would end up with much the same output if you disassembled any object file. So you are not really revealing any more of your source code than you would be doing by releasing an object version of the same library.
Of course a fork is required. The decision required is whether or not to keep it "permanently" forked: that is - no more updates from the parent train.
Now, I'm not a GCC developer but the general idea of fork is this: If you don't keep it permanently forked, periodic updates are required which can get in the way of development and as you mentioned there are issues on merge back. If you keep it permanently forked, the only time you have to deal with the parent train is if you need some features - in many cases this requires an update anyway. An update over time can get very ugly.
I was aware of the moving target dynamic that is gcc. Used to deal with that on IRIX from time to time, with the stuff specific to IRIX wouldn't always be in working order, and I would be building something that required a newer gcc. (and thanks Ross for the kid gloves) What I meant by that, and expressed poorly enough to warrant a follow on post, is do we hack gcc enough to never return the code to the project, instead folding in updates as needed", or is the goal to eventually return everything, and just become part of gcc as a whole, with somebody maintaining the prop stuff proper with each revision?
If funky linking and binding and such are done, for whatever reason, there could be a perma-split, that's all.
Some version tools like Perforce allow the developer to use certain directories of a project source and binary libraries for the other pieces of a project which only require linking to save build time. This allows work without interference from changes in non-dependent code.
The GCC rsync tool appears to use CVS/RCS as it's backend. CVS is an all or nothing tool, but rsync appears to bring in the source as chunks. This is not clear.
Perhaps they think the wider GCC community will support their port for them? Or perhaps they intend to rely on the people in these forums? Either one seems unlikely.
Not only is this unlikely, but it would put Parallax right back in the spot of not offering a Parallax supported product. However, I think that Parallax does need to reach out the relevant open-source communities (GCC/Eclipse/alternatives) as part of their feasibility research. People with direct project experience would add a lot of value to the discussion.
As for a fork... why not just fork Catalina?
Kidding aside, the decision to roll changes back into the trunk of any project would be made by the project leaders of the trunk, not the branch. There's no guarantee that any submitted changes would even be accepted. For all intents and purposes, Parallax needs to own the fork, regardless of which project is actually forked.
As for the issue of what should be targeted... I think that Parallax needs to make decisions about what constitutes the "official" LMM/XMM/whatever, and build support for only those configurations. If somebody builds the UberBlade that requires UberMM, they should be the one responsible for drivers for that system. If they need a special version of the delivered compiler... they should follow the OSS model, develop the functionality themselves, and submit the patch back to Parallax. Or maintain their own fork.
I suspect there are a few people who would much prefer to drive a wooden stake into it!
Am I the only one who thinks it is odd how little interaction this thread is generating? Should I go back to posting Catalina propaganda? - at least it livened things up a bit!
I suspect this thread is being read, primarily, by two groups: the choir (C adherents) and the apostates (C renouncers). Neither really has much to say. Get the middle ground involved, and you'll get some discussion.
I'm following the thread but for the most part the discussion is way over my head. I'm not a compiler writer.
Personally I have no interest in using C. I write in Objective C for my OS X programming, but I'm perfectly happy with Spin/PASM when I'm writing for the Propeller. But I completely understand that Parallax Semiconductor needs to make a C compiler available in order to create industry inroads for the Prop II and that's very important.
Because I'm running Xcode at work on a G5, my programs are still compiled with gcc. But Apple is switching to Clang/LLVM. I hesitate to say this since I'm clueless about compiler technology but is it worth at least taking a look at using those? I have to think Apple is switching for a reason.
Yes, good point. I'm not exactly sure why Parallax seems to have a preference for GCC (other than the "me too" factor). I have heard that Clang is a faster compiler than GCC, and generates smaller code. It also claims to have superior C++ compliance. But of course some of this could just be hype put out by Clang propagandists.
But you're quite right - Apple must have a reason. Performance? Licensing? Just to differentiate themselves?
However, it's probably also worth noting that Clang/LLVM does not seem to target any small embedded chips - ARM 6&7 seems to be the smallest, and they both have MMU's (I think - I get a headache whenever I try and figure out the details of the hundreds of different ARM/Cortex processors!). But there may be for a reason for this, and it may mean that Clang would not be easily ported to a small chip like the Propeller - especially one with such an unusual architecture.
Anyone here have experience/knowledge of Clang/LLVM?
I got the impression that LLVM is GNU's answer to .net. I could be wrong of course.
Ok, I'm getting further out on the limb here having no experience with .NET, but do you say that because .NET is a virtual machine abstraction over the hardware? Because I don't get the impression that LLVM is a virtual machine in that sense. It generates machine code.
It seems like we should at least look. There might be some advantages to a more recently-designed approach. Of course its advantages might be good for microprocessors and terrible for microcontrollers, but at least we took a look. But I have to leave it to others to figure that out (llvm.org).
Ok, I'm getting further out on the limb here having no experience with .NET, but do you say that because .NET is a virtual machine abstraction over the hardware? Because I don't get the impression that LLVM is a virtual machine in that sense. It generates machine code.
It seems like we should at least look. There might be some advantages to a more recently-designed approach. Of course its advantages might be good for microprocessors and terrible for microcontrollers, but at least we took a look. But I have to leave it to others to figure that out (llvm.org).
I got the impression that LLVM is GNU's answer to .net. I could be wrong of course.
It would probably be more accurate to say that LLVM is intended by Apple to become an alternative to Microsoft's Common Language Runtime (CLR) - see http://www.kdedevelopers.org/node/1628
The problem with CLR is that it is inappropriate for very small targets like microcontrollers. I suspect LLVM may run into the same problem.
The problem with CLR is that it is inappropriate for very small targets like microcontrollers. I suspect LLVM may run into the same problem.
I've done a little more reading and was starting to get that impression. I'm going to crawl back in from the end of this limb before it breaks and leave this thread back in the hands of those more qualified than me.
I'd like to say on behalf of the peanut gallery to all those involved: thanks for all the hard work.
I suspect there are a few people who would much prefer to drive a wooden stake into it[Catalina]!
Nooo...Not even Zog himself would really want to do that.
Am I the only one who thinks it is odd how little interaction this thread is generating?
Odd, I though there was quite a lot of opinion here. Or was it just me...
SSteve,
But Apple is switching to Clang/LLVM. I hesitate to say this since I'm clueless about compiler technology but is it worth at least taking a look at using those?
I believe it is. There is even talk of Linux going over to Clang/LLVM. Even GCC developers admit that it easier to work with when creating new targets etc. Here is my favourite quote about that from wikipedia: "...as one long-time GCC developer put it, "Trying to make the hippo dance is not really a lot of fun.""
RossH,
However, it's probably also worth noting that Clang/LLVM does not seem to target any small embedded chips
I suspect that is not a technical issue, just the result of Clang/LLVM being quite new and no one has tackled those other targets yet. I see no reason why LLVM cannot target an 8bit AVR as well as GCC can for example.
I got the impression that LLVM is GNU's answer to .net. I could be wrong of course.
You could not be more wrong, LLVN is not a GNU project. It is MIT licensed. From wiki: "LLVM can provide the middle layers of a complete compiler system, taking intermediate form (IF) code from a compiler and emitting an optimized IF. This new IF can then be converted and linked into machine-dependent assembly code for a target platform."
No need for that run time JIT compilation step like .NET.
RossH,
It would probably be more accurate to say that LLVM is intended by Apple to become an alternative to Microsoft's Common Language Runtime (CLR) - see http://www.kdedevelopers.org/node/1628
That may well be true, but Clang/LLVM can and is used to generate native code directly at compile time. There the LLVM is not used as a CLR. It's just a normal source to binary executable compiler. LLVM is the intermediate form that is optimized along the way at compile time.
The problem with CLR is that it is inappropriate for very small targets like microcontrollers. I suspect LLVM may run into the same problem.
No, because of the above.
SSteve:
I've done a little more reading and was starting to get that impression. I'm going to crawl back in from the end of this limb before it breaks and leave this thread back in the hands of those more qualified than me.
No, I think you are on a solid limb there, LLVM should be looked at.
...over to Clang/LLVM. Even GCC...long-time GCC developer...result of Clang/LLVM being ... why LLVM cannot ... AVR as well as GCC can ...LLVN is not a GNU ... MIT licensed. From wiki: "LLVM can... form (IF) code ... optimized IF. This new IF can... run time JIT ... like .NET... but Clang/LLVM can ...There the LLVM is ...as a CLR. It's... LLVM is the intermediate...
Am I the only one who thinks it is odd how little interaction this thread is generating?
I think a lot of us are just sitting back watching...
I'll throw in my two cents.
I think the cart is being put somewhat before the horse. By that I mean I think a lot of energy is being spent discussing alphabet soup GCC/LLVM GPL/MIT, etc. without first laying out what is needed.
Some of this may have been addressed but seems to get lost in the noise.
Memory Models:
1) Straight PASM in a COG, I know there isn't much space, but the ability to do driver level type programming in C would be nice.
2) LMMx, whatever new incantation of LMM fits prop2, I think this should really be a primary focus, being able to maximize what can be done without resorting to XMM. It seems me that once an application is forced to add external memory the decision to use a prop over some other chip becomes a much harder argument.
3) XMM, because some apps just won't fit in the hub. For XMM I see the need for options for code to run from RAM or ROM. I haven't looked at the new instruction set, but I assume some amount of self-modification is still helpful, that would need to run from non-ROM space in the ROMable code mode.
System Configuration
Obviously there is some need to be able to configure the compiler to produce code for various systems with different memory layouts, XMM setups, etc. Focus on making this easy for a user to setup is important. I know a lot of folks on here have boards that they produce that they want to see having "canned" support, but we need to make sure it is easy for engineers to use the prop in boards of their own design without feeling pushed into using an existing board with canned support. Same ideas apply to various video setups, keep in mind not every prop app uses video, there seems to be maybe too much focus on that aspect of the prop sometimes.
Threading
Given the props multi-core nature threading is a must, at least threading using multiple cogs and ideally within a COG using some form of cooperative multitasking.
External Input (user)
Maybe Parallax could solicit involvement from engineers working for prospective clients, we spend a lot of time trying to decide what "they" need, maybe we should just ask.
Sapieha's tag line probably should be one of the guiding principles:
"If your gonna construct something, make it as simple as possible yet as versatile as possible."
I think a lot of us are just sitting back watching...
Nice observations C.W. Your input and others are very welcome.
The serious specification business (the "What" in the "Why, What, Who, How" process) has not been completely defined yet as usage or deliverable "requirements."
RE : Memory Models
Of the 3 memory models you mentioned, the one that may not work is compiling to straight PASM - not saying it won't be tried. I agree it would be nice to write COG code in C.
A fully functional System On a Chip "SOC" without any external support is indeed a high priority target. I expect that being able to use external memory solutions for running programs is also important. BTW, It is entirely possible for LMM (or other VM) to run programs straight from ROM or Flash - I have a board on my desk doing that right now with Propeller I.
RE: System Configuration
Having a linker that would allow "any possible user configuration" for external memory without needing support from a consultant is important for $BILLION volume customers.
Am I the only one who thinks it is odd how little interaction this thread is generating?
The target customer set (big revenue and volume purchasers) do not have much to say in this forum primarily because Propeller has not attracted them ... yet. Without proper tools, Propeller I/II is not interesting to big customers. Of course it's interesting to us, but we won't be generating billions in revenue needed for Parallax to get a big enough slice for Parallax Semiconductor to succeed.
Parallax Semiconductor was apparently created in part for solving the volume problem. It's an up-hill battle to succeed in evangelizing a non-mainstream product. Propeller II and "proper tools" will definitely help this effort. If Parallax Semiconductor succeeds, everyone stands to benefit ... if not ... well that's not an option.
The target customer set (big revenue and volume purchasers) do not have much to say in this forum primarily because Propeller has not attracted them ... yet.
I think Ross may have been referring to interaction with Parallax, not with potential customers.
I guarantee Parallax is reading this thread. I also guarantee they won't get into crazy debates about it.
Hmmm. Not sure about the "crazy bit", but I do question the point of having a debate like this if Parallax are not actually going to participate.
Are we intended to uncover their actual intentions and requirements purely by chance? This may be fun for us enthusiasts - but it seems an unusual way to conduct a project specifically intended to lift their professional profile.
IMHO, attention is on getting a synthesis out the door and cooking. Probably done right about now.
While that is brewing this topic will come back up, and I suspect there are no hard requirements, or there are a few based on some feedback they have received.
(which is why I advocated for a market research type discussion right away)
Some higher level goal, with some ownership would help, because then at least advocacy would be targeted correctly.
Until then, anyone want to debate the merits of gcc vs llvm?
Honestly, that is highly likely to be productive, given where things are at present.
Comments
I'm afraid That it was TO small KEY contributors amount that review/approve That had only Theirs NEED's as agenda NOT total usability for PROPELLER's - BE else NOT to BE.
And that can impact on entire Propeller II Hardware/Software line - Very bad way to Go.
Hi Sapieha,
Actually, that's not the case. As I responded to David Betz earlier, the "code" is compiler generated PASM (no comments, no C code). You would end up with much the same output if you disassembled any object file. So you are not really revealing any more of your source code than you would be doing by releasing an object version of the same library.
Ross.
Thanks -- Now I understand.
Of course a fork is required. The decision required is whether or not to keep it "permanently" forked: that is - no more updates from the parent train.
Now, I'm not a GCC developer but the general idea of fork is this: If you don't keep it permanently forked, periodic updates are required which can get in the way of development and as you mentioned there are issues on merge back. If you keep it permanently forked, the only time you have to deal with the parent train is if you need some features - in many cases this requires an update anyway. An update over time can get very ugly.
Sorry, I guess something was lost in translation.
I was aware of the moving target dynamic that is gcc. Used to deal with that on IRIX from time to time, with the stuff specific to IRIX wouldn't always be in working order, and I would be building something that required a newer gcc. (and thanks Ross for the kid gloves) What I meant by that, and expressed poorly enough to warrant a follow on post, is do we hack gcc enough to never return the code to the project, instead folding in updates as needed", or is the goal to eventually return everything, and just become part of gcc as a whole, with somebody maintaining the prop stuff proper with each revision?
If funky linking and binding and such are done, for whatever reason, there could be a perma-split, that's all.
Edit: I see Jazzed expressed this better.
The GCC rsync tool appears to use CVS/RCS as it's backend. CVS is an all or nothing tool, but rsync appears to bring in the source as chunks. This is not clear.
Can anyone give a good summary of rsync?
Not only is this unlikely, but it would put Parallax right back in the spot of not offering a Parallax supported product. However, I think that Parallax does need to reach out the relevant open-source communities (GCC/Eclipse/alternatives) as part of their feasibility research. People with direct project experience would add a lot of value to the discussion.
As for a fork... why not just fork Catalina?
Kidding aside, the decision to roll changes back into the trunk of any project would be made by the project leaders of the trunk, not the branch. There's no guarantee that any submitted changes would even be accepted. For all intents and purposes, Parallax needs to own the fork, regardless of which project is actually forked.
As for the issue of what should be targeted... I think that Parallax needs to make decisions about what constitutes the "official" LMM/XMM/whatever, and build support for only those configurations. If somebody builds the UberBlade that requires UberMM, they should be the one responsible for drivers for that system. If they need a special version of the delivered compiler... they should follow the OSS model, develop the functionality themselves, and submit the patch back to Parallax. Or maintain their own fork.
I suspect there are a few people who would much prefer to drive a wooden stake into it!
Am I the only one who thinks it is odd how little interaction this thread is generating? Should I go back to posting Catalina propaganda? - at least it livened things up a bit!
Ross.
I suspect this thread is being read, primarily, by two groups: the choir (C adherents) and the apostates (C renouncers). Neither really has much to say. Get the middle ground involved, and you'll get some discussion.
-Phil
Personally I have no interest in using C. I write in Objective C for my OS X programming, but I'm perfectly happy with Spin/PASM when I'm writing for the Propeller. But I completely understand that Parallax Semiconductor needs to make a C compiler available in order to create industry inroads for the Prop II and that's very important.
Because I'm running Xcode at work on a G5, my programs are still compiled with gcc. But Apple is switching to Clang/LLVM. I hesitate to say this since I'm clueless about compiler technology but is it worth at least taking a look at using those? I have to think Apple is switching for a reason.
Yes, good point. I'm not exactly sure why Parallax seems to have a preference for GCC (other than the "me too" factor). I have heard that Clang is a faster compiler than GCC, and generates smaller code. It also claims to have superior C++ compliance. But of course some of this could just be hype put out by Clang propagandists.
But you're quite right - Apple must have a reason. Performance? Licensing? Just to differentiate themselves?
However, it's probably also worth noting that Clang/LLVM does not seem to target any small embedded chips - ARM 6&7 seems to be the smallest, and they both have MMU's (I think - I get a headache whenever I try and figure out the details of the hundreds of different ARM/Cortex processors!). But there may be for a reason for this, and it may mean that Clang would not be easily ported to a small chip like the Propeller - especially one with such an unusual architecture.
Anyone here have experience/knowledge of Clang/LLVM?
Ross.
Ok, I'm getting further out on the limb here having no experience with .NET, but do you say that because .NET is a virtual machine abstraction over the hardware? Because I don't get the impression that LLVM is a virtual machine in that sense. It generates machine code.
It seems like we should at least look. There might be some advantages to a more recently-designed approach. Of course its advantages might be good for microprocessors and terrible for microcontrollers, but at least we took a look. But I have to leave it to others to figure that out (llvm.org).
I'm not saying don't look. I started a thread last year that asked if LLVM might be an easier solution than stock GCC. I didn't take it too far because of other things. You can read it here: http://forums.parallax.com/showthread.php?118313-P8x32a-LLVM-Target&highlight=LLVM
It would probably be more accurate to say that LLVM is intended by Apple to become an alternative to Microsoft's Common Language Runtime (CLR) - see http://www.kdedevelopers.org/node/1628
The problem with CLR is that it is inappropriate for very small targets like microcontrollers. I suspect LLVM may run into the same problem.
Ross.
I've done a little more reading and was starting to get that impression. I'm going to crawl back in from the end of this limb before it breaks and leave this thread back in the hands of those more qualified than me.
I'd like to say on behalf of the peanut gallery to all those involved: thanks for all the hard work.
Nooo...Not even Zog himself would really want to do that.
Odd, I though there was quite a lot of opinion here. Or was it just me...
SSteve,
I believe it is. There is even talk of Linux going over to Clang/LLVM. Even GCC developers admit that it easier to work with when creating new targets etc. Here is my favourite quote about that from wikipedia: "...as one long-time GCC developer put it, "Trying to make the hippo dance is not really a lot of fun.""
RossH,
I suspect that is not a technical issue, just the result of Clang/LLVM being quite new and no one has tackled those other targets yet. I see no reason why LLVM cannot target an 8bit AVR as well as GCC can for example.
You could not be more wrong, LLVN is not a GNU project. It is MIT licensed. From wiki: "LLVM can provide the middle layers of a complete compiler system, taking intermediate form (IF) code from a compiler and emitting an optimized IF. This new IF can then be converted and linked into machine-dependent assembly code for a target platform."
No need for that run time JIT compilation step like .NET.
RossH,
That may well be true, but Clang/LLVM can and is used to generate native code directly at compile time. There the LLVM is not used as a CLR. It's just a normal source to binary executable compiler. LLVM is the intermediate form that is optimized along the way at compile time.
No, because of the above.
SSteve:
No, I think you are on a solid limb there, LLVM should be looked at.
I think a lot of us are just sitting back watching...
I'll throw in my two cents.
I think the cart is being put somewhat before the horse. By that I mean I think a lot of energy is being spent discussing alphabet soup GCC/LLVM GPL/MIT, etc. without first laying out what is needed.
Some of this may have been addressed but seems to get lost in the noise.
Memory Models:
1) Straight PASM in a COG, I know there isn't much space, but the ability to do driver level type programming in C would be nice.
2) LMMx, whatever new incantation of LMM fits prop2, I think this should really be a primary focus, being able to maximize what can be done without resorting to XMM. It seems me that once an application is forced to add external memory the decision to use a prop over some other chip becomes a much harder argument.
3) XMM, because some apps just won't fit in the hub. For XMM I see the need for options for code to run from RAM or ROM. I haven't looked at the new instruction set, but I assume some amount of self-modification is still helpful, that would need to run from non-ROM space in the ROMable code mode.
System Configuration
Obviously there is some need to be able to configure the compiler to produce code for various systems with different memory layouts, XMM setups, etc. Focus on making this easy for a user to setup is important. I know a lot of folks on here have boards that they produce that they want to see having "canned" support, but we need to make sure it is easy for engineers to use the prop in boards of their own design without feeling pushed into using an existing board with canned support. Same ideas apply to various video setups, keep in mind not every prop app uses video, there seems to be maybe too much focus on that aspect of the prop sometimes.
Threading
Given the props multi-core nature threading is a must, at least threading using multiple cogs and ideally within a COG using some form of cooperative multitasking.
External Input (user)
Maybe Parallax could solicit involvement from engineers working for prospective clients, we spend a lot of time trying to decide what "they" need, maybe we should just ask.
Sapieha's tag line probably should be one of the guiding principles:
"If your gonna construct something, make it as simple as possible yet as versatile as possible."
C.W.
The serious specification business (the "What" in the "Why, What, Who, How" process) has not been completely defined yet as usage or deliverable "requirements."
RE : Memory Models
Of the 3 memory models you mentioned, the one that may not work is compiling to straight PASM - not saying it won't be tried. I agree it would be nice to write COG code in C.
A fully functional System On a Chip "SOC" without any external support is indeed a high priority target. I expect that being able to use external memory solutions for running programs is also important. BTW, It is entirely possible for LMM (or other VM) to run programs straight from ROM or Flash - I have a board on my desk doing that right now with Propeller I.
RE: System Configuration
Having a linker that would allow "any possible user configuration" for external memory without needing support from a consultant is important for $BILLION volume customers.
The target customer set (big revenue and volume purchasers) do not have much to say in this forum primarily because Propeller has not attracted them ... yet. Without proper tools, Propeller I/II is not interesting to big customers. Of course it's interesting to us, but we won't be generating billions in revenue needed for Parallax to get a big enough slice for Parallax Semiconductor to succeed.
Parallax Semiconductor was apparently created in part for solving the volume problem. It's an up-hill battle to succeed in evangelizing a non-mainstream product. Propeller II and "proper tools" will definitely help this effort. If Parallax Semiconductor succeeds, everyone stands to benefit ... if not ... well that's not an option.
Dave i'm confused by TLA and FLA too
At UPS we had a TLA that was TLA, it was Talk, Listen, and Act...
C.W.
I think Ross may have been referring to interaction with Parallax, not with potential customers.
Hmmm. Not sure about the "crazy bit", but I do question the point of having a debate like this if Parallax are not actually going to participate.
Are we intended to uncover their actual intentions and requirements purely by chance? This may be fun for us enthusiasts - but it seems an unusual way to conduct a project specifically intended to lift their professional profile.
Ross.
While that is brewing this topic will come back up, and I suspect there are no hard requirements, or there are a few based on some feedback they have received.
(which is why I advocated for a market research type discussion right away)
Some higher level goal, with some ownership would help, because then at least advocacy would be targeted correctly.
Until then, anyone want to debate the merits of gcc vs llvm?
Honestly, that is highly likely to be productive, given where things are at present.