...we are still lacking an open source Spin/PASM compiler.
mpark...
Seriously??
OK Sorry, forgot about Sphinx. Probably because I was focused on compilers/IDEs than will run on a PC. Still we could run Sphinx under SpinSim on a PC:)
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
The slow and bloated abomination that is Eclipse should be deleted, world wide, permanently:)
Yesterday I found myself trying to install Eclipse on a Debian machine so that I could have a play with the Android SDK. No way could I get it to install.
Meanwhile at home somehow I did get Eclipse for Android installed on Debian a while back, don't remember how. BUT it does not rebuild anything, after editing some files, when you hit the build button or Control-B. Oh no, it will only rebuild when you hit RUN.
This has been a recurring theme with Eclipse ever since I first discovered it. It just does not work and when it does it's hard to see what the point is. I have yet to find out what benefits Eclipse can offer over Vim and a Makefile.
In the time it takes one to find out how to create the Eclipse plug-ins for a new language a clever guy like Andrey Demenyev can create an entire IDE from the ground up with Qt that "just works".
Sorry. I'm just miffed at Eclipse for wasting half a day of my life, again.
Ah, you have totally changed your first post again.
The goal is to eventually have a cross platform IDE written in assembly.
You do realize that this is a contradiction in terms. If it's written in assembler for one machine and OS combination it surely will not run on any other machine/OS combination.(Without the aid of an emulator of course). A quick recompile won't do it and a total rewrite is required in many cases.
Correct, there is no such thing as cross platform assembly program. There can be many separate programs that look and behave identically - but they are stlll separate programs. And now imagine all the headache with maintaining this . This is for sure a way to nowhere
Heater:
Thank you for the laugh. Yes I do realize that on the surface this is a contradiction in terms. I am writing as much as possible as OS independent code (though obviously CPU dependent), once it is functional I will also hand rewrite the entire thing for other CPUs, and thank to the magic of make and defines we have a truly cross platform IDE written in assembly. Why do I need any OS calls to parse a file that is already loaded into RAM? OS calls are being kept separate from the bulk of the code, and are only used to:
1) allocate a large buffer in mem.
2) Open, read into mem, close the config file(s).
3) Open, read into mem, close source file(s).
4) Display to the screen.
5) Create/Truncate, open, write, close compiled binaries.
6) Open, write, close the config file.
7) Open Write, close source files.
8) Read the Keyboard and mouse.
9) Communicate with the serial port (for programming the Prop).
I think that just about covers it. And most of the reads, and writes are only done once per file (unless the user requests otherwise).
Also (almost forgot), I may use the C library for file IO. This is such a small thing at this point there is no reason not to, besides I think it will make a lot of people happy.
Re what Andrey is doing, yes I agree, and I think it is relevant to this discussion.
Andrey has built a graphical IDE. Now, I have an IDE too and it is written in vb.net and it can compile C and BCX Basic programs and also can take a Youtube video and turn it into a movie that you can run on a propeller. I appreciate what it takes to write an IDE, especially the part about having really complicated code behind the scenes, but at the same time making it easy for the user. What Apple are really good at.
I also have started down the road of building a cross platform IDE. I spent two weeks researching and quite a few days coding. And at the end of all that, my conclusion is that I believe the best solution is to support what Andrey is doing.
I came to that conclusion after a very simple question to Andrey about how you integrate the GUI part of an IDE with the compiler part. The GUI part is the part the user sees - syntax highlighting, autocomplete, intelligent integration of objects and the like. The compiler bit is fully text based. It takes characters (ascii text) and turns it into other characters (a compiled program).
Andrey said that his approach is to build an IDE that shells out to text based compilers. I do the same with my IDE, and I know this works.
So - for Spin, use the command line Homespun or BST. For C, use Catalina. For BCX basic, use their command line converter. To download, use Payload. Or Xmodem etc etc.
These programs already exist, plus they are 'command line', ie old-skool, which means they run fast. You could even think about running these programs on the propeller itself. It has been done before, and indeed it is perfectly possibly to compile a C program, on the propeller using a C based compiler (BDSC running under CP/M).
The GUI bit is harder. GUI on the propeller is not simple and is limited mainly by the graphics of the prop chip. Everything is a compromise. You can go for text based blocky graphics 80x40 and that works, or pixel based but at much lower resolution 160x120, or you can go higher res but sacrifice colors.
It seems to me that it makes sense to separate the GUI from the compiler, both on a PC and on the propeller. This is Andrey's approach, and it makes it easier to split the task up between lots of people, and to use code already written.
I think a propeller based compiler might be possible. Several approaches. Try to get hold of the source for existing compilers. Reverse engineer one. Or write a 'Spin to C' translator and compile the C.
I am not so sure about a GUI running on the propeller. I suspect it would be text based rather than 'graphical', and for a start it would need to be a rudimentary word processor, like notepad. Nothing impossible there either (we have wordstar running on a prop) but even when you have a word processor, you then also need to shell out to the compiler(s).
In terms of an IDE, eventually I'd like to see the features of mine incorporated into Andrey's, and to do that I'm recoding parts of the code so that it can be translated into a 'command line' universal language, eg Qt/C/RealBasic/others. I'm putting more things into batch files for instance.
heater's point about assembly is valid. In moments of madness it makes me ponder things like an x86 to PASM translator.
I really like the suggestion about building the GUI IDE to run on the prop. I was beaten to the line!
As michael has already done both the homespun compiler (also used by Catalina) and the prop sphinx version, I would suggest we do not need any more compilers. The GUI IDE is what is really lacking and on all platforms. Brad has done a great job, but there are still lots of improvements to be made.
But to make one that runs on the prop would be fabulous and have many other applications too. Remember, the PropII will be here sometime and this will become more of a reality. Just support a VGA, PS2 Keyboard and microSD. We already have a number of hardware versions with external memory. Just be careful to allow for the dual prop processor boards (with VGA & Kbd on another prop).
An IDE for the propeller using BigSpin would be really neat. You have the advantages of a high-level language that can use external memory in the way you want. A board like Cluso's RamBlade, Bill's Morpheus, hive, DracBlade and so on can be easily setup. Text edit is not a cpu hog (sorting, search-and-replace, compile... are). You do not really need a PC... For something like an IDE... assembler may not be the fastest (time-to-market) way.
Ok it appears that my work will then focus on the Prop port, and my existing code will be used to complete the DOS port. Then we will see where we go from there.
Dr_Acula:
It has been shown that the existence of more compilers, and other development tools for a platform tends to draw more interest in the platform. As to keeping the Compilers, and assembler separate from the rest, and shell them; that is slow. There is out there some where a port of GCC for Linux that loads all the tools into memory as one app, then loads all the source files into ram, and does not touch the disk again until compiling is complete, and it is 7 times faster than the same version of GCC running in the traditional way. I should note that there no other optimizations to that GCC. Sorry I do not remember where I had found that modified GCC.
I have run into an interesting trap. In rewriting what I have so far for the Propeller host (trying to keep the DOS and Prop hosted versions in sync as these are the initial targets), I found my self wishing for a stack. In coding Compilers and assemblers I have always used the stack to allow recursion, and help assure that expressions are evaluated correctly.
Also I am beginning to look at the SPIN side, and am wondering if there would be any objection to compiling SPIN directly to Prop Asm?
I'm not sure what the problem is. Although the Prop does not have a hardware stack, it's easy enough to code one in software. The Spin bytecode interpreter, for example, uses a stack and allows recursion.
Comments
mpark...
OK Sorry, forgot about Sphinx. Probably because I was focused on compilers/IDEs than will run on a PC. Still we could run Sphinx under SpinSim on a PC:)
Yes thank you. I had already read that, earlier today. Though thank you for the comment.
The slow and bloated abomination that is Eclipse should be deleted, world wide, permanently:)
Yesterday I found myself trying to install Eclipse on a Debian machine so that I could have a play with the Android SDK. No way could I get it to install.
Meanwhile at home somehow I did get Eclipse for Android installed on Debian a while back, don't remember how. BUT it does not rebuild anything, after editing some files, when you hit the build button or Control-B. Oh no, it will only rebuild when you hit RUN.
This has been a recurring theme with Eclipse ever since I first discovered it. It just does not work and when it does it's hard to see what the point is. I have yet to find out what benefits Eclipse can offer over Vim and a Makefile.
In the time it takes one to find out how to create the Eclipse plug-ins for a new language a clever guy like Andrey Demenyev can create an entire IDE from the ground up with Qt that "just works".
Sorry. I'm just miffed at Eclipse for wasting half a day of my life, again.
Ah, you have totally changed your first post again.
You do realize that this is a contradiction in terms. If it's written in assembler for one machine and OS combination it surely will not run on any other machine/OS combination.(Without the aid of an emulator of course). A quick recompile won't do it and a total rewrite is required in many cases.
Thank you for the laugh. Yes I do realize that on the surface this is a contradiction in terms. I am writing as much as possible as OS independent code (though obviously CPU dependent), once it is functional I will also hand rewrite the entire thing for other CPUs, and thank to the magic of make and defines we have a truly cross platform IDE written in assembly. Why do I need any OS calls to parse a file that is already loaded into RAM? OS calls are being kept separate from the bulk of the code, and are only used to:
1) allocate a large buffer in mem.
2) Open, read into mem, close the config file(s).
3) Open, read into mem, close source file(s).
4) Display to the screen.
5) Create/Truncate, open, write, close compiled binaries.
6) Open, write, close the config file.
7) Open Write, close source files.
8) Read the Keyboard and mouse.
9) Communicate with the serial port (for programming the Prop).
I think that just about covers it. And most of the reads, and writes are only done once per file (unless the user requests otherwise).
Re what Andrey is doing, yes I agree, and I think it is relevant to this discussion.
Andrey has built a graphical IDE. Now, I have an IDE too and it is written in vb.net and it can compile C and BCX Basic programs and also can take a Youtube video and turn it into a movie that you can run on a propeller. I appreciate what it takes to write an IDE, especially the part about having really complicated code behind the scenes, but at the same time making it easy for the user. What Apple are really good at.
I also have started down the road of building a cross platform IDE. I spent two weeks researching and quite a few days coding. And at the end of all that, my conclusion is that I believe the best solution is to support what Andrey is doing.
I came to that conclusion after a very simple question to Andrey about how you integrate the GUI part of an IDE with the compiler part. The GUI part is the part the user sees - syntax highlighting, autocomplete, intelligent integration of objects and the like. The compiler bit is fully text based. It takes characters (ascii text) and turns it into other characters (a compiled program).
Andrey said that his approach is to build an IDE that shells out to text based compilers. I do the same with my IDE, and I know this works.
So - for Spin, use the command line Homespun or BST. For C, use Catalina. For BCX basic, use their command line converter. To download, use Payload. Or Xmodem etc etc.
These programs already exist, plus they are 'command line', ie old-skool, which means they run fast. You could even think about running these programs on the propeller itself. It has been done before, and indeed it is perfectly possibly to compile a C program, on the propeller using a C based compiler (BDSC running under CP/M).
The GUI bit is harder. GUI on the propeller is not simple and is limited mainly by the graphics of the prop chip. Everything is a compromise. You can go for text based blocky graphics 80x40 and that works, or pixel based but at much lower resolution 160x120, or you can go higher res but sacrifice colors.
It seems to me that it makes sense to separate the GUI from the compiler, both on a PC and on the propeller. This is Andrey's approach, and it makes it easier to split the task up between lots of people, and to use code already written.
I think a propeller based compiler might be possible. Several approaches. Try to get hold of the source for existing compilers. Reverse engineer one. Or write a 'Spin to C' translator and compile the C.
I am not so sure about a GUI running on the propeller. I suspect it would be text based rather than 'graphical', and for a start it would need to be a rudimentary word processor, like notepad. Nothing impossible there either (we have wordstar running on a prop) but even when you have a word processor, you then also need to shell out to the compiler(s).
In terms of an IDE, eventually I'd like to see the features of mine incorporated into Andrey's, and to do that I'm recoding parts of the code so that it can be translated into a 'command line' universal language, eg Qt/C/RealBasic/others. I'm putting more things into batch files for instance.
heater's point about assembly is valid. In moments of madness it makes me ponder things like an x86 to PASM translator.
As michael has already done both the homespun compiler (also used by Catalina) and the prop sphinx version, I would suggest we do not need any more compilers. The GUI IDE is what is really lacking and on all platforms. Brad has done a great job, but there are still lots of improvements to be made.
But to make one that runs on the prop would be fabulous and have many other applications too. Remember, the PropII will be here sometime and this will become more of a reality. Just support a VGA, PS2 Keyboard and microSD. We already have a number of hardware versions with external memory. Just be careful to allow for the dual prop processor boards (with VGA & Kbd on another prop).
my 2c
Dr_Acula:
It has been shown that the existence of more compilers, and other development tools for a platform tends to draw more interest in the platform. As to keeping the Compilers, and assembler separate from the rest, and shell them; that is slow. There is out there some where a port of GCC for Linux that loads all the tools into memory as one app, then loads all the source files into ram, and does not touch the disk again until compiling is complete, and it is 7 times faster than the same version of GCC running in the traditional way. I should note that there no other optimizations to that GCC. Sorry I do not remember where I had found that modified GCC.
Also I am beginning to look at the SPIN side, and am wondering if there would be any objection to compiling SPIN directly to Prop Asm?
-Phil