Re: Dumping RTL???

Re: Dumping RTL???

[gyanindra mishra]

Thanks ..

>Can you explain your problem, rather than just ask about a proposed
>solution. Why do you want to do this?

       I am trying to divide the Gcc flow into two parts so that the vast 
GCC code can be splitted.
In the front-end,i want to dump the RTL with full information and Back-End 
is to convert RTL to object.

So I need to dump the RTL into a file. and in backend to get it back into 
the same form.

Regards
Mishra



>From: dewar@gnat.com (Robert Dewar)
>To: gcc@gcc.gnu.org, gyana_m@hotmail.com
>Subject: Re: Dumping RTL???
>Date: Mon,  2 Dec 2002 09:57:05 -0500 (EST)
>
> > Hello,
> >      I am trying to dump the RTL into a file and in the backend to take 
>this
> > file and generate the assembly. What is the feasibility of my idea ??
> > Thanks in Adv..
> > Mishra
>
>

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: Dumping RTL???

[Andrew Haley]

gyanindra mishra writes:
 > Thanks ..
 > 
 > >Can you explain your problem, rather than just ask about a proposed
 > >solution. Why do you want to do this?
 > 
 >        I am trying to divide the Gcc flow into two parts so that the vast 
 > GCC code can be splitted.
 > In the front-end,i want to dump the RTL with full information and Back-End 
 > is to convert RTL to object.
 > 
 > So I need to dump the RTL into a file. and in backend to get it back into 
 > the same form.

This question is asked quite a lot.

We've made that impossible with standard gcc.  This is deliberate.

It's deliberate because we don't want someone to be able to use the
front end of gcc with an unfree back end.

Andrew.

Re: Dumping RTL???

[Fabio Alemagna]

On Tue, 3 Dec 2002, Andrew Haley wrote:
> We've made that impossible with standard gcc.  This is deliberate.
>
> It's deliberate because we don't want someone to be able to use the
> front end of gcc with an unfree back end.

Then just prohibit it in the license...

Fabio Alemagna

Re: Dumping RTL???

[Joe Buck]

On Tue, 3 Dec 2002, Andrew Haley wrote:
> > We've made that impossible with standard gcc.  This is deliberate.
> >
> > It's deliberate because we don't want someone to be able to use the
> > front end of gcc with an unfree back end.

Fabio Alemagna writes:
> Then just prohibit it in the license...

It's not that simple.  Licenses can't do everything.

[ It's quite likely that the following isn't completely correct, and
  my fellow amateur lawyers will enjoy picking it to death.  I suggest
  that this is only worthwhile if there are major errors rather than
  errors in detail. ]

Some types of license terms only work if there is a contract.  The GPL,
LGPL, Berkeley, and other open source licenses work because they start
with copyright law, and grant the user more rights: if you have legally
obtained a copyrighted work, you can use it however you want, but you have
(almost) no right to copy, modify or distribute it (I say "almost" because
the law lets you make a backup copy of a program, there's fair use, etc,
and details depend on the country you live in).  Free software/Open source
licenses let the user do things that copyright law normally forbids, if
certain conditions are followed (fewer conditions for Berkeley, more for
LGPL, still more for GPL).  Because rights are only added, not taken away,
we don't have to force GCC users to agree to a license.

But a license that forbids using a piece of software in a certain way (in
this case, reading the dumped output into a proprietary program, or
accepting certain data as input) takes rights away, so there has to be a
binding contract.  Shrink-wrap licenses are one possibility in some
jurisdictions, but how do you make sure that all users have agreed to the
license?

In the US, the DMCA could be used, I suppose: add some kind of bogus
encryption/access control mechanism, threaten users with five years in
jail if they go around it.  I'd be against such tactics.

Re: Dumping RTL???

[Svein E. Seldal]

Andrew Haley wrote:

> It's deliberate because we don't want someone to be able to use the
> front end of gcc with an unfree back end.

Hmm... gcc is open source... A company like this could ""simply"" alter 
gcc to produce complete RTL output and then use their unfree backend 
anyways? Given that they release the gcc-patch-source, am I right? Or is 
this sceanrio merely academic?

Svein

Re: Dumping RTL???

[Marc Espie]

In article <3DEE8C16.2050107@solidas.com> you write:
>Andrew Haley wrote:
>
>> It's deliberate because we don't want someone to be able to use the
>> front end of gcc with an unfree back end.
>
>Hmm... gcc is open source... A company like this could ""simply"" alter 
>gcc to produce complete RTL output and then use their unfree backend 
>anyways? Given that they release the gcc-patch-source, am I right? Or is 
>this sceanrio merely academic?

No, this scenario is not merely academic.

In fact, anyone who wishes to patch gcc to dump intermediate representations
or use dumps of intermediate representations may do so.

I won't beat a dead horse and launch again into a discussion of the many
reasons why having intermediate representations dumps would be a good thing,
from many technical point of views.

Such a patch will emphatically not be supported by the official gcc release, 
and I wonder how it would fare over time.  Would it get active UNsupport by 
the official gcc release (e.g., changing enough details to deliberately break
it), or not ?  One wonders... then, this is probably not necessary to 
deliberately break an hypothetical patch, seeing the speed at which development
breaks existing extensions, or how hard it is to bring old existing front-ends
(modula3, mercury, pascal...) in line with recent gcc.

I do think that the current non-existence of such a patch mainly comes from
a lack of resources in the camp of those that would like to have intermediate
representations as full-fledged objects.

Re: Dumping RTL???

[Robert Dewar]

> It couldn't ever be, unless you don't really mean "interface".
> Use of one work as the basic materials (ie the ideas or actual physical 
> materials from that work) to create another that does not include that 
> work does not make a derivative (Fer instance, as an an example of 
> physical materials, if I use copyrighted newspapers to make a paper 
> mache dinosaur, i've not created a derivative work of those newspapers. 

This is just a legal theory, not a statement of fact, since little of this
is statutory. I suggest reading up case law on recent copyright decisions
in software matters. It may make you less sanguine about the results. Note
that in particular there is no statutory notion of "interface", and only
a very vague and confused case law notion.

>   Same thing with the ideas part. Ideas are specifically *not* 
> protected).  As long as one can clearly delineate interfaces as the 
> idea, and the implementation as the expression, the interface is not 
> protectible.

Well we all know this is the principle, but the line between an idea
and an expression of an idea is quite flexible (look at the Coming to
America case Art Buchwald vs ??? for details).

Re: Dumping RTL???

[Richard Kenner]

    Same thing with the ideas part. Ideas are specifically *not*
    protected).  As long as one can clearly delineate interfaces as the
    idea, and the implementation as the expression, the interface is not
    protectible.

Well, let's just say *less* protectable.  But that's exactly the point:
if we raise it to the level of an "interface", we lessen it's protection.
As long as it's simply a dump of internal data structures, it's much more
highly protectable.

    I don't think you mean "we" (I slip sometimes too in gcc talk), since 
    the FSF owns the copyright. :)

I mean "we" as developers for the FSF, but technically you're right, I
mean the FSF itself.

Re: Dumping RTL???

[Daniel Berlin]

On Sunday, December 8, 2002, at 10:51  AM, Richard Kenner wrote:

>     BTW, if there is a legal argument that means such a scenario is 
> impossible,
>     why not allow people to dump the RTL ?
>
> A legal "argument" will not necessarily prevail in court since the 
> opposing
> side would have the opposite "argument".  This is an area of copyright 
> law
> that has not been ligitated yet so nobody can say for certain which 
> way it
> would go.

I should add that especially in these times, it is not a time to be 
litigating controversial issues.  Every decision lately seems to be of 
one extreme or another.

>


>     There is something subtle I must be missing here...
>
> You're missing it, but it's not that subtle and has been said before: 
> if the
> copyright holder were to provide such an interface, it could be used 
> to argue
> that using that interface was *not* a violation of the copyright.
It couldn't ever be, unless you don't really mean "interface".
Use of one work as the basic materials (ie the ideas or actual physical 
materials from that work) to create another that does not include that 
work does not make a derivative (Fer instance, as an an example of 
physical materials, if I use copyrighted newspapers to make a paper 
mache dinosaur, i've not created a derivative work of those newspapers. 
  Same thing with the ideas part. Ideas are specifically *not* 
protected).  As long as one can clearly delineate interfaces as the 
idea, and the implementation as the expression, the interface is not 
protectible.


> In other
> words, our legal position is far stronger without such an interface 
> because
> the fact that we haven't provided the interface it makes it clear that 
> we, as
> the copyright holders,

I don't think you mean "we" (I slip sometimes too in gcc talk), since 
the FSF owns the copyright. :)
>  do not view such activity as permissible.

Re: Dumping RTL???

[Richard Kenner]

    BTW, if there is a legal argument that means such a scenario is impossible,
    why not allow people to dump the RTL ?

A legal "argument" will not necessarily prevail in court since the opposing
side would have the opposite "argument".  This is an area of copyright law
that has not been ligitated yet so nobody can say for certain which way it
would go.

    There is something subtle I must be missing here...

You're missing it, but it's not that subtle and has been said before: if the
copyright holder were to provide such an interface, it could be used to argue
that using that interface was *not* a violation of the copyright.  In other
words, our legal position is far stronger without such an interface because
the fact that we haven't provided the interface it makes it clear that we, as
the copyright holders, do not view such activity as permissible. 

Re: Dumping RTL???

[Richard Kenner]

    Front-end/back-ends: separate programs.

So?  The fact that two programs are, from a technical point of view, separate
doesn't mean they are separate from a legal copyright point of view.  They
made be and they may not be.

    You can very well invoke closed source programs from within gcc.
    In fact, if you install it on many systems, then your toolchain will
    depend upon closed source assembler/linker.

    What we're talking about is:
    - release a gcc that's patched to dump intermediate representation, with
    complete source.
    - relase a binary program that's invoked by this gcc, without source.

    How is this different ?

Because the interface between the assembler and compiler is a
documented interface *meant* to be used for that purpose.  It is not a
copyrighted part of the assembler.  Here, data the that's being dumped
is in a format that's part of the copyrighted work (GCC).  Using that
data is a copyright violation.

Re: Dumping RTL???

[Robert Dewar]

> What we're talking about is:
> - release a gcc that's patched to dump intermediate representation, with
> complete source.
> - relase a binary program that's invoked by this gcc, without source.
> 
> How is this different ?

It is very different for many reasons, but (a) this has been discussed
here before (b) it is not relevant.

Re: Dumping RTL???

[Robert Dewar]

It is interesting to note that in the case of GNAT, we do have a facility
for dumping the (very well defined) AST, and utility functions for reading
the tree back in again. This is used by ASIS, and could theoretically be
used by an independent back end.

Whether or not this would violate the GPL if that independent back end
was not GPL'ed and was released, who knows? The situation would require
litigation and there is no point in bothering about it until it happens
(my own viewpoint, from the point of view of an expert on copyright law
but I am not an attorney), is that this would indeed be a copyright
violation (anyone really interested in understanding my point of view can
dig up the trial testimony for Intergraph vs Bentley systems :-)

Anyway, nothing vaguely like this has happened, we don't expect it to happen,
and worrying about it does not keep us awake at night!

Re: Dumping RTL???

[Marc Espie]

In article <10212050323.AA12005@vlsi1.ultra.nyu.edu> you write:
>    Hmm... gcc is open source... A company like this could ""simply"" alter 
>    gcc to produce complete RTL output and then use their unfree backend 
>    anyways? Given that they release the gcc-patch-source, am I right? Or is 
>    this sceanrio merely academic?
>
>No, doing so would be a clear GPL violation.  If the distributed GCC contained
>a facility to do this dumping, then doing what you propose would *probably*
>be a GPL violation, but but it would be a much weaker case.


How so ?

Front-end/back-ends: separate programs.

You can very well invoke closed source programs from within gcc.
In fact, if you install it on many systems, then your toolchain will
depend upon closed source assembler/linker.

What we're talking about is:
- release a gcc that's patched to dump intermediate representation, with
complete source.
- relase a binary program that's invoked by this gcc, without source.

How is this different ?

Re: Dumping RTL???

[Barak Zalstein]

>> Hmm... gcc is open source... A company like this could ""simply"" alter 
>> gcc to produce complete RTL output and then use their unfree backend 
>> anyways? Given that they release the gcc-patch-source, am I right? Or is 
>> this sceanrio merely academic?
> In fact nobody knows whether this would be legitimate. It has not been
> litigated, and we would just as soon prefer that things stay that way.

Well if it happened to trees (http://open64.sourceforge.net/) why shouldn't it happen to rtx?
It's only a matter of few global variables.

Barak.

Re: Dumping RTL???

[Robert Dewar]

> Hmm... gcc is open source... A company like this could ""simply"" alter 
> gcc to produce complete RTL output and then use their unfree backend 
> anyways? Given that they release the gcc-patch-source, am I right? Or is 
> this sceanrio merely academic?


In fact nobody knows whether this would be legitimate. It has not been
litigated, and we would just as soon prefer that things stay that way.

Re: Dumping RTL???

[Richard Kenner]

    Hmm... gcc is open source... A company like this could ""simply"" alter 
    gcc to produce complete RTL output and then use their unfree backend 
    anyways? Given that they release the gcc-patch-source, am I right? Or is 
    this sceanrio merely academic?

No, doing so would be a clear GPL violation.  If the distributed GCC contained
a facility to do this dumping, then doing what you propose would *probably*
be a GPL violation, but but it would be a much weaker case.

Re: Dumping RTL???

[Chris Lattner]

Svein E. Seldal wrote:
> > Andrew Haley wrote:
> > It's deliberate because we don't want someone to be able to use the
> > front end of gcc with an unfree back end.
>
> Hmm... gcc is open source... A company like this could ""simply"" alter
> gcc to produce complete RTL output and then use their unfree backend
> anyways? Given that they release the gcc-patch-source, am I right? Or is
> this sceanrio merely academic?

That is certainly correct.  In fact, if you ask on the list, people will
point out the C backend that is available in the archives, but that was
not applied.  As with many political problems, this one has an easy
solution that will never happen, and the current approach is flawed in
obtaining the ideals that are supposed to be upheld.  :(

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Re: Dumping RTL???

[Robert Dewar]

I must say I still don't understand the motivation behind the split
in this particular case. Splitting gcc into two parts has no particular
benefit of its own.

Re: Dumping RTL???

[Chris Lattner]

> I am trying to divide the Gcc flow into two parts so that the vast GCC
> code can be splitted. In the front-end,i want to dump the RTL with full
> information and Back-End is to convert RTL to object.

> So I need to dump the RTL into a file. and in backend to get it back
> into the same form.

GCC doesn't provide the capability to do this.  RTL intentionally does not
contain all of the information neccesary to represent the program.  This
unfortunately is due more to political reasons than any technical reason,
so it's very unlikely to change. :(

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Re: Dumping RTL???

[Robert Dewar]

> Hello,
>      I am trying to dump the RTL into a file and in the backend to take this 
> file and generate the assembly. What is the feasibility of my idea ??
> Thanks in Adv..
> Mishra

Can you explain your problem, rather than just ask about a proposed 
solution. Why do you want to do this?

Dumping RTL???

[gyanindra mishra]

Hello,
     I am trying to dump the RTL into a file and in the backend to take this 
file and generate the assembly. What is the feasibility of my idea ??
Thanks in Adv..
Mishra


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail