[TUHS] Reading UNIX V6: Does eash process has its own user
brantley at coraid.com
Wed Oct 4 05:40:07 AEST 2006
I'm reading from the printed Lion's commentary and I have the
0742 mov (sp)+, r1
0743 mov (sp),KISA6
0744 mov $_u,r0
What are you looking at?
> hi Brantley,
> Now I start to understand what's going on.
> But do you mean 0744 by 0743?
> 0743 mov (sp), r0
> 0744 mov $_u, r0
> And 2230 should be 2229, which is:
> 2229 sureg();
> Thanks &
> On 10/3/06, Brantley Coile <brantley at coraid.com> wrote:
>> Rp->p_addr is the address of the swappable image in core. The process
>> image begins with the user segment for that process. Line 0743 maps
>> the upage into the current address space (KISA6) and _retu loads
>> previously saved sp and r5 from there. Notice that on line 2230
>> Ken reloads the other memory mapping registers.
>> Read the section `Memory Management' starting on page 2-4 for background
>> on this.
>> U.u_rsave is just a constant location in memory. Notice that rp->p_addr
>> isn't a byte address but a core click address in units of 64 bytes.
>> Hope that helps.
>> > The final question is about how savu/retu work.
>> > savu:
>> > line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
>> > are the address of u.u_rsav.
>> > retu:
>> > 0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
>> > "rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
>> > confess I look stupid here...) When making call to retu, why bother
>> > "retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
>> > mean that rp->p_addr == u.u_rsav?
More information about the TUHS