Shop OBEX P1 Docs P2 Docs Learn Events
Open-sourced Propeller Windows IDE - very possible, but helpful? - Page 3 — Parallax Forums

Open-sourced Propeller Windows IDE - very possible, but helpful?

135

Comments

  • mctriviamctrivia Posts: 3,772
    edited 2009-12-12 20:44
    Clock Loop said...
    The army of parallaxians here would take them down.
    I have never used any product that had a following like parallax does.

    Quiet literally. I see an army of prop2 ICs all over the globe in parallel attacking the sights web sight. If my web server alone has the power to shut down must web sites until there firewall blocks me what would they do from an orchestrated attack of 10s of thousands of propellers all attacking in such a way as not to trigger firewall block outs.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
  • grahamreitzgrahamreitz Posts: 56
    edited 2009-12-12 20:50
    Thanks Ken!

    This is an excellent discussion.

    Consider:

    1) What are Parallax's core competencies?

    I suspect it's the hardware and not so much the software. The fact that some of the software was written in x86 assembly is brutal and unusual in tool development on a modern OS. It's also quite an achievement by today's standards. There also seems to be a culture at Parallax that is anti-software, unless it's yours. Yea, Windows does that to the educated, informed, and burned.

    2) Share only what you need to.

    As an interested tool developer it would be good to know all of the information required to write or port a compiler/linker/assembler to the Propeller platform without having to reverse engineer anything. It's not necessary to open source your code unless it provides algorithms or methods that are difficult to document or understand. Although, having source code is a good reference to start from.

    It's fairly clear that there is a contingent of Propellerheads (myself included) that have no interest or desire to use or learn Spin. It's a great method to introduce newcomers to software development but for serious work it's less desirable due to its proprietary nature.

    3) Multicore is the future

    It's only a matter of time before your competitors start implementing them on their micros. Do it better and with more flexibility than they will offer.

    This flexibility is already implicit in the Propeller's hardware design. Go the rest of the way to make it as easy as possible for engineers to port development tools to your hardware platform or write their own.

    Respectfully,
    graham
  • James LongJames Long Posts: 1,181
    edited 2009-12-12 20:52
    Ken Gracey (Parallax) said...
    Many good points have been made and all of you are considerate to be concerned about the long-term welfare of your business, Parallax. <= how's that for open-source? We will have to become a 501(c)(3) non-profit when we're done giving everything away.

    All fun aside, one motivating fear against an open-source release is that we could enable a competitor to develop a hardware product from our code. What if a competitor used our material to make their own "Propeller", then pursuing us under patent infringement over their new "multicore" patents? That's a dirty thing to do and probably not very likely.

    On the other hand, establishing prior art is a strong reason to release since our legal policy is to defend ourselves and protect what we've engineered.

    Whatever we do today should not cause us need to work more closely with lawyers in the future. While mentioning lawyers, a company with bad intentions or patent sharks should know that we're ready to fight for what's ours, just in case they're reading. . .we all know that a "well-trained" Silicon Valley legal team could bring Parallax or similar company to its knees paying legal fees. But we'll die on our feet before we live on our knees. I really shouldn't be thinking out loud on these forums.

    I'm actually starting to think that the IP protection rage with lawyers is actually waning a bit in our USA society. It's bad for our economy, innovation and customers. Who really wants to base on product on intellectual property that was made available with an exclusion for commercial uses anyway? Bad guys do, probably in other countries. There's no stopping them, but there's also no need to help them.

    Carry on, please, freely.

    Ken Gracey
    Parallax Inc.

    Ken,

    Although you do make extremely focused and valid points, I do not think that is the main issue for me with open-source.

    So far the Propeller community has worked well to define the Propeller with a multitude of functionality. Most of this based in a IDE which is tied to Windows. I am discouraged the IDE doesn't function on Mac's, even though I do not use or own one.

    I am scared the open-source could possibly spread the "peanut butter" too thin. For example, if you end up with a vast array of IDE's (possible but not likely), where will the center focus group be? Sure many will still be here churning out great Objects from the Standard IDE, but many others may be diluting the effort with IDE's which are not inter-compatible.

    If Parallax was the size of Microchip, the issue would be moot. But the Propellers success, unfortunately, is partially due to the restrictive nature of the programming (if it hadn't been, I would have elected to use a language that I knew). If 50% of the people making objects had been using a non-compatible IDE, then only 50% of the OBEX would be useful to each user(not in real terms, just an example).

    I do understand that open-source adds some possibility to expand the success of the Propeller, but I also feel it may detract from the future success of the group effort (which is the Propeller's greatest asset, in my opinion).

    I'm not sure the Propeller is mature enough for "open-source" status.

    I personally think, it's not a bad idea, the timing is just not right.

    This is only my opinion,

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • potatoheadpotatohead Posts: 10,261
    edited 2009-12-12 21:21
    @heater: Yes, absolutely it would, and that is one of the things I like about self-hosting, regarding this discussion.

    @hippy: Understood, and agreed. My own experience here with the OBEX and sharing code to better ourselves is one where the GPL is toxic. I must highlight, given the context of my earlier contribution, the use value of the pool of GPL code and MIT, BSD, and even plain old Public Domain code is all high, and all share the property of you get more out than you put in, or it's at least possible to get more out than you put in.

    For me then, it's the intent of the pool or body of code in question. With the OBEX, I prefer the MIT because the intent is to empower people to build things they either find useful, or profitable. Nobody cares if closed derivatives are produced from the OBEX, as that is the intent. That's all good, and I see clearly where the GPL is toxic. On the other hand, that pool isn't something necessary either. One can take it or leave it and be uninhibited either way, thus the threat of closed derivatives is an empty one, and it all just works.

    Those proponents of the GPL, who do not want the threat of closed to be at issue, realize that necessary tech is a prime target of closed, and resent how it is so often used. Secondly, if open is to grow, it must do so without also feeding the closed pools of code, meaning the cost of open is to deny closed, and that's why GPL surrounds necessary tech. That pool of code is always open, and will grow unless every user denies that use value. This is as necessary as the tech is.

    The code we are discussing here isn't strictly necessary, meaning there is a strong case for MIT. For us users, particularly those active here, the intentions are clear. People just want to add value and build stuff. That may or may not always be true, and with that comes risk for Parallax. A GPL release would marginalize that risk, and be strong should that risk come to pass, leaving Parallax in greater control over the product definition, while not inhibiting truly open efforts.

    If somebody can't do that, for whatever reason, a non GPL license can be issued to that person, and that was the point of my post above as well. Being the originator of core enabling technology, Parallax is in a position where such management is necessary, if they are to manage risk, that is all.

    A MIT release is essentially a blanket statement that Parallax doesn't care who does what with that code, as once released, that is exactly the result, whether they like it or not. The difference between that and GPL is the profit motive, and the need to be open. Those two check most reasons why somebody with nefarious intent would go down this road in the first place, where the MIT does not.

    The burden then is sorting out whether or not Parallax could say that with impunity. Can they? Really?

    I'm not convinced they can right now, at this time, thus my support for the GPL... Edit: or no release at this time, or a release under binding contract, where the well aligned interests are known to strengthen both parties as a whole.

    @Ken: That's pretty funny actually!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 12/12/2009 10:55:13 PM GMT
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-12 21:40
    James Long said...
    ...where will the center focus group be? ... If 50% of the people making objects had been using a non-compatible IDE, then only 50% of the OBEX would be useful to each user.
    This is the point I tried to make earlier. The OBEX has to be the focus, and anything submitted to it has to be compatible with Parallax's official dev tools to avoid splintering. Someone may have to enforce this compatibility, too, as voluntary compliance could be an inadequate safeguard.
    ___

    It's a tiny bit ironic that Parallax now finds itself in this potential position. Year's ago, they were on the other side of the fence, when they created their own assembler for Microchip's PIC processor and completely re-invented the mnemonics (thank goodness: the official mnemonics are hideous). As a consequence, programs written using the Parallax mnemonics, although easier to read, were incompatible with Microchip's own dev tools, and Microchip seemed to hold the new mnemonics in disdain (as experienced by my early tech support experiences with them). Since then, the mnemonics live on in Tech Tools' assembler, which was purchased from Parallax; and Microchip seems, more recently, to be granting them grudging acceptance. But still, any programs appearing in Microchip's code library and app notes use their own mnemonics, and that's the way it should be.

    -Phil
  • James LongJames Long Posts: 1,181
    edited 2009-12-12 21:50
    Phil Pilgrim (PhiPi) said...
    This is the point I tried to make earlier. The OBEX has to be the focus, and anything submitted to it has to be compatible with Parallax's official dev tools to avoid splintering. Someone may have to enforce this compatibility, too, as voluntary compliance could be an inadequate safeguard.
    ___

    It's a tiny bit ironic....

    Phil,

    I did get your point, and was definitely agreeing with you.

    I will keep my fingers crossed, and hope to see an outcome that sides with success.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • Luis DigitalLuis Digital Posts: 371
    edited 2009-12-12 22:18
    What are you afraid of?

    Created languages incompatible with spin? That already exists (Basic, C, etc.).
    Indeed, many are happy with the different versions of C, even have an official section on OBEX.

    Other compilers / IDEs? That already exists.

    Create a multi-core microcontroller? There existed before Propeller. And I see no reason to be afraid at this point, because the information was released long ago.

    Gentlemen (and ladies?), new information just may help create or improve existing compilers.
  • SRLMSRLM Posts: 5,045
    edited 2009-12-12 22:21
    ClockLoop said...
    The army of parallaxians here would take them down.
    I have never used any product that had a following like parallax does.

    Sparkfun is going through a similar situation. As it appears now the "army of Sparktonians" seems to be ineffective. I sent an email on their behalf, but didn't get a reply...

    www.sparkfun.com/commerce/news.php?id=300

    Sparkfun Followup News post said...

    First off, we want to give a hearty "thank you" to all of you for your impressive display of support in the previous news post. Just as we are continually amazed by all the cool projects you guys/gals put together, we are also impressed by the amazing number of comments and the large amount of email support regarding the "cease and desist" letter we received.

    We really do appreciate the support you have all offered - it's amazing to have such a committed community base and we are honored to have you on our side. If you'd like to help us, please email sparcinfo@sparc.org explaining the reasons why you believe SparkFun and SPARC International would not be confused. Please keep in mind there are people involved on both sides, and threatening emails will not help our cause.

    To give you an update: we are at the beginning of what we assume will be a long legal battle. It is unfortunate, but this is why we have experienced legal counsel on staff. We are optimistic, but we are preparing for multiple outcomes. Our 'people' have talked to their 'people' and we just keeping doing what we do best - building, tinkering, and having fun. Nothing will change overnight and we will keep our customers and fans up-to-date as we hear it.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Powered by enthusiasm
  • cgraceycgracey Posts: 14,274
    edited 2009-12-12 22:42
    Lots of discussion here! Most of you know way more than we do about the pitfalls of various "open" schemes.

    There is really no secret ingredient to making a new Propeller IDE. It seems to me that the Propeller Tool GUI is pretty understandable, based on what you see it do. The internal compiler, written in '386 assembly, is not so blatant in its function, but Michael Parks has made a Spin version of it called Sphinx, which I think would provide a better starting path for alternate compiler development, as it's more readily understandable.

    I think the main effect that releasing the code to the Propeller Tool might have is to give people an initial sense of possibility. In the end, they would probably have to learn HOW it works, down to the bottom level, in order to make anything meaningful from it. I see this as mainly just a confidence catalyst. Might as well start from your OS of choice and study the behavior of Sphinx.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Chip Gracey
    Parallax, Inc.
  • James LongJames Long Posts: 1,181
    edited 2009-12-12 22:59
    Luis Digital said...
    What are you afraid of?

    Created languages incompatible with spin? That already exists (Basic, C, etc.).
    Indeed, many are happy with the different versions of C, even have an official section on OBEX.

    Other compilers / IDEs? That already exists.

    Create a multi-core microcontroller? There existed before Propeller. And I see no reason to be afraid at this point, because the information was released long ago.

    Gentlemen (and ladies?), new information just may help create or improve existing compilers.

    But those all comply with a set format (their own, but still a set format of a singular nature). What if someone else does a C compiler that doesn't comply with the existing one. Then you have two versions of language that do not correspond to each other. That causes confusion and frustration. Then you will have multitudes of objects for the same processor which can not be mixed to complete a task.

    This not about different compilers, this is about conformity in each system.

    For example, how many different basic compilers does the PIC have? How many share a common basis for programming? Not many (if any). That is for a company which produces millions (probably billions) of chips per year. Parallax doesn't have that kind of large production, and needs the "group" effort to facilitate the OBEX.

    If the "sauce" is diluted too much, it's not going to be very palatable, and many people will loose interest do to lack of support in their particular flavor of programming.

    The perfect example here is Parallax themselves. It is the support of "their flavor" which put them in business. The education, continuing support, and relentlessness of shoving help, down customers throats, is what makes them different than any other micro-controller company (meant to be funny, not offensive).

    We are not talking about the uber active people like Bean or Hanno who are creating different programming languages/methods. We are talking about the possibility of multitudes of IDEs which may work on the PC/Mac, and not share any similarities with any other IDE.

    I can list at least 10 different languages (basic in nature) for the PIC line. None of which are real good. Limited support at best. Sure it helps sell chips, but how does it help the end user? Another programming language that you must figure out on your own, or search for possible help to get it working. Hours upon hours on Google to attempt to find the answer you need. Not my idea of a great IDE/compiler. More diluted sauce. I know this, it is what made me a Parallax customer!

    I may be wrong. The open-source may drive the unhappy IDE person to the original IDE, and they will become another Mike Green (we could only hope), Hanno, or Rockicki.

    James L

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James L
    Partner/Designer
    Lil Brother SMT Assembly Services

    Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-12 23:59
    Compatibility is one of the reasons I've been pushing hard for preprocessor hooks in the Parallax IDE. A preprocessor can expand and manipulate the language in many interesting ways. But its output is still plain vanilla Spin, since that's what the compiler accepts. And plain vanilla Spin is what has to be the lingua franca of the OBEX.

    In this light, one possible alternative to completely open-sourcing the IDE would be to produce freeware versions of the compiler that run from the command line on the three major Intel-based platforms: Windows (done, i.e. Propellent), Linux, and OS/X. Since the compiler is written in i386 assembly, this should be as simple as adding OS-specific wrappers to it. If the compiler were widely available on these platforms, programmers would be encouraged to use it, in lieu of rolling their own and, possibly, introducing language inconsistencies.

    -Phil
  • Luis DigitalLuis Digital Posts: 371
    edited 2009-12-13 00:20
    James Long,

    With current information it is possible to create compilers compatible / incompatible.

    As Chip said:
    "There is really no secret ingredient to making a new Propeller IDE."
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-12-13 00:38
    This whole thread (and idea) was born out of comments on Adafruit's blog and soon after the PropScope thread
    on Parallax being a "closed" company in regard to Open Source.

    Personally, I don't see where releasing the IDE will make much of a difference as a whole. As Chip and others
    have said, enough material has been released to allow alternate compilers already. What it *might* do is change
    a little of the perception. (maybe).

    I'm still extremely confused when looking at the other "Open Source" microcontroller why everyone
    goes crazy over it? It does much less than the Propeller. Every other day I see some RSS feed in my
    newsreader in which someone makes it do some that we did on the Prop a year or more ago and now it's a big deal.

    I don't see Atmel releasing more data on that chip than Parallax has released on theirs. What's the difference?

    The last thing I want to see is Parallax releasing information which allows Propeller clones to be created,
    and quite frankly releasing the Propeller Tool appears to be a waste of time and resources I'd rather
    see committed to improving the current product or re-tasked to finishing the Propeller II or some other
    forward moving project.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • evanhevanh Posts: 16,240
    edited 2009-12-13 01:18
    hippy said...
    I personally hate GPL, I see it as a viral cancer, politically motivated and unreasonably restrictive. I don't see a problem with fully unrestricted licensing and others taking that, commercialising and profiting from it; it's not like access to the original is removed. Far better IMO that something useful is done with my code than it never being taken further for lack of resources or interest
    Again, you surprise me Hippy. Where is the politics? Requiring disclosure doesn't stop commercialising a product.

    As has been pointed out many times over, a commercial entity wanting to use a closed edition can still ask for a special license for their purposes. So, GPL allows the author to see who is wanting what at the very lease. This is useful if the author is operating commercially.

    That's just sensible business imho.
  • heaterheater Posts: 3,370
    edited 2009-12-13 01:26
    OBC said...
    The last thing I want to see is Parallax releasing information which allows Propeller clones to be created, and quite frankly releasing the Propeller Tool appears to be a waste of time and resources I'd rather see committed to improving the current product or e-tasked to finishing the Propeller II or some other forward moving project.

    I agree.

    To be frank.

    1) The Prop Tool IDE source is not of much use or interest. Lets face it, the world is full of open source IDE's now, Eclipse, KDevelop, etc. A lot of serious coders are quite happy with Emacs and Vi still. It's just another editor.

    2) The Prop Tool Spin compiler is not much use. Of interest as a kind of ultimate reference for Spin maybe. Which it should not be if the language is defined properly. It's x86 assembler so it's a non-portable dead end. We have at least 3 third party Spin compilers now so obviously that x86 asm code is not required.

    3) Purely selfishly on my part, I'd rather you got on with some more of your brilliantly productive work.

    So, after much consideration, I'm now with OBC. Forget this open source idea and use Parallax's resources for getting the Prop II out and whatever other brilliant product ideas you have up your sleeves, I'm feel sure you have many [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-12-13 01:48
    Hippy, please can you explain to me what is the political motivation behind the GPL? I have heard this idea many times but have never understood what it meant.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • BradCBradC Posts: 2,601
    edited 2009-12-13 01:48
    heater said...

    2) The Prop Tool Spin compiler is not much use. Of interest as a kind of ultimate reference for Spin maybe. Which it should not be if the language is defined properly. It's x86 assembler so it's a non-portable dead end. We have at least 3 third party Spin compilers now so obviously that x86 asm code is not required.

    I speak only for myself here, but it's of interest to verify some of the speculation and guesswork I've put into the bstc compiler about how I *think* the Parallax compiler works based on observing the generated bytecode.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If you always do what you always did, you always get what you always got.
  • evanhevanh Posts: 16,240
    edited 2009-12-13 01:54
    Oldbitcollector said...
    This whole thread (and idea) was born out of comments on Adafruit's blog and soon after the PropScope thread
    on Parallax being a "closed" company in regard to Open Source.
    Well, that is prolly some politics. But it's a separate issue from what license to use for open sourcing.
  • heaterheater Posts: 3,370
    edited 2009-12-13 02:21
    BradC: Thinking about, what you have done is quite weird isn't it?

    Surely most compilers are written to conform to some language standard as input without there also being the requirement to produce some uniquely correct code sequence as output.

    I mean, generally two C (say) compilers for the same processor will not produce the same code sequence as output.

    So what you have done is above and beyond the call of duty.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Beanie2kBeanie2k Posts: 83
    edited 2009-12-13 02:22
    A view from a different perch:

    I have the PropRPM, which has a serial port for programming. This means that for one PC, I have to use a USB to Serial adapter. Version 1.06 of the Proptool worked fine. I upgraded to V 1.1 and it broke. It could find the Prop OK, but couldn't download a program. What to do? Call Parallax? Well, unless they had the exact same converter I had, there would be no way they could debug. Result: I had to go back to V 1.06. Compare this to two other cases.

    1: Linux ver. 1.x (I forget the number) worked fine on an ancient 60 MHz Pentium (complete with FDIV bug) and an equally ancient proprietary CD-ROM drive which ran off the sound card. Upgraded to ver. 1.(x+1) and the CD-ROM quit working. Looking at the driver source, I found they had turned off the port autoconfig, and the default values were wrong. Putting in the correct values and recompiling on the old version solved the problem.

    2: An open source binary file viewer/editor named Biew. Ran well on one PC, but had major video problems on another. Downloaded the source and set about debugging. Turns out the author assumed that the video card preserved register values across two BIOS calls. Wrong. Added a couple lines of code to properly restuff the registers and voila! It worked perfectly.

    If I had the source to v. 1.1 of the Proptool, I might have been able to get it to work with the USB-Serial converter.
  • BradCBradC Posts: 2,601
    edited 2009-12-13 03:19
    Beanie2k said...

    If I had the source to v. 1.1 of the Proptool, I might have been able to get it to work with the USB-Serial converter.

    Except that not having access to the commercial components Parallax has used in building the IDE, you would not have been able to build it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If you always do what you always did, you always get what you always got.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-13 03:56
    I have thought long about my reply...

    What are some of the possibilities...
    • A lot more products being created for the prop because the code will provide the bits necessary for faster development and for additions where there are shortcomings.
    • Brad & Michael would not have had to spend (waste)·so much time testing their compilers to be exactly object compatible. What other features could we have now??? Brad's runs on windoze, *nix and mac.
    • Both these compilers have extensions (#ifdef). As heater has said, we could not have come so far with ZiCog and the various hardware platforms without this.
    • Hanno could add other features to his commercial products. Compiling code is one possibility. I suspect Hanno may already have access and this is a good thing. Better commercial products.
    • Other languages can be written more easily - PropBasic, etc. Certainly easier for other languages if you have access to the compiler code.
    • Maybe spin on competing hardware (micro)? Exposes spin to perhaps become a mainstream language?
    • Parallax can concentrate on other things, namely Prop II tongue.gif
    What is required...
    • OBEX: A new section for non-PropTool code. Why? So that we can use the extensions (#ifdef) without confusing the beginners. We already have a 'C' section and they cannot be compiled with PropTool!

    I like MIT and I suspect so do Chip and Ken. I think GPL has too many restrictions.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-13 04:12
    heater said...
    2) The Prop Tool Spin compiler is not much use. ... It's x86 assembler so it's a non-portable dead end.
    That statement puzzles me. 99% of the hardware that users run programs on is Intel x86-compatible, whether it be under Windows, Linux, OS/X, or whatever. Unless Chip is making a lot of calls to the Window API, the compiler (basically just a file reader/writer and text processor) ought to be pretty much OS-agnostic and, thus, easy to port to another OS. I would much rather see this happen, as a common, compatible kernel for the efforts of others, than to see this core piece of software reinvented many times over, with unkowable consequences.

    -Phil
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-13 04:19
    Cluso99 said...
    What is required... OBEX: A new section for non-PropTool code. Why? So that we can use the extensions (#ifdef) without confusing the beginners. We already have a 'C' section and they cannot be compiled with PropTool!
    I strongly disagree. That's a slippery slope which will lead, ultimately, to the fragmentation of software development for the Prop, with a jumble of incompatible objects. Anything that's written using conditional compilation, macros, or other preprocessing can be translated into plain vanilla Spin, which (aside from C, perhaps) must remain the common (and only) language for the OBEX. I would rather see Chip and Jeff add support for these features direclty, so that programs that use them can be included. Beyond that, though, it's not in Parallax's interest to have the Tower of Babble parked in their OBEX server.

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-13 04:28
    Phil: Parallax have stated they do not intend to add features to the PropTool.

    The #ifdef has become fundamental to code I am writing. (I haven't put anything into the OBEX - note to self, bad boy!)

    However, it is my firm belief that extensions are required and if it means nothing can be placed in the OBEX, then that is to the detriment of Parallax and the rest of us.
    So, I restate, another section for non-compliant PropTool code is required.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • BradCBradC Posts: 2,601
    edited 2009-12-13 04:31
    Phil Pilgrim (PhiPi) said... That statement puzzles me. 99% of the hardware that users run programs on is Intel x86-compatible

    Phil, that's just like saying "Oh well, 99% of computer users use Windows, so we'll only target that". You have just locked out the not-insignificant portion of users that still use PPC Macs, not to mention the ARM based products that are starting to appear.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If you always do what you always did, you always get what you always got.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-13 04:39
    Cluso99 said...
    Parallax have stated they do not intend to add features to the PropTool.
    When did they say that? I've been under the impression that there is a to-do list, but that stack items keep getting pushed on top of it. But even if what you state were true, that doesn't mean that a groundswell of demand can't change their mind.

    But let's say that it is true, and the language remains frozen — a deplorable state, to be sure. What would be wrong with using your preprocessor to produce a default version for the OBEX that the standard compiler can compile, along with comments for those who need to edit in other options?

    -Phil
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-13 04:41
    BradC said...
    You have just locked out the not-insignificant portion of users that still use PPC Macs...
    I have a PPC Mac that I use every day. But I recognize that it's quickly becoming a dinosaur, so it would be disingenuous of me to demand support for it.

    -Phil
  • evanhevanh Posts: 16,240
    edited 2009-12-13 04:45
    The assembly being common or not it not that important. AMD64 is quite a new beast so one could say x86 is on the way out.
  • evanhevanh Posts: 16,240
    edited 2009-12-13 04:49
    Cluso99 said...
    I think GPL has too many restrictions.
    For example?

    It seems to always come back to just one point - Requiring disclosure. Doesn't seems like lots of restrictions to me.
Sign In or Register to comment.