The Java Virtual Machine has a very large footprint and is also very slow. I think Java would make even SPIN look lightening fast by comparison. Overall Java it is not generally a good fit for a microcontroller - especially one with very limited RAM.
I think convincing Michael Park to open up Homespun would be the best way forward. I use Homespun a lot, and I find it extremely robust - so how bad can the internals be? Mind you, just ask Jazzed about the internals of Catalina - even I look at it sometimes and go yecch! But sometimes you just have to put it out there - warts and all.
I think some of the compiler can be gleaned from Sphinx as mpark has the makings of a compiler in there. I am looking at antlr to write the parser. Take a look at eclipse.org for the ide. There is a toolkit available for integrating domain specific languages (DSL) into eclipse. I use eclipse a lot in my real work so would love to have a spin perspective in it as well.
I really don't find java that slow on a modern machine. I agree the footprint can get large if abused, but I could say the same of any framework on windows. I am not talking of running java on the propeller - just a portable very powerful ide. You get a lot more than a syntax editor in eclipse - it was developed to be a workbench for exactly this type of work.
Brainstorming here in a random sort of way, but if you had access to the internals of a compiler you could think about hybridising C and Spin. Why? Well, it might be a way to incorporate all the Obex code into C programs. You could get the best of both worlds - huge programs in C coupled with libraries of code already written.
I'm still a bit unclear as what you get though if you can see the source code of, say, homespun or BST. Do you get a list of all the variables and where they are stored? Could you modify the order in which PUBs appear, and hence automatically group DAT segments together? Would it be enough to create standalone PUB functions that could be stored in external memory and ported to hub memory as required? Is there enough information to glue together the variables in some C and Spin code?
The Java Virtual Machine has a very large footprint and is also very slow. I think Java would make even SPIN look lightening fast by comparison. Overall Java it is not generally a good fit for a microcontroller - especially one with very limited RAM.
Propeller JVM (Javelin version of Java 1.1) performance is fine. Spin is about 2.5x faster .
I'm still a bit unclear as what you get though if you can see the source code of, say, homespun or BST.
Among other things it means the community can do enhancements or bug fixes even if the author loses interest or is for some reason permanently unavailable.
I would think that with 32MB of ram and an sdcard, one could develop a pretty good ide. It could be pretty fast also since it doesn't have to go through an operating system that has a lot of baggage. What is needed is a good editor, a fast/portable way to get files to/from pc and internet(OBEX, forum). I believe that Dr Acula already has a means to get files via Xmodem, but at what speed?
The ide just ha to be faster than we think in spin or pasm, which for me isn't that fast.
I had another idea. How about using the Zipit Z2 as the bais for an open development platform for the prop. It already has gcc, gforth, python, tcl, etc available for porting. It has built in wifi screen, and keyboard. You could use it as a portable dev platform when on the go, or telnet to it when at a real keyboard & screen.
Plus, they are REALLY afordable right now on ebay.
I'm hoping that with a bit of arm twisting (pun intended) BradC will cross compile a version of BSTC and BSTL that will run on the ARM architecture. We have discussed this before.
I have to apply some pressure soon as I now have a 1GHz credit card sized ARM board with WIFI, Ethernet, SD card etc that will run dev kits easily. Only $150
Hey, but I forgot HomeSpun is Java. I wonder how well Java works on the Zipit.
I would think that with 32MB of ram and an sdcard, one could develop a pretty good ide. It could be pretty fast also since it doesn't have to go through an operating system that has a lot of baggage. What is needed is a good editor, a fast/portable way to get files to/from pc and internet(OBEX, forum). I believe that Dr Acula already has a means to get files via Xmodem, but at what speed?
The ide just ha to be faster than we think in spin or pasm, which for me isn't that fast.
It's going to be difficult to get a 32MB Propeller solution running that is faster than SPIN. The problem is that the stack alone could exceed available Propeller memory.
I'm working with ZOG to get video and other features working for 32MB SDRAM that would enable GUI/IDE programs. Progress is slowed a bit just now because of new hardware testing.
If you have ideas about using C/C++ to make GUIs with Propeller video constraints I would like to hear about them. For SDRAM right now only TV is available. I'm developing another product that allows using a second Propeller for VGA - not as cheap as TV which uses one Propeller.
I use David Hein's Spinix to transfer programs from my PC to the SDCARD using Ymodem. It's not very fast, but it works. At some point I plan to use Nick's Ethernet module to tftpboot programs.
Do you have internal dimensions for the Zipit PCB mounting?
If you want to discuss this more, you can PM me or start a new thread.
The great advantage of the Dracblade is the solitary Prop, but at the expense of about 50% speed (assuming text based screens). I too am thinking that the two props are better than fudging other chips to help the lack of Port B.
I believe that Dr Acula already has a means to get files via Xmodem, but at what speed?
I just updated the speed from 38k to 115k. So the same speed as a download to eeprom. I'm using this for 'Big C' programs as well as copying things like movies. Xmodem on the propeller is part of KyeDOS. I'm finding that if a file is less than about 60k it is quicker to use xmodem and if larger than 60k, quicker to take out the sd card and pop it into the PC and copy it via windows.
What is needed is a good editor, a fast/portable way to get files to/from pc and internet(OBEX, forum).
Because it appears that the core of such a program depends on secret code, I would not be sure how to progress this for Spin.
On the other hand, I've made a lot of progress in the last week doing just this for Catalina. An IDE with fancy things like auto indenting and color highlighting of code, (very soon to be) integration with PASM blobs of code that can be loaded and reloaded many times, fast file transfers using both xmodem or RossH's Catalyst/Payload, and the beginnings of a color graphical GUI on the propeller.
The more I write code the more I am convinced this is entirely possible in C.
Theoretically, I think it is possible in Spin as well, but it would need access to the source code of the Spin compiler. And possibly some idea how the Spin interpreter works if you want to integrate external memory into Spin.
I think the ZipIt2 would be a great open source platform. It is easy to add a serial port (its been hacked) to talk to the prop. Then we could compile on it, download the code to the prop, and then use the ZipIt2 as a color terminal which also has WiFi and mini/microSD. What better, cheap and portable open system could you ask for???
I am correct in that we have the open source of the Sphinx compiler ??? If so, surely someone can convert it to run on the ZipIt2.
Sphinx is a good call - I like how it also demonstrates the unique features of the prop, too.
I didn't know that Propellent was heartless. I would hope the files compile to propellent.dll & propellent.exe, but I'm no expert. As I imagine it (and I'm probably wrong, so please correct me);
The Propeller Tool is a frontend for Propellent
Propellent tokenizes spin code
uploads it to the Prop
Spin byte code interpreter runs the code
Poking around the Propellent source, I see code for serial port com. I've also seen spin interpreter assembly floating around the forums (although it's not OSS), but that's part of the Propeller rom, right? Is the Propellent source missing the 'tokenizer'?
I think folks want a little OSS IDE for the Prop - Spin is pretty important because it's the main propeller language. They would also like something that works on Mac / Linux reasonably well. BST is there, but it's not OSS. I haven't tried homespun, though.
If the last 4 years pontification about compilers and IDE's had been directed into the keyboard to produce code, you'd have a MS Visual Studio clone by now. It can't be that hard, surely?
Brainstorming here in a random sort of way, but if you had access to the internals of a compiler you could think about hybridising C and Spin. Why? Well, it might be a way to incorporate all the Obex code into C programs. You could get the best of both worlds - huge programs in C coupled with libraries of code already written.
Ugh! No thanks!
But if you do want to pursue this idea, I believe Parallax is already working on something similar - they called it "Propeller Micro C" - I haven't heard anything about it for a while, but the details are here.
I'm still a bit unclear as what you get though if you can see the source code of, say, homespun or BST. Do you get a list of all the variables and where they are stored? Could you modify the order in which PUBs appear, and hence automatically group DAT segments together? Would it be enough to create standalone PUB functions that could be stored in external memory and ported to hub memory as required? Is there enough information to glue together the variables in some C and Spin code?
I think it is more in the nature of a philosophical objection - some people just want to see a 100% open source solution.
When you mention compile1 & compile2, those are the files that went into 'pbcom.obj' - the bytecode-izer, right?
'Sounds like it could be right, but I really don't know what they got assembled into. I've only heard Chip mention that the compiler was written in x86 assembly. I'm just inferring from the Propellent source that compile1 and compile2 are the compiler's two passes. But they don't seem to be represented anywhere in the so-called "open source" distribution in source form.
Propeller JVM (Javelin version of Java 1.1) performance is fine. Spin is about 2.5x faster .
.
Aha! I knew there was one, but couldn't find the link - thanks. 2.5 times slower than SPIN is better than I would have expected - but you are probably going to run out of RAM space before you could support a development IDE on the Prop itself. Any plans for an XMM version? Also, any idea how the code density of JVM compares to SPIN? SPIN is actually pretty decent in that respect.
If the last 4 years pontification about compilers and IDE's had been directed into the keyboard to produce code, you'd have a MS Visual Studio clone by now. It can't be that hard, surely?
Coding it is not the difficult bit. Agreeing on what to code is
'Sounds like it could be right, but I really don't know what they got assembled into. I've only heard Chip mention that the compiler was written in x86 assembly. I'm just inferring from the Propellent source that compile1 and compile2 are the compiler's two passes. But they don't seem to be represented anywhere in the so-called "open source" distribution in source form.
The binary blob in the source tree is the compiler.
If anyone has a basic understanding of x86 assembly they should really disassemble the binary blob and have a look around. When I was chasing some issues I had with the floating point lsb I spent a lot of time inside propellent with a disassembler, then Chip sent me his fp rounding code with comments which I used to verify my assumptions based on the dissasembly. I can tell you right now that the assembler code is a work of art and so clean it's practically self documenting.
If you built a very basic Delphi wrapper using the example code and then stepped through the assembler with a debugger as it's running it's almost as good as reading a clean high level language source tree and allows a good understanding of precisely why the compiler does what it does.
But if you do want to pursue this idea, I believe Parallax is already working on something similar - they called it "Propeller Micro C" - I haven't heard anything about it for a while, but the details are here.
Yes, silly idea. I won't pursue that one. Thanks for the link - interesting reading. I suspect that catalina has already solved the problem anyway.
I think it is more in the nature of a philosophical objection - some people just want to see a 100% open source solution.
Hmm - once people start talking about disassemblers...
I'm starting to think that maybe catalina is the most open source solution?
Any plans for an XMM version? Also, any idea how the code density of JVM compares to SPIN? SPIN is actually pretty decent in that respect.
I've mused over an XMM version some. That's the only way a Java6 JVM could be done and maintain value. The problem is once you start using XMM for stack space performance goes in the toilet. That's ZOG's curse. Catalina might be a little faster with stack in XMM. Java and Spin are just about tied for code size as I remember. The actual JVM code is much bigger than the Spin VM.
Hmm - once people start talking about disassemblers...
Did you ever take something apart as a kid just to find out how it works? Same deal. There is no mystery surrounding object code, it's just a very low level representation of what the program is doing. No different than pulling down an engine to look at how the cam timing is achieved.
The Parallax compiler occasionally generates FP results that are off by 1lsb. The disassembler and debugger told me why, and when I asked Chip about how he generated the constants that are in there it became obvious the assembler was generating constants that were slightly off (~1/2 lsb) which was enough to cause rounding errors in some corner cases. Would never have known if I'd just looked at the black box and gone "oh well, I'm not allowed to look under the hood so I'll just let it be".
When you say "decompiled", are you saying that you disassembled it? That would just get you assembly language, which would not be the ideal language for development. Or are you somehow able to magically decompile it to a high level with comments?
Part of the problem with open source is the language that would be used. It seems like there are at least four or five preferences for the language. I am happy to work with the Prop Tool and BST without fiddling around with the source. Of course, it would be really nice to get a few bug fixes and add a macro pre-processor.
Decompiled is the correct terminology when dealing with .NET.
When you write a program in C# or VB etc it gets compiled into CIL (refer to MS or wikipedia for detailed info).
Now a weakness in .NET is that anything compiled to CIL can be 'decompiled' back into actual source code i.e. C# or VB. etc, says a lot about code security and that;s why there are a plethora of tools that obfuscate compiled .NET assembly's in the market.
Btw the recompiled EXE does not operate correctly which I assumed would be the case as some manual touching up is required even though VS did build it without errors, it was just a quick play.
I'm starting to think that maybe catalina is the most open source solution?
I support Catalina (and all the other alternate languages for the Prop), but most will probably agree that Spin is the de facto propeller language. Having no open source PC-based Spin compiler is problematic.
The Parallax compiler occasionally generates FP results that are off by 1lsb. The disassembler and debugger told me why, and when I asked Chip about how he generated the constants that are in there it became obvious the assembler was generating constants that were slightly off (~1/2 lsb) which was enough to cause rounding errors in some corner cases. Would never have known if I'd just looked at the black box and gone "oh well, I'm not allowed to look under the hood so I'll just let it be".
Brad, would you be willing to share your PropTool-compatible FP conversion algorithm? Either real or pseudo-code. I'd be interested to see what it would take to get Homespun in line. Please start a new thread if you decide to share.
Comments
I think convincing Michael Park to open up Homespun would be the best way forward. I use Homespun a lot, and I find it extremely robust - so how bad can the internals be? Mind you, just ask Jazzed about the internals of Catalina - even I look at it sometimes and go yecch! But sometimes you just have to put it out there - warts and all.
Ross.
Ross.
Brainstorming here in a random sort of way, but if you had access to the internals of a compiler you could think about hybridising C and Spin. Why? Well, it might be a way to incorporate all the Obex code into C programs. You could get the best of both worlds - huge programs in C coupled with libraries of code already written.
I'm still a bit unclear as what you get though if you can see the source code of, say, homespun or BST. Do you get a list of all the variables and where they are stored? Could you modify the order in which PUBs appear, and hence automatically group DAT segments together? Would it be enough to create standalone PUB functions that could be stored in external memory and ported to hub memory as required? Is there enough information to glue together the variables in some C and Spin code?
Among other things it means the community can do enhancements or bug fixes even if the author loses interest or is for some reason permanently unavailable.
The ide just ha to be faster than we think in spin or pasm, which for me isn't that fast.
Plus, they are REALLY afordable right now on ebay.
Yep that's more like it.
I'm hoping that with a bit of arm twisting (pun intended) BradC will cross compile a version of BSTC and BSTL that will run on the ARM architecture. We have discussed this before.
I have to apply some pressure soon as I now have a 1GHz credit card sized ARM board with WIFI, Ethernet, SD card etc that will run dev kits easily. Only $150
Hey, but I forgot HomeSpun is Java. I wonder how well Java works on the Zipit.
It's going to be difficult to get a 32MB Propeller solution running that is faster than SPIN. The problem is that the stack alone could exceed available Propeller memory.
I'm working with ZOG to get video and other features working for 32MB SDRAM that would enable GUI/IDE programs. Progress is slowed a bit just now because of new hardware testing.
If you have ideas about using C/C++ to make GUIs with Propeller video constraints I would like to hear about them. For SDRAM right now only TV is available. I'm developing another product that allows using a second Propeller for VGA - not as cheap as TV which uses one Propeller.
I use David Hein's Spinix to transfer programs from my PC to the SDCARD using Ymodem. It's not very fast, but it works. At some point I plan to use Nick's Ethernet module to tftpboot programs.
Do you have internal dimensions for the Zipit PCB mounting?
If you want to discuss this more, you can PM me or start a new thread.
I just updated the speed from 38k to 115k. So the same speed as a download to eeprom. I'm using this for 'Big C' programs as well as copying things like movies. Xmodem on the propeller is part of KyeDOS. I'm finding that if a file is less than about 60k it is quicker to use xmodem and if larger than 60k, quicker to take out the sd card and pop it into the PC and copy it via windows.
Because it appears that the core of such a program depends on secret code, I would not be sure how to progress this for Spin.
On the other hand, I've made a lot of progress in the last week doing just this for Catalina. An IDE with fancy things like auto indenting and color highlighting of code, (very soon to be) integration with PASM blobs of code that can be loaded and reloaded many times, fast file transfers using both xmodem or RossH's Catalyst/Payload, and the beginnings of a color graphical GUI on the propeller.
The more I write code the more I am convinced this is entirely possible in C.
Theoretically, I think it is possible in Spin as well, but it would need access to the source code of the Spin compiler. And possibly some idea how the Spin interpreter works if you want to integrate external memory into Spin.
I think the ZipIt2 would be a great open source platform. It is easy to add a serial port (its been hacked) to talk to the prop. Then we could compile on it, download the code to the prop, and then use the ZipIt2 as a color terminal which also has WiFi and mini/microSD. What better, cheap and portable open system could you ask for???
I am correct in that we have the open source of the Sphinx compiler ??? If so, surely someone can convert it to run on the ZipIt2.
Sphinx is a good call - I like how it also demonstrates the unique features of the prop, too.
I didn't know that Propellent was heartless. I would hope the files compile to propellent.dll & propellent.exe, but I'm no expert. As I imagine it (and I'm probably wrong, so please correct me);
- The Propeller Tool is a frontend for Propellent
- Propellent tokenizes spin code
- uploads it to the Prop
- Spin byte code interpreter runs the code
Poking around the Propellent source, I see code for serial port com. I've also seen spin interpreter assembly floating around the forums (although it's not OSS), but that's part of the Propeller rom, right? Is the Propellent source missing the 'tokenizer'?I think folks want a little OSS IDE for the Prop - Spin is pretty important because it's the main propeller language. They would also like something that works on Mac / Linux reasonably well. BST is there, but it's not OSS. I haven't tried homespun, though.
-Phil
If the last 4 years pontification about compilers and IDE's had been directed into the keyboard to produce code, you'd have a MS Visual Studio clone by now. It can't be that hard, surely?
@phil - got it. Compile1 & compile2, are the files that went into 'pbcom.obj' - the bytecode-izer. (david already pointed this out).
Humm...
Ugh! No thanks!
But if you do want to pursue this idea, I believe Parallax is already working on something similar - they called it "Propeller Micro C" - I haven't heard anything about it for a while, but the details are here.
I think it is more in the nature of a philosophical objection - some people just want to see a 100% open source solution.
Ross.
-Phil
Aha! I knew there was one, but couldn't find the link - thanks. 2.5 times slower than SPIN is better than I would have expected - but you are probably going to run out of RAM space before you could support a development IDE on the Prop itself. Any plans for an XMM version? Also, any idea how the code density of JVM compares to SPIN? SPIN is actually pretty decent in that respect.
Ross.
Coding it is not the difficult bit. Agreeing on what to code is
Ross.
The binary blob in the source tree is the compiler.
If anyone has a basic understanding of x86 assembly they should really disassemble the binary blob and have a look around. When I was chasing some issues I had with the floating point lsb I spent a lot of time inside propellent with a disassembler, then Chip sent me his fp rounding code with comments which I used to verify my assumptions based on the dissasembly. I can tell you right now that the assembler code is a work of art and so clean it's practically self documenting.
If you built a very basic Delphi wrapper using the example code and then stepped through the assembler with a debugger as it's running it's almost as good as reading a clean high level language source tree and allows a good understanding of precisely why the compiler does what it does.
Yes, silly idea. I won't pursue that one. Thanks for the link - interesting reading. I suspect that catalina has already solved the problem anyway.
Hmm - once people start talking about disassemblers...
I'm starting to think that maybe catalina is the most open source solution?
Did you ever take something apart as a kid just to find out how it works? Same deal. There is no mystery surrounding object code, it's just a very low level representation of what the program is doing. No different than pulling down an engine to look at how the cam timing is achieved.
The Parallax compiler occasionally generates FP results that are off by 1lsb. The disassembler and debugger told me why, and when I asked Chip about how he generated the constants that are in there it became obvious the assembler was generating constants that were slightly off (~1/2 lsb) which was enough to cause rounding errors in some corner cases. Would never have known if I'd just looked at the black box and gone "oh well, I'm not allowed to look under the hood so I'll just let it be".
I have not however tried to compile anything with it but reversed engineered it to see if it could be done perhaps someone will give it a test run:)
BTW mpark the code looks OK to me.
Cheers
When you say "decompiled", are you saying that you disassembled it? That would just get you assembly language, which would not be the ideal language for development. Or are you somehow able to magically decompile it to a high level with comments?
Part of the problem with open source is the language that would be used. It seems like there are at least four or five preferences for the language. I am happy to work with the Prop Tool and BST without fiddling around with the source. Of course, it would be really nice to get a few bug fixes and add a macro pre-processor.
Dave
Decompiled is the correct terminology when dealing with .NET.
When you write a program in C# or VB etc it gets compiled into CIL (refer to MS or wikipedia for detailed info).
Now a weakness in .NET is that anything compiled to CIL can be 'decompiled' back into actual source code i.e. C# or VB. etc, says a lot about code security and that;s why there are a plethora of tools that obfuscate compiled .NET assembly's in the market.
Btw the recompiled EXE does not operate correctly which I assumed would be the case as some manual touching up is required even though VS did build it without errors, it was just a quick play.
Cheers
I support Catalina (and all the other alternate languages for the Prop), but most will probably agree that Spin is the de facto propeller language. Having no open source PC-based Spin compiler is problematic.
Brad, would you be willing to share your PropTool-compatible FP conversion algorithm? Either real or pseudo-code. I'd be interested to see what it would take to get Homespun in line. Please start a new thread if you decide to share.