* GCC porting questions @ 2010-06-10 17:21 Radu Hobincu 2010-06-10 18:06 ` Ian Lance Taylor 0 siblings, 1 reply; 11+ messages in thread From: Radu Hobincu @ 2010-06-10 17:21 UTC (permalink / raw) To: gcc; +Cc: Petronela Agache Hello again, I have written here a few weeks ago regarding some tutorials on GCC porting and got some very interesting replies. However, I seem to have gotten stuck with a couple of issues in spite of my massive Googling, and I was wondering if anyone could spare a couple of minutes for some clarifications. I am having troubles with the condition codes (cc_status). I have looked over a couple of architectures and I do not seem to understand how they work. The machine I am porting GCC for has 1 4bit status register for carry, zero, less than and equal. I do not have explicit comparison instructions, all of the ALU instructions modify one or more flags. What I figured out so far looking over AVR and Cris machine descriptions is that each instruction that modifies the flags contain an attr declaration which specify what flags it is changing. Also, there is a macro called NOTICE_UPDATE_CC which sets up the cc_status accordingly by reading this attr. This is the part of the code I do not understand. There are certain functions for which I could not find any descriptions, like "single_set" and macros like "SET_DEST" and "SET_SRC". Also, looking over conditions.h, I see that the CC_STATUS structure contains 2 rtx fields: "value1" and "value2", and also an int called "flags". What do they represent? Is "flags" the contents of the machine's flag register? Thanks in advance, Radu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-10 17:21 GCC porting questions Radu Hobincu @ 2010-06-10 18:06 ` Ian Lance Taylor 2010-06-11 14:59 ` Radu Hobincu 0 siblings, 1 reply; 11+ messages in thread From: Ian Lance Taylor @ 2010-06-10 18:06 UTC (permalink / raw) To: Radu Hobincu; +Cc: gcc, Petronela Agache "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes: > I have written here a few weeks ago regarding some tutorials on GCC > porting and got some very interesting replies. However, I seem to have > gotten stuck with a couple of issues in spite of my massive Googling, and > I was wondering if anyone could spare a couple of minutes for some > clarifications. > > I am having troubles with the condition codes (cc_status). I have looked > over a couple of architectures and I do not seem to understand how they > work. > > The machine I am porting GCC for has 1 4bit status register for carry, > zero, less than and equal. I do not have explicit comparison instructions, > all of the ALU instructions modify one or more flags. > > What I figured out so far looking over AVR and Cris machine descriptions > is that each instruction that modifies the flags contain an attr > declaration which specify what flags it is changing. Also, there is a > macro called NOTICE_UPDATE_CC which sets up the cc_status accordingly by > reading this attr. This is the part of the code I do not understand. There > are certain functions for which I could not find any descriptions, like > "single_set" and macros like "SET_DEST" and "SET_SRC". Also, looking over > conditions.h, I see that the CC_STATUS structure contains 2 rtx fields: > "value1" and "value2", and also an int called "flags". What do they > represent? Is "flags" the contents of the machine's flag register? For a new port I recommend that you avoid cc0, cc_status, and NOTICE_UPDATE_CC. Instead, model the condition codes as 1 or 4 pseudo-registers. In your define_insn statements, include SET expressions which show how the condition code is updated. This is how the i386 backend works; see uses of FLAGS_REG in i386.md. As far as things like single_set, SET_DEST, and SET_SRC, you have reached the limits of the internal documentation. You have to open the source code and look at the comments. Similarly, the description of the CC_STATUS fields may be found in the comments above the definition of CC_STATUS in conditions.h. Ian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-10 18:06 ` Ian Lance Taylor @ 2010-06-11 14:59 ` Radu Hobincu 2010-06-11 16:37 ` Ian Lance Taylor 0 siblings, 1 reply; 11+ messages in thread From: Radu Hobincu @ 2010-06-11 14:59 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc, Petronela Agache Thanks for the reply. I scrolled a lot through the i386 md and c files. I notice that the i386 architecture has dedicated instructions for comparing values and ALU instructions only specify (clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify the way ALU instructions affect the flags. In order to set the flags, I am trying something like this: (define_expand "addsi3" [( parallel [(set (match_operand:SI 0 "register_operand" "") (plus:SI (match_operand:SI 1 "register_operand" "") (match_operand:SI 2 "nonmemory_operand" "")) ) (set (reg:CC FLAGS_REG) (compare:SI (match_dup 1) (match_dup 2)))] )] "" " if(GET_CODE(operands[2])==CONST_INT && INTVAL(operands[2])==1){ emit_insn(gen_inc(operands[0], operands[1])); DONE; } " ) and to use them: (define_insn "beq" [(set (pc) (if_then_else (eq:SI (reg:CC FLAGS_REG) (const_int 0)) (label_ref (match_operand 0 "" "")) (pc) ) )] "" "jeq \\t%l0" ) but that does not look right. The carry and zero flags should be set after the operation and the less than and equal, before the sum is done, since the destination register can just as well be the same with one of the sources. The "parallel" statement, afaik, tells the compiler to evaluate the operands first, then execute both insns which means that all flags will be set with the state of the operands before the operation. I am probably a bit confused about the compiler behavior since I am thinking more like in the way of machine execution. The compiler doesn't know the values of the operands at compile time, so it doesn't really set any flags in the condition register. How does it work then? Sorry for the large text and thanks again for your time. > "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes: > >> I have written here a few weeks ago regarding some tutorials on GCC porting and got some very interesting replies. However, I seem to have gotten stuck with a couple of issues in spite of my massive Googling, and >> I was wondering if anyone could spare a couple of minutes for some clarifications. >> I am having troubles with the condition codes (cc_status). I have looked >> over a couple of architectures and I do not seem to understand how they work. >> The machine I am porting GCC for has 1 4bit status register for carry, zero, less than and equal. I do not have explicit comparison >> instructions, >> all of the ALU instructions modify one or more flags. >> What I figured out so far looking over AVR and Cris machine descriptions >> is that each instruction that modifies the flags contain an attr declaration which specify what flags it is changing. Also, there is a macro called NOTICE_UPDATE_CC which sets up the cc_status accordingly by >> reading this attr. This is the part of the code I do not understand. There >> are certain functions for which I could not find any descriptions, like "single_set" and macros like "SET_DEST" and "SET_SRC". Also, looking over >> conditions.h, I see that the CC_STATUS structure contains 2 rtx fields: "value1" and "value2", and also an int called "flags". What do they represent? Is "flags" the contents of the machine's flag register? > > For a new port I recommend that you avoid cc0, cc_status, and > NOTICE_UPDATE_CC. Instead, model the condition codes as 1 or 4 > pseudo-registers. In your define_insn statements, include SET > expressions which show how the condition code is updated. This is how the i386 backend works; see uses of FLAGS_REG in i386.md. > > As far as things like single_set, SET_DEST, and SET_SRC, you have reached the limits of the internal documentation. You have to open the source code and look at the comments. Similarly, the description of the CC_STATUS fields may be found in the comments above the > definition of CC_STATUS in conditions.h. > > Ian > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-11 14:59 ` Radu Hobincu @ 2010-06-11 16:37 ` Ian Lance Taylor 2010-06-17 22:56 ` Radu Hobincu 0 siblings, 1 reply; 11+ messages in thread From: Ian Lance Taylor @ 2010-06-11 16:37 UTC (permalink / raw) To: Radu Hobincu; +Cc: gcc, Petronela Agache "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes: > Thanks for the reply. I scrolled a lot through the i386 md and c files. I > notice that the i386 architecture has dedicated > instructions for comparing values and ALU instructions only specify > (clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify > the way ALU instructions affect the flags. E.g., (define_insn "*sub<mode>_2" [(set (reg FLAGS_REG) (compare (minus:SWI (match_operand:SWI 1 "nonimmediate_operand" "0,0") (match_operand:SWI 2 "<general_operand>" "<r><i>,<r>m")) (const_int 0))) (set (match_operand:SWI 0 "nonimmediate_operand" "=<r>m,<r>") (minus:SWI (match_dup 1) (match_dup 2)))] "ix86_match_ccmode (insn, CCGOCmode) && ix86_binary_operator_ok (MINUS, <MODE>mode, operands)" "sub{<imodesuffix>}\t{%2, %0|%0, %2}" [(set_attr "type" "alu") (set_attr "mode" "<MODE>")]) > In order to set the flags, I am trying something like this: > > (define_expand "addsi3" > [( parallel [(set (match_operand:SI 0 "register_operand" "") > (plus:SI (match_operand:SI 1 "register_operand" "") > (match_operand:SI 2 "nonmemory_operand" "")) > ) > (set (reg:CC FLAGS_REG) (compare:SI (match_dup 1) (match_dup 2)))] > )] > "" > " > if(GET_CODE(operands[2])==CONST_INT && INTVAL(operands[2])==1){ > emit_insn(gen_inc(operands[0], operands[1])); > DONE; > } > " > ) That doesn't look right, unless your machine is rather odd. You want something like the above: set the FLAGS_REG to the comparison of the sum with zero. > I am probably a bit confused about the compiler behavior since I am > thinking more like in the way of machine execution. The compiler doesn't > know the values of the operands at compile time, so it doesn't really set > any flags in the condition register. How does it work then? You describe to the compiler what value the flags register will hold after the operation is complete, in terms of the operands. Ian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-11 16:37 ` Ian Lance Taylor @ 2010-06-17 22:56 ` Radu Hobincu 2010-06-18 6:38 ` Ian Lance Taylor 0 siblings, 1 reply; 11+ messages in thread From: Radu Hobincu @ 2010-06-17 22:56 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Radu Hobincu, gcc, Petronela Agache Hello again, I managed to get the thing working and I have two last issues to solve. 1. My machine does not have any kind of floating point instructions. When I write in the C source code float f = 0.5f; The compiler crashes with "Segmentation fault". Running a gdb on it, the output becomes Program received signal SIGSEGV, Segmentation fault. 0x00007ffff75e343a in vfprintf () from /lib/libc.so.6 I do not have a multiply instruction either but when I write "int c = a * b;" the compiler properly inserts a LIBCALL to __mulsi3. Any idea what to do with the float? 2. When I try "char c = 'c';", the compiler fails an assert: test0.c:17: internal compiler error: in emit_move_multi_word, at expr.c:3273 This is strange since a char is smaller than an int, it should not be calling emit_move_MULTI_word. I have #define UNITS_PER_WORD 4 #define MIN_UNITS_PER_WORD 1 /* Promote those modes that are smaller than an int, to int mode. */ #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \ ((GET_MODE_CLASS (MODE) == MODE_INT \ && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \ ? (MODE) = SImode : 0) in my header file. Again, I do not know how to proceed. Thank you again for your time, R. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-17 22:56 ` Radu Hobincu @ 2010-06-18 6:38 ` Ian Lance Taylor 2010-06-18 9:42 ` Radu Hobincu 0 siblings, 1 reply; 11+ messages in thread From: Ian Lance Taylor @ 2010-06-18 6:38 UTC (permalink / raw) To: Radu Hobincu; +Cc: gcc, Petronela Agache "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes: > The compiler crashes with "Segmentation fault". > 2. When I try "char c = 'c';", the compiler fails an assert: It's time to break out the debugger and look at the source code and figure out what the compiler is doing. Neither of these problems ring any sort of bell for me. Ian ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-18 6:38 ` Ian Lance Taylor @ 2010-06-18 9:42 ` Radu Hobincu 2010-06-18 15:36 ` Manuel López-Ibáñez 0 siblings, 1 reply; 11+ messages in thread From: Radu Hobincu @ 2010-06-18 9:42 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Radu Hobincu, gcc, Petronela Agache > "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes: > >> The compiler crashes with "Segmentation fault". > >> 2. When I try "char c = 'c';", the compiler fails an assert: > > It's time to break out the debugger and look at the source code and > figure out what the compiler is doing. Neither of these problems ring > any sort of bell for me. > > Ian > All right, thank you again and sorry for the spam. R. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC porting questions 2010-06-18 9:42 ` Radu Hobincu @ 2010-06-18 15:36 ` Manuel López-Ibáñez 2010-06-18 22:31 ` GCC plugin support when using Ada PeteGarbett 0 siblings, 1 reply; 11+ messages in thread From: Manuel López-Ibáñez @ 2010-06-18 15:36 UTC (permalink / raw) To: Radu Hobincu; +Cc: Ian Lance Taylor, gcc, Petronela Agache This may be useful: http://gcc.gnu.org/wiki/DebuggingGCC And in general the info here: http://gcc.gnu.org/wiki/GettingStarted It is a wiki, so contributions and fixes are very welcome. Thanks, Manuel. On 18 June 2010 10:55, Radu Hobincu <radu.hobincu@arh.pub.ro> wrote: >> "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes: >> >>> The compiler crashes with "Segmentation fault". >> >>> 2. When I try "char c = 'c';", the compiler fails an assert: >> >> It's time to break out the debugger and look at the source code and >> figure out what the compiler is doing. Neither of these problems ring >> any sort of bell for me. >> >> Ian >> > > All right, thank you again and sorry for the spam. > > R. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* GCC plugin support when using Ada 2010-06-18 15:36 ` Manuel López-Ibáñez @ 2010-06-18 22:31 ` PeteGarbett 2010-06-19 22:44 ` Richard Guenther 2010-06-20 6:18 ` Duncan Sands 0 siblings, 2 replies; 11+ messages in thread From: PeteGarbett @ 2010-06-18 22:31 UTC (permalink / raw) To: gcc I see nothing in the GCC 4.5 release notes about plugin support being language specific, and yet if I using the treehydra plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra notes), I get this gnat1: warning: command line option "-fplugin=/home/linux/gcc-dehydra/dehydra/gcc_treehydra.so" is valid for C/C++ but not for Ada I assume the plan is to have something in the GCC 4 series be agnostic about what front end has generated your GIMPLE. Is this correct? I'd like to be able to analyse GIMPLE structures generated from gnat. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC plugin support when using Ada 2010-06-18 22:31 ` GCC plugin support when using Ada PeteGarbett @ 2010-06-19 22:44 ` Richard Guenther 2010-06-20 6:18 ` Duncan Sands 1 sibling, 0 replies; 11+ messages in thread From: Richard Guenther @ 2010-06-19 22:44 UTC (permalink / raw) To: petegarbett; +Cc: gcc On Fri, Jun 18, 2010 at 10:32 PM, PeteGarbett <petegarbett@blueyonder.co.uk> wrote: > > I see nothing in the GCC 4.5 release notes about > plugin support being language specific, and yet if I using the treehydra > plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra > notes), I get this > > gnat1: warning: command line option > "-fplugin=/home/linux/gcc-dehydra/dehydra/gcc_treehydra.so" is valid for > C/C++ but not for Ada > > I assume the plan is to have something in the GCC 4 series be agnostic > about what front end has generated your GIMPLE. Is this correct? > I'd like to be able to analyse GIMPLE structures generated from gnat. In GCC 4.5 plugin support is not language specific. This must be a "patched GCC 4.3.4 as per the dehydra notes" issue. Richard. > > > > > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC plugin support when using Ada 2010-06-18 22:31 ` GCC plugin support when using Ada PeteGarbett 2010-06-19 22:44 ` Richard Guenther @ 2010-06-20 6:18 ` Duncan Sands 1 sibling, 0 replies; 11+ messages in thread From: Duncan Sands @ 2010-06-20 6:18 UTC (permalink / raw) To: gcc Hi PeteGarbett, > I see nothing in the GCC 4.5 release notes about > plugin support being language specific, and yet if I using the treehydra > plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra > notes), I get this I use plugins with Ada all the time, with gcc-4.5, and it works fine for me. Ciao, Duncan. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-06-19 12:49 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-06-10 17:21 GCC porting questions Radu Hobincu 2010-06-10 18:06 ` Ian Lance Taylor 2010-06-11 14:59 ` Radu Hobincu 2010-06-11 16:37 ` Ian Lance Taylor 2010-06-17 22:56 ` Radu Hobincu 2010-06-18 6:38 ` Ian Lance Taylor 2010-06-18 9:42 ` Radu Hobincu 2010-06-18 15:36 ` Manuel López-Ibáñez 2010-06-18 22:31 ` GCC plugin support when using Ada PeteGarbett 2010-06-19 22:44 ` Richard Guenther 2010-06-20 6:18 ` Duncan Sands
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).