[Barrelfish-users] about port barrelfish on tilera platform

[Robert Radkiewicz]

Hi Andrew,
>> - Should *all* registers from register_state be loaded? Is the content
>> of all registers arbitrary or can we have some assumptions (for example
>> on the THREAD_REGISTER or lr)? In the moment, we're not sure how to load
>> the program counter, after all other registers have a been restored,
>> without destroying the content of one of these registers. The possible
>> workaround for now would be to tell GCC to not use one register
>> (-ffixed-reg), and use this. TilePro has enough registers...
>>      
> Yes. THREAD_REGISTER is the one possible exception to this, but it is a kludge that should go away (it already has on x86_64).
>
> I would expect that any sane architecture would have a way to go from kernel mode to an arbitrary user-mode context (including PC), since otherwise I don't see how you can implement preemptive multitasking. If you can't figure out how to do this, then yes you'll probably need to pin a user-mode register.
>    
It works for switching to a process and should work very similar for 
threads, but I get a protection fault, where I clearly shouldn't get 
one. But for the moment, a pinned register should be sufficient.

>> - In the x86 code you put registers into the __asm clobbered list. What
>> is the purpose of this?
>>      
> Are you talking about the kernel's resume() or execute()? I don't see any clobber lists there. Perhaps we're not looking at the same thing?
>    
I'm talking about lib/barrelfish/arch/x86/dispatch.c disp_switch() & 
disp_save().
For disp_switch() this makes now sense to me. Before the asm-directive, 
GCC puts the values onto the stack, and on later re-execution with the 
same function, they are loaded from the stack with the instructions 
issued by GCC.

But I don't get the meaning of it in disp_save().

>> - What is the intended order of the arguments from disp_switch()? If I'm
>> not mistaken, x86 and ARM use different arguments to save to and load
>> from. Does "from" mean, the thread we are switching from or the location
>> to read the registers from?
>>      
> disp_switch() is a bit special, because it relies on clobbering all the registers and getting GCC to emit the code to save/restore them. This is a little bit fragile -- in general it just needs to work like setjmp/longjmp.
>
> from is the register storage location for the thread we're currently on, and switching away from (i.e. it's the out pointer); to is the complete register context of the thread we are switching to (it's the in pointer). I thought the header comment was pretty clear on this one:
>    
Ok, that was just a bug in ARM. Maybe I was confused, because I read the 
ARM code first.
Thanks for the patch, Simon.

Regards,
Robert