How can I see, if a loop fits into the fcache?
Christof Eb.
Posts: 1,237
Hi,
I am doing my first experiments with PropGCC. I use LMM with a demoboard.
Up to now everythig works. Only the loader needs sometimes several startings.
Now I want a really fast loop.
How can I see, if the loop can fit in the fast cache? Is there a possibility to declare cog-variables?
Thanks a lot!
Christof
I am doing my first experiments with PropGCC. I use LMM with a demoboard.
Up to now everythig works. Only the loader needs sometimes several startings.
Now I want a really fast loop.
How can I see, if the loop can fit in the fast cache? Is there a possibility to declare cog-variables?
Thanks a lot!
Christof
Comments
You can look at the generated code - the Wiki page at http://code.google.com/p/propgcc/wiki/PropGccMaps (Understanding PropGCC's memory usage and code generation using dumps and maps) shows you how.
You can use the -S option of propeller-elf-gcc to look at the generated code (or equivalently use the --save-temps option, as suggested by the wiki page).
You can declare cog variables with __attribute__((cogmem)), or with the easier macro _COGMEM defined in <propeller.h>: Note that in LMM and even more so XMM mode there is very little space left in the kernel for COG variables, so use this sparingly; also, only simple scalar variables may be declared this way (no arrays).
Eric
If you examine the generated code, you'll note that the kernel has a reasonably large number of registers, and if you enable optimization then PropGCC tends to use these cog-based registers for most local variables in a function (without needing to do anything force this).
Hm- Unfortunately, the -S option gives an asm file without the source. Who is supposed to be able to understand this? I could not find an option to switch on the output of the source with the asm.
Regards Christof
If you look at the wiki, you'll see directions to use propeller-elf-objdump to create a dissembly listing that intersperses code with the dissembly. Also, if you look at the .s file when compiled with the both the --save-temps (aka -S) and -g flags, you'll notice lines like this:
This means that the following assembly goes with line 33 of the source file.
Christof
I don't use the SimpleIDE, but I just tried it and I see your problems. Try this:
1) Uncheck the "Strip ELF" checkbox.
2) Compile your program as you previously did.
3) Bring up a DOS prompt and CD to the directory with your project.
4) Making sure that you have PropGCC in your PATH, run the objdump as specified in the Wiki (something like propeller-elf-objdump -d -S a.out > a.dump), then check out the a.dump file.
If you're using C++, then you might want to add the demangler as shown in the Wiki.
I did not follow your last instructions, but I have managed to understand some lines of the asm and I am sure, that my loop does not fit. I try to split it.
Christof
Steve/jazzed: I just looked into this further. If I use SimpleIDE V0-5-0 and add "--save-temps -g" in the first "extra options" box and build, these options appear in the build output box but they don't seem to have an effect. On the other hand, if I bring up a DOS prompt and try the exact command that SimpleIDE said it used (via cut and paste), then the options do seem to take effect. This appears to be a SimpleIDE bug.
A suggestion: It would be nice to have a place to put in a "prebuild" and "postbuild" command. Using this it would be easy for SimpleIDE users to get post-build dumps by putting "propeller-load-objdump -d -S a.out > a.dump" into the postbuild command. If these boxes could handle .bat files it would be even cooler.
It's "Propably" a bug. I'll have a look.
I'll think about it. I have to have a dividing line of what's simple and what's not.
Thanks.
--Steve