Thank you for the bug report, and I have fixed the fcache problem in GCC by preventing it from fcache'ing loops that have inline assembly in them.
Does this mean that 'converging on a solution' is not so easy ?
If a user asks for fcache, and finds on inspection that is very close, but they need to modify one small part, how do they do that if any in-line asm then disables fcache ?
I was talking about GCC's automatic placing of loops in fcache. It no longer adds code to copy a particular loop into fcache if that loop contains inline assembly; in that case, either (a) the user has to place the fcache pseudo-instruction explicitly in the inline assembly, or (b) the user has to request that the whole function be placed in fcache by putting an explicit __attribute__("fcache") on it. This won't affect other loops in the program.
Does this mean two forms of in-line ASM are needed ?
In-line assembly inside fcache has to be written to be aware of that (references to labels, for example, have to be adjusted because the fcache'd code runs in a particular place in COG memory, rather than out of hub memory). This has always been the case.
It also points out why it's probably better to avoid inline assembly unless you really know what you're doing (as David does ). An automatically fcache'd gcc loop is definitely going to run faster than a manually coded non fcache'd loop.
I think I know what I am doing, plus, you can't drive NeoPixels without using assembler in the propeller, the short tight delay cannot be reached easily. Personally I will rather point-out that the GCC should be fixed so we can use it properly.
I'm sorry, my comment came across with the wrong tone -- I didn't mean to imply you don't know what you're doing. Thank you for the bug report, and I have fixed the fcache problem in GCC by preventing it from fcache'ing loops that have inline assembly in them.
I do disagree though that you can't drive the NeoPixels without using assembler. I think GCC should be able to produce efficient enough code. What I was trying to get at (and not phrasing it well) is that the automatic optimizations that GCC performs (like fcache) will produce very good code which will often run faster than hand written assembly. Certainly fcache'd C code will outperform non-fcache'd hand written assembly.
Sorry, I just meant that..... well, to use or not use the assembler was not really the issue, the inline and GCC was crashing the code so I am glad to see that there is a fix. The propeller platform, simpledIDE and the C libraries are fantastic, I just wish there were more memory thought. Hope for more development on the propeller C platform.
Comments
In-line assembly inside fcache has to be written to be aware of that (references to labels, for example, have to be adjusted because the fcache'd code runs in a particular place in COG memory, rather than out of hub memory). This has always been the case.
Sorry, I just meant that..... well, to use or not use the assembler was not really the issue, the inline and GCC was crashing the code so I am glad to see that there is a fix. The propeller platform, simpledIDE and the C libraries are fantastic, I just wish there were more memory thought. Hope for more development on the propeller C platform.