headers
Frank Ch. Eigler | 13 Dec 2002 13:56
Picon
Favicon
Gravatar

[tkoelman <at> xs4all.nl: Re: subscribe cgen <at> sources.redhat.com]

Hi -

We should shortly have a GMANE newsgroup for this mailing list.

----- Forwarded message from Tom Koelman <tkoelman=qWit8jRvyhVmR6Xm/wNWPw <at> public.gmane.org> -----
> Newsgroups: gmane.discuss.subscribe
> Subject: Re: subscribe cgen=R2MHTz/CkKAf7BdofF/totBPR1lH4CV8 <at> public.gmane.org
> From: Tom Koelman <tkoelman=qWit8jRvyhVmR6Xm/wNWPw <at> public.gmane.org>
> Posted-To: gmane.discuss.subscribe
> 
> The following message is a courtesy copy of an article
> that has been posted to gmane.discuss.subscribe as well.
> 
> fche <at> redhat.com wrote:
> 
> > #gmane.comp.tools.cgen.devel   cgen=R2MHTz/CkKAf7BdofF/totBPR1lH4CV8 <at> public.gmane.org
> >   Development discussions about CGEN: a cpu tools generator
> >   ezmlm dummy 
> >   encode=encrypt
> >
> > URL: http://sources.redhat.com/cgen/
> [...]
Permalink | Reply | 0 comments |
headers
Doug Evans | 13 Dec 2002 14:49

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

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).

The short answer is, please don't commit this just yet.
The purpose of this message is to (try to) solicit input from folks.

Hans-Peter Nilsson writes:
 > As the comments say and as the example show, without the patch
 > at the end of the message, more than one field with the same
 > name can appear in union sem_fields in the generated
 > sim/x/cpu.h.  For example, apply the following nonsensical but
 > supposedly harmless patch to m32r.cpu.  It makes the div insn
 > access sr in QI mode (besides the existing access in its default
 > or natural mode) and reg h-gr 13 in both SI and QI mode.  If you
 > think using the same operand in different modes in an insn is a
 > semantic error, let's fix the parser so that it's identified as
 > such.
 > 
 > Index: m32r.cpu
 > ===================================================================
 > RCS file: /cvs/src/src/cgen/cpu/m32r.cpu,v
 > retrieving revision 1.1
 > diff -c -p -u -p -r1.1 m32r.cpu
 > cvs server: conflicting specifications of output style
 > --- m32r.cpu	5 Jul 2001 12:45:47 -0000	1.1
 > +++ m32r.cpu	5 Dec 2002 19:06:16 -0000
 >  <at>  <at>  -1026,7 +1026,13  <at>  <at> 
 >       ()
 >       "div $dr,$sr"
 >       (+ OP1_9 OP2_0 dr sr (f-simm16 0))
(Continue reading)

Permalink | Reply | 9 comments |
headers
Doug Evans | 13 Dec 2002 15:10

[RFA:] Simplification transformations in semantics.scm

Hans-Peter Nilsson writes:
 > Another way (independently correct AFAICT) to make model support
 > work for me would be to make the model machinery just ignore the
 > semantics of the insn and use the operands I *tell it* to use in
 > the model description, as long as it can find them in the format
 > description.  Right now inputs and outputs of units are filtered
 > through whatever is collected from the semantic compilation, so
 > "op" in (set (reg h-hw (index-of (operand op))) src) is *not*
 > marked as an output operand.  Subsequently, with (op INT -1) in
 > a unit output list, the model function for that unit always get
 > -1 for that operand; op is listed as an input but not as an
 > output.  Gah!  That's a bug, I think; the unit input and output
 > should override what the semantic compiler thinks.

One way to solve this which I thought I implemented (but now can't
find it) is something along these lines.

Suppose you could give names to expressions in the semantic code
and use these names in the model description.
Note that I don't think you want to use the format description
as some operands can be implicit.

e.g. something like

;[sr,dr are operands]

(dni add-gr-13
  ...
  (sequence ((QI tmp))
    (set tmp (rename QI foo (reg QI h-gr 13)))
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hans-Peter Nilsson | 13 Dec 2002 15:42
Picon
Favicon

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

> From: Doug Evans <dje <at> 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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Hans-Peter Nilsson | 13 Dec 2002 15:56
Picon
Favicon

Re: [RFA:] Simplification transformations in semantics.scm

> From: Doug Evans <dje <at> transmeta.com>
> Date: Fri, 13 Dec 2002 06:10:14 -0800 (PST)

> Suppose you could give names to expressions in the semantic code
> and use these names in the model description.

That'd be very nice!

> Note that I don't think you want to use the format description
> as some operands can be implicit.

No; currently I don't see how they can be implicit.  It'd be
nice if they could.

> e.g. something like
> 
> ;[sr,dr are operands]
> 
> (dni add-gr-13
>   ...
>   (sequence ((QI tmp))
>     (set tmp (rename QI foo (reg QI h-gr 13)))
>     (set dr (add tmp sr)))
>   ((model-baz (unit u-exec (in src1 sr) (in src2 foo) (out dr #f))))
> )
> 
> Here `rename' is being used to attach a name to something that is then
> referenced by the model parameters of the dni.
> 
> semantic operand sr -> u-exec input src1
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Ch. Eigler | 13 Dec 2002 17:49
Picon
Favicon
Gravatar

Re: bad shifts generated in sim code

Hi -

On Tue, Dec 10, 2002 at 12:40:08AM -0800, Doug Evans wrote:
> I found these in sim/m32r/decodex.c
>           unsigned int val = (((insn >> -8) & (3 << 0)));
>           unsigned int val = (((insn >> -12) & (1 << 0)));
> [...]

Do these bad shifts still occur with current cgen?

FWIW, working on sim/m32r may be a short-lived pleasure, if the
target-obsoleting eagerness of gdb guys ends up getting that target
removed.  You're welcome to work in sid land. :-)

- FChE
Permalink | Reply | 0 comments |
headers
Doug Evans | 14 Dec 2002 01:50

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

Hans-Peter Nilsson writes:
 > > 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.

Righto.
My point was solely focused on the compilation error.
Clearly we want to be able to feed explicitly specified
registers into the model machinery.

 > > 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.

I recognize the issue.

But suppose each of those multiple-mode accesses feed into different
(Continue reading)

Permalink | Reply | 7 comments |
headers
Doug Evans | 14 Dec 2002 01:52

Re: [RFA:] Simplification transformations in semantics.scm

Hans-Peter Nilsson writes:
 > > How much pain would it be if we continue to disallow
 > > conditions in the left side of `set'?
 > 
 > If you mean in (set (reg h-hw RMODE exp1) exp2)
 > then much so, but in (set exp1 exp2) none at all.  I think it's
 > currently invalid and should remain so.

Righto.  I _think_ (set (reg h-hw RMODE exp1) exp2) may be ok.
exp1 may have conditions but some register of h-hw will be set.
Permalink | Reply | 1 comment |
headers
Hans-Peter Nilsson | 14 Dec 2002 02:38
Picon
Favicon

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

> From: Doug Evans <dje <at> transmeta.com>
> Date: Fri, 13 Dec 2002 16:50:25 -0800 (PST)

> Hans-Peter Nilsson writes:
>  >     (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.
> 
> I recognize the issue.
> 
> But suppose each of those multiple-mode accesses feed into different
> units and suppose they're conditionally referenced.  Collapsing
> them all into one would be wrong.
> The proposed new `rename' rtx would help here,

Yep.  All my problems would be solved with the unit redirection
stuff (well, AFAICS).  I won't argue about the modes if I get
that.  Gimme! :-)

brgds, H-P
Permalink | Reply | 6 comments |
headers
Hans-Peter Nilsson | 14 Dec 2002 02:40
Picon
Favicon

Re: [RFA:] Simplification transformations in semantics.scm

> From: Doug Evans <dje <at> transmeta.com>
> Date: Fri, 13 Dec 2002 16:52:46 -0800 (PST)

> Hans-Peter Nilsson writes:
>  > > How much pain would it be if we continue to disallow
>  > > conditions in the left side of `set'?
>  > 
>  > If you mean in (set (reg h-hw RMODE exp1) exp2)
>  > then much so, but in (set exp1 exp2) none at all.  I think it's
>  > currently invalid and should remain so.
> 
> Righto.  I _think_ (set (reg h-hw RMODE exp1) exp2) may be ok.

(given exp1 a condition, like (if SI ...))

Yes, it definitely is!

brgds, H-P
Permalink | Reply | 0 comments |

Gmane