RE: [PATCH] boehm gc support for CRIS

["Boehm, Hans" <hans dot boehm at hp dot com>]

In that case, I'm basically fine with the patch.

Simon - Can you resubmit the patch with the small change from
CRIS32 to CRIS?  That will reduce the chance of a misapplication
on my part, or divergence between the gcc and my trees.

Thanks.

Hans

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org
> [mailto:java-patches-owner@gcc.gnu.org]On Behalf Of Hans-Peter Nilsson
> Sent: Thursday, October 28, 2004 7:22 AM
> To: simon.posnjak@siol.net
> Cc: Boehm, Hans; hans-peter.nilsson@axis.com; tromey@redhat.com;
> rmathew@gmail.com; green@redhat.com; java-patches@gcc.gnu.org
> Subject: Re: [PATCH] boehm gc support for CRIS
> 
> 
> > From: Simon Posnjak <simon.posnjak@siol.net>
> > Date: Thu, 28 Oct 2004 11:42:54 +0200
> 
> > V Ä?et, 28.10.2004 ob 02:55 je Boehm, Hans napisal(a):
> 
> > > - Can we identify the original author of the GC_test_and_set code,
> > > and get his/her OK?  Is it Ulrich Drepper?  The collector 
> distribution
> > > itself falls under an MIT style license, and linuxthreads 
> is LGPL, if
> > > I understand correctly?  There is sufficiently little 
> code that I'm
> > > not sure we absolutely need permission, but I'd like to be sure,
> > > and get it.  (I'd also like to carry this forward to gc7.0 by
> > > putting similar code in the atomic_ops package.  The 
> atomic instruction
> > > support in the GC itself is going away.)
> > I think the author of this code is Hans-Peter Nilsson. So he is the
> > person to ask.
> 
> I mentioned in
> <URL:http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02148.html>
> that it is ok.  (Referring to the "ripped" comment above the
> code in question.)
> 
> > > - Is it possible to add a comment how this works?  It 
> looks like this
> > > assumes a uniprocessor (probably safe for now), and tests 
> a flag which
> > > is set on context switch?  Am I reading that correctly?
> > Hans-Peter should have some more info on this, but CRIS is only
> > uniprocessor platform so this should be OK.
> 
> It's called "load-locked, store-conditional principle".  It's
> documented in
> <URL:http://developer.axis.com/doc/hardware/etrax100lx/prog_ma
> n/1_architectural_description.pdf>
> chapter 1.13 "Integral Read-Write Operations".
> 
> The particular construct is mentioned in some textbook; I'll ask
> the hardware designer for the proper reference.  (It's certainly
> safe -- it's the designed atomicity construct!  It does extend
> to multiprocessor systems, but as pointed out, there are none.)
> 
> brgds, H-P
>