Anyone using any of the XMM memory models? For which boards?
David Betz
Posts: 14,516
I'm about to change the interface between the XMM kernel and the external memory drivers. This will affect all XMM memory models and will replace all of the current "cache drivers" with "external memory drivers". I have many of the current cache drivers converted to this new interface but not all of them. I want to make sure I have support for the drivers that people are currently using. I have drivers for the C3, EEPROM, the Propeller Memory Card, and generic drivers that should work with any board using either SPI or QuadSPI flash or SRAM chips. Is anyone using anything beyond those? I don't have, for example, a driver for the DracBlade, the SDRAM board that jazzed designed, and a number of others.
If you're using XMM could you please post a list of the boards you're using it with and what driver you're currently using. Just saying which board configuration file is enough.
Thanks!
David
If you're using XMM could you please post a list of the boards you're using it with and what driver you're currently using. Just saying which board configuration file is enough.
Thanks!
David
Comments
I wonder how much the DracBlade departed from Cluso's TriBlade.
Whilst we're at it, what is the status of propgcc on the P2 and any driver for the RAM on the FPGA cards?
The short answer is that the PropGCC P2 support is currently broken because of the instruction set changes.
--mark
However ... in this case, the change is to enable multi-cog xmm programs. It is impossible to do without the change David has described.
One important point of xmm to me is to be able to continue a development when code space allowed for in LMM/CMM is exhausted (as has happened to me time after time with SPIN ... because I do more than blink LEDs). If you have a program that does cogstart(function, ....) written in LMM/CMM and you run out of space, this change will allow you to continue development.
If you don't want that or the cache changes, then release_1_0 will always have the old method, but it will never support any chip other than P8X32A.
I do look forward to porting the old SDRAM and SSF cache drivers though ... just not today.
To do multi-cog xmm with the old cache driver interface we would have to lock the cache driver for every access to external memory to prevent the xmm cogs from stepping on each other. The performance would likely be horrible. We could solve that to some extend by having an n-way cache where each xmm cog gets at least one "way". That is complicated code and some of the cache drivers probably wouldn't fit in COG memory anymore with that approach. This seemed like the most straight forward approach that was likely to work. This should be possible especially in xmmc mode. The other xmm modes will be tricky because of cache coherency. I'm not sure why you would want to stay away from these changes. If it's just because you're using a cache driver that we haven't yet ported then you should make a request and it will get ported. That would be great! Actually, if you just provide init/read/write functions for SDRAM and SSF then I can do the rest.
Edit: FYI, this new external memory interface is compatible with the one that Chip designed for SDRAM on the P2 so it should allow XMM on P2 to be implemented relatively easily.
And, to answer your question, no there will not be two versions of PropGCC going forward. The next release of PropGCC will include the changes that are currently in the default branch. That's why kernel-work was merged into default.
Side note: How often does it happen that a compiler is broken because the target processor's instruction set got changed? :-)
===Jac
When I asked the department that was building the CPU they casually said "Lock exchange is not implemented in that CPU version you have there".
The release_2_0 when that happens will support new features.
So there will be two versions, functionally different, going forward.
All that Steve was saying is that the current released version will be maintained until we are ready to make another release and that new release will be from the default branch and will include these changes.
I don't have a problem producing release_2_0 code from the default branch whatever that is.
http://forums.parallax.com/showthread.php/151558-Anyone-using-any-of-the-XMM-memory-models-For-which-boards?p=1219675&viewfull=1#post1219675
I was just wondering about the mechanics of maintaining two different compilers.
It seems to me that these memory interfaces define different machine architectures. We are not talking Propeller chip here but some "virtual machine" defined by the run time kernel and XMM interface.
Heck, even the LMM machine is not real but a software defined virtual machine architecture.
I can't see the sense in proliferating these virtual machine architectures and having to maintain them.
Easy:
$ hg update release_1_0
$ hg update default
# or when the time comes
$ hg update release_2_0
That's easy for us out here:)
But who is going to maintain this, and why?
I'm not even sure why branch release_1_0 is even moving forward. It should have been released, tagged, done, move on.
The compiler itself doesn't change, and the XMM APIs are the same for the two different cache schemes. The only really visible differences are:
(1) The new method allows XMM code to run in other COGs (a good thing).
(2) The new method takes up a small amount of extra HUB memory for cache tags (a "bad" thing, but it is very small, so I doubt it will really be much impact to programmers).
(3) The new method will be easier to port to P2.
People writing XMM drivers for boards will have to make changes, of course, but for most programmers the new method and old method will both work just fine, and the new one offers more functionality.
Eric
Also, the old interface made calls to the cache driver COG for almost every memory access. The new interface only calls the external memory driver on cache misses.
Of course, all of this is pretty much invisible to user programs except for the small hub memory hit for keeping tags in hub memory. That can be smaller than 512 bytes if you adjust the cache geometry. The tags take up one long for every cache line. You can trade memory performance for hub memory space by adjusting the geometry. That feature is available to every board configuration in the new scheme. It was only available to some boards in the old scheme.
Maybe don't bother about the dracblade (512k sram) driver. I think it has been rendered obsolete by the larger serial sram chips and also by the clever cache driver code. I'm using serial chips now - far less pins as well.
I'm maybe thinking the dracblade could be removed from the drop down menu in GCC? It kind of is cluttering up the list of better drivers...