Segment register support for the i386

[Linus Torvalds]

In article < 199912301755.SAA01528@delius.kettenis.local >,
Mark Kettenis  <kettenis@wins.uva.nl> wrote:
>
>It would be nice if I could write:
>
>   register struct thread_descr *__thread_self __asm__("%gs");
>
>such that I could use the same C code as in the Sparc case to access
>and manipulate the thread descriptor.  It seems that it isn't that
>hard to implement this in GCC.  I managed to get this working by only
>changing a few lines of code in the i386 back-end code.

Hmm..  Using the segment registers as "real" pointers in C kind of makes
sense, but at the same time it does sound confusing.  You cannot do a
lot of the operations that you are supposed to do with a pointer, and
that lack of true "pointerness" makes it suspect.  What would happen
when somebody converts the pointer to an integer?

>That's why I'm not sure if this approach is acceptable, and I'd like
>to hear what other people think of this proposal before spending too
>much time on finishing my current implementation.  I can imagine that
>people say that this extension is really an ugly hack that should
>never be allowed in GCC.

How about another approach entirely: think of segments not as pointers
(which they really aren't, not in the C sense), but as _objects_.  Which
they really were meant to be, after all.  Never mind the fact that it
never really worked out very well. 

Now, if done right, you could do this with a C++ approach, methinks. 
I'm not a big fan of C++ myself, but you could think of it as a minor
extension to C rather than having to go full hog.  So what you could
have is something like the "%fs segment object", and then you overload
the assignment and dereference operations, so that you have

	fs_object *thread_ptr;

	y = thread_ptr->tid;

where the dereference gets transformed by the C++ upper layers into

	__asm__("movl %%fs:%0,%1": :"m" (tid), "r" (y));

Ugh..

I'm probably explaining this badly.  What I _mean_ to say is really that
you can try to get the behaviour you want (the _appearance_ of a "thread
structure pointer dereference") without ever going down into the actual
code-generation layer, but instead converting it at a higher level into
the asm code you really want. 

That would require no changes at the architecture-specific time, and
might be useful for other things.  I guess you can't do it as-is (does
C++ even allow overloading of the assignment and dereference
operators?), but that might be an approach that is more generic and more
acceptable to maintainers (because this approach could be used for other
tricks too - hiding nasty syntax behind a C++ layer). 

But maybe the above is just even worse than playing with the code generator.

		Linus