Re: [RFA:] In -build-operand!, -build-reg-operand, collect the natural mode, not the used mode,

[Hans-Peter Nilsson <hans-peter.nilsson@axis.com>]

> From: Doug Evans <dje@transmeta.com>
> Date: Fri, 13 Dec 2002 05:49:03 -0800 (PST)

> Sorry for the delay.  Now that I'm back up to speed on the m32r response
> times may actually improve (but don't hold your breath of course, sigh).

I've still not replied to your reply about the previous patch so
no need to be sorry.

> The short answer is, please don't commit this just yet.

I have no intention to.  (Except locally.  Muhahaha! :-)

> The purpose of this message is to (try to) solicit input from folks.

> Note also that while there are two copies of in_h_gr_<mumble>,
> there's no problem with them as the mode distinguishes them.

Sorry, I think you're missing the point: I want to get the
register accesses through to the model machinery.

> So another way to look at the bug (no claim is made that this
> isn't obvious) is that the two copies of `in_sr' are ok except
> that one or both should include a mode so there's no compilation error.
>
> Clearly that's what's already happening with in_h_gr_<mumble>.
> No claim is also made that this is a better way to look at the bug.
> Maybe it is, maybe it isn't.  It comes down to "what do we want?".

No no no.  Not a copy for each accessed mode, please.  Please
don't do that.  For one, how would you map that on the model
machinery?  How you you send this to the unit function in:

    (unit u-foo "Foo Unit" () 1 1 ()
          ((dr INT -1))
          () ()))

Consider the case where one insn accesses a register in multiple
modes, while another accesses it in one mode.

> We should also look at the effect on opcodes/m32r-opinst.c.
> The salient change here is:
> 
> @@ -202,6 +202,16 @@ static const CGEN_OPINST sfmt_cmpz_ops[]

> Is the mode relevant here?  What do you think?

I don't claim to know my way around the CGEN assembler/opcode
parts, except as I told previously, that the assembler parts
should obviously *not* be affected by anything in the semantics.
It should only look at the (+ OP1_9 OP2_0 dr sr (f-simm16 0))
(heh, cute, looks like a curse :-) format line.

> IIRC, way back when, I wanted the mode to be relevant,
> it was (at the time) useful information.
> 
> Plus, for architectures where the set of a register in different modes
> has different effects on the register (e.g. x86, m68k),
> the mode is important.  The x86 also has to deal with
> ah,bh,etc.

I'm using this in a related situation, actually.

> where there's no current mode one can apply to eax,ebx,etc. and get the
> intended meaning.  So do we outlaw such things and say
> registers can only be set in their natural mode, and for x86,m68k,etc.
> we create additional registers that alias the appropriate bits of the
> "real" register?

Does the patch have this "outlawing" effect?  I didn't intend
that.

>  Or do we attach meaning to setting a register in
> a mode different than its natural mode?

Like what? (Except for the obvious: affecting only the part of
the register corresponding to the mode.  I did not intend to
change this.)

> [for x86 and ah,bh,etc. we can still go the latter way and either
> create new modes (blech (*1)) or define aliases]

No new modes or aliases, please.

> I've started to come up with a patch that allows us to retain the mode
> of the use, rather than always using the natural mode, should we want to go
> this route.  I think we do.

And the model thingy?  That's the one thing that's important to
me.

brgds, H-P