New binutils directory src/include/cpu/ for .cpu and .opc files?

New binutils directory src/include/cpu/ for .cpu and .opc files?

[Andrew Cagney]

Hello,

I'd like to propose a new directory:

	src/include/cpu/

The directory would contain the CGEN .cpu and .opc input files used to 
generate CGEN based binutils disassemblers, assemblers and (?) 
relocations.  GDB could also use these files when generating CGEN based 
simulators.

The directory would be part of the FSF's BINUTILS package and, hence, 
would be covered by the BINUTILS copyright assignment.

Thoughts?
Andrew

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[DJ Delorie]

> I'd like to propose a new directory:
> 
> 	src/include/cpu/
> 
> The directory would contain the CGEN .cpu and .opc input files used to 
> generate CGEN based binutils disassemblers, assemblers and (?) 
> relocations.  GDB could also use these files when generating CGEN based 
> simulators.

They aren't really include files, they're *source* files.  Shouldn't
they go in one of the source directories?

I really don't think we want to go down the slippery slope of using
include as a catch-all.  Perhaps the opcodes directory would be a
better choice?

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Hans-Peter Nilsson]

On Thu, 12 Sep 2002, Andrew Cagney wrote:
> I'd like to propose a new directory:
>
> 	src/include/cpu/
>
> The directory would contain the CGEN .cpu and .opc input files used to
> generate CGEN based binutils disassemblers, assemblers and (?)
> relocations.  GDB could also use these files when generating CGEN based
> simulators.
>
> The directory would be part of the FSF's BINUTILS package and, hence,
> would be covered by the BINUTILS copyright assignment.

Being part of binutils requires copyright for all parts to
belong to the FSF, which isn't the case for these files;
copyright is owned by Red Hat (mostly; also other holders).

brgds, H-P

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Doug Evans]

DJ Delorie writes:
 > > I'd like to propose a new directory:
 > > 
 > > 	src/include/cpu/
 > > 
 > > The directory would contain the CGEN .cpu and .opc input files used to 
 > > generate CGEN based binutils disassemblers, assemblers and (?) 
 > > relocations.  GDB could also use these files when generating CGEN based 
 > > simulators.
 > 
 > They aren't really include files, they're *source* files.  Shouldn't
 > they go in one of the source directories?
 > 
 > I really don't think we want to go down the slippery slope of using
 > include as a catch-all.  Perhaps the opcodes directory would be a
 > better choice?

I've always thought the .opc files should go in src/opcodes.

Similarily, I kinda think the opcodes file generators should
go in opcodes.  After all, they're rather closely tied with
the rest of opcodes.  They're also closely tied with cgen of course.
But application file generators should be able to go with the
application and not cgen.  Otherwise writing new generators for
new applications becomes problematic ....

And, fwiw, I don't like putting the .cpu files in src/include either.

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Ben Elliston]

>>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:

  Andrew> Hello,
  Andrew> I'd like to propose a new directory:
  Andrew> 	src/include/cpu/

I think this is a misleading place to put CGEN .cpu files.  `include'
implies that this directory holds C header files that are brought in
using `#include'.

Ben

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Doug Evans]

Ben Elliston writes:
 > >>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:
 > 
 >   Andrew> Hello,
 >   Andrew> I'd like to propose a new directory:
 >   Andrew> 	src/include/cpu/
 > 
 > I think this is a misleading place to put CGEN .cpu files.  `include'
 > implies that this directory holds C header files that are brought in
 > using `#include'.

How about src/cgen-cpu (*)?  Or maybe even src/cpu/cgen.

I like the latter (though I only put a few seconds of thought into it).
It doesn't preclude having cgen-like things other than cgen, and gives
them a home.

(*) It screws up tab-completion of src/cgen, but it's descriptive.

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Andrew Cagney]

> On Thu, 12 Sep 2002, Andrew Cagney wrote:
> 
>> I'd like to propose a new directory:
>>
>> 	src/include/cpu/
>>
>> The directory would contain the CGEN .cpu and .opc input files used to
>> generate CGEN based binutils disassemblers, assemblers and (?)
>> relocations.  GDB could also use these files when generating CGEN based
>> simulators.
>>
>> The directory would be part of the FSF's BINUTILS package and, hence,
>> would be covered by the BINUTILS copyright assignment.

> Being part of binutils requires copyright for all parts to
> belong to the FSF.

``The [new, initially empty] directory would be part of the FSF's 
BINUTILS package and, hence, would be covered by the BINUTILS copyright 
assignment.''

Andrew

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[DJ Delorie]

> How about src/cgen-cpu (*)?  Or maybe even src/cpu/cgen.

Or src/cpu/<cpu>

Of course, you could break up opcodes that way also ;)

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Doug Evans]

DJ Delorie writes:
 > 
 > > How about src/cgen-cpu (*)?  Or maybe even src/cpu/cgen.
 > 
 > Or src/cpu/<cpu>

That works too.

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Frank Ch. Eigler]

dje wrote:

> [...]
> How about src/cgen-cpu (*)?  Or maybe even src/cpu/cgen.

If the idea of a new directory is just to separate (C)FSF from
non-(C)FSF CGEN input model files, then such a big hierarchy change is
not needed: e.g. src/cgen/fsf-cpu.

- FChE

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Hans-Peter Nilsson]

On Thu, 12 Sep 2002, Andrew Cagney wrote:
> > On Thu, 12 Sep 2002, Andrew Cagney wrote:
> >
> >> I'd like to propose a new directory:
> >>
> >> 	src/include/cpu/
> >>
> >> The directory would contain the CGEN .cpu and .opc input files used to
> >> generate CGEN based binutils disassemblers, assemblers and (?)
> >> relocations.  GDB could also use these files when generating CGEN based
> >> simulators.
> >>
> >> The directory would be part of the FSF's BINUTILS package and, hence,
> >> would be covered by the BINUTILS copyright assignment.
>
> > Being part of binutils requires copyright for all parts to
> > belong to the FSF.
>
> ``The [new, initially empty] directory would be part of the FSF's
> BINUTILS package and, hence, would be covered by the BINUTILS copyright
> assignment.''

Thanks for the clarification.  I didn't see the "initially
empty" part at all implied by "new".  Frankly I think it's the
wrong solution to any copyright problem to introduce *another*
directory for these files.  Also, it seems odd to put it solely
under the binutils domain.  What about CGEN ports only intended
for simulators?

brgds, H-P

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Doug Evans]

Hans-Peter Nilsson writes:
 > What about CGEN ports only intended for simulators?

Nothing.

Re: New binutils directory src/include/cpu/ for .cpu and .opc files?

[Andrew Cagney]

> Hello,
> 
> I'd like to propose a new directory:
> 
>     src/include/cpu/
> 
> The directory would contain the CGEN .cpu and .opc input files used to generate CGEN based binutils disassemblers, assemblers and (?) relocations.  GDB could also use these files when generating CGEN based simulators.
> 
> The directory would be part of the FSF's BINUTILS package and, hence, would be covered by the BINUTILS copyright assignment.
> 
> Thoughts?
> Andrew

It would appear that the first preference is src/cpu/.  The runner up 
being src/opcodes/<something>/

Nick?

Andrew