RFA: hardware can have ISA attributes, too

RFA: hardware can have ISA attributes, too

[Jim Blandy]

I don't really feel like I understand CGEN's data model well enough to
know whether this is really appropriate, or just a kludge.

Here's the motivation.  We have a toolchain that supports several
different machines within a family; some register sets are present on
some machines, but not on others.  Given an ISA, we want to be able to
traverse the hardware list and see which register sets are available
on that ISA.

So along with this will come another patch that produces an extern
declaration for @arch@_cgen_hw_table, so we can traverse it.

What's the best way to do this?

2003-07-22  Jim Blandy  <jimb@redhat.com>

	* mach.scm (def-isa-attr!): hardware can have ISA attributes, too.

Index: cgen/mach.scm
===================================================================
RCS file: /cvs/cvsfiles/devo/cgen/mach.scm,v
retrieving revision 1.47.34.1
diff -c -r1.47.34.1 mach.scm
*** cgen/mach.scm	5 Jun 2002 22:18:35 -0000	1.47.34.1
--- cgen/mach.scm	22 Jul 2003 16:47:16 -0000
***************
*** 501,507 ****
        ; for it.
        (if (= (length isas) 1)
  	  '(for)
! 	  '(for ifield operand insn))
        (cons 'values isa-enums))
      )
  
--- 501,507 ----
        ; for it.
        (if (= (length isas) 1)
  	  '(for)
! 	  '(for ifield operand insn hardware))
        (cons 'values isa-enums))
      )
  

RFA: hardware can have ISA attributes, too

[Doug Evans]

Jim Blandy writes:
 > I don't really feel like I understand CGEN's data model well enough to
 > know whether this is really appropriate, or just a kludge.
 > 
 > Here's the motivation.  We have a toolchain that supports several
 > different machines within a family; some register sets are present on
 > some machines, but not on others.  Given an ISA, we want to be able to
 > traverse the hardware list and see which register sets are available
 > on that ISA.
 > 
 > So along with this will come another patch that produces an extern
 > declaration for @arch@_cgen_hw_table, so we can traverse it.
 > 
 > What's the best way to do this?

The patch to mach.scm is fine.

I'm not sure about the patch to provide extern @arch@_cgen_hw_table though.
If it's ultimately needed, great.
The way it's intended to normally work is that you access the CGEN_HW_ENTRY
elements via struct cgen_cpu_desc . hw_table.
struct cgen_cpu_desc is filled by the call to @arch@_cgen_cpu_open,
and the hw_table member is filled in based on the requested machs, not isas.
That's why, I think, I didn't initially add the extern declaration.
OTOH, if that were the case I would have made it static ...
And if it's not static, where's its entry in some header?

I don't know enough about the application at hand to know whether
all the hw entries you want to look at are in cgen_cpu_desc . hw_table,
but given that I didn't make the hw_table static, it should have
an extern declaration anyway.  Thus go for it.
[There are other tables in the same boat, but we can to them on
an as-needed basis.]

Re: RFA: hardware can have ISA attributes, too

[Jim Blandy]

Doug Evans <dje@transmeta.com> writes:
> The patch to mach.scm is fine.

Okay, great!

> I'm not sure about the patch to provide extern @arch@_cgen_hw_table though.
> If it's ultimately needed, great.
> The way it's intended to normally work is that you access the CGEN_HW_ENTRY
> elements via struct cgen_cpu_desc . hw_table.

I had considered instantiating a desc, the way the disassembler does.
That would work, too.  But I wasn't sure how expensive they were, and
I knew the information I needed was right there in the table, no
allocation necessary.

The toolchain at hand could be handling up to a dozen processor
variants.  There'd be a separate desc instantiated for each variant
the user refers to in a single GDB session.  Does that seem
reasonable?

Re: RFA: hardware can have ISA attributes, too

[Doug Evans]

Jim Blandy writes:
 > > I'm not sure about the patch to provide extern @arch@_cgen_hw_table though.
 > > If it's ultimately needed, great.
 > > The way it's intended to normally work is that you access the CGEN_HW_ENTRY
 > > elements via struct cgen_cpu_desc . hw_table.
 > 
 > I had considered instantiating a desc, the way the disassembler does.
 > That would work, too.  But I wasn't sure how expensive they were, and
 > I knew the information I needed was right there in the table, no
 > allocation necessary.
 > 
 > The toolchain at hand could be handling up to a dozen processor
 > variants.  There'd be a separate desc instantiated for each variant
 > the user refers to in a single GDB session.  Does that seem
 > reasonable?

Sorry for the delay!  The message got lost in my queue.

Whether it's reasonable or not I'll leave to you.
I'm guessing not but I'm not sure what the usage pattern would be.
In the end, adding the extern decl is probably a useful thing to do
anyway, so just go ahead.

Re: RFA: hardware can have ISA attributes, too

[Jim Blandy]

Doug Evans <dje@transmeta.com> writes:

> Jim Blandy writes:
>  > > I'm not sure about the patch to provide extern @arch@_cgen_hw_table though.
>  > > If it's ultimately needed, great.
>  > > The way it's intended to normally work is that you access the CGEN_HW_ENTRY
>  > > elements via struct cgen_cpu_desc . hw_table.
>  > 
>  > I had considered instantiating a desc, the way the disassembler does.
>  > That would work, too.  But I wasn't sure how expensive they were, and
>  > I knew the information I needed was right there in the table, no
>  > allocation necessary.
>  > 
>  > The toolchain at hand could be handling up to a dozen processor
>  > variants.  There'd be a separate desc instantiated for each variant
>  > the user refers to in a single GDB session.  Does that seem
>  > reasonable?
> 
> Sorry for the delay!  The message got lost in my queue.
> 
> Whether it's reasonable or not I'll leave to you.
> I'm guessing not but I'm not sure what the usage pattern would be.
> In the end, adding the extern decl is probably a useful thing to do
> anyway, so just go ahead.

Okay, thanks.  (Delay in committing patches due to personal entropy,
nothing else.)