ifield's value processing -- help is needed

ifield's value processing -- help is needed

[Lev Yudalevich]

Hello,
(I'm not 100% sure if this is a correct place to ask, but I'd very
appreciate any answer)

I'm wandering if there is a possibility to specify (either in a `.cpu'
file or in a corresponding `.opc' file) an additional processing
function for a value of an instruction's ifield. For example, I'd like
to define several isa sets. Suppose that these sets differ by opcode
values only. In this case, I may supply a simple lookup function that
picks the correct value depending on the isa. My problem is that I can
not find a way to pass such a function (nor in Scheme neither in C) as
a part of the format list of an
instruction definition. Having user-defined parse and print handlers
(as for operand definitions) would have solve the problem, but there
are none for ifields. Another workaround is to hardcode all opcodes
for all isas, but in this case I have no way to distinguish between
different isas inside cgen_dis_hash function, which only gets a buffer
and a value as arguments.

Any advice is highly welcome.

Sincerely,
Lev.

Re: ifield's value processing -- help is needed

[Frank Ch. Eigler]

Hi -

> (I'm not 100% sure if this is a correct place to ask, [...]

It is.

> I'm wandering if there is a possibility to specify (either in a `.cpu'
> file or in a corresponding `.opc' file) an additional processing
> function for a value of an instruction's ifield. For example, I'd like
> to define several isa sets. Suppose that these sets differ by opcode
> values only. In this case, I may supply a simple lookup function that
> picks the correct value depending on the isa. [...]

Have you considered using macros to expand to explicit isa-specific
instructions (basically generating the cartesian product of
instruction X isa in the cgen model), as opposed to trying to do this
selection based upon a run-time function call?

- FChE

Re: ifield's value processing -- help is needed

[Lev Yudalevich]

Thank you very much for the reply, Frank!

Right, I can write instruction definitions using macros. But then I'd
have to deal with this full cartesian product of instruction X isa,
which is exactly what I'm trying to avoid, as it creates much more
headache (for example, I'd have to know the currently active isa
inside the cgen_dis_hash function and I couldn't find a guide or an
example of using CGEN_COMPUTE_ISA, except for a mention of its
existence in the CGEN documentation). On the contrary, by using a
run-time function I'd be able to converge (i.e. to map) all isas into
a singe virtual one, on which I can perform any processing or analysis
I might need later. Do you think it is a correct and a possible
approach? If not, would you be so kind to give me a hint of how to
write CGEN_COMPUTE_ISA please?

Sincerely,
Lev.

On Tue, Jun 11, 2013 at 5:20 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
>> (I'm not 100% sure if this is a correct place to ask, [...]
>
> It is.
>
>> I'm wandering if there is a possibility to specify (either in a `.cpu'
>> file or in a corresponding `.opc' file) an additional processing
>> function for a value of an instruction's ifield. For example, I'd like
>> to define several isa sets. Suppose that these sets differ by opcode
>> values only. In this case, I may supply a simple lookup function that
>> picks the correct value depending on the isa. [...]
>
> Have you considered using macros to expand to explicit isa-specific
> instructions (basically generating the cartesian product of
> instruction X isa in the cgen model), as opposed to trying to do this
> selection based upon a run-time function call?
>
> - FChE

Re: ifield's value processing -- help is needed

[Frank Ch. Eigler]

Hi -

On Wed, Jun 12, 2013 at 12:27:06PM +0300, Lev Yudalevich wrote:

> [...]  for example, I'd have to know the currently active isa inside
> the cgen_dis_hash function and I couldn't find a guide or an example
> of using CGEN_COMPUTE_ISA, except for a mention of its existence in
> the CGEN documentation).

When disassembling (or simulating the execution of) anything, you
usually have to specify a-priori the ISA of the binary dump.  (If you
want to try auto-detection, that'd have to be done via hand-written
code in the .opc file or elsewhere.)  For example, see how
disasemble_info* is passed into the generated default_print_insn()
function; or examples like sh* with its compact & media ISA's or m32rc
with its m16c/m32c.

- FChE

Re: ifield's value processing -- help is needed

[Lev Yudalevich]

Thank you very much!!!

On Thu, Jun 13, 2013 at 1:52 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Wed, Jun 12, 2013 at 12:27:06PM +0300, Lev Yudalevich wrote:
>
>> [...]  for example, I'd have to know the currently active isa inside
>> the cgen_dis_hash function and I couldn't find a guide or an example
>> of using CGEN_COMPUTE_ISA, except for a mention of its existence in
>> the CGEN documentation).
>
> When disassembling (or simulating the execution of) anything, you
> usually have to specify a-priori the ISA of the binary dump.  (If you
> want to try auto-detection, that'd have to be done via hand-written
> code in the .opc file or elsewhere.)  For example, see how
> disasemble_info* is passed into the generated default_print_insn()
> function; or examples like sh* with its compact & media ISA's or m32rc
> with its m16c/m32c.
>
> - FChE