[Barrelfish-users] about port barrelfish on tilera platform

[Robert Radkiewicz]

Moin,

I have some follow-up questions for this, regarding 
lib/barrelfish/arch/<arch>/dispatch.c:

- I guess the CPU should be in the user mode / protection level, since 
executing "resume" in exec.c. Is this function always called from the 
user mode?
- 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...
- In the x86 code you put registers into the __asm clobbered list. What 
is the purpose of this?
- 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?

Regards,
Robert

On 19.11.2012 20:02, Andrew Baumann wrote:
> Hi Robert,
>
> Start of day for userland is a pretty special environment on Barrelfish, and probably some of the toughest code to understand or port. The main thing you need to understand to make sense of it is the dispatch model: the crt0 code runs with the dispatcher "disabled", which means that it cannot take upcalls from the kernel. This in turn means that it cannot take a page fault, nor can it send or receive IDC messages, or use threading functionality such as mutexes. The normal printf() path uses IDC (e.g. to communicate with the serial driver), so it can't be called from this environment. Instead, the debugging facilities available boil down to a debugging system call sys_print(). You can see examples of this in lib/barrelfish/dispatcher.c for things like disp_assert_fail() etc. Also, beware that you have a very small stack at this point.
>
> Once you get onto a thread (i.e. once threads_init_disabled() completes and uses disp_resume() to start the thread) then most of these restrictions go away, and normal printf() calls should work.
>
> Hope this helps,
> Andrew
>