This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Segment register support for the i386


In article <576.946299306@upchuck>, Jeffrey A Law  <law@cygnus.com> wrote:
>
>Yes CSE and other passes would all have to know about this kind of
>stuff.  Though I don't think it would be that nasty since a seg + offset
>pointer would have a different mode than just an offset pointer.
>
>The tougher problem is the general infrastructure to have pointers of
>differing sizes, supporting partial mode arithmetic, and ABI issues with
>segment/space registers.

I think that the original suggestion was NOT to support 48-bit pointers
on x86 (which is basically damn hard to do efficiently, because you end
up with a new class or register reload issues to get efficient segment
register usage), but to simply support standard 32-bit pointers that
just are in a different "address space". 

This is not a x86-only issue per se: it's more akin to the difference
between "data" and "code" address spaces - both may be 32-bit pointers,
but that doesn't mean that they have anything else in common.

The "data" vs "code" thing is much easier, because obviously in C you
can't ever dereference a code pointer for data (you can cast it to a
data pointer type, but then you lose the "codeness" of it if the
architecture has two separate address spaces).  So you never have any
issues with CSE etc on dereferencing the stuff. 

I think Java has this issue: you have "stack" vs "data" pointers, but
then Java as a language doesn't actually let you play games with them,
so again that rats-nest is avoided too. 

So what I think the original poster was after was more of a

 "Ok, I've set up %fs to be a thread-specific pointer, and %gs points to
  the global segment, and now I want gcc to treat this 32-bit pointer as
  a 'fs' pointer and that other 32-bit pointer as a 'gs' pointer, while
  the "normal" cases are all the default ds=ss pointer case"

So it wouldn't ever be a case of "seg + offset". It would always be just
"offset" together with a "address space attribute".

That sounds easier to me than a full "different pointer lengths" kind of
thing, modulo the CSE kind of issues.. 

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]