[M3commit] CVS Update: cm3

[jay.krell at cornell.edu]

(somewhat out of order sorry)

Assiging function to pointer variable will keep an uninlined copy,  
possibly (if the variable is ever read!) but would not force specific  
direct calls to not be inlined.

Competing with optimizers is an "arms race". You can escalate e.g. by  
putting stuff in seperate files, but then there are systems with cross  
file optimization. We can avoid that by not using whatever compiler  
switches. Really, actually, I almost never test optimized.

"arms race"
You often win by instead "cooperating".
Introduce "noinline" and communicate it down. Microsoft Visual C++ has  
such a feature and I generally believe its extensions are often not  
always well-informed and worth considering.

Most code doesn't care, let the compiler do whatever it can think of,  
but sometimes some code is very special/careful.

Again though an accurate stack bound may help much. I'll look into it.

  - Jay (phone)

On Nov 22, 2009, at 5:03 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

>
> On 22 Nov 2009, at 19:19, Jay K wrote:
>
>> You think I should just leave Win32 using the same method?
>> No point scanning past that?
>
> Right.
>
>>  I think, as I was saying the other day, there is a slight danger  
>> in the current code.
>> Imagine an aggressive optimizer inlines RunThread into ThreadBase.
>> I think when I manually inlined it I caused just such breakage.
>
> Yeah, could be a problem.
>
>>  We need <*NOINLINE*>?
>
> Perhaps, though there are ways to avoid inlining, like passing  
> assigning the procedure (address) to a global.
>
>>
>>  - Jay
>>
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Sun, 22 Nov 2009 18:52:31 -0500
>> CC: jkrell at elego.de; m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> It is precise re traced refs.  That's the lowest frame that can  
>> hold a traced reference.
>>
>> On 22 Nov 2009, at 16:53, Jay K wrote:
>>
>> The end of the stack isn't precise:
>>
>> C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\POSIX 
>> \ThreadPosix.m3(1058):    self.stackbase := ADR(xx);
>>
>> "stack" here:
>>
>> void
>> ProcessContext(Context *c, void *stack,
>>         void (*p) (void *start, void *stop))
>> {
>>   if (stack < c->uc.uc_stack.ss_sp)
>>     p(stack, c->uc.uc_stack.ss_sp);
>>   else
>>     p(c->uc.uc_stack.ss_sp, stack);
>> #ifdef __APPLE__
>>   p(&(c->uc.uc_mcontext[0]), &(c->uc.uc_mcontext[1]));
>> #else
>>   p(&c[0], &c[1]);
>> #endif
>> }
>>
>>  - Jay
>>
>>
>> > From: hosking at cs.purdue.edu
>> > Date: Sun, 22 Nov 2009 13:41:26 -0500
>> > To: jkrell at elego.de
>> > CC: m3commit at elegosoft.com
>> > Subject: Re: [M3commit] CVS Update: cm3
>> >
>> > > Note that ThreadPosix.m3 could also implement such precise  
>> stackbase.
>> >
>> > ThreadPosix *does* implement a precise stack base. It's obtained  
>> from the ucontext set in the thread switch routine (swapcontext).
>> >
>> > > ThreadPThread.m3 probably often could, like with the functions  
>> on OpenBSD (broken) and FreeBSD, etc.
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091123/d9ad9861/attachment-0002.html>