I hate to suggest this but one possible "solution" would be to install VirtualPC and a Linux distro and build under Linux. You can even still use Windows as your Propeller development environment since Eric recently added a way to build Windows binaries under Linux. The build is a lot faster under Linux and probably also won't have these problems you're encountering. In fact, you might decide you like Linux so much you'll abandon Windows! :-)
I have no problem using Linux because I'm quite familiar with it. Used it for years when I did Java development.
But maybe it is faster if Steve could upload his default branch build, so that I can test this weekend ;-)
If Steve has no time I will definitely consider installing Linux :-)
Thanks David for the suggestion!
Thanks very much! I will test if XMM is working today evening.
Did you do something special to get the branch built on windows? I have problems using make.
Wooooooooohooooooooooooo! It works, I have XMMC with sqi SRAM working :-) Never thought that I could be so happy ;-)
So there is definitely an issue when using the rebuild.sh script instead of make. If I don't get make to work on windows I will use Linux for development.
@Steve: Could you post how u built the sources? Because I have no luck with make.
Wooooooooohooooooooooooo! It works, I have XMMC with sqi SRAM working :-) Never thought that I could be so happy ;-)
So there is definitely an issue when using the rebuild.sh script instead of make. If I don't get make to work on windows I will use Linux for development.
@Steve: Could you post how u built the sources? Because I have no luck with make.
Christian
Could you try xmm-single to see if that works for you? I'm having trouble getting ebasic3 working in xmm-single mode but I haven't been able to find the bug in the XMM kernel that might cause this problem.
Could you try xmm-single to see if that works for you? I'm having trouble getting ebasic3 working in xmm-single mode but I haven't been able to find the bug in the XMM kernel that might cause this problem.
Thanks,
David
Hi David,
XMM-Single is working for me. I will solder the flash ram onto my board today evening and try XMM split also.
Thanks very much! I will test if XMM is working today evening.
Did you do something special to get the branch built on windows? I have problems using make.
Christian
I built it on Linux. The windows build really needs to be fixed. The linux build generally takes less time though.
Could you try xmm-single to see if that works for you? I'm having trouble getting ebasic3 working in xmm-single mode but I haven't been able to find the bug in the XMM kernel that might cause this problem.
Thanks,
David
Hi David,
XMM-Split does also work. Filling an array with 1024 int values takes 3,6 us in XMM-Split.
XMM-Split does also work. Filling an array with 1024 int values takes 3,6 us in XMM-Split.
Christian
Thanks for testing xmm-single. I wonder why it doesn't work with ebasic3? I can't see anything wrong with the XMM kernel code. I must be missing something somewhere I guess.
XMM-Split does also work. Filling an array with 1024 int values takes 3,6 us in XMM-Split.
Christian
I just noticed you said xmm-split not xmm-single. That shouldn't work with only an SRAM for external memory. It's designed for a system that has both flash and RAM. The code runs from flash and the data is placed in RAM. Did you mean "xmm-single"?
I just noticed you said xmm-split not xmm-single. That shouldn't work with only an SRAM for external memory. It's designed for a system that has both flash and RAM. The code runs from flash and the data is placed in RAM. Did you mean "xmm-single"?
Hi David,
I tested XMM-single, which worked and XMM-split (My own board has sram and flash. I have just soldered the flash ram to the board after sram test was successfull. So both ram work :-))
I tested XMM-single, which worked and XMM-split (My own board has sram and flash. I have just soldered the flash ram to the board after sram test was successfull. So both ram work :-))
Okay thanks. I didn't know you had a flash chip as well. Which driver are you using for both? sqi_flash_sram_xmem?
Yes, this is the driver I am using. Works absolutely well and even the xmm-split performance is good enough for my needs. I need a bigger RAM because I have to buffer DMD characters, numbers and so on.
Yes, this is the driver I am using. Works absolutely well and even the xmm-split performance is good enough for my needs. I need a bigger RAM because I have to buffer DMD characters, numbers and so on.
Great! I'm glad things are working well for you. Thanks for reporting the XMM problems!
FYI, I figured out why ebasic3 isn't working in xmm-single mode. The problem is that I'm missing HUB declarations to force certain variables into hub memory so they can be accessed by the PASM VM running in a separate COG. I'm not going to bother fixing this because I would probably never want to run ebasic3 in xmm-single or xmm-split mode anyway. It was designed for CMM or xmmc. However, ebasic2 seems to work just fine in xmm-single mode. I'm posting this to let you know that I don't think my problem with ebasic3 has anything to do with a bug in the xmm-single support in propgcc.
FYI, I figured out why ebasic3 isn't working in xmm-single mode. The problem is that I'm missing HUB declarations to force certain variables into hub memory so they can be accessed by the PASM VM running in a separate COG. I'm not going to bother fixing this because I would probably never want to run ebasic3 in xmm-single or xmm-split mode anyway. It was designed for CMM or xmmc. However, ebasic2 seems to work just fine in xmm-single mode. I'm posting this to let you know that I don't think my problem with ebasic3 has anything to do with a bug in the xmm-single support in propgcc.
I have a question with regards to start a new cog in the default branch. Is it by default, that the cog runs in xmm mode, when xmm is set when compiling the sources or do I have to use another function to do that?
Is there also a way to start a new cog in LMM mode?
I have a question with regards to start a new cog in the default branch. Is it by default, that the cog runs in xmm mode, when xmm is set when compiling the sources or do I have to use another function to do that?
Is there also a way to start a new cog in LMM mode?
Thanks,
Christian
I'm not sure. We may have to wait for Eric to answer that. I only did the new xmem driver support. Eric added the multiple XMM COG support. Sorry.
No problem, maybe Eric reads this and answers. Would be good if LMM cogs are still available.
Actually, now that I think of it, I don't think there is any way to have two different memory models in the same program. The problem is that you'd have to have two copies of any library functions you used.
Actually, now that I think of it, I don't think there is any way to have two different memory models in the same program. The problem is that you'd have to have two copies of any library functions you used.
It is possible to run LMM code from an XMM memory model of course. Just tag the function as HUBTEXT. Not sure if that applies to cogs other than the main one though.
It is possible to run LMM code from an XMM memory model of course. Just tag the function as HUBTEXT. Not sure if that applies to cogs other than the main one though.
I don't think this is true. Just because it is in hub memory does not mean it is LMM code. There is no LMM kernel in an XMM program to load into another COG. You can, of course, run XMM code that happens to be running a function that is in hub memory. Maybe that would be adequate? Again, you'd have to be sure that function was not going to call any library functions because those will probably be in external memory in XMM mode. It will work to call them but it will go through the cache.
I don't think this is true. Just because it is in hub memory does not mean it is LMM code.
In this case (where code is tagged as HUBTEXT) the XMM kernel is supposed to fetch code from HUB RAM, and since the code is essentially the same except for some macros, it is practically LMM code.
I have a program where the tagged LMM code out-performs normal LMM code
In this case (where code is tagged as HUBTEXT) the XMM kernel is supposed to fetch code from HUB RAM, and since the code is essentially the same except for some macros, it is practically LMM code.
I have a program where the tagged LMM code out-performs normal LMM code
Really? That's hard to believe. Every memory reference in XMM mode goes through an XMM macro as does fetching of the next instruction. It's hard to believe that could outperform rdlong for fetching instructions. Maybe we should examine that code to see if there is some bug at work?
Really? That's hard to believe. Every memory reference in XMM mode goes through an XMM macro as does fetching of the next instruction. It's hard to believe that could outperform rdlong for fetching instructions. Maybe we should examine that code to see if there is some bug at work?
I'll test it on the default branch and see if it fails. :<
Comments
But maybe it is faster if Steve could upload his default branch build, so that I can test this weekend ;-)
If Steve has no time I will definitely consider installing Linux :-)
Thanks David for the suggestion!
Here is an alpha_1_9 default branch build package. https://drive.google.com/file/d/0BzcfH7bdVTbtWVVDRndHeWt0Qkk/edit?usp=sharing
Hi Steve,
Thanks very much! I will test if XMM is working today evening.
Did you do something special to get the branch built on windows? I have problems using make.
Christian
So there is definitely an issue when using the rebuild.sh script instead of make. If I don't get make to work on windows I will use Linux for development.
@Steve: Could you post how u built the sources? Because I have no luck with make.
Christian
Thanks,
David
Hi David,
XMM-Single is working for me. I will solder the flash ram onto my board today evening and try XMM split also.
Christian
I built it on Linux. The windows build really needs to be fixed. The linux build generally takes less time though.
Which compiler are you using that you can create windows binaries with linux?
Pull repository.
$ cd propgcc
$ make
$ make CROSS=win32
Hi David,
XMM-Split does also work. Filling an array with 1024 int values takes 3,6 us in XMM-Split.
Christian
I tested XMM-single, which worked and XMM-split (My own board has sram and flash. I have just soldered the flash ram to the board after sram test was successfull. So both ram work :-))
Thanks for the update, David!
I have a question with regards to start a new cog in the default branch. Is it by default, that the cog runs in xmm mode, when xmm is set when compiling the sources or do I have to use another function to do that?
Is there also a way to start a new cog in LMM mode?
Thanks,
Christian
It is possible to run LMM code from an XMM memory model of course. Just tag the function as HUBTEXT. Not sure if that applies to cogs other than the main one though.
In this case (where code is tagged as HUBTEXT) the XMM kernel is supposed to fetch code from HUB RAM, and since the code is essentially the same except for some macros, it is practically LMM code.
I have a program where the tagged LMM code out-performs normal LMM code
I'll test it on the default branch and see if it fails. :<