Hi All,
BACKGROUND:
Downloaded the source code of the Xemics CoolRISC gcc port from Raisonance's
website (ftp://www.raisonance.com/pub/CoolRISC/cool3_2.zip). I
concluded that the port is based in gcc 3.2 from looking at the NEWS
file in the gcc folder.
I what to bring to this gcc port up to the latest version of gcc.
The motivations for doing this are:
1- Gain experience on how to port gcc. This will be useful in the
not-so-distant future.
2- Fix bugs in current version of port. For example: the #pragma
interrupt do not work correctly, the size of structures is limited to
255 (otherwise the generated code is broken).
3- Try to improve the generated code density
CURRENT STATUS:
1- I downloaded the latest version of gcc. Then I took the
target-specific files from the CoolRISC port (c816.md, c816.c and
c816.h) and add them to the latest gcc code under the gcc/config/c816
folder.
2- Fixed multiple poised #defines in the c816.h file
3- Changed references to gen_rtx ( RTXCODE, ...) to gen_rtx_RTXCODE
(...) in the c816.c file.
4- Currently, I am able to compile the updated files. Furthermore, I
used the cc1 to do test compiles and the output asm code looks
promising.
NEXT STEPS:
1- Modify code to make use of newer gcc techniques: ie, make use of
define_constraint
instead of using the old #define method.
2- Better define the cpu using the md file's rtl macros (I want to
move away from the current approach of relying heavily in the c816.c
to do the rtl->asm transformations).
QUESTIONS:
1-The c816's port is heavily using the c816.c instead of better
describing the cpu in the c816.md file. For instance, looking at the
define_insn movhi:
;; movhi
(define_insn "movhi"
[(set (match_operand:HI 0 "general_operand" "=g")
(match_operand:HI 1 "general_operand" "g"))]
""
"*
{
return output_move(insn, operands);
}
")
I noticed that predicates and constraints are essentially disabled,
and the output_move function in the c816.c does all the work. Also,
since c816 can only move bytes, it looks to me like this definition is
incorrectly since it is basically lying to gcc and making it believe
that there is a two byte move. Is a define_split (or a define_expand)
more appropriate in this situation?
2- I am trying to sort-out define_expand from define_split. Looks
like they can be used to perform similar tasks. By looking at other
ports I came to the following conclusions (I gather this from reading
multiple posts, please correct me if this statements are not true):
2.1 define_split should be used to break an operation into simpler
operations *of a different mode*. That is, to describe a movhi in
terms of two movqi I should use a define_split instead of a
define_expand.
2.2 the define_expand expects the mode of the matching rtl macro and
the output operations to be preserve. Otherwise gcc could get confuse
since the mode will be change for no apparent reason.
Thanks for your help.
Best regards,
-Omar
