I think if you reread my post you'll understand that I wasn't trying to start a language war. I don't disagree that Parallax needs to offer C to those who think (or whose managers think) they need it. I'm just not one of those people, that's all. As long as the resources applied to C are not done so at Spin's expense, I'll be content to watch C development from the sidelines. Should Spin's continued development and enhancement suffer as a result of any resource diversion to C, however, Parallax will be hearing plenty from my quarter!
Bill Henning,
Have you considered the idea of using multiple cogs for LMM2? Since we'll have the internal port for inter cog communication, it's possible to have multiple cogs participating in LMM execution.
Also, there is 128 longs worth of "data" space available in each cog in the form of the CLUTs, so those could be a form of "faster FCACHE". It's exciting to think about.
Phil,
I'm with you on retaining Spin/PASM as a first class citizen in Prop 2. I expect Chip will be doing this and that the on chip dev built into the ROM will be Spin/PASM.
IMHO it would be a big mistake to not support Spin on the Prop 2. I think the Prop 2 should use the same bytecodes as Prop 1, and use the code $3C as an escape code to add additional instructions. I've looked in detail at the Spin interpreter source and there are various ways to speed it up. It would be nice to have more than 496 longs of cog memory, but it could be sped up by using external lookup tables in hub RAM. Prop 2's auto-increment will improve the performance of instruction fetching and stack operations. I would love to see an environment where C and Spin modules could be linked together into a single executable image.
Single cog LMM2 will almost certainly be faster than multi-cog LMM2, the "almost" part depends on exactly what Chip does for the inter-cog communications - if it is like what I discussed with him months ago, it won't really help LMM2 run faster using multiple cogs.
The 128 longs of CLUT space is not usable for FCACHE *unless* the cog can execute code in it, which is not the case as far as I understand.
I have been thinking evil thoughts of using the CLUT as a return stack, which should be feasible if the auto increment/decrement cog memory indirection will work on it.
' evil clut usage, assumes INDA/INDB are names of cog pointer registers, syntax is made up
'
' top of code, initialize INDA to CLUT
'
mov INDA,clut_addr
'
jmpret subaddr,--INDA ' call subroutine at subaddr, push return address on stack, maybe make it a "CALLS subaddr" macro to hide stack manipulation
' returns here
'
'
subaddr ' write subroutine code here
jmp INDA++ ' return to address on top of return stack, pop address, maybe call it "RETS" as a macro to hide stack manipulation
clut_addr long $200 ' assuming CLUT starts right after regular longs
Bill Henning,
Have you considered the idea of using multiple cogs for LMM2? Since we'll have the internal port for inter cog communication, it's possible to have multiple cogs participating in LMM execution.
Also, there is 128 longs worth of "data" space available in each cog in the form of the CLUTs, so those could be a form of "faster FCACHE". It's exciting to think about.
Phil,
I'm with you on retaining Spin/PASM as a first class citizen in Prop 2. I expect Chip will be doing this and that the on chip dev built into the ROM will be Spin/PASM.
Bill,
I meant storing code snips of code in the CLUT and pulling it out into the FCACHE space instead of going to hub. Of course, it could also just hold extra data for the LMM core freeing up main cog memory for more code.
As for the multi-cog approach, you could have the "slave" cog(s) just receive signals from the mast cog that cause them to execute code and provide results. Or perhaps you could pipe code throught that internal port to be executed locally or remotely. There are so many options that I'm not sure what to think yet. We need more details
The 128 longs of CLUT space is not usable for FCACHE *unless* the cog can execute code in it, which is not the case as far as I understand. ...
Using LUT as a small, limited "local" function stack sounds interesting .... On function entry, the initial stack context can be stored there and manipulated without accessing slower HUB until the function returns which would restore the context to hub space. Of course knowing whether or not that is a good optimization at compile time wouldn't hurt ... something that GCC could be capable of already. Perhaps alternatively the LUT can be a first level overlay store for small complete routines that are used less often than interpreter macros.
It would not be much faster than reading bits of code from hub for FCACHE with a loop of RDQLONG/djnz, which reads (effectively) one long per two prop2 clocks; the minimum loop for copying from the CLUT would also be two instructions with djnz... although the REP prefix might make it 1 cycle; depends on the exact implementation. Besides, the 128 CLUT locations would not store THAT much code.
If we can use the CLUT as a return stack as per my example above, that would be a pretty big win for call/return addresses (as long as the call stack depth was less than 128 levels)
Another potential good use for CLUT area is saving/restoring thread contexts.
Bill,
I meant storing code snips of code in the CLUT and pulling it out into the FCACHE space instead of going to hub. Of course, it could also just hold extra data for the LMM core freeing up main cog memory for more code.
As for the multi-cog approach, you could have the "slave" cog(s) just receive signals from the mast cog that cause them to execute code and provide results. Or perhaps you could pipe code throught that internal port to be executed locally or remotely. There are so many options that I'm not sure what to think yet. We need more details
The register model I have been playing with for LMM2 follows:
R0 general purpose register
R1 general purpose register
R2 general purpose register
R3 general purpose register
R4 general purpose register
R5 general purpose register
R6 general purpose register
R7 general purpose register
IX (R8) INDIRA hub pointer for auto increment/decrement modes
IY (R9) INDIRB hub pointer for auto increment/decrement modes
NOS (R11) scratch for compiler generated expression evaluation
TOS (R12) top of stack for stack oriented code
FP (R13) frame pointer, SP at entry to a function
SP (R14) current stack pointer
PC (R15) program counter
The reason for the above is the KISS principle, plus trying to reserve as much memory as possible for FCACHE overlay area.
To save memory, there should NOT be a jump table for micro-ops in the cog, the linker should bind the JMP #kernelopaddress references to actual addresses within the current LMM2 kernel.
This allows for multiple kernels optimized for different usages to be source/binary compatible; perhaps this binding should be left to the loader?
The above also allows simplistic stack oriented expression code to execute fairly decently using TOS&NOS optimizations, allowing more complicated register-allocating backend to be written later.
One of my major design goals is to reserve 128 longs of the 496 (or is it 506 now?) standard cog locations for the FCACHE area. For LMM2, I want to use $000-$07F as the FCACHE area; the kernel initialization code can live there and be overwritten by the first FCACHE.
Note: it may make more sense to use one of the indirection pointers for FP.
Bill,
I like the idea of compile time binding of the code to the kernel. This would then allow the compiler to link together a kernel from fragments based on what it's compiling. So the kernel would be tuned more to the code it's running, and FCACHE would be used for bringing in the other kernel fragments that were not linked in to the primary space. This could make for some very optimal performance. Very nice!
I was talking to chip on this and he said there is a like 8 long read instruction. I might be wrong but, the prop 2 should be able to execute instructions at more than 1/2 native speed. It would make sense then to have the register space map be something ridculus like 256 general purpose registers.
Whatever the case is, the prop2 is not the prop1. Nor will it likely take the same path as to avoid being ostracized.
Yes I'm quite happy with Spin as well and for sure it will be there on the Prop II. However this discussion is about GCC/Eclipse. The reason for wanting a real C and a real IDE for the Propeller is, I believe, to address the large scale commercial "profesionals". I don't belive Spin should be part of that picture or this debate. Nor should worrying about making Spin and C live together.
What happens to Spin, and hopefully it is enhanced and backward compatible, is a totally other picture. I would not even bother attempting to adopt Eclipse as a Spin IDE, it's not beginner, casual programmer, friendly like the Prop Tool.
David Hein,
...but [Spin] could be sped up by using external lookup tables in hub RAM.
Interesting, I think that might be the same as what I found with the Z80 emulator, of course those tables could presumably be in ROM as well saving RAM space and making life easier.
@Roy and Bill
Use two COGs to run an LMM (C/C++) program? I don't thing so. COGs are a precious resource.
Kye,
Whatever the case is, the prop2 is not the prop1. Nor will it likely take the same path as to avoid being ostracized.
Hence my suggestion to leave Spin out of this picture.
Thing is using two COGs to speed up LMM somehow even if it is a bit quicker is bound to be slower than having two COGs running two separate LMM programs. In total MIPs. Besides COGs are a precious resource.
I don't belive Spin should be part of that picture or this debate.
Then one of us is confused. This is what I thought this thread was about:
1. Adopting Eclipse as the universal IDE/dev platform for the Propeller (I and II).
2. Writing cross-compilers (for Spin, C, or whatever other language) in C, C++, or whatever (compiled with GCC) which integrate with Eclipse in a seamless fashion.
I did not think the thread was strictly about a C cross-compiler for the Prop.
Then one of us is confused. This is what I thought this thread was about:
1. Adopting Eclipse as the universal IDE/dev platform for the Propeller (I and II).
2. Writing cross-compilers (for Spin, C, or whatever other language) in C, C++, or whatever (compiled with GCC) which integrate with Eclipse in a seamless fashion.
I did not think the thread was strictly about a C cross-compiler for the Prop.
-Phil
After Ken's clarification, I tend to agree with Phil - what Parallax mostly seem to want is a common, professional IDE for the Propeller. They are also looking to see whether GCC can be used to compile all the languages they want that IDE to support - including SPIN and C. As I tried to point out before, the main problem with this is not that it can't be done, it is the sheer amount of work involved - i.e. one new Eclipse plugin (Spin), one new GCC front-end (Spin) and two new GCC back-ends (assuming C targets LMM PASM and Spin targets Spin VM byte codes).
Seems a lot of work just to reproduce what we already have (but not in a single tool)!
I did not think the thread was strictly about a C cross-compiler for the Prop.
You are right. The objective statement is clearly put by Ken in the opening post:
The objective is create an open-source cross-platform compatible compiler suite for Propeller 2 (code name) supporting Spin, C/C++ and possibly other languages.
However this thread is in the "Parallax Semiconductor" section of the forums. I infer from that that we are talking about the "other" Parallax. The thrust of Parallax Semiconductor is to push the Prop II into places the Prop I has hardly penetrated. The large scale, commercial market place.
As I see it in that world, as has been argued to death on the forums for years, C/C++ is what counts. If you can squeeze in Ada and perhaps a few other standardized languages that's a bonus.
In that world a grown up development environment, like Eclipse, is expected.
My observation is that Spin and C are such different animals that address the needs of such different users that there is no point in worrying about interoperability between the two. Hence I believe Spin should be sidelined for this debate and effort.
Nor is there any pressing need to be able to develop Spin in a huge and complicated IDE like Eclipse. Spin and the Prop tool together do an excellent job of what they were designed to do. Be a lean and mean, quick and easy system that allows begineers and casual programmers to get productive almost instantly whilst making very good use of the features of the Propeller.
Dropping Spin into Eclipse (or other large scale IDE) seems pointless. Those "professional" users won't use it and it's too much to expect beginners and casual programmers to deal with.
As RosH says:
As I tried to point out before, the main problem with this is not that it can't be done, it is the sheer amount of work involved - i.e. one new Eclipse plugin (Spin), one new GCC front-end
(Spin) and two new GCC back-ends (assuming C targets LMM PASM and Spin targets Spin VM byte codes).
So, don't do that. Concentrate on professional tools for those "professionals" C/C++ and Eclipse. Standards and standardization is what counts there.
Dropping Spin into Eclipse (or other large scale IDE) seems pointless. Those "professional" users won't use it and it's too much to expect beginners and casual programmers to deal with.
I guess that's where we have a profound divergence of opinion. I've never used Eclipse, so can't speak from experience. But if it's so user-unfriendly that casual programmers would shun it, shouldn't we be casting a wider net for IDE candidates? The objective of a universal dev platform is well-worth considering, IMO, and I think that if Spin were at least available on it, there would be some "professional" programmers who would use it -- and like it for it's RAD capabilities. More options are always good, right? Therefore, Spin should definitely not be off the table in this discussion.
In the old days we would get ourselves a C64 or Sinclair or whatever. Turn it on and boom, you are instantly at a position where you can type:
10 PRINT "HELLO"
20 GOTO 10
There was the introduction to programming for many of us of our generation. We were instantly hooked, we could make this machine jump from the get go. Anything more complicated, I believe may never have had that effect.
"Professionals" at the time were happy hand crafting assembler or working on minis or mainframes.
Wind the clock forward three decades and we have the Arduino. A dead simple target platform, a dead simple IDE and C++ presented as the programming language in such a way that it is, well, dead simple. They don't even call it C++ and they don't document all the tortuous features of the language in their documentation. No, just start the IDE, type and run. The IDE even hides "complexities" like "int main(int argc, char* argv[])".
That simplicity is what makes the Arduino as a system, chip, board, language, IDE so wildly popular.
Similarly the Propeller plus Spin plus the Prop Tool makes the Propeller so simple and accessible to beginner programmers and casual programmers.
I don't believe you can do that, achieve that simplicity, with an IDE like Eclipse which is designed as a universal do everything tool for large scale programming.
Perhaps a "universal" tool is a worthy goal. But I believe that it's exactly that universality that robs us of the simplicity required for Prop Tool/Arduino IDE class users.
As a practical matter, what is the difference between the effort required to maintain say a Prop Tool for Spin and a plug in for an IDE like Eclipse?
I noticed that there has often been talk of a Spin plugin for Eclipse, during which time Andrey Denenyev has written a very nice open source Spin IDE from scratch!
I guess that's where we have a profound divergence of opinion. I've never used Eclipse, so can't speak from experience. But if it's so user-unfriendly that casual programmers would shun it, shouldn't we be casting a wider net for IDE candidates? The objective of a universal dev platform is well-worth considering, IMO, and I think that if Spin were at least available on it, there would be some "professional" programmers who would use it -- and like it for it's RAD capabilities. More options are always good, right? Therefore, Spin should definitely not be off the table in this discussion.
-Phil
Eclipse isn't at all hard to use, it's just another IDE. Thousands of people are using it with the very cheap NXP LPCXpresso boards without any problems, not having used an ARM device before, who are probably familiar with the simpler IDEs provided by Microchip and Atmel for the PIC and AVR.
It does have a complex appearance, though, and NetBeans has a much cleaner, simpler-looking interface.
Most professionals are used to dashing off a few lines of C if they need a quick test of a hardware function. I can't see them bothering to work out how to do it in Spin. Including it might even make Parallax Semiconductor look "unprofessional" to some users.
No Eclipse is not so hard. This is all relative after all. If you are working as a coder full time and it takes you a day or more to get familiar with a tool that's no loss provided the tool offers savings in time and effort over the long haul. After all that's why you took the time and trouble to learn C or whatever rather than continue hacking away in assembler all those years back.
I'm talking about easy from the point of view of someone who has never coded before. Or someone who does so infrequently. Or someone who really does not want to expend any more mental effort that absolutely necessary to achieve something relatively simple because they have a lot else to apply their mind to.
For theses people you cannot beat the: run IDE program, type code, hit F11 simplicity offered by the Prop Tool or other such simple systems.
I just don't believe Eclipse or such IDE is ever going to offer that extreme simplicity.
P.S. Ever tried to get the Android SDK up and running in Eclipse. That is a major project compared to firing up the Prop tool.
P.P.S. The company who shall remain nameless uses Eclipse, well that had me running around in circles for a long while and I'm supposed to be proficient at such things:)
Ergo, leave Spin off this particular table. I rest my case.
With all due respect, Heater, you haven't really made a case. Besides, if you look at the Parallax Semiconductor Gold Standard for objects, it's all about Spin. If existing Spin objects can't be linked into C code under a universal IDE, there's an awful lot of work that will have to be redone. (Which one of you wants to recast TV_text or FullDuplexSerial in C?) Also, the current Prop Tool can't be open-sourced and is on its way out. Are you suggesting that yet another effort be mounted to replace it, separately from the pro-level IDE? I didn't think so. For these reasons, I feel it's imperative that Spin play a significant role in any professional dev system.
Okay, those two (I guess I should've looked first. ); but it doesn't invalidate my point.
No, it doesn't completely invalidate your point But it does demonstrate that with just a little guidance any programmer can easily achieve the same thing. The kinds of customers who use GCC don't need much hand-holding and are usually quite proud of that.
The kinds of customers who use GCC don't need much hand-holding and are usually quite proud of that.
Very true. For some, an IDE is not required either.
@Heater,
I am a professional programmer, however not in the microcontroller realm. I noticed you mentioned the Arduino IDE, which is targeted at the maker/education/hobbyist market where simple is better. I don't know that targeting me (the hobbyist) is the idea. AVR-GCC or (WinAVR) and AVR-Eclipse might be a more fair comparison.
Comments
I think if you reread my post you'll understand that I wasn't trying to start a language war. I don't disagree that Parallax needs to offer C to those who think (or whose managers think) they need it. I'm just not one of those people, that's all. As long as the resources applied to C are not done so at Spin's expense, I'll be content to watch C development from the sidelines. Should Spin's continued development and enhancement suffer as a result of any resource diversion to C, however, Parallax will be hearing plenty from my quarter!
-Phil
Have you considered the idea of using multiple cogs for LMM2? Since we'll have the internal port for inter cog communication, it's possible to have multiple cogs participating in LMM execution.
Also, there is 128 longs worth of "data" space available in each cog in the form of the CLUTs, so those could be a form of "faster FCACHE". It's exciting to think about.
Phil,
I'm with you on retaining Spin/PASM as a first class citizen in Prop 2. I expect Chip will be doing this and that the on chip dev built into the ROM will be Spin/PASM.
Roy
Single cog LMM2 will almost certainly be faster than multi-cog LMM2, the "almost" part depends on exactly what Chip does for the inter-cog communications - if it is like what I discussed with him months ago, it won't really help LMM2 run faster using multiple cogs.
The 128 longs of CLUT space is not usable for FCACHE *unless* the cog can execute code in it, which is not the case as far as I understand.
I have been thinking evil thoughts of using the CLUT as a return stack, which should be feasible if the auto increment/decrement cog memory indirection will work on it.
' evil clut usage, assumes INDA/INDB are names of cog pointer registers, syntax is made up ' ' top of code, initialize INDA to CLUT ' mov INDA,clut_addr ' jmpret subaddr,--INDA ' call subroutine at subaddr, push return address on stack, maybe make it a "CALLS subaddr" macro to hide stack manipulation ' returns here ' ' subaddr ' write subroutine code here jmp INDA++ ' return to address on top of return stack, pop address, maybe call it "RETS" as a macro to hide stack manipulation clut_addr long $200 ' assuming CLUT starts right after regular longsI meant storing code snips of code in the CLUT and pulling it out into the FCACHE space instead of going to hub. Of course, it could also just hold extra data for the LMM core freeing up main cog memory for more code.
As for the multi-cog approach, you could have the "slave" cog(s) just receive signals from the mast cog that cause them to execute code and provide results. Or perhaps you could pipe code throught that internal port to be executed locally or remotely. There are so many options that I'm not sure what to think yet. We need more details
Roy
Roy beat me to the punch
It would not be much faster than reading bits of code from hub for FCACHE with a loop of RDQLONG/djnz, which reads (effectively) one long per two prop2 clocks; the minimum loop for copying from the CLUT would also be two instructions with djnz... although the REP prefix might make it 1 cycle; depends on the exact implementation. Besides, the 128 CLUT locations would not store THAT much code.
If we can use the CLUT as a return stack as per my example above, that would be a pretty big win for call/return addresses (as long as the call stack depth was less than 128 levels)
Another potential good use for CLUT area is saving/restoring thread contexts.
The reason for the above is the KISS principle, plus trying to reserve as much memory as possible for FCACHE overlay area.
To save memory, there should NOT be a jump table for micro-ops in the cog, the linker should bind the JMP #kernelopaddress references to actual addresses within the current LMM2 kernel.
This allows for multiple kernels optimized for different usages to be source/binary compatible; perhaps this binding should be left to the loader?
The above also allows simplistic stack oriented expression code to execute fairly decently using TOS&NOS optimizations, allowing more complicated register-allocating backend to be written later.
One of my major design goals is to reserve 128 longs of the 496 (or is it 506 now?) standard cog locations for the FCACHE area. For LMM2, I want to use $000-$07F as the FCACHE area; the kernel initialization code can live there and be overwritten by the first FCACHE.
Note: it may make more sense to use one of the indirection pointers for FP.
I like the idea of compile time binding of the code to the kernel. This would then allow the compiler to link together a kernel from fragments based on what it's compiling. So the kernel would be tuned more to the code it's running, and FCACHE would be used for bringing in the other kernel fragments that were not linked in to the primary space. This could make for some very optimal performance. Very nice!
Roy
Whatever the case is, the prop2 is not the prop1. Nor will it likely take the same path as to avoid being ostracized.
Yes I'm quite happy with Spin as well and for sure it will be there on the Prop II. However this discussion is about GCC/Eclipse. The reason for wanting a real C and a real IDE for the Propeller is, I believe, to address the large scale commercial "profesionals". I don't belive Spin should be part of that picture or this debate. Nor should worrying about making Spin and C live together.
What happens to Spin, and hopefully it is enhanced and backward compatible, is a totally other picture. I would not even bother attempting to adopt Eclipse as a Spin IDE, it's not beginner, casual programmer, friendly like the Prop Tool.
David Hein,
Interesting, I think that might be the same as what I found with the Z80 emulator, of course those tables could presumably be in ROM as well saving RAM space and making life easier.
@Roy and Bill
Use two COGs to run an LMM (C/C++) program? I don't thing so. COGs are a precious resource.
Kye,
Hence my suggestion to leave Spin out of this picture.
Thing is using two COGs to speed up LMM somehow even if it is a bit quicker is bound to be slower than having two COGs running two separate LMM programs. In total MIPs. Besides COGs are a precious resource.
1. Adopting Eclipse as the universal IDE/dev platform for the Propeller (I and II).
2. Writing cross-compilers (for Spin, C, or whatever other language) in C, C++, or whatever (compiled with GCC) which integrate with Eclipse in a seamless fashion.
I did not think the thread was strictly about a C cross-compiler for the Prop.
-Phil
After Ken's clarification, I tend to agree with Phil - what Parallax mostly seem to want is a common, professional IDE for the Propeller. They are also looking to see whether GCC can be used to compile all the languages they want that IDE to support - including SPIN and C. As I tried to point out before, the main problem with this is not that it can't be done, it is the sheer amount of work involved - i.e. one new Eclipse plugin (Spin), one new GCC front-end (Spin) and two new GCC back-ends (assuming C targets LMM PASM and Spin targets Spin VM byte codes).
Seems a lot of work just to reproduce what we already have (but not in a single tool)!
Ross.
Could well be me:)
You are right. The objective statement is clearly put by Ken in the opening post:
However this thread is in the "Parallax Semiconductor" section of the forums. I infer from that that we are talking about the "other" Parallax. The thrust of Parallax Semiconductor is to push the Prop II into places the Prop I has hardly penetrated. The large scale, commercial market place.
As I see it in that world, as has been argued to death on the forums for years, C/C++ is what counts. If you can squeeze in Ada and perhaps a few other standardized languages that's a bonus.
In that world a grown up development environment, like Eclipse, is expected.
My observation is that Spin and C are such different animals that address the needs of such different users that there is no point in worrying about interoperability between the two. Hence I believe Spin should be sidelined for this debate and effort.
Nor is there any pressing need to be able to develop Spin in a huge and complicated IDE like Eclipse. Spin and the Prop tool together do an excellent job of what they were designed to do. Be a lean and mean, quick and easy system that allows begineers and casual programmers to get productive almost instantly whilst making very good use of the features of the Propeller.
Dropping Spin into Eclipse (or other large scale IDE) seems pointless. Those "professional" users won't use it and it's too much to expect beginners and casual programmers to deal with.
As RosH says:
So, don't do that. Concentrate on professional tools for those "professionals" C/C++ and Eclipse. Standards and standardization is what counts there.
That's just cruel.:)
-Phil
There was the introduction to programming for many of us of our generation. We were instantly hooked, we could make this machine jump from the get go. Anything more complicated, I believe may never have had that effect.
"Professionals" at the time were happy hand crafting assembler or working on minis or mainframes.
Wind the clock forward three decades and we have the Arduino. A dead simple target platform, a dead simple IDE and C++ presented as the programming language in such a way that it is, well, dead simple. They don't even call it C++ and they don't document all the tortuous features of the language in their documentation. No, just start the IDE, type and run. The IDE even hides "complexities" like "int main(int argc, char* argv[])".
That simplicity is what makes the Arduino as a system, chip, board, language, IDE so wildly popular.
Similarly the Propeller plus Spin plus the Prop Tool makes the Propeller so simple and accessible to beginner programmers and casual programmers.
I don't believe you can do that, achieve that simplicity, with an IDE like Eclipse which is designed as a universal do everything tool for large scale programming.
Perhaps a "universal" tool is a worthy goal. But I believe that it's exactly that universality that robs us of the simplicity required for Prop Tool/Arduino IDE class users.
As a practical matter, what is the difference between the effort required to maintain say a Prop Tool for Spin and a plug in for an IDE like Eclipse?
I noticed that there has often been talk of a Spin plugin for Eclipse, during which time Andrey Denenyev has written a very nice open source Spin IDE from scratch!
Ergo, leave Spin off this particular table.
I rest my case:)
Eclipse isn't at all hard to use, it's just another IDE. Thousands of people are using it with the very cheap NXP LPCXpresso boards without any problems, not having used an ARM device before, who are probably familiar with the simpler IDEs provided by Microchip and Atmel for the PIC and AVR.
It does have a complex appearance, though, and NetBeans has a much cleaner, simpler-looking interface.
Most professionals are used to dashing off a few lines of C if they need a quick test of a hardware function. I can't see them bothering to work out how to do it in Spin. Including it might even make Parallax Semiconductor look "unprofessional" to some users.
I'm talking about easy from the point of view of someone who has never coded before. Or someone who does so infrequently. Or someone who really does not want to expend any more mental effort that absolutely necessary to achieve something relatively simple because they have a lot else to apply their mind to.
For theses people you cannot beat the: run IDE program, type code, hit F11 simplicity offered by the Prop Tool or other such simple systems.
I just don't believe Eclipse or such IDE is ever going to offer that extreme simplicity.
P.S. Ever tried to get the Android SDK up and running in Eclipse. That is a major project compared to firing up the Prop tool.
P.P.S. The company who shall remain nameless uses Eclipse, well that had me running around in circles for a long while and I'm supposed to be proficient at such things:)
-Phil
-Phil
@Heater,
I am a professional programmer, however not in the microcontroller realm. I noticed you mentioned the Arduino IDE, which is targeted at the maker/education/hobbyist market where simple is better. I don't know that targeting me (the hobbyist) is the idea. AVR-GCC or (WinAVR) and AVR-Eclipse might be a more fair comparison.