#44874 - yamaneko - Mon Jun 06, 2005 1:23 pm
Hi
I would know how use the gba's Arm7 pipeline in c/c++.
I juste know it's a 3stage pipeline.
#44887 - tepples - Mon Jun 06, 2005 3:12 pm
For one thing, there is no language called "C/C++". There are two separate languages, one called "C", the other called "C++". Which will you be using?
In addition, you don't have to worry about the pipeline in C or in C++. The compiler and the CPU's instruction decoder handle everything for you.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#44895 - SevenString - Mon Jun 06, 2005 5:19 pm
http://www.amazon.com/exec/obidos/search-handle-url/index=stripbooks:relevance-above&field-keywords=c/c%25252B%25252B&search-type=ss&bq=1&store-name=books/ref=xs_ap_l_xgl14/102-6979120-8707367
Referring to "C" and "C++" as "C/C++" is very common, since "C++" is a superset of "C", and not truly a seperate language.
Also, if you know how a particular compiler works, you can do certain coding tricks to arrange code so that it uses the target processor more efficiently. For instance, knowing the limitations of the processor's pipeline, along with how registers are used, one could organize an inner loop so that there is minimal stack usage and instruction type conflict, all within "C" or "C++".
I'm not fully up to speed on ARM7 assembly or what the DevKitArm compiler is doing internally, but I've used these techniques in the past for x86, 680xx, and PPC processor-based game work.
Of course, I PREFER to use in-line assembly language or seperate ASM code modules for that sort of optimization, but sometimes that isn't an option for later maintainability for other non-asm coders.
_________________
"Artificial Intelligence is no match for natural stupidity."
#44899 - tum_ - Mon Jun 06, 2005 5:57 pm
| SevenString wrote: |
For instance, knowing the limitations of the processor's pipeline, along with how registers are used, one could organize an inner loop so that there is minimal stack usage and instruction type conflict, all within "C" or "C++".
I'm not fully up to speed on ARM7 assembly or what the DevKitArm compiler is doing internally, but I've used these techniques in the past for x86, 680xx, and PPC processor-based game work.
Of course, I PREFER to use in-line assembly language or seperate ASM code modules for that sort of optimization, but sometimes that isn't an option for later maintainability for other non-asm coders. |
Not for the ARM7 core. To the best of my knowledge, there are no tricks
that can be used to improve the efficiency of the ARM7 pipeline.
Due to its relative simplicity, it does not "suffer" from instructions' dependancies & various interlocks that you might want to consider when
working with architectures like x86...
#44911 - SevenString - Mon Jun 06, 2005 6:46 pm
That's a cool thing, then. I might actually ENJOY doing the occasional bit of assembly language. There's certainly no shortage of general purpose registers compared to some other architectures. :D
_________________
"Artificial Intelligence is no match for natural stupidity."
#44912 - poslundc - Mon Jun 06, 2005 6:49 pm
| tum_ wrote: |
Not for the ARM7 core. To the best of my knowledge, there are no tricks
that can be used to improve the efficiency of the ARM7 pipeline. |
Branches flush the pipeline.
Fewer branches = better performance. Especially in memory areas that have different waitstates for sequential and random accesses, such as ROM.
In high-level languages such as C and C++, these optimizations can be achieved to some extent by avoiding unnecessary conditionals, unrolling loops, using switch statements or function tables where appropriate, inlining functions, etc. Many of these optimizations can also be done by the compiler automatically with optimization settings enabled - to some degree.
Dan.
#44916 - SevenString - Mon Jun 06, 2005 6:56 pm
so i'm not crazy, then! yay!
thanks, dan.
_________________
"Artificial Intelligence is no match for natural stupidity."
#44925 - Ultima2876 - Mon Jun 06, 2005 9:19 pm
Unnecessary conditionals? You mean if statements? x.x
#44933 - poslundc - Mon Jun 06, 2005 9:49 pm
| Ultima2876 wrote: |
| Unnecessary conditionals? You mean if statements? x.x |
For the most part, yes. For example,
| Code: |
int spriteIndex = SPRITE_BASE;
if (isDisabled)
{
spriteIndex += DISABLED_OFFSET;
} |
... may be equivalently coded by...
| Code: |
| int spriteIndex = SPRITE_BASE + isDisabled * DISABLED_OFFSET; |
The second version may compile to more efficient code than the first version. Which is not to say the second version is necessarily better or even faster all of the time; only that it optimizes for the ARM7 pipeline behaviour.
Dan.
#45051 - tum_ - Tue Jun 07, 2005 10:09 am
| poslundc wrote: |
Branches flush the pipeline.
Fewer branches = better performance. Especially in memory areas that have different waitstates for sequential and random accesses, such as ROM.
Dan. |
Absolutely agree. I just don't refer to this as "a trick" ;-) When you estimate the execution time using the datasheet - the pipeline refill is already included into B,BL instruction timings (2S + 1N).
To SevenString: If you enjoy assembly you WILL enjoy ARM asm. And it's not just the register space but a number of other nice features, especially conditional instructions and "built-in" shifts.
I've been into Z80 assembly for several years - now I really enjoy ARM ("unfortunately" ;-), assembly is rarely actually needed for ARM as it's fast enough for most tasks).
#45078 - yamaneko - Tue Jun 07, 2005 3:26 pm
Ok men.
If i understand well , i have juste to erase some branche.
My compilateur is very bad. It unroll my code with stupid branche.
So,thank you every one.
#45178 - tum_ - Wed Jun 08, 2005 9:08 am
| yamaneko wrote: |
Ok men.
If i understand well , i have juste to erase some branche.
My compilateur is very bad. It unroll my code with stupid branche.
So,thank you every one. |
Which compiler is this? Maybe it's not as bad as you think.
You might want to look at the compiler options as well.
#45199 - yamaneko - Wed Jun 08, 2005 3:22 pm
DevKitAdv with gcc 3.0.3 i cant use higter cause of mi .mak
I use all option (-funroll)
#45229 - wintermute - Wed Jun 08, 2005 8:50 pm
| yamaneko wrote: |
DevKitAdv with gcc 3.0.3 i cant use higter cause of mi .mak
I use all option (-funroll) |
what do you mean you can't use higher because of your .mak?
#45304 - yamaneko - Thu Jun 09, 2005 1:45 pm
In my file i use for make (.mak). There is bad line for the other gcc version like "-lgcc" and i dont know how change it.
#45309 - strager - Thu Jun 09, 2005 3:05 pm
You need to change your library path when you do that. -lxxx means "include the library 'libxxx.lib/libxxx.a'."
#45311 - yamaneko - Thu Jun 09, 2005 3:33 pm
But i dont where is the ew path in new devkitadv.
#45315 - strager - Thu Jun 09, 2005 3:56 pm
#45316 - yamaneko - Thu Jun 09, 2005 3:57 pm
Sorry,i repeat:
I dont know where is the new path in new devkitadv
#45317 - yamaneko - Thu Jun 09, 2005 4:01 pm
But i dont know the new path in DevKitARM too.