Shop OBEX P1 Docs P2 Docs Learn Events
Suggestions for a future IDE. — Parallax Forums

Suggestions for a future IDE.

davidsaundersdavidsaunders Posts: 1,559
edited 2011-03-23 11:14 in Propeller 1
The goal is to eventually have a cross platform IDE written in assembly. In response to questions already posted on this thread, as well as in the interest of being as much of an aid to the Propeller Community as I can be, on the evening of 3-22-2011 I ask in Post #19:
OK Many good points have been made. Beings that I will also be porting it to the Propeller, what Platform would more people want to see it for first? I have not written very much platform specific code yet, though it is x86 specific, so what x86 based Open Source OS that is NOT Win32, DOS, Linux, or OS X would more of you be interested in me focusing on?

I look forward to your input.
«1

Comments

  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-21 17:34
    Almost forgot. Does any one know of an open source raw fixed width font that is similar to the Propellers built in one, and released under a MIT, BSD, or PD license?
  • BradCBradC Posts: 2,601
    edited 2011-03-21 17:55
    To note: The Propeller Tool, and the Win32 version of BST do not run very well on anything other than Windows NT 5.x/6.x (2000, 2003, XP, Vista, 7).

    I test bst on Win98OSR2 and Win95SR2. The only thing that fails there is the upper unicode Propeller font characters. Early Win32 variants had some nasty hacks they called unicode support, but nothing really consistent until Win2k.

    Also, as to your comment about "most propeller users use win32 variants".. I have months of download logs to prove otherwise.

    Why would you run an IDE under WINE? Just compile it natively for Linux and OSX.
  • localrogerlocalroger Posts: 3,452
    edited 2011-03-21 18:17
    In Windows land I moved directly from WFW 3.11 to Win98 SE to XP. I am still using XP. I cannot imagine why you would want a Windows version that runs on something other than 2000+, even the worst die hards have moved to 32 bit kernal by now because XP got it right. I actually have deployed production code that doesn't run under 95/98/ME because the API serial port buffers are thread-bound. The solution is to upgrade. There were serious problems moving from 98SE to NT4.0 and 2000, but not with XP.

    As for Vista / 7, that's still ME II land as far as I'm concerned.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-21 21:55
    BradC:
    I would be happy to compile it native for multiple OSes. But to do so without using a toolkit (which is not 'Native' though an API layer [Same thing WINE is]) would require many ifdef statements surrounding large chunks of code (remember I am working in ASM). I will probably do so eventually, though that is in the future. O thank you for the note on non win platform prop dev possibly being more common than I had thought.

    Iocalroger:
    Different people have different preferences. I know many people who refuse to upgrade from MS-DOS 6.22 + Windows (WfW) 3.11 + Win32s, simply because there system has not crashed in 15+ years, though they say that newer systems are more crash prone (due to there personal experience). I personly think that as windows goes the best that there is would be 2000, though most disagree with me. So let us let each maintain there personal preference.
    I should add that I primarily use Haiku-OS, FreeDOS, and Puppy Linux for my PC Operating Systems.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-21 22:08
    BradC:
    I do very strongly agree with you that using extra API layers (like WINE, or the various cross platform toolkits) is a bad idea in general. Though as these API layers go WINE is a lot faster than most (with the exception of early versions of FLTK).
  • Heater.Heater. Posts: 21,230
    edited 2011-03-22 02:42
    davidsauders,
    Are there any suggestions?

    Oh yes, I have lot's of suggestions. I guess you are not going to like most of them so please don't take any of this personally it's just my opinions:

    1) An open source IDE, or any other tool, for the propeller is always welcome.

    2) Creating an open source tool that rests on an closed source operating system does not make any sense to me.

    3) Yes, I know there is wine. I think my statement 2) still stands. After all if it depends on wine it would be better to be written in a cross platform IDE if I'm going to use it on another OS. Wine is not available everywhere.

    4) I would not be so sure that "most propeller developers use win32 variants". It may be true to say "most" but there seems to be a lot more going on around here than that. As BradC will testify to.

    5) Writing an IDE in x86 assembler means that the thing is not in anyway cross-platform. How am I going to run it on my ARM based net-book, or my IGEP ARM board or my Android tab? I know tabs are pushing the point a bit but I'm sure soon they will be usable for such tasks. Who knows what compute devices are coming down the pipe.

    6) Writing an IDE in assembler means it's going to be much harder for anyone to add features to it.

    7) Seems that the Odin OS has not been under active development since 2007.

    8)
    I do very strongly agree with you that using extra API layers (like WINE, or the various cross platform toolkits) is a bad idea in general.

    No. Or yes. Depends on what your goals are. If you want cross-platform, both OS and CPU architecture, if you want to have long lived and widely spread software that will run on platforms you have not heard of yet then of course a cross-platform tool kit is pretty much essential.

    I could argue that things like stdio in C are a cross-platform API that ensures your console app will run on any system with any console device for the foreseeable future. Why do people have a downer on the cross-platform API when it comes to graphics and GUIs?

    I do admire your desire for small, fast, bloat free software but all in all this seems to be one of the most bizarre ideas I have come across since I decided it would be neat to create an Intel 8080 emulator for the Propeller and run CP/M 2.2 on the Prop:) (See PropAltair and ZiCog threads).

    Now, I have no doubt that you have the skill and talent to pull it off and a desire to put some neat code out into the community. But given that is the case there are far more important, useful and interesting tasks to be tackled in Propeller land. For example we are still lacking an open source Spin/PASM compiler. Sadly that is something I am not proficient enough to pull off.

    There, that was not so bad, was it? Hope not.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 06:57
    Heater:
    Thank you for your suggestions. Let me begin by saying, for me the first part of an IDE is the compiler, and the Propeller ASM compiler is going to be the first thing completed. I do agree that it is not good to be tied to one platform, All OS specific code will be isolated in its own modules, in a way that will make it simple to replace the OS calls with others (and eventually I will do so), Yes the C std lib is a cross platform API, when I program in C I avoid the STD Lib like the plague. And it will be using an absolute minimum of OS calls (It looks as if I will end up with between 15 to 20 system calls). Also the cross platform toolkits tend to be either very limiting, or better suited for one OS over another, not to mention they omit support for many platforms, that support graphics though not a GUI, or that have a GUI though do not support all the functions required by the ToolKit.

    Now as far as cross CPU; This is a good portion of the reason for going assembly, and very small, as I will take what I learn and port this project first to the Propeller (on the Demo board [at first]) and then to the 68k, thereafter I will bring it to as many CPUs as I can. I do dislike windows, My reasons for this choice of starting points are stated.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 07:39
    Heater:
    Slightly off topic; Is the ARM based system you use running RiscOS? If so this may very well be the third CPU + OS supported (after the Propeller with no OS). I have always had an affinity for the ARM as a simple RISC CPU that outperformed most CISC CPUs in the time period of its release by Acorn. And you can not find a much more eloquent OS design than RiscOS.
  • Heater.Heater. Posts: 21,230
    edited 2011-03-22 08:18
    My new toy is an ARM based board from ISEE in Spain, the IGEP v2 : http://www.igep-latform.com/index.php?option=com_content&view=article&id=46&Itemid=55 It is something of a souped up clone of the Beagle Board : http://beagleboard.org/

    Out of the box it has a minimal Linux sitting in it's on board 512MB FLASH memory. My board is currently running a version of Ubuntu (Linaro) from an 8GB SD card.

    If you are so inclined you can run Android on these things.

    A quick google for "BeagleBoard RiscOS" or "IGEP RiscOS" soon turns up the fact that, sure enough, those RiscOS enthusiasts have got RiscOS running on those boards! They are using RiscOS Open http://www.riscosopen.org

    Damn, I always wanted an "Archie" back in the late 80's, now it looks like I have to make my own. Luckily we have a few more IGEPs on order.
  • mparkmpark Posts: 1,305
    edited 2011-03-22 08:45
    Heater. wrote: »
    ...we are still lacking an open source Spin/PASM compiler.

    Seriously??
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 08:49
    Heater:
    You almost had me going, talking about an open source RiscOS. It turns out to be a non commercial only open source restrictive license.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 09:31
    As it stands, I wish to optimize the x86 variant for size to get an idea of what can be done, this will simplify porting to the Propeller as the COG mem is quite limited, and I wish to minimize the dynamic loading of code into COG mem once things get to the prop. Also I updated the top post in this thread to be more clear.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 10:55
    I may be switching directions and starting with DOS, then moving to Win32. Due to how long it has been since I had written any Win32 code, I had forgot how much work it is to set up a device dependent bitmap and draw to it in win32. Would be quicker to test my code and get things working to just use a VESA 2 LFB under DOS to get started. And yes I am aware of the bug in the DOS VM in Win XP/2003/Vista, related to VESA Graphics, that will prevent it from running native on those systems.
  • AleAle Posts: 2,363
    edited 2011-03-22 14:02
    I'd suggest using something like Python. I think it would be much more productive than anything else... maybe not as pretty as PropTool or VisualStudio... but cross.platform... even on my N810 (I got rid of the iPad!) :)
  • tonyp12tonyp12 Posts: 1,951
    edited 2011-03-22 14:25
    In the assembler include a pool of values that are expressed with a underscore.
    As the prop can only include numbers #0-511 inline.

    mov counter, _#2000 ' creates a long with the value 2000 at a address calculated by the assembler.

    The actual location is not known by user, if same value is repeated the pool only keeps it at one location.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 14:26
    If I were going to use an interpreted language, it would be some dialect of BASIC, NOT something like JS, Python, VBscript, no. Thank you for the comment though.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 14:31
    tonyp12:
    Thank you, for the suggestion. I am working on the preprocessor and I have a simple Macro expansion that could accomplish the same goal (if so used) at a little extra overhead. Would this live up to your usage?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 18:43
    OK Many good points have been made. Beings that I will also be porting it to the Propeller, what Platform would more people want to see it for first? I have not written very much platform specific code yet, though it is x86 specific, so what x86 based Open Source OS that is NOT Win32, DOS, Linux, or OS X would more of you be interested in me focusing on?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-03-22 18:59
    ...so what x86 based Open Source OS that is NOT Win32, DOS, Linux, or OS X would more of you be interested in me focusing on?
    'No Win32, DOS, Linux, or OS X? Are you actually hoping/expecting to attract any users?

    -Phil
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-03-22 19:05
    Can you explain more about the idea of porting it to the propeller?

    That is an intriguing idea. You would have to think about what language can run on both a propeller and on a windows machine. I'd be thinking of ANSI C89 as a common language for both. It is close to the metal in terms of speed, has been around long enough that it exists on many platforms and can handle text files and string processing.

    Are you planning on writing an IDE or a compiler or both?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 19:23
    Phil:
    The response I have gotten is kind of cold on Win32, There is already a stable system for Linux, and I do not like coding for Mac OS X. There are other quite popular OSes/OEs out there, such as; HaikuOS, NewOS, AROS, SymbianOS, Cube, and Minix just to name a few.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 19:32
    Dr_Acula:
    It would be written in ASM in both cases, porting it would consist of hand translating the entire code to the Propeller assembly, and then going back and optimizing it for the new target. The one thing that I believe is important is that the UI be as close to perfectly Identical on all targets as possible. I think that most would agree that differences in the UI of our IDE often slows us down when we have to switch from one to another, while developing one project.
    Dr_Acula wrote:
    Are you planning on writing an IDE or a compiler or both?
    BOTH. What is an IDE if not written as part of a complete tool chain. For me 'Integrated' says it all, when an IDE is written as an afterthought, or by some third party, it often feels like it does not belong with the tool chain (or at least that how it feels to me).
  • Kevin WoodKevin Wood Posts: 1,266
    edited 2011-03-22 19:47
    David, I think you misunderstand what people are looking for.

    Nobody is opposed to having a Propeller IDE on Win32. The biggest complaint is the lack of support (primarily Parallax support) on Linux & OS-X. You have to understand BradC's comment about download logs in the right context. His Spin Tool is the only tools that supports Windows, Mac, and Linux, so if he shows a bias towards Mac & Linux, it's because he get all of those users, whereas he only gets X percentage of Win32 users. This is because Win32 users have the Propeller Tool.

    The truth is, if Parallax is selling boatloads of Propellers, there are probably more people using them on Windows than Mac & Linux. The majority are probably just using the Propeller Tool. BST is probably used more by the more advanced or serious developer crowd.

    As far as the project you're proposing, I think you'll find that all of the "other quite popular OSes/OEs out there" really aren't all that popular compared to Win32, DOS, Linux, and OS-X. However, since it's your project, you can create it for whatever OS you want. For the most part, people here would be happy with something like an Eclipse-based IDE that ran under Windows, Linux, and OS-X, and ARM, I suppose, since it's now becoming mainstream relevant.

    All that said, what I personally think would be cool would be something akin to the Turbo Pascal for DOS IDE, that could run on all platforms. It's probably about as minimal as you'll get, and once you get used to that type of environment, it's not difficult to be productive. Maybe a package to extend Vi/VIM would be a start in that direction.

    FWIW, my vote for non-mainstream OS to be supported is OpenVMS. :)
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 19:55
    Keven:
    Thank you for your comments. Something along the lines of the Turbo Pascal/Turbo C/Turbo BASIC/ QB45 IDEs is kind of what I was thinking for the high level UI. At this point I am still working on getting the Propeller Assembler and the Preprocessor complete, which must be done before to much effort is put into the UI.

    Every One:
    Still have not been able to find a raw bitmapped Open source font that fits the bill, any suggestions were to find one. I am not an artist (not even for fonts).
  • RossHRossH Posts: 5,519
    edited 2011-03-22 19:58
    Hi David,

    I have a suggestion for you - why not take Michael Park's sphinx compiler (see http://www.sphinxcompiler.com) and create an IDE for that - one which runs on the Propeller itself?

    This would not only be a useful thing in its own right, but it would also allow you to hone your ideas about what type of IDE you could have given the limited graphical and RAM resources available on the Propeller.

    Ross.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 20:07
    RossH:
    That is the best suggestion I have yet heard. Would you be willing to help test the code? Unfortunately until I make a new order (a couple weeks before I have the money), I lost most of my resistors (to a bread board burning up), and do not have video at all right now. That happened two days ago in the middle of a test of my video code. Every thing I have for the Prop is bread boarded at this time.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-03-22 20:11
    Also is Sphinx SPIN only or SPIN +Asm?
  • RossHRossH Posts: 5,519
    edited 2011-03-22 20:14
    Would you be willing to help test the code?

    Unfortunately I doubt I would have the time. But I'm sure there are others here who would help out. Everybody's always very interested in anything that offers the possibility of self-hosted development on the Propeller.

    Ross.

    P.S. If you are going to do serious software development for the Propeller, you'd be well advised to buy at least one prefabricated prop board that you can rely on - e.g. a demo board or a C3. The reason is that otherwise you will spend a lot of time trying to track down software issues only to find that they are in fact hardware problems. Trust me on this :frown:
  • RossHRossH Posts: 5,519
    edited 2011-03-22 20:17
    David,

    From memory, Sphinx supports a reduced set of SPIN, but I think it supports the whole PASM language.

    Ross.
  • mparkmpark Posts: 1,305
    edited 2011-03-22 23:17
    Also is Sphinx SPIN only or SPIN +Asm?

    From [url]www.sphinxcompiler.com:[/url] "It can compile many complex and substantial programs, including those containing Propeller assembly language..."

    Sometimes I wonder why I bother :)
Sign In or Register to comment.