From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28132 invoked by alias); 19 Nov 2004 02:52:51 -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 28110 invoked from network); 19 Nov 2004 02:52:47 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 19 Nov 2004 02:52:47 -0000 Received: (qmail 3646 invoked from network); 19 Nov 2004 02:52:47 -0000 Received: from localhost (HELO taltos.codesourcery.com) (zack@127.0.0.1) by mail.codesourcery.com with SMTP; 19 Nov 2004 02:52:47 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Thu, 18 Nov 2004 18:52:46 -0800 To: Ziemowit Laski Cc: Matt Austern , gcc mailing list Subject: Re: generalized lvalues 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> From: Zack Weinberg Date: Fri, 19 Nov 2004 04:22:00 -0000 In-Reply-To: (Ziemowit Laski's message of "Thu, 18 Nov 2004 18:00:19 -0800") Message-ID: <87oehuim81.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00666.txt.bz2 Ziemowit Laski writes: >> 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. :-) Yeah, I'd be fine with that. > Note that I do need to hand both 'ptr' and 'object' (and not just > the result of the assignment) to the write-barrier. In my proposal, you could hook into the parser and get the MODIFY_EXPR instead of the result of assignment. Think Lisp special form. (For an existing example, look at the implementation of __builtin_va_arg.) > 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. Any GC write-barrier implemented by having the compiler synthesize extra code for pointer operations - API calls, open-coded manipulation of GC structures, whatever - qualifies as "annotation of pointer operations." The intended contrast is with a write barrier that doesn't affect the generated code, e.g. one implemented by having the operating system write-protect old generations. > 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. Fair enough. I do understand this sort of constraint. zw