From owner-freebsd-current@FreeBSD.ORG Sun Aug 2 14:50:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16091106564A for ; Sun, 2 Aug 2009 14:50:10 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id A11AD8FC1A for ; Sun, 2 Aug 2009 14:50:09 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 8405E802A for ; Sun, 2 Aug 2009 16:34:54 +0200 (CEST) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 5030B802E; Sun, 2 Aug 2009 16:34:49 +0200 (CEST) Message-Id: <9A2BA686-016B-4B60-A247-7321C1E7F51A@solfertje.student.utwente.nl> From: Alban Hertroys To: Christoph Mallon In-Reply-To: <4A756BA1.90002@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 2 Aug 2009 16:34:49 +0200 References: <4A756214.8010002@elischer.org> <4A756BA1.90002@gmx.de> X-Mailer: Apple Mail (2.935.3) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Aug 2 16:34:54 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 930,4a75a40e10131514347140 X-DSPAM-Factors: 27, only+I, 0.40000, could, 0.40000, but, 0.40000, but, 0.40000, The+asm, 0.40000, From*Alban, 0.40000, Received*2009+16, 0.40000, just, 0.40000, Date*Aug+2009, 0.40000, References*<4A756214.8010002, 0.40000, if+(sizeof(__val), 0.40000, e, 0.40000, you+though, 0.40000, can't+figure, 0.40000, Mime-Version*Message, 0.40000, to+explain, 0.40000, you'll+do, 0.40000, or, 0.40000, an, 0.40000, an, 0.40000, Speaking+as, 0.40000, turns, 0.40000, trees, 0.40000, trees, 0.40000, doesn't+help, 0.40000, meant, 0.40000, (+(struct, 0.40000 Cc: Julian Elischer , FreeBSD Current Subject: Re: puzzling code in pcpu stuff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 14:50:10 -0000 On 2 Aug 2009, at 12:34, Christoph Mallon wrote: > Julian Elischer schrieb: >> I simplified the output of the preprocessor for a PCPU_SET(xx, >> newval) >> (to look at it). >> I came down to: (after formatting) for i386.. >> { >> __typeof(((struct pcpu *)0)->pc_xx) __val; >> struct __s >> { >> u_char __b[(((sizeof(__val)) < (4)) ? >> (sizeof(__val)) : (4))]; >> } __s; >> __val = (newval); /* aligned */ >> if (sizeof(__val) == 1 >> || sizeof(__val) == 2 >> || sizeof(__val) == 4) { >> __s = *(struct __s *)(void *)&__val; >> __asm volatile("mov %1,%%fs:%0" : "=m" >> (*(struct __s *)(__builtin_offsetof( >> struct pcpu, pc_xx))) : "r" (__s)); >> } else { >> *__extension__ ( >> { >> __typeof(__val) *__p; >> __asm volatile("movl %%fs:%1,%0; >> addl %2,%0" : "=r" (__p) : "m" >> (*(struct pcpu *)(__builtin_offsetof(struct pcpu, pc_prvspace))), >> "i" >> (__builtin_offsetof(struct pcpu, pc_xx))); >> __p; >> }) = __val; >> } >> } >> having had my brain explode on this several times, >> I can't figure out exactly what teh clause after the else is doing. >> anyone better at reading __asm better than me care to explain it in >> simple words? > > First, ({}) is a statement expression - a GCC extension (not to be > confused with expression statement, which is an expression followed > by a semicolon). It wraps a compound statement, i.e. {}, and turns > it into an expression. The value of the last statement is the value > of the expression. In this case it's __p;. Speaking as an outsider I'd better be careful with any criticism, but the first thing I noticed here was the lack of comments. From Julian's question it seems obvious that this function could do with some. I wonder what people would make of this in a couple of years when none of the (then) active developers has any intimate knowledge of the workings of functions like this one? I got from the posted code sample that __extension__ is probably a no- op meant for documentation purposes only. I think it would help to add what extension is being used though, maybe as a comment (but what would be the use of defining __extension__ then) or as a parameter. That's up to you though. Not being familiar with x86 assembly doesn't help me here of course, the last time I touched assembly was on a Z80 a couple of decades back... > Let's have a closer look at the else clause: The asm reads the > pointer to per-cpu information into __p and the statement expression > returns it. This pointer gets dereferenced (mind the * before > __extension__ - __extension__ does nothing, it just marks that the > following is a GCC extension) and __val is assigned. As I read it the value of __val is read into the memory address calculated by the expression in the statement expression (__p internally), am I right? Just chiming in with my opinion. I'm sure you'll do fine without it, but still. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4a75a40e10131514347140!