[Top] [All Lists]

Re: thread-ready ABIs

To: Daniel Jacobowitz <>
Subject: Re: thread-ready ABIs
From: Dominic Sweetman <>
Date: Tue, 22 Jan 2002 15:44:54 +0000
Cc: "Kevin D. Kissell" <>, Dominic Sweetman <>, Ralf Baechle <>, Ulrich Drepper <>, Mike Uhler <>, "MIPS/Linux List (SGI)" <>, "H . J . Lu" <>
In-reply-to: <>
References: <m3elkoa5dw.fsf@myware.mynet> <> <01b801c1a081$3f6518e0$0deca8c0@Ulysses> <> <m3d703thl6.fsf@myware.mynet> <01be01c1a2d7$6ec299c0$0deca8c0@Ulysses> <> <002001c1a33e$d9936560$0deca8c0@Ulysses> <>
User-agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (中ノ庄) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux)
> In any case, that's not the real problem.  Linux user threads do not
> have true separate stacks.  They share their _entire_ address space;
> the stacks are all bounded (default is 2MB) and grouped together at
> the top of the available memory region.


A comment by Kevin reminded me of the real constraint (which the
experts probably take for granted): this system is supposed to work on
shared-memory multiprocessors and multithreaded CPUs.

In both cases two or more threads within an address space can be
active simultaneously.  On a multithreaded CPU (in particular) there's
only one TLB, so memory (including any memory specially handled by the
kernel) is all held in common.  The *only* thing available to a user
privilege program which distinguishes the threads is the CPU register

(Well, and the stack, which is a difference inherited from the value
in the stack pointer register.  But the stack pointer is not really
going to help much to return a thread-characteristic pointer or ID.)

So MIPS really do need to figure out which register can be freed up.
Well, at least I know why now.  Hope the rest of you aren't too bored!

Dominic Sweetman
Algorithmics Ltd

<Prev in Thread] Current Thread [Next in Thread>