Re: about named address space

Re: about named address space

[Rony Paul]

Rony Paul <ronypaul77@gmail.com> writes:

> On Wed, May 4, 2011 at 4:35 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Rony Paul <ronypaul77@gmail.com> writes:
>>
>>> Thank you for your reply. I am new in this development. so I am askig
>>> you Âvery basic question. I dont have enough knowledge on "backend",
>>> what did you man with this term?
>>>
>>> my task is to use one memory space as big endian, other as little
>>> endian, and to use Âcopying of pointer from 1 memory space to another.
>>> Just tell me what should be my beggining step? which files I should modify?
>>
>> Please reply to the mailing list, not just to me. ÂAlso, please don't
>> top-post. ÂThanks.
>>
>> Re: backend: See http://en.wikipedia.org/wiki/Compilers . ÂIn gcc the
>> backend is the CPU-specific code in config/CPU.
>>
>> You haven't said anything about your target. ÂIs your memory different
>> at the hardware level? ÂIf not, named address spaces are probably not
>> the right approach.
>>
>> Ian
>>
>>
>>> Rony Paul <ronypaul77@gmail.com> writes:
>>>
>>>> I want to use named address space support to allow mixed endian
>>>> applications. Specifying the endianness of address spaces.
>>>> Can you suggest me what should I do in this purpose? and which files I
>>>> need to modify ?
>>>
>>> In general named address space is described here:
>>>
>>> http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html
>>>
>>> You didn't mention which backend you are using and you didn't mention
>>> how you mean to handle pointers to an address space of different
>>> endianness. ÂNamed address spaces seem appropriate if some of your
>>> memory is big-endian and some is little-endian. ÂI don't know whether
>>> they are appropriate if you want to have both big-endian and
>>> little-endian pointers to the same area of memory.
>>>
>>> Ian
>>
> Thank you for the reply.
>
> Yes I have separate memory at the hardware level. And as far I learnt
> that named address space is already implemented for SPU processor. SPU
> port uses the __ea address space to refer to memory in the host
> processor, rather than memory local to the SPU processor.
> I am now just in the learning phase. SO , if I want to modify that
> code (just to learn) and want to add one more address space keyword
> like "__ea"............what should I do?

Start by reading the link I mentioned above:

http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html

That explains what you do to add more address spaces.  It requires
modifying the gcc source code and rebuilding gcc.

Ian


Dear Ian,

Thanks for your help. I have started according to the mentioned link.
And I could give support for another address space. what I want to do
now is, I want to store data in different byte order in the new
address space. that is, suppose I have 2 address spaces supported. 1.)
Generic address space. 2.) __net address space.

when some variable is declared in the __net address space, I will
store in Bigendian order. , and whrn variable is declared in generic
address space, It will store in little Endian order.

Do you have any suggestion or idea??

-Rony

Re: about named address space

[Rony Paul]

On Tue, May 17, 2011 at 5:35 PM, Rony Paul <ronypaul77@gmail.com> wrote:
> Rony Paul <ronypaul77@gmail.com> writes:
>
>> On Wed, May 4, 2011 at 4:35 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> Rony Paul <ronypaul77@gmail.com> writes:
>>>
>>>> Thank you for your reply. I am new in this development. so I am askig
>>>> you Âvery basic question. I dont have enough knowledge on "backend",
>>>> what did you man with this term?
>>>>
>>>> my task is to use one memory space as big endian, other as little
>>>> endian, and to use Âcopying of pointer from 1 memory space to another.
>>>> Just tell me what should be my beggining step? which files I should modify?
>>>
>>> Please reply to the mailing list, not just to me. ÂAlso, please don't
>>> top-post. ÂThanks.
>>>
>>> Re: backend: See http://en.wikipedia.org/wiki/Compilers . ÂIn gcc the
>>> backend is the CPU-specific code in config/CPU.
>>>
>>> You haven't said anything about your target. ÂIs your memory different
>>> at the hardware level? ÂIf not, named address spaces are probably not
>>> the right approach.
>>>
>>> Ian
>>>
>>>
>>>> Rony Paul <ronypaul77@gmail.com> writes:
>>>>
>>>>> I want to use named address space support to allow mixed endian
>>>>> applications. Specifying the endianness of address spaces.
>>>>> Can you suggest me what should I do in this purpose? and which files I
>>>>> need to modify ?
>>>>
>>>> In general named address space is described here:
>>>>
>>>> http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html
>>>>
>>>> You didn't mention which backend you are using and you didn't mention
>>>> how you mean to handle pointers to an address space of different
>>>> endianness. ÂNamed address spaces seem appropriate if some of your
>>>> memory is big-endian and some is little-endian. ÂI don't know whether
>>>> they are appropriate if you want to have both big-endian and
>>>> little-endian pointers to the same area of memory.
>>>>
>>>> Ian
>>>
>> Thank you for the reply.
>>
>> Yes I have separate memory at the hardware level. And as far I learnt
>> that named address space is already implemented for SPU processor. SPU
>> port uses the __ea address space to refer to memory in the host
>> processor, rather than memory local to the SPU processor.
>> I am now just in the learning phase. SO , if I want to modify that
>> code (just to learn) and want to add one more address space keyword
>> like "__ea"............what should I do?
>
> Start by reading the link I mentioned above:
>
> http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html
>
> That explains what you do to add more address spaces.  It requires
> modifying the gcc source code and rebuilding gcc.
>
> Ian
>
>
> Dear Ian,
>
> Thanks for your help. I have started according to the mentioned link.
> And I could give support for another address space. what I want to do
> now is, I want to store data in different byte order in the new
> address space. that is, suppose I have 2 address spaces supported. 1.)
> Generic address space. 2.) __net address space.
>
> when some variable is declared in the __net address space, I will
> store in Bigendian order. , and whrn variable is declared in generic
> address space, It will store in little Endian order.
>
> Do you have any suggestion or idea??
>
> -Rony
>

Hello,

Can you explain me the following piece of code?

      rtx result, ls;

      ls = gen_const_mem (DImode,
			  gen_rtx_SYMBOL_REF (Pmode, "__ea_local_store"));
      set_mem_align (ls, 128);

      result = gen_reg_rtx (Pmode);
      ls = force_reg (Pmode, convert_modes (Pmode, DImode, ls, 1));
      op = force_reg (Pmode, convert_modes (Pmode, EAmode, op, 1));
      ls = emit_conditional_move (ls, NE, op, const0_rtx, Pmode,
					  ls, const0_rtx, Pmode, 1);

      emit_insn (gen_subsi3 (result, op, ls));


-Rony

Re: about named address space

[Ian Lance Taylor]

Rony Paul <ronypaul77@gmail.com> writes:

> Can you explain me the following piece of code?
>
>       rtx result, ls;
>
>       ls = gen_const_mem (DImode,
> 			  gen_rtx_SYMBOL_REF (Pmode, "__ea_local_store"));

Build a memory reference to the address __ea_local_store in DImode
(64-bit).

>       set_mem_align (ls, 128);

Set the alignment of that memory to 128 bits.

>       result = gen_reg_rtx (Pmode);

Build a pseudo-register of type Pmode.

>       ls = force_reg (Pmode, convert_modes (Pmode, DImode, ls, 1));

Copy ls to a new pseudo-register, converting it from DImode to Pmode.

>       op = force_reg (Pmode, convert_modes (Pmode, EAmode, op, 1));

Copy op to a new pseudo-register, converting it from EAmode to Pmode.

>       ls = emit_conditional_move (ls, NE, op, const0_rtx, Pmode,
> 					  ls, const0_rtx, Pmode, 1);

Equivalent to ls = op != 0 ? ls : 0.

>       emit_insn (gen_subsi3 (result, op, ls));

Equivalent to result = op - ls.

So basically if op is not 0, this subtracts __ea_local_store from it.

Ian

Re: about named address space

[Rony Paul]

On Sat, May 21, 2011 at 8:19 AM, Ian Lance Taylor <iant@google.com> wrote:
> Rony Paul <ronypaul77@gmail.com> writes:
>
>> Can you explain me the following piece of code?
>>
>>       rtx result, ls;
>>
>>       ls = gen_const_mem (DImode,
>>                         gen_rtx_SYMBOL_REF (Pmode, "__ea_local_store"));
>
> Build a memory reference to the address __ea_local_store in DImode
> (64-bit).
>
>>       set_mem_align (ls, 128);
>
> Set the alignment of that memory to 128 bits.
>
>>       result = gen_reg_rtx (Pmode);
>
> Build a pseudo-register of type Pmode.
>
>>       ls = force_reg (Pmode, convert_modes (Pmode, DImode, ls, 1));
>
> Copy ls to a new pseudo-register, converting it from DImode to Pmode.
>
>>       op = force_reg (Pmode, convert_modes (Pmode, EAmode, op, 1));
>
> Copy op to a new pseudo-register, converting it from EAmode to Pmode.
>
>>       ls = emit_conditional_move (ls, NE, op, const0_rtx, Pmode,
>>                                         ls, const0_rtx, Pmode, 1);
>
> Equivalent to ls = op != 0 ? ls : 0.
>
>>       emit_insn (gen_subsi3 (result, op, ls));
>
> Equivalent to result = op - ls.
>
> So basically if op is not 0, this subtracts __ea_local_store from it.
>
> Ian
>

Hello,

I user declare a variable "x", then when compiler executes that and
stores in memory, can  you tell me what is the rtx code for storing
that variable? and in which file in GCC it is done?

-Rony

Re: about named address space

[Ian Lance Taylor]

Rony Paul <ronypaul77@gmail.com> writes:

> I user declare a variable "x", then when compiler executes that and
> stores in memory, can  you tell me what is the rtx code for storing
> that variable? and in which file in GCC it is done?

It's difficult to answer that question in a simple way.  Assuming you
are using C, the C frontend will create a VAR_DECL for x.  If you assign
a value to that variable, it will create a MODIFY_EXPR.  The MODIFY_EXPR
will then be converted to a GIMPLE_ASSIGN statement in GIMPLE.  This
will then eventually be converted to an RTL SET.  So the rtx code is
SET.  If this is a local variable which is stored in memory rather than
in a register, the stack space will be allocated by assign_stack_local.

Ian

Re: about named address space

[Rony Paul]

On Tue, May 24, 2011 at 4:22 PM, Ian Lance Taylor <iant@google.com> wrote:
>
> Rony Paul <ronypaul77@gmail.com> writes:
>
> > I user declare a variable "x", then when compiler executes that and
> > stores in memory, can  you tell me what is the rtx code for storing
> > that variable? and in which file in GCC it is done?
>
> It's difficult to answer that question in a simple way.  Assuming you
> are using C, the C frontend will create a VAR_DECL for x.  If you assign
> a value to that variable, it will create a MODIFY_EXPR.  The MODIFY_EXPR
> will then be converted to a GIMPLE_ASSIGN statement in GIMPLE.  This
> will then eventually be converted to an RTL SET.  So the rtx code is
> SET.  If this is a local variable which is stored in memory rather than
> in a register, the stack space will be allocated by assign_stack_local.
>
> Ian

suppose I have the following piece of code in my program.

  extern  int __ea x;
  int y;
  y = x;

that means I am copying data from one address space to another.
in that case will the method spu_addr_space_convert (rtx op, tree
from_type, tree to_type);  be called by the compiler?
in the spu.c file the defination of " spu_addr_space_convert " is
given. but when and under which condition they will be called ?where
is it defined?

Re: about named address space

[Ian Lance Taylor]

Rony Paul <ronypaul77@gmail.com> writes:

> suppose I have the following piece of code in my program.
>
>   extern  int __ea x;
>   int y;
>   y = x;
>
> that means I am copying data from one address space to another.
> in that case will the method spu_addr_space_convert (rtx op, tree
> from_type, tree to_type);  be called by the compiler?
> in the spu.c file the defination of " spu_addr_space_convert " is
> given. but when and under which condition they will be called ?

I'm pretty sure it won't be called.  That function converts a pointer to
one address space into a pointer to a different address space.  No such
conversion is happening here.

> where
> is it defined?

The function spu_addr_space_convert is the SPU-specific implementation
of the target hook TARGET_ADDR_SPACE_CONVERT which is documented in the
section on named address spaces.

Ian

Re: about named address space

[Rony Paul]

On Fri, May 27, 2011 at 4:51 PM, Ian Lance Taylor <iant@google.com> wrote:
> Rony Paul <ronypaul77@gmail.com> writes:
>
>> suppose I have the following piece of code in my program.
>>
>>   extern  int __ea x;
>>   int y;
>>   y = x;
>>
>> that means I am copying data from one address space to another.
>> in that case will the method spu_addr_space_convert (rtx op, tree
>> from_type, tree to_type);  be called by the compiler?
>> in the spu.c file the defination of " spu_addr_space_convert " is
>> given. but when and under which condition they will be called ?
>
> I'm pretty sure it won't be called.  That function converts a pointer to
> one address space into a pointer to a different address space.  No such
> conversion is happening here.
>
>> where
>> is it defined?
>
> The function spu_addr_space_convert is the SPU-specific implementation
> of the target hook TARGET_ADDR_SPACE_CONVERT which is documented in the
> section on named address spaces.
>
> Ian
>


Then if I want to prevent these type of copying data from one address
space to another (ie. I dont want to allow these type of copy
operation in my application). where should I write code in GCC
compiler?

Actually I can define different address space, but still I cant store
there data in different byte order. would you give me any idea about
how to store data in different byte order in different address space?

-Rony
 please suggest me,

Re: about named address space

[Rony Paul]

On Mon, Jun 6, 2011 at 11:34 AM, Rony Paul <ronypaul77@gmail.com> wrote:
> On Fri, May 27, 2011 at 4:51 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Rony Paul <ronypaul77@gmail.com> writes:
>>
>>> suppose I have the following piece of code in my program.
>>>
>>>   extern  int __ea x;
>>>   int y;
>>>   y = x;
>>>
>>> that means I am copying data from one address space to another.
>>> in that case will the method spu_addr_space_convert (rtx op, tree
>>> from_type, tree to_type);  be called by the compiler?
>>> in the spu.c file the defination of " spu_addr_space_convert " is
>>> given. but when and under which condition they will be called ?
>>
>> I'm pretty sure it won't be called.  That function converts a pointer to
>> one address space into a pointer to a different address space.  No such
>> conversion is happening here.
>>
>>> where
>>> is it defined?
>>
>> The function spu_addr_space_convert is the SPU-specific implementation
>> of the target hook TARGET_ADDR_SPACE_CONVERT which is documented in the
>> section on named address spaces.
>>
>> Ian
>>
>
>
> Then if I want to prevent these type of copying data from one address
> space to another (ie. I dont want to allow these type of copy
> operation in my application). where should I write code in GCC
> compiler?
>
> Actually I can define different address space, but still I cant store
> there data in different byte order. would you give me any idea about
> how to store data in different byte order in different address space?
>
> -Rony
>  please suggest me,
>

in c-type.c file there are some code like :
===========================================================
 asl = TYPE_ADDR_SPACE (ttl);
 asr = TYPE_ADDR_SPACE (ttr);
      if (!null_pointer_constant_p (rhs)
	  && asr != asl && !targetm.addr_space.subset_p (asr, asl))
	{
	  switch (errtype)
	    {
	    case ic_argpass:
	      error_at (location, "passing argument %d of %qE from pointer to "
			"non-enclosed address space", parmnum, rname);
	      break;
	    case ic_assign:
	      error_at (location, "assignment from pointer to "
			"non-enclosed address space");
	      break;
	    case ic_init:
	      error_at (location, "initialization from pointer to "
			"non-enclosed address space");
	      break;
	    case ic_return:
	      error_at (location, "return from pointer to "
			"non-enclosed address space");
	      break;
	    default:
	      gcc_unreachable ();
	    }
	  return error_mark_node;
	}
-==================================================================

and in my program if I write code like,
 __ea int * p = malloc_ea(sizeof(int));
   int * v;
   p=v;

this returns error message  "assignment from pointer to non-enclosed
address space"
so, this checking for pointer of the different address space is done
for pointer. now if I want to add this check for data variable also,
what should I do. I cant understand, would you please help me?

ie. I want to write code like

extern  int __ea x;
int y;

and it should give error message like
"assignment from variable to non-enclosed address space"


Thanks

Re: about named address space

[Ian Lance Taylor]

Rony Paul <ronypaul77@gmail.com> writes:

> and in my program if I write code like,
>  __ea int * p = malloc_ea(sizeof(int));
>    int * v;
>    p=v;
>
> this returns error message  "assignment from pointer to non-enclosed
> address space"
> so, this checking for pointer of the different address space is done
> for pointer. now if I want to add this check for data variable also,
> what should I do. I cant understand, would you please help me?
>
> ie. I want to write code like
>
> extern  int __ea x;
> int y;
>
> and it should give error message like
> "assignment from variable to non-enclosed address space"

I'm not aware of any support in current gcc for anything like that.  In
effect you are asking not for named address spaces, but for a brand new
type.  You want to permit pointers to your new type, but you don't want
to permit assignments between values of your new type and the old types.
I suspect that the most straightforward way to handle this would be to
do it entirely in the frontend, which is where types are handled.  I
suppose you could tie it into named address spaces to the extent that
you want values of your new type to be aggregated into specific areas in
memory.

In short I don't know of any easy way to do what you want.

Ian

Re: about named address space

[Ian Lance Taylor]

Rony Paul <ronypaul77@gmail.com> writes:

> On Wed, May 4, 2011 at 4:35 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Rony Paul <ronypaul77@gmail.com> writes:
>>
>>> Thank you for your reply. I am new in this development. so I am askig
>>> you  very basic question. I dont have enough knowledge on "backend",
>>> what did you man with this term?
>>>
>>> my task is to use one memory space as big endian, other as little
>>> endian, and to use  copying of pointer from 1 memory space to another.
>>> Just tell me what should be my beggining step? which files I should modify?
>>
>> Please reply to the mailing list, not just to me.  Also, please don't
>> top-post.  Thanks.
>>
>> Re: backend: See http://en.wikipedia.org/wiki/Compilers .  In gcc the
>> backend is the CPU-specific code in config/CPU.
>>
>> You haven't said anything about your target.  Is your memory different
>> at the hardware level?  If not, named address spaces are probably not
>> the right approach.
>>
>> Ian
>>
>>
>>> Rony Paul <ronypaul77@gmail.com> writes:
>>>
>>>> I want to use named address space support to allow mixed endian
>>>> applications. Specifying the endianness of address spaces.
>>>> Can you suggest me what should I do in this purpose? and which files I
>>>> need to modify ?
>>>
>>> In general named address space is described here:
>>>
>>> http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html
>>>
>>> You didn't mention which backend you are using and you didn't mention
>>> how you mean to handle pointers to an address space of different
>>> endianness.  Named address spaces seem appropriate if some of your
>>> memory is big-endian and some is little-endian.  I don't know whether
>>> they are appropriate if you want to have both big-endian and
>>> little-endian pointers to the same area of memory.
>>>
>>> Ian
>>
> Thank you for the reply.
>
> Yes I have separate memory at the hardware level. And as far I learnt
> that named address space is already implemented for SPU processor. SPU
> port uses the __ea address space to refer to memory in the host
> processor, rather than memory local to the SPU processor.
> I am now just in the learning phase. SO , if I want to modify that
> code (just to learn) and want to add one more address space keyword
> like "__ea"............what should I do?

Start by reading the link I mentioned above:

http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html

That explains what you do to add more address spaces.  It requires
modifying the gcc source code and rebuilding gcc.

Ian

Re: about named address space

[Rony Paul]

On Wed, May 4, 2011 at 4:35 PM, Ian Lance Taylor <iant@google.com> wrote:
> Rony Paul <ronypaul77@gmail.com> writes:
>
>> Thank you for your reply. I am new in this development. so I am askig
>> you  very basic question. I dont have enough knowledge on "backend",
>> what did you man with this term?
>>
>> my task is to use one memory space as big endian, other as little
>> endian, and to use  copying of pointer from 1 memory space to another.
>> Just tell me what should be my beggining step? which files I should modify?
>
> Please reply to the mailing list, not just to me.  Also, please don't
> top-post.  Thanks.
>
> Re: backend: See http://en.wikipedia.org/wiki/Compilers .  In gcc the
> backend is the CPU-specific code in config/CPU.
>
> You haven't said anything about your target.  Is your memory different
> at the hardware level?  If not, named address spaces are probably not
> the right approach.
>
> Ian
>
>
>> Rony Paul <ronypaul77@gmail.com> writes:
>>
>>> I want to use named address space support to allow mixed endian
>>> applications. Specifying the endianness of address spaces.
>>> Can you suggest me what should I do in this purpose? and which files I
>>> need to modify ?
>>
>> In general named address space is described here:
>>
>> http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html
>>
>> You didn't mention which backend you are using and you didn't mention
>> how you mean to handle pointers to an address space of different
>> endianness.  Named address spaces seem appropriate if some of your
>> memory is big-endian and some is little-endian.  I don't know whether
>> they are appropriate if you want to have both big-endian and
>> little-endian pointers to the same area of memory.
>>
>> Ian
>
Thank you for the reply.

Yes I have separate memory at the hardware level. And as far I learnt
that named address space is already implemented for SPU processor. SPU
port uses the __ea address space to refer to memory in the host
processor, rather than memory local to the SPU processor.
I am now just in the learning phase. SO , if I want to modify that
code (just to learn) and want to add one more address space keyword
like "__ea"............what should I do?

And if I could change it, then my final target is to add named address
support for different endianess for i386.


- Rony

Re: about named address space

[Ian Lance Taylor]

Rony Paul <ronypaul77@gmail.com> writes:

> I want to use named address space support to allow mixed endian
> applications. Specifying the endianness of address spaces.
> Can you suggest me what should I do in this purpose? and which files I
> need to modify ?

In general named address space is described here:

http://gcc.gnu.org/onlinedocs/gccint/Named-Address-Spaces.html

You didn't mention which backend you are using and you didn't mention
how you mean to handle pointers to an address space of different
endianness.  Named address spaces seem appropriate if some of your
memory is big-endian and some is little-endian.  I don't know whether
they are appropriate if you want to have both big-endian and
little-endian pointers to the same area of memory.

Ian

about named address space

[Rony Paul]

I want to use named address space support to allow mixed endian
applications. Specifying the endianness of address spaces.
Can you suggest me what should I do in this purpose? and which files I
need to modify ?

Thanks and best regards.