From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30457 invoked by alias); 19 Nov 2004 02:00:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29907 invoked from network); 19 Nov 2004 02:00:25 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 19 Nov 2004 02:00:25 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iAJ270f4019527 for ; Thu, 18 Nov 2004 18:07:00 -0800 (PST) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Thu, 18 Nov 2004 18:01:03 -0800 Received: from [17.219.197.191] ([17.219.197.191]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id iAJ20KIk002943; Thu, 18 Nov 2004 18:00:21 -0800 (PST) In-Reply-To: <87vfc2ipil.fsf@codesourcery.com> References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> <87zn1eiuy4.fsf@codesourcery.com> <39B69E96-39C9-11D9-8317-00039390FFE2@apple.com> <87vfc2ipil.fsf@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Matt Austern , gcc mailing list From: Ziemowit Laski Subject: Re: generalized lvalues Date: Fri, 19 Nov 2004 03:56:00 -0000 To: Zack Weinberg X-SW-Source: 2004-11/txt/msg00665.txt.bz2 On 18 Nov 2004, at 17.41, Zack Weinberg wrote: > Ziemowit Laski writes: > >> The __builtin_gc_register approach would require that the entire GC >> API be redesigned, and of course would be extremely inefficient, since >> _every_ assignment in a program would have to go through a >> write-barrier which would either do something or nothing depending on >> whether __builtin_gc_register and/or __builtin_gc_unregister has been >> called. > > I think you misunderstood what I meant it to mean - it was intended to > be a suggestion for alternative notation producing *exactly the same > code generation* as your proposal. In other words, the effect of > __builtin_gc_register would be to notify the compiler to generate > write barriers for every assignment to ptr from then until a > subsequent __builtin_gc_unregister. Oh, OK. I read __builtin_gc_register like a regular statement (i.e., affected by control-flow), whereas you're giving it a more #pragma-like flavor. > >> __builtin_objc_gc_strong(ptr) = object; > > How about > > __builtin_with_write_barrier (ptr = object); Actually, a secret admirer gave me an off-list suggestion for __builtin_with_write_barrier(ptr, object); which ain't bad. :-) Note that I do need to hand both 'ptr' and 'object' (and not just the result of the assignment) to the write-barrier. > Tangentially. I am not enthused by the implication that you (Apple) > have implemented write barriers by compiler annotation of pointer > operations. That's not my idea of state-of-the-art GC technology. I'm no GC maven, and so can't really argue that one with you. I will say, though, that the objective here was to introduce GC into Objective-C in a way that was binary compatible with legacy ObjC programs running against the new runtime. So our theoretical playing field was not very large here. In a way, this is very similar to our _setjmp()/_longjmp()-based EH in ObjC and why we could not use the DWARF EH approach. Actually, I'm not sure what you mean by "compiler annotation of pointer operations" -- the write-barriers (of which there are several flavors!) are all implemented as API calls into the runtime. --Zem