GCC porting questions

GCC porting questions

[Radu Hobincu]

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

Re: GCC porting questions

[Ian Lance Taylor]

"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

Re: GCC porting questions

[Radu Hobincu]

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
>

Re: GCC porting questions

[Ian Lance Taylor]

"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

Re: GCC porting questions

[Radu Hobincu]

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.

Re: GCC porting questions

[Ian Lance Taylor]

"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

Re: GCC porting questions

[Radu Hobincu]

> "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.

Re: GCC porting questions

[Manuel López-Ibáñez]

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.
>

GCC plugin support when using Ada

[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

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.

Re: GCC plugin support when using Ada

[Richard Guenther]

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.

>
>
>
>
>
>
>
>
>
>
>

Re: GCC plugin support when using Ada

[Duncan Sands]

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.