Our compiler tools are written in almost entirely in standard C and can be compiled to run under Linux. The IDE is a GUI shell.
However, having a Linux / Mac OSX product is another matter. So far it has not been deemed enough ROI. Even for OS X, the best solution now is to buy Parallel Desktop for $80 or so...
We do not currently have the debugger technology in house. Traditionally we have been working with NoICE to port their debuggers to our platforms, but I would need to convince him that it is profitable to do so. There is a chance that we will get some debugger expertise in house, possibly via the form of gdb. Don't know yet.
But yes, unfortunately, debugging solution will be an issue for a while. It should not be hard per se, as the compiler tool chain fully supports debug info generation, and the LMM kernel is spec'ed to support debugging. We just need a client program.
u/COSII and Salvo will not be supported immediately. There are definitely interesting issues to tackle due to the Propeller multiprocessing features.
Methinks the ROI argument is a chicken-and-egg issue. It takes courage to break out of the shell. Perhaps, through courage, you'll find your ticket to retirement in Tahiti. Given the market turmoil created by the Windows Vista fiasco, the time may well be ripe.
Phil Pilgrim (PhiPi) said...
Methinks the ROI argument is a chicken-and-egg issue. It takes courage to break out of the shell. Perhaps, through courage, you'll find your ticket to retirement in Tahiti. Given the market turmoil created by the Windows Vista fiasco, the time may well be ripe.
-Phil
As a matter of fact, we have released a Linux version of our compiler, back in 1998 or so. Guess how many we sold?
May be half a dozen in two years.
Sure, may be we could have done marketing differently, or may be this and that, but market reality is often very different from some people's assumptions.
> As a matter of fact, we have released a Linux version of our compiler, back in 1998 or so. Guess how many we sold?
I'm not trying to explain you *your* business. But '98 was last century.
No, I feel things changed quite a bit in the last years. And I would prefer having a complete toolchain on my Linux-box over the XP. And I know that I'm not alone.
Would be interesting to get numbers for the ratio Win/*nix/Mac for Eagle (by Cadsoft).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Prices have not changed for well for 7 years!!! so it's about time, with inflation and all. I understand that a lot of the Propeller users are hobbyists so I may run a "release special" for $99 or something like that for a few months. Heck, if you want to send me $99 now to keep us going (hey, pizza and ramen can get expensive), I'll take it
I am ready to send my $99, please provide a telephone number or address for purchase order
Seriously, on the Linux matter, things have changed considerably since the late 90's early '00's. At 2000, we were at RH 6 level of development. Powerful, but very rough around the edges. Pretty much was something only existing Unix heads used, and a lot of those uses were skunk works, Internet / Web/ Firewall, glue kinds of things.
Serious graphics were a hit and miss affair. Everybody remember Linux was why you owned a Matrox graphics card?
Last year I loaded up a high-end CAD eval for some mechanical types running Linux. That's been a milestone for me personally. Mechanical is kind of the last to go Linux, for whatever reason.
Lots of engineering types run it now. Not just for network geeks anymore. BTW: Their software purchase decision was on the order of $50K. They ended up going all the way down the think different road and are waiting for an Apple release to come this year. They are gonna buy into MCAD on Apple. (Apple!!)
Of the types that I know running Linux, this crowd is gonna be pretty well represented. Mechanical engineers not so much as only high-end stuff, or limited low end stuff runs on Linux for them. Network people have always ran it. High end simulation / analysis people, bio sciences and graphics / visualization people all do now to a notable degree. It's not exclusive with those people, but it's there now and they are spending fairly large amounts of money for Linux tool sets.
Many --and I think it's a majority now, of movie / CGI / pre-and post production tool chains are very heavy linux these days. Most of that used to be IRIX. Win32 came through and was out the door just that quick. That crowd got the news big in the early 00's and never looked back. It being open worked huge for them. OS costs and the ability to build custom environments, sometimes for a single movie production, gets it done for them. Alias was more or less told to port, or those guys were gonna use something else besides MAYA.
I see a lot of synergies between those people and EE engineering / embedded types. Both work at a level that involves software being a part of the process, not just a tool to get there. Maybe that's why the MCAD crowd isn't so hot on Linux just yet. The simulation / bio-sciences people are in a similar boat, having to deal with software as process and not just tool.
Where that is the case, Linux has some attraction and value add factor.
Personally, the way I see it, being a part timer, Linux does not cost anything but time. So you get a nice set of tools, all you do is provide the hardware and that's pretty cheap. Lack of yearly costs and entry costs for the basics means dollars to spend on hardware goodies and their relevant tools. I really like getting new hardware goodies. I don't like paying for baseline software that gets in the way of that.
I'm gonna buy the compiler when it's done. It's way easier to do that when I've not had to spend the $500 - $1000 or so for a nice set of win32 tools to start with. I'll actually pay MORE for the Linux tools, because that reinforces the value Linux has, and that's just worth it.
Kind of sorry I asked about Linux ports now; I was just curious.
ImageCraft or anyone else faces stiff competition from GNU in serious Linux areas today
as it was in 1998 (just ask Wind River -- EDIT: they were providing GNU for windows then).
Since there is no GNU port for Propeller, it is unlikely it will ever achieve acceptance in high
volume product areas that depend on Linux for builds. Perhaps ImageCraft should leverage
it's know-how into a licensable port for Propeller ?
For Parallax, the stepping stone for design wins in high volume production for Propeller
(translated "Even the janitor could retire to Tahiti") is an investment by Parallax in a GNU port.
Today Linux is the serious tool for serious business in companies that don't use windoze.
In 1998 Sun SPARC workstations were the primary build farms for dev/release images.
Today, SPARC is just a remnant that made EMACS popular (meta what?) to many developers,
today all serious builds are done with Linux SMP server farms.
The question to ask of course is: "Is it possible for Propeller to get design wins in big
business that use linux for builds?" The answer of course primarily depends on whether
or not tools are available [noparse]:)[/noparse] I know for a fact that AVR gets design wins in such places,
as do 8051 cores, for line-card device configuration controllers.
There are of course Windows build server equivalents. Maybe someone cares to comment?
ADDED: How much Ramen do you need?· Put me on your list.
Everyone prefers to use what they prefer, but just how big are the markets for Windows, Linux, Mac and the others - Are there any hard or even useful figures ?
There will always be examples of Big Industry and others using some particular platform ( the movie industry and top-end maths modelling, anyone seriously into DTP used to swear on Quark and Macs, and would anyone not consider Linux as a web server platform ? ), but how does that pan out to actual market shares across the embedded sector ? My ( very limited ) experience has been much the same as ImageCraft's; big demand for Linux/Mac support, minimal market when it arrives. A lot of work and effort going into something which could have been much better spent on furthering the market which actually existed.
That's not to say Linux or Mac is any less credible than Windows and often the reverse is true, nor that Linux and Mac tools shouldn't be delivered, but companies make their money from markets which exist, not those which do not. I seem to frequently hear the mantra of "GNU port <this>" presented as a universal panacea and throwing open the door to unlimited riches, and maybe it is, but I rarely see evidence which would back that up.
I'm also not saying anyone is right or wrong; that can only be judged on the evidence, not what theory or self-interest may say.
Complicating this is fact that there are a fair number of ways to run some Windows applications under Linux and the MacOS. It would sure be nice for developers who are targeting Windows for their applications to make some attempt to limit the Windows interfacing to calls compatible with CodeWeavers' commercial version of Wine or to Wine itself if possible. That would allow users to run their systems under the MacOS or under Linux while allowing the developer to keep their Windows codebase and have a single distribution.
If it was a native X11 app, it would port easily to Linux, OS/X:X11, and Windows:CygWin. (I'm not a huge fan of CygWin, though.)
While XP reigned, I think most people were at least mollified enough by Windows to use it when they had to. But Vista has made a complete mess of things; and if XP were to disappear, Windows would lose what little attraction it had for its marginally-willing users. To me, that's what makes the platform issue particularly poignant right now. The opportunities presented by this kind of upheaval don't come along every day.
Tight/Real VNC is a heavily used tool in the networking industry that allows the user friendly features of a desktop running whatever a "window" into a powerful build cluster -- something necessary absolutely necessary for switch/router images and linux distribution builds for embedded or otherwise systems.
I also enjoy building Windows applications, but that's mostly for fun.
Just thought of a good idea: when we release the product (and the beta), we'd give a discount for anyone who port or write library modules to use with ICC. Hopefully this will get us all th Spin object equivalence of TV, VGA, mouse, IO, etc. very rapidly....
Sounds like a good idea. Are you going to allow any of the objects in the object exchange or just some of them, would they all get the same discount and if you do more than one do you get more of a discount? I might have a go at one or two of them. I assume that we can use pure assembler and not the LMM assembler?
stevenmess2004,
You would need to use the LMM assembler since any assembly language would need to be loaded (COGNEW) from the LMM "interpreter" just like they currently get loaded via the Spin interpreter. The linker needs the information from the ICC assembler directives. The other thing is that really all of the I/O objects provide a Spin interface to the assembly language. With the LMM, there'll have to be an equivalent C interface to the assembly program running in the cog(s).
Mike, if I understand right you are saying that you would need an interface written in C or LMM assembler and a function in the interface that starts a cog running in pure assembler (although the syntax may be slightly different to the current assembler). So it would end up like most current objects with a spin section to start the object and interface with it and another cog that runs the actual driver? Assuming that the particular driver needs its own cog of course (say tv or vga display).
stevenmess2004 said...
Mike, if I understand right you are saying that you would need an interface written in C or LMM assembler and a function in the interface that starts a cog running in pure assembler (although the syntax may be slightly different to the current assembler). So it would end up like most current objects with a spin section to start the object and interface with it and another cog that runs the actual driver? Assuming that the particular driver needs its own cog of course (say tv or vga display).
Keep in mind that we haven't worked out all the details on starting another COG yet. It's not rocket science, but it needs to be done. Anyway, the idea is, if you need to start another COG, there will be a function, probably called COGNEW and you pass it the name of the function. The function is just a C function in your program.
We will probably want to overlay a more sophisticated process/thread interface on top later, but this should get users started.
As for what objects are qualified for discount, we will definitely be generous especially in the beginning. We want momentum
I'll want to do a simple TV bitmap / character mode driver object for sure. (not trying to reserve that object, just stating that popped into my head right out of the gate!)
Maybe get this rolling during the BETA program? Would be a great way to vet the code and get some stuff done.
stevenmess2004,
Yes. I was talking about the typical I/O driver that's partly in assembly and partly in Spin. ImageCraft was talking about the equivalent to starting up a cog in Spin. Since this is LMM code mostly, the tradeoffs between pure assembly and higher level code shift. Many of the objects that now require pure assembly for speed could be written directly in LMM C. Objects that also require tight timing control like video and the FullDuplexSerial driver will still have to be in pure assembler without the LMM "interpreter".
IDE working with the "Propellent" program downloader integrated. Compiler working and we are tweaking the code. Right now we have a generic LMM kernel routine that does function prologue with saving the registers and allocating stack frame, but since it's so generic, it takes billion years to run (OK, slight exaggeration) and fibo(29) is embarrassing. How long does fibo(29) take to run in Spin anyway?
26 sec with SPIN
1.8 sec with PHP on my mid-range Windows Notebook
800 ms with the above posted piece of code (PASM)
30 ms with a very efficient FORTH Implementation on my mid-range Windows Notebook
Ackerman's function is something I use for testing compilers, it is doubly recursive and I've known some beta compilers crash when trying to compile it.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
@Leon : Isn't the problem with Ackermann's two-fold, that it's deeply recursive and quickly involves very large numbers ? Not really a very good fit for a processor with just 16KW of stack maximum and 32-bit signed.
PRI ackermann( m, n )
if m == 0
return n+1
else
if n == 0
return ackermann( m-1, 1 )
else
return ackermann( m-1, ackermann( m, n-1 ) )
Woohoo!!! Now fibo(29) runs in ~15 seconds. Much slower than I'd like, but not embarrassing so.Most of the time is spent in the function entry and exit sequence. There are ways to further optimize, but it's good for now.
Now wrapping things up for at least a semblance of something beta'able...
deSilva: Easter = March 23rd; fibo(29) = 10 sec
Beanie2K: April 1st; fibo(29) = 15 sec
NickMueller: Feb 27th; fibo(29) = 13 sec
BTW, I am 100% sure that we can do much better than 10 secs for the required function.
Well, I didn't use the super-optimized version I actually did the slow recursive version.
Next time someone who suggests using fibonacci() or ackermann() for benchmarking purpose should be sentenced to writing PIC asm code for a year as a "reward."
hippy said...
@Leon : Isn't the problem with Ackermann's two-fold, that it's deeply recursive and quickly involves very large numbers ? Not really a very good fit for a processor with just 16KW of stack maximum and 32-bit signed.
PRI ackermann( m, n )
if m == 0
return n+1
else
if n == 0
return ackermann( m-1, 1 )
else
return ackermann( m-1, ackermann( m, n-1 ) )
"Next time someone who suggests using fibonacci() or ackermann() for benchmarking purpose should be sentenced to writing PIC asm code for a year as a "reward." "
I spent 5 years writing PIC asm, so thats a serious "reward"you are threatening !!!.
p.s. got the email response to my request to be a beta tester.
Comments
However, having a Linux / Mac OSX product is another matter. So far it has not been deemed enough ROI. Even for OS X, the best solution now is to buy Parallel Desktop for $80 or so...
We do not currently have the debugger technology in house. Traditionally we have been working with NoICE to port their debuggers to our platforms, but I would need to convince him that it is profitable to do so. There is a chance that we will get some debugger expertise in house, possibly via the form of gdb. Don't know yet.
But yes, unfortunately, debugging solution will be an issue for a while. It should not be hard per se, as the compiler tool chain fully supports debug info generation, and the LMM kernel is spec'ed to support debugging. We just need a client program.
u/COSII and Salvo will not be supported immediately. There are definitely interesting issues to tackle due to the Propeller multiprocessing features.
-Phil
As a matter of fact, we have released a Linux version of our compiler, back in 1998 or so. Guess how many we sold?
May be half a dozen in two years.
Sure, may be we could have done marketing differently, or may be this and that, but market reality is often very different from some people's assumptions.
I'm not trying to explain you *your* business. But '98 was last century.
No, I feel things changed quite a bit in the last years. And I would prefer having a complete toolchain on my Linux-box over the XP. And I know that I'm not alone.
Would be interesting to get numbers for the ratio Win/*nix/Mac for Eagle (by Cadsoft).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Jim
·
Seriously, on the Linux matter, things have changed considerably since the late 90's early '00's. At 2000, we were at RH 6 level of development. Powerful, but very rough around the edges. Pretty much was something only existing Unix heads used, and a lot of those uses were skunk works, Internet / Web/ Firewall, glue kinds of things.
Serious graphics were a hit and miss affair. Everybody remember Linux was why you owned a Matrox graphics card?
Last year I loaded up a high-end CAD eval for some mechanical types running Linux. That's been a milestone for me personally. Mechanical is kind of the last to go Linux, for whatever reason.
Lots of engineering types run it now. Not just for network geeks anymore. BTW: Their software purchase decision was on the order of $50K. They ended up going all the way down the think different road and are waiting for an Apple release to come this year. They are gonna buy into MCAD on Apple. (Apple!!)
Of the types that I know running Linux, this crowd is gonna be pretty well represented. Mechanical engineers not so much as only high-end stuff, or limited low end stuff runs on Linux for them. Network people have always ran it. High end simulation / analysis people, bio sciences and graphics / visualization people all do now to a notable degree. It's not exclusive with those people, but it's there now and they are spending fairly large amounts of money for Linux tool sets.
Many --and I think it's a majority now, of movie / CGI / pre-and post production tool chains are very heavy linux these days. Most of that used to be IRIX. Win32 came through and was out the door just that quick. That crowd got the news big in the early 00's and never looked back. It being open worked huge for them. OS costs and the ability to build custom environments, sometimes for a single movie production, gets it done for them. Alias was more or less told to port, or those guys were gonna use something else besides MAYA.
I see a lot of synergies between those people and EE engineering / embedded types. Both work at a level that involves software being a part of the process, not just a tool to get there. Maybe that's why the MCAD crowd isn't so hot on Linux just yet. The simulation / bio-sciences people are in a similar boat, having to deal with software as process and not just tool.
Where that is the case, Linux has some attraction and value add factor.
Personally, the way I see it, being a part timer, Linux does not cost anything but time. So you get a nice set of tools, all you do is provide the hardware and that's pretty cheap. Lack of yearly costs and entry costs for the basics means dollars to spend on hardware goodies and their relevant tools. I really like getting new hardware goodies. I don't like paying for baseline software that gets in the way of that.
I'm gonna buy the compiler when it's done. It's way easier to do that when I've not had to spend the $500 - $1000 or so for a nice set of win32 tools to start with. I'll actually pay MORE for the Linux tools, because that reinforces the value Linux has, and that's just worth it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Post Edited (potatohead) : 3/6/2008 4:53:47 PM GMT
ImageCraft or anyone else faces stiff competition from GNU in serious Linux areas today
as it was in 1998 (just ask Wind River -- EDIT: they were providing GNU for windows then).
Since there is no GNU port for Propeller, it is unlikely it will ever achieve acceptance in high
volume product areas that depend on Linux for builds. Perhaps ImageCraft should leverage
it's know-how into a licensable port for Propeller ?
For Parallax, the stepping stone for design wins in high volume production for Propeller
(translated "Even the janitor could retire to Tahiti") is an investment by Parallax in a GNU port.
Today Linux is the serious tool for serious business in companies that don't use windoze.
In 1998 Sun SPARC workstations were the primary build farms for dev/release images.
Today, SPARC is just a remnant that made EMACS popular (meta what?) to many developers,
today all serious builds are done with Linux SMP server farms.
The question to ask of course is: "Is it possible for Propeller to get design wins in big
business that use linux for builds?" The answer of course primarily depends on whether
or not tools are available [noparse]:)[/noparse] I know for a fact that AVR gets design wins in such places,
as do 8051 cores, for line-card device configuration controllers.
There are of course Windows build server equivalents. Maybe someone cares to comment?
ADDED: How much Ramen do you need?· Put me on your list.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
Post Edited (jazzed) : 3/6/2008 5:37:57 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
There will always be examples of Big Industry and others using some particular platform ( the movie industry and top-end maths modelling, anyone seriously into DTP used to swear on Quark and Macs, and would anyone not consider Linux as a web server platform ? ), but how does that pan out to actual market shares across the embedded sector ? My ( very limited ) experience has been much the same as ImageCraft's; big demand for Linux/Mac support, minimal market when it arrives. A lot of work and effort going into something which could have been much better spent on furthering the market which actually existed.
That's not to say Linux or Mac is any less credible than Windows and often the reverse is true, nor that Linux and Mac tools shouldn't be delivered, but companies make their money from markets which exist, not those which do not. I seem to frequently hear the mantra of "GNU port <this>" presented as a universal panacea and throwing open the door to unlimited riches, and maybe it is, but I rarely see evidence which would back that up.
I'm also not saying anyone is right or wrong; that can only be judged on the evidence, not what theory or self-interest may say.
While XP reigned, I think most people were at least mollified enough by Windows to use it when they had to. But Vista has made a complete mess of things; and if XP were to disappear, Windows would lose what little attraction it had for its marginally-willing users. To me, that's what makes the platform issue particularly poignant right now. The opportunities presented by this kind of upheaval don't come along every day.
-Phil
I also enjoy building Windows applications, but that's mostly for fun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
Post Edited (jazzed) : 3/6/2008 9:21:53 PM GMT
You would need to use the LMM assembler since any assembly language would need to be loaded (COGNEW) from the LMM "interpreter" just like they currently get loaded via the Spin interpreter. The linker needs the information from the ICC assembler directives. The other thing is that really all of the I/O objects provide a Spin interface to the assembly language. With the LMM, there'll have to be an equivalent C interface to the assembly program running in the cog(s).
Keep in mind that we haven't worked out all the details on starting another COG yet. It's not rocket science, but it needs to be done. Anyway, the idea is, if you need to start another COG, there will be a function, probably called COGNEW
We will probably want to overlay a more sophisticated process/thread interface on top later, but this should get users started.
As for what objects are qualified for discount, we will definitely be generous especially in the beginning. We want momentum
Maybe get this rolling during the BETA program? Would be a great way to vet the code and get some stuff done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Yes. I was talking about the typical I/O driver that's partly in assembly and partly in Spin. ImageCraft was talking about the equivalent to starting up a cog in Spin. Since this is LMM code mostly, the tradeoffs between pure assembly and higher level code shift. Many of the objects that now require pure assembly for speed could be written directly in LMM C. Objects that also require tight timing control like video and the FullDuplexSerial driver will still have to be in pure assembler without the LMM "interpreter".
from http://forums.parallax.com/showthread.php?p=692277
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
PRI ackermann( m, n ) if m == 0 return n+1 else if n == 0 return ackermann( m-1, 1 ) else return ackermann( m-1, ackermann( m, n-1 ) )Untested algorithm from en.wikipedia.org/wiki/Ackermann_function
Now wrapping things up for at least a semblance of something beta'able...
Well, I didn't use the super-optimized version
Next time someone who suggests using fibonacci() or ackermann() for benchmarking purpose should be sentenced to writing PIC asm code for a year as a "reward."
It's often used to test compilers, not processors. The compiler shouldn't crash when compiling it, I've know some that have.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
"Next time someone who suggests using fibonacci() or ackermann() for benchmarking purpose should be sentenced to writing PIC asm code for a year as a "reward."
I spent 5 years writing PIC asm, so thats a serious "reward"you are threatening !!!.
p.s. got the email response to my request to be a beta tester.
MikeW