Re: Segment registers support for i386

Re: Segment registers support for i386

[Ross Ridge]

Remy Saissy wrote:
>I've looked for a target specific callback to modify but I've found
>nothing, even in the gcc internals info pages. Do you mean I would
>have to modify some code outside of the i386 directory ? Or maybe to
>add such a callback if it doesn't exist ;)

You'ld have to modify code in the main GCC directory, probably a lot
of code.  Since it's target dependent, you'ld need to implement it using
a hook or hooks.

>In which file does the tree to RTL conversion code is located ?

There are several files that do this jobs.  See the internals
documentation.

>Does it mean that an RTL expression which use reg: force gcc to use a
>particular pseudo register ? 

Pseudo registers aren't real registers.  They either get changed to real
hard registers, or memory references to stack slots.  See the internals
documentation for more details.

					Ross Ridge

Re: Segment registers support for i386

[Rémy Saissy]

>Remy Saissy wrote:
>>I've looked for a target specific callback to modify but I've found
>>nothing, even in the gcc internals info pages. Do you mean I would
>>have to modify some code outside of the i386 directory ? Or maybe to
>>add such a callback if it doesn't exist ;)

>You'ld have to modify code in the main GCC directory, probably a lot
>of code.  Since it's target dependent, you'ld need to implement it using
>a hook or hooks.

>>In which file does the tree to RTL conversion code is located ?

>There are several files that do this jobs.  See the internals
>documentation.

>>Does it mean that an RTL expression which use reg: force gcc to use a
>>particular pseudo register ?

>Pseudo registers aren't real registers.  They either get changed to real
>hard registers, or memory references to stack slots.  See the internals
>documentation for more details.

>					Ross Ridge

Ok,
Thanks a lot for your help, I'm going to see what I can do and if I
don't give up now ;)
Have a great day.


-- 
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Rémy Saissy]

>Ross Ridge wrote:
>>Remy Saissy wrote:

>> What I understand is that there is two kind of managment for attribute :

>Attributes are handled in various different ways depending on what the
>attribute does.  To handle your case correctly, you'ld have to change how
>the tree to RTL conversion generates RTL addresses expressions whenever
>a pointer with the "far" attribute is dereferenced.  This is probably
>going to be a lot work.

I've looked for a target specific callback to modify but I've found
nothing, even in the gcc internals info pages. Do you mean I would
have to modify some code outside of the i386 directory ? Or maybe to
add such a callback if it doesn't exist ;)
In which file does the tree to RTL conversion code is located ?

>> Therefore, I can consider the following relationship:
>>  (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
>>       |      |                    |                    |
>>      \/     \/                   \/                   \/
>>      int *                 __attribute__((far("fs")))                      p;

>No, that's not what the RTL expression represents.  Declarations aren't
>represented in RTL.  The example RTL expression I gave is just an
>expression, not a full RTL instruction.  It's something that could be
>used as the memory operand of an instruction.  The RTL expression I gave
>would correspond to a C expression (not a statement) like this:

>	*(int * __atribute__((far("fs")))) var

Ok, I thanks for the precisions :)

>> does (reg:HI fs) care about the type of the parameter fs ?

>See the GCC Internals documentation.  In my example, since I don't know
>what the actual hard register number you assigned to the FS segment
>register, I just put "fs" in the place where the actual register number
>would appear.  Similarily, the "var" in  "(reg:SI var)" represents
>the number of the pseudo-register GCC would allocate for an automatic
>variable named "var".

Does it mean that an RTL expression which use reg: force gcc to use a
particular pseudo
register ? Is there something I should care about when I choose the
number of this pseudo
register ?

>> how does gcc recognize such an expression ?

>Since this expression is a memory operand, it's recognized by the
>GO_IF_LEGITIMATE_ADDRESS() macro.  In the i386 port, that's implemented
>by legitimate_address_p() in "i386.c".

Ok thank you very much.

>					Ross Ridge


-- 
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Ross Ridge]

Remy Saissy wrote:
>if I understand well, to make gcc generating rtx according to an
>__attribute__((far("fs"))) on a pointer I only have to add or modify
>rtx in the i386.md file and add an UNSPEC among the constants ?

No, the work you need to on the backend, adding an UNSPEC constant to
"i386.md" and writing code to handle the UNSPEC in "i386.c" is just the
easy part.

> What I understand is that there is two kind of managment for attribute :

Attributes are handled in various different ways depending on what the
attribute does.  To handle your case correctly, you'ld have to change how
the tree to RTL conversion generates RTL addresses expressions whenever
a pointer with the "far" attribute is dereferenced.  This is probably
going to be a lot work.

> Therefore, I can consider the following relationship:
>  (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
>       |      |                    |                    |
>      \/     \/                   \/                   \/
>      int *                 __attribute__((far("fs")))                      p;

No, that's not what the RTL expression represents.  Declarations aren't
represented in RTL.  The example RTL expression I gave is just an
expression, not a full RTL instruction.  It's something that could be
used as the memory operand of an instruction.  The RTL expression I gave
would correspond to a C expression (not a statement) like this:

	*(int * __atribute__((far("fs")))) var

> does (reg:HI fs) care about the type of the parameter fs ?

See the GCC Internals documentation.  In my example, since I don't know
what the actual hard register number you assigned to the FS segment
register, I just put "fs" in the place where the actual register number
would appear.  Similarily, the "var" in  "(reg:SI var)" represents
the number of the pseudo-register GCC would allocate for an automatic
variable named "var".

> how does gcc recognize such an expression ? 

Since this expression is a memory operand, it's recognized by the
GO_IF_LEGITIMATE_ADDRESS() macro.  In the i386 port, that's implemented
by legitimate_address_p() in "i386.c".

					Ross Ridge

Re: Segment registers support for i386

[Rémy Saissy]

>> Ross Ridge wrote:
>>    You won't be able to.  You're going to need to write your own code that,
>>    during the conversion of the tree to RTL, creates RTL expressions which
>>    indicate that the memory references use segment registers.  This probably
>>    won't be easy since there are a lot of contexts where your "far" pointer
>>    can be used.  I suspect this is where you're going to give up on your
>>    project, but if you do then RTL expressions you'll need to create should
>>    probably look like:


>>    (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))


>>    After getting GCC to generate expressions like these, then it's a
>>    realtively simple case of modifying ix86_decompose_address() to handle
>>    the unspec.  You might also need to change other backend code for
>>    handling addresses.

>>    Ross Ridge

Hi,
if I understand well, to make gcc generating rtx according to an
__attribute__((far("fs")))
on a pointer I only have to add or modify rtx in the i386.md file and
add an UNSPEC among the constants ?
Actually, it is not specifically for this attribute but more to
understand how does gcc manage attributes internally.

What I understand is that there is two kind of managment for attribute :
 - The attribute is handled before the tree -> rtl conversion so some
code has to be added
   in the C source code and this code removes the attribute from the
tree once it has
   finished its job.
 - the attribute is handled during the tree -> rtl conversion so some
code is added in the .md
   file and gcc consider the attribute node of the tree as an UNSPEC rtx class.
   After what it looks for an rtx pattern which match with this UNSPEC.
   Therefore, I can consider the following relationship:

   (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
        |                           |                    |
               |
       \/                          \/                   \/
              \/
       int *                 __attribute__((far("fs")))                      p;

If these are right, I have some questions:
 - does (reg:HI fs) care about the type of the parameter fs ? (a
string in the C code)
 - how does gcc recognize such an expression ? I mean (reg:SI var) is
a register in SImode
   but there is no indication about the storage of p in the C souce.
Does it begin by
   identifying that the pattern matches the unspec and then try to put
p in a register as
   written in the pattern?

Thanks for your help.
Have a great day.


--
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Rémy Saissy]

>You won't be able to.  You're going to need to write your own code that,
>during the conversion of the tree to RTL, creates RTL expressions which
>indicate that the memory references use segment registers.  This probably
>won't be easy since there are a lot of contexts where your "far" pointer
>can be used.  I suspect this is where you're going to give up on your
>project, but if you do then RTL expressions you'll need to create should
>probably look like:

>	(mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))

>After getting GCC to generate expressions like these, then it's a
>realtively simple case of modifying ix86_decompose_address() to handle
>the unspec.  You might also need to change other backend code for
>handling addresses.

>					Ross Ridge

Thanks for your precisions.


-- 
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Ross Ridge]

Remy Saissy wrote:
>I don't really understand how to access the attribute set up in the
>tree in the rtx struct.

You won't be able to.  You're going to need to write your own code that,
during the conversion of the tree to RTL, creates RTL expressions which
indicate that the memory references use segment registers.  This probably
won't be easy since there are a lot of contexts where your "far" pointer
can be used.  I suspect this is where you're going to give up on your
project, but if you do then RTL expressions you'll need to create should
probably look like:

	(mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))

After getting GCC to generate expressions like these, then it's a
realtively simple case of modifying ix86_decompose_address() to handle
the unspec.  You might also need to change other backend code for
handling addresses. 

					Ross Ridge

Re: Segment registers support for i386

[Rémy Saissy]

Hi people,
I added an attribute "far" for the i386, this attribute takes one
argument, the segment register.
This attribute is intended to be use with pointers.
There is something I'm not sure about
Once the attribute handler has returned NULL_TREE without setting
no_add_attr to true, the atribute is added in the ssa tree but how to
handle this attribute after ?
I must check and handle this attribute when gcc writes the .S file
therefore in print_operand_address().
My problem is that print_operand_address use and rtx structure and not
a tree one and
I don't really understand how to access the attribute set up in the
tree in the rtx struct.
The patch for TLS model which uses %gs uses UNSPEC_TP and added some code in
ix86_decompose_address() to check for an UNSPEC code. ok but in the
same time there
is some patterns defined in i386.md for UNSPEC and if I do the same,
I'll probablty end up
by modifying most of the patterns of the file to handle a new UNSPEC
for the attribute.
It seems to be too ugly so I was wondering if there is another way to do it.
Thanks.
Have a great day.


-- 
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Rask Ingemann Lambertsen]

On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
 
> To manage the manipulation of the register class, I added entries in
> the i386.md file.
> 
> ;; get a value from a segment register.
> (define_insn "store_seg"
>  [(set (match_operand:SI 0 "nonimmediate_operand" "")
>        (match_operand:SI 1 "general_operand" "s"))]
>        ""
>        "movl\t%1,%0")
> 
> ;; set a value in a segment register.
> (define_insn "load_seg"
>  [(set (match_operand:SI 0 "general_operand" "=s")
>        (match_operand:SI 1 "register_operand" ""))]
>        ""
>        "movl\t%1,%0")

I think you'll have to add "s" alternatives to the *movhi pattern instead of
adding two new patterns, since otherwise there will be two nearly identical
patterns and GCC might use the wrong one. If you need patterns named
"store_seg" and "load_seg", use an expander.

-- 
Rask Ingemann Lambertsen

Re: Segment registers support for i386

[Rémy Saissy]

On 5/15/06, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:
> On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
> > To manage the manipulation of the register class, I added entries in
> > the i386.md file.
> >
> > ;; get a value from a segment register.
> > (define_insn "store_seg"
> >  [(set (match_operand:SI 0 "nonimmediate_operand" "")
> >        (match_operand:SI 1 "general_operand" "s"))]
> >        ""
> >        "movl\t%1,%0")
>
> Operand 0 should have a constraint of "=rm" or so. Operand 1 should have a
> predicate of "register_operand".
>
> > ;; set a value in a segment register.
> > (define_insn "load_seg"
> >  [(set (match_operand:SI 0 "general_operand" "=s")
> >        (match_operand:SI 1 "register_operand" ""))]
> >        ""
> >        "movl\t%1,%0")
>
> Operand 1 should have a predicate of "nonimmediate_operand" and a constraint
> of "rm".
>
> Also, aren't the segment registers HImode registers? Above, you wrote:
>
> >    register short a __asm__ ("es");
>               ^^^^^
> And have you adjusted HARD_REGNO_MODE_OK() and HARD_REGNO_NREGS() accordingly?
>
Thank you for your suggestions, I have fixed it and modified the
HARD_REGNO_MODE_OK() and HARD_REGNO_NREGS() as you told me.
However, the compilation of gcc still fails but with another error:
../.././gcc/libgcc2.c:1477: error: unable to generate reloads for:
(insn 61 60 62 1 ../.././gcc/libgcc2.c:1475 (set (reg:HI 0 ax [70])
        (mem/c:HI (plus:SI (reg/f:SI 6 bp)
                (const_int -2 [0xfffffffe])) [0 S2 A8])) 29 {load_seg} (nil)
    (nil))
../.././gcc/libgcc2.c:1477: internal compiler error: in find_reloads,
at reload.c:3734
Please submit a full bug report,

If I'm not wrong, this is when the compiler compiles itself with a
freshly generated binary.
Since I don't want to let the register allocator decide by itself
which segment register to use
(there is no need of it in fact), I tried to set the entries in
FIXED_REGISTERS to 0 instead of 1 but I still get the error.
I think it is not normal to have this error since no code use the 's'
__asm__() in gcc source and since the segment registers are in a
different class but I don't really know how to fix it.
What should I modify in the i386.{c,h,md}?
Thank you very much.


-- 
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Rask Ingemann Lambertsen]

On Mon, May 15, 2006 at 12:09:00AM +0800, Rémy Saissy wrote:
> To manage the manipulation of the register class, I added entries in
> the i386.md file.
> 
> ;; get a value from a segment register.
> (define_insn "store_seg"
>  [(set (match_operand:SI 0 "nonimmediate_operand" "")
>        (match_operand:SI 1 "general_operand" "s"))]
>        ""
>        "movl\t%1,%0")

Operand 0 should have a constraint of "=rm" or so. Operand 1 should have a
predicate of "register_operand".

> ;; set a value in a segment register.
> (define_insn "load_seg"
>  [(set (match_operand:SI 0 "general_operand" "=s")
>        (match_operand:SI 1 "register_operand" ""))]
>        ""
>        "movl\t%1,%0")

Operand 1 should have a predicate of "nonimmediate_operand" and a constraint
of "rm".

Also, aren't the segment registers HImode registers? Above, you wrote:

>    register short a __asm__ ("es");
              ^^^^^
And have you adjusted HARD_REGNO_MODE_OK() and HARD_REGNO_NREGS() accordingly?

-- 
Rask Ingemann Lambertsen

Re: Segment registers support for i386

[Rémy Saissy]

Hi everybody,
I decided to split the modification in two parts:
 - add an __asm__ () statement to control the value of
   the segment registers from an high level language;
   This __asm__ () statement is then used as follow:
    register short a __asm__ ("es");

    int main(int argc, char **argv)
     {
	short b;

	b = a;
	a = 0x2a;
	printf("old value: %x new value: %x\n", b, a);
	return (0);
     }

 - add an __attribute__ ((__far__())) to allow pointers to
   choose their data segment.
   This __attribute__(()) statement is then used as follow:
	int	*gs_p __attribute__ ((__far__("gs"))) = 0x2a;

   int main(int argc, char **argv)
    {
	int	*fs_p __attribute__((__far__("fs"))) = 0x0;

	fs_p[1] = 10;
	gs_p[0] = fs_p[0];
	return (0);
    }

 Presently I have a problem with the first part.
 I have added the the entries for es,fs and gs at the end of
 FIXED_REGISTERS under the value 1,1,1 and in
 CALL_USED_REGISTERS with the value 1,1,1
 I also add the entries at the end of REG_ALLOC_ORDER and in
 both HI_REGISER_NAMES and ADDITIONAL_REGISTER_NAMES.
 Because those registers are different, I have created a new
 register class at the end of the reg_class enum and added
 the relevant REG_CLASS_NAMES and REG_CLASS_CONTENTS entries.
 At least, I added the 's' id in REG_CLASS_FROM_LETTER.

To manage the manipulation of the register class, I added entries in
the i386.md file.

;; get a value from a segment register.
(define_insn "store_seg"
  [(set (match_operand:SI 0 "nonimmediate_operand" "")
        (match_operand:SI 1 "general_operand" "s"))]
        ""
        "movl\t%1,%0")

;; set a value in a segment register.
(define_insn "load_seg"
  [(set (match_operand:SI 0 "general_operand" "=s")
        (match_operand:SI 1 "register_operand" ""))]
        ""
        "movl\t%1,%0")

I think I did everything needed to make it working but when I compile
gcc I get the following error:
../.././gcc/crtstuff.c:301: error: unable to generate reloads for:
(insn:HI 17 15 18 1 (set (reg:SI 0 ax [orig:62 p.25 ] [62])
        (mem/f/c/i:SI (symbol_ref:SI ("p.5512") [flags 0x2] <var_decl
0x3b01dc60 p>) [7 p+0 S4 A32])) 28 {store_seg} (nil)
    (nil))
../.././gcc/crtstuff.c:301: internal compiler error: in find_reloads,
at reload.c:3734
Please submit a full bug report,
[...]

This is the 4.1.0 version of the compiler.
If somebody can light me... Thanks.


-- 
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Rémy Saissy]

On 4/4/06, Andrew Haley <aph@redhat.com> wrote:
> Rémy Saissy writes:
>
>  > > It would take a massive target-specific backend hack to make that
>  > > happen, as GCC > currently only supports flat address spaces. ;-)
>  >
>  > I don't understand why.
>  > gcc currently consider every data access on i386 to be %ds:offset or %ss:offset
>  > depending on the instruction.
>
> No, that's not true.  gcc doesn't know about %ds or %ss.

oh sorry. that's what I though but It seems I explained it with a bad english ;)

>
>  > The purpose is only to add a way to explicitly indicate the section
>  > to use then is could be %gs:offset or %fs:offset.
>  >
>  > I'm new in gcc hacking therefore I still have to learn more about the
>  > internals but
>  > at first glance it doesn't sounds like a so big work.
>
> You'd have to teach gcc about different address spaces.  For example,
> gcc would have to know that %gs:foo couldn't be accessed via %ds.
>

Ok. thanks you too for your anwers, I'll try to do something good now ;)
Have a great day.



--
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Andrew Haley]

Rémy Saissy writes:

 > > It would take a massive target-specific backend hack to make that
 > > happen, as GCC > currently only supports flat address spaces. ;-)
 > 
 > I don't understand why.
 > gcc currently consider every data access on i386 to be %ds:offset or %ss:offset
 > depending on the instruction.

No, that's not true.  gcc doesn't know about %ds or %ss.

 > The purpose is only to add a way to explicitly indicate the section
 > to use then is could be %gs:offset or %fs:offset.
 > 
 > I'm new in gcc hacking therefore I still have to learn more about the
 > internals but
 > at first glance it doesn't sounds like a so big work.

You'd have to teach gcc about different address spaces.  For example,
gcc would have to know that %gs:foo couldn't be accessed via %ds.

Andrew.

Re: Segment registers support for i386

[Rémy Saissy]

> It would take a massive target-specific backend hack to make that happen, as GCC > currently only supports flat address spaces. ;-)

I don't understand why.
gcc currently consider every data access on i386 to be %ds:offset or %ss:offset
depending on the instruction. The purpose is only to add a way to
explicitly indicate
the section to use then is could be %gs:offset or %fs:offset.

I'm new in gcc hacking therefore I still have to learn more about the
internals but
at first glance it doesn't sounds like a so big work.
Could you explain me why do you think it would take a massive
target-specific backend ?
Thanks a lot.


--
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

Re: Segment registers support for i386

[Lucas (a.k.a T-Bird or bsdfan3)]

It would take a massive target-specific backend hack to make that 
happen, as GCC currently only supports flat address spaces. ;-)

Rémy Saissy wrote:

>Hi everybody,
>I'm looking for gcc support of x86-32 segment registers but the only information
>I've found about it is in this old thread:
>http://gcc.gnu.org/ml/gcc/1999-12/msg00526.html
>I was wondering what happened since this thread, does somebody have integrated
>the segment register support for i386 in gcc ?
>There is nothing about it in the manual pages and gcc 4.0.3 doesn't
>seem to support it.
>Thank for your precisions.
>Have a great day.
>
>
>--
>Rémy Saissy            JabberID: remy.saissy@jabber.fr
>                                Web:     http://remysaissy.free.fr
>"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
>mais celui qui a le plus senti la vie."
>J.-J. Rousseau, Emile.
>  
>

Segment registers support for i386

[Rémy Saissy]

Hi everybody,
I'm looking for gcc support of x86-32 segment registers but the only information
I've found about it is in this old thread:
http://gcc.gnu.org/ml/gcc/1999-12/msg00526.html
I was wondering what happened since this thread, does somebody have integrated
the segment register support for i386 in gcc ?
There is nothing about it in the manual pages and gcc 4.0.3 doesn't
seem to support it.
Thank for your precisions.
Have a great day.


--
Rémy Saissy            JabberID: remy.saissy@jabber.fr
                                Web:     http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.