Search |
 |
|
 |
| Author |
Message |
|
|
 Posted: Feb 05, 2012 - 01:02 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
skeeve wrote:
SprinterSB wrote:
Ensure that code outside of ISRs does not grow. And if, what code growth would be acceptable?
Is such growth even possible in an otherwise correct solution?
Yes, I think so. But you don't know before you have implemented it.
Quote:
Are the call-saved and call-used registers hard-coded for ordinary functions?
If not, supplying ISRs with different lists would seem an obvious thing to do.
Problem is not the ABI because an ISR must save/restore anything it might clobber, anyways.
The issue in the current imlpementation is that R0 and R1 are neither call-saved nor call-clobbered, they are fixed and used implicitely, i.e. the compiler machinery does not manage their contents or even has an idea what their content is or if they are used at all. Same for T:
R0, T: fixed, used in an insn-clobbered way
R1: fixed, used in an insn-saved way
Moreover, whether R0, R1, T is actually needed or not, is not known before reload, i.e. before the non-strict RTL → strict RTL transition.
Soon after reload there is pro/epilogue generation. Afterwards, there are more optimization passes like text and RTL peephole, split passes, register renaming and propagations, machine dependent reorg, etc. That might change R0/R1/T usage.
How do you ship the information on R0/R1/T at all? As explicit RTL? As insn attributes? When do you generate that information? When and how do you use it? How do you ensure debug information is not currupt if you change prologue late after prologue generation? How do you cope with the needs of specific insns like emit different code depending on optimization switches and register classes used? You *really* don't want to quadruple the numer of constraint alternatives... |
|
|
| |
|
|
|
|
|
|
Posted: Feb 05, 2012 - 01:44 PM |
|
Joined: Jul 18, 2005
Posts: 62299
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Georg-Johann,
Where do you get all this knowledge from? I know there's a GCC "internals" manual - is it all from that, or from studying the code, or from talking to other developers? I'm sure there are others like myself who would LIKE to contribute to GCC but don't have the foggiest idea where to start reading about its operation.
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 05, 2012 - 08:34 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
clawson wrote:
Where do you get all this knowledge from? I know there's a GCC "internals" manual - is it all from that, or from studying the code, or from talking to other developers?
There are many ways how to get better understanding of GCC:
Communicate with experienced developers
The most valuable resource of information. Unfortunately, expert GCC developers are very rare and very busy. If you don't already have an understanding of how things work, an extert's answer won't help you nothing or even serves to confuse you even more. And most likely, the expert won't explain the whole story and write novels because it's simpl much tooo time consuming...
Read the internals
If you are interested in AVR, most interesting parts are Machine Description and Target Description and therein Standard Names. You won't understand everything reading it the first time. Just skim and get an idea what parts are there to describe a target.
In particular, one of the first things you'll want to learn is what an insn is, what its components are, how they are named and when and where and how they are used. If you don't know what a "predicate" or a "constraint" is, an answer from an expert won't help you.
Read compiler dumps
If you are interested in a backend, -da (same -fdump-rtl-all) lets RTL passes generate dumps. You can see how the compiled code evolves as the pass number increases. You can also dump the final RTL within asm with -save-temps -dP and use the assembler code side-by-side to RTL as Rosetta stone to decipher and learn RTL.
Similarly, the tree dumps can be generated with -fdump-tree-all. These dumps are C-like and you understand them immediately, but for backend they are not as important as RTL.
Learn more about passes
Get an understanding what passes are run and what they are good for. Is a pass inevitable and runs even at -O0 or is it "just" an optimization pass? What piece of information fom the backend is used where and how?
Read the sources
Try to figure out how a trivial program gets compiled and transformed. Try to identify the respective parts in the backend (for the RTL passes). If you work for AVR, you'll most likely end up in avr.md or avr.c.
Vice versa, try to learn what piece of backend is used/essencial in what pass.
If you have to solve a problem for avr, you can look at other backends and how they address similar problems. Avoid complicated backends like x86 or rs6000 (PowerPC).
Browse the source and build tree
Try to find your way through the sources files and the build directory: What is located where? Where is the AVR backend? And where libgcc? What files are auto-generated? What happens to avr.md as it is transformed to C?
Change the compiler
Try to fix a problem or just make the compiler generate the code that you desire or print some log output like
Code:
avr_edump ("%?: I'm here!\n");
Try to work out if your change covers all cases imagineable. Observe how the intermediate representation and dumps changes as you change the compiler.
Debug the compiler
Look at the compiler in action. Make sure you don't debug the driver xgcc but the compile proper cc1 resp. cc1plus. Learn how to display RTL and tree in gdb. Build the compiler with debug info and without optimization. Learn to run the compiler from build directory without installing it.
Don't get frustrated
GCC is very complex and it's lerning curve is steep. If you have problems to understand something or to follow what's happening, it's not because you are too dumb. It's simply because it's really complex and new and intertwined and historically grown and GCC is faster evolvong than its documentation. GCC is not a compiler for educational purposes. It's a real world compiler supporting more hardware than any other compiler.
Quote:
I'm sure there are others like myself who would LIKE to contribute to GCC but don't have the foggiest idea where to start reading about its operation.
Even if it's too time consuming or too complex to contribute to the compiler proper you can help avr-gcc. Just some examples:
File a Problem Report if you hit a problem
If a problem is not reported, it's unlikely it will be fixed.
Test new features
like new command line options, address spaces, built-in types, etc.
Help writing test programs
Due to lack of time, there is not a single test program for AVR-specific features like upcoming __flash or __memx in the GCC testsuite. Contributing to the testsuite does not require changing the compiler or understanding its internals. You just need to know some magic comments to advise the framework.
Extend avrtest
Similarly, there is not a single test program to test ISR code. One reason is that avrtest — the simulator used to run avr-gcc testsuite — has no IRQ support. One way could be to trigger soft-IRQ by special sequence like SEH SEH in the simulator when requested per option. Or use the I-flag and set IRQ frequency and burst by writing to some magic SFR. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 05, 2012 - 09:23 PM |
|
Joined: Jul 18, 2005
Posts: 62299
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Great answer!  |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 05, 2012 - 11:30 PM |
|
Joined: Jul 16, 2009
Posts: 1579
|
|
Hi SprinterSB,
I bow to your knowledge!!! Very impressive replies in this thread.
By the way, I've reworked my dsprintf using the state machine concept. I shaved a few hundred bytes of flash off of it, implemented it as a state machine, added hexidecimal output, added 64 bit integer support, and added tunable settings do you can include or exclude features might need.
Please take a look at it and let me know if you like it better than what I had! Again if you see a way to improve it, please let me know!!
Thanks,
Alan |
|
|
| |
|
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
