Re: generalized lvalues

[Zack Weinberg <zack@codesourcery.com>]

Ziemowit Laski <zlaski@apple.com> 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