headers
fche | 1 Oct 2009 16:13
Favicon

new cgen snapshot available

A new automated cgen source snapshot is available
ftp://sources.redhat.com/pub/cgen/snapshots/cgen-20091001.tar.bz2
1581450 bytes, cgen-snapshot-20091001 tag
See also ftp://sources.redhat.com/pub/cgen/snapshots/
Permalink | Reply | 0 comments |
headers
Jean-Marc Saffroy | 1 Oct 2009 16:41

problem with 64-bit arch

Hi,

I am trying to use CGEN for an experimental 64-bit architecture (ie. 
word-bitsize is 64), and in my case the generated arch-ibld.c file is 
incorrect.

I defined the following insn field:

(df f-disp24     "disp24"              (PCREL-ADDR) 8 24 INT
     ((value pc) (sra WI (sub WI value pc) (const 2)))
     ((value pc) (add WI (sll WI value (const 2)) pc))
)

(define-operand
   (name disp24)
   (comment "24 bit signed displacement")
   (type h-iaddr)
   (mode WI)
   (index f-disp24)
)

And arch-ibld.c contains the following code (in <arch>_cgen_insert_operand):

   switch (opindex)
     {
     case <ARCH>_OPERAND_DISP24 :
       {
         long value = fields->f_disp24;
         value = (() (((value) - (pc))) >> (2));
         errmsg = insert_normal (cd, value,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Doug Evans | 1 Oct 2009 17:57

Re: problem with 64-bit arch

Jean-Marc Saffroy wrote:
> Hi,
>
> I am trying to use CGEN for an experimental 64-bit architecture (ie. 
> word-bitsize is 64), and in my case the generated arch-ibld.c file is 
> incorrect.
>
> I defined the following insn field:
>
> (df f-disp24     "disp24"              (PCREL-ADDR) 8 24 INT
>     ((value pc) (sra WI (sub WI value pc) (const 2)))
>     ((value pc) (add WI (sll WI value (const 2)) pc))
> )
>
> (define-operand
>   (name disp24)
>   (comment "24 bit signed displacement")
>   (type h-iaddr)
>   (mode WI)
>   (index f-disp24)
> )
>
> And arch-ibld.c contains the following code (in 
> <arch>_cgen_insert_operand):
>
>   switch (opindex)
>     {
>     case <ARCH>_OPERAND_DISP24 :
>       {
>         long value = fields->f_disp24;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jean-Marc Saffroy | 1 Oct 2009 18:34

Re: problem with 64-bit arch

Doug Evans wrote:
> We were just discussing instruction word bitsizes of 64, and it's not 
> clear what to do.
> I don't mind going down the path of having 64 bit instructions expressed 
> as a single 64 bit integer (*1), but can you confirm your architecture 
> has 64-bit instructions?  From the given sample, it seems like it has 32 
> bit instructions and 64-bit words (like sparc64).

You guessed right: my target arch has 32 bit instructions (which I 
expressed with base-insn-bitsize == 32), and uses 64-bit words for data 
and addresses (expressed with word-bitsize == 64).

> Clearly the missing type in the cast is a bug.  That should be easy to 
> fix.  As for the use of long to record a 64-bit value, that should also 
> be (relatively) easy to fix.
> I'll dig deeper tonight.

Good to hear, thanks!

I found the cast could be fixed by changing the "(dfm 'DI..." line in 
mode.scm, but have no idea about the possible side effects, and didn't 
find a cure for the use of long anyway.

Cheers,
JM
Permalink | Reply | 1 comment |
headers
Doug Evans | 2 Oct 2009 19:58

Re: problem with 64-bit arch

Jean-Marc Saffroy wrote:
> Doug Evans wrote:
>> We were just discussing instruction word bitsizes of 64, and it's not 
>> clear what to do.
>> I don't mind going down the path of having 64 bit instructions 
>> expressed as a single 64 bit integer (*1), but can you confirm your 
>> architecture has 64-bit instructions?  From the given sample, it 
>> seems like it has 32 bit instructions and 64-bit words (like sparc64).
>
> You guessed right: my target arch has 32 bit instructions (which I 
> expressed with base-insn-bitsize == 32), and uses 64-bit words for 
> data and addresses (expressed with word-bitsize == 64).
>
>> Clearly the missing type in the cast is a bug.  That should be easy 
>> to fix.  As for the use of long to record a 64-bit value, that should 
>> also be (relatively) easy to fix.
>> I'll dig deeper tonight.
>
> Good to hear, thanks!
>
> I found the cast could be fixed by changing the "(dfm 'DI..." line in 
> mode.scm, but have no idea about the possible side effects, and didn't 
> find a cure for the use of long anyway.
>
>
> Cheers,
> JM

Ok, I understand what's going on.  There's two separate issues.
Using a long to store a 64-bit value is a long outstanding "todo" item
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joern Rennecke | 3 Oct 2009 22:39
Favicon

Re: ALIAS instructions are messed up?

> Whether to disallow alias insns entirely is a separate question. Dunno.
> [We could still keep it for macro-insns.
> And I realize there are a few ports that currently use it, or at  
> least specify > it.]

Currently, macro-instructions can't be used in all instances where
it should be natural to use them.
When you want to set a multi-ifield to a constant, you end up with
the entire costant being added in in the bit position of each of
constituent simple bitfields.

By adding an ALIAS instruction by hand, you can at least work around
the problem by setting only simple bitfields to constants.
Permalink | Reply | 2 comments |
headers
Doug Evans | 5 Oct 2009 20:04

Re: [patch] One more cpu-vs-prefix fix.

Dave Korn wrote:
>   Hiya!  I found one more place that looks to me like it should be using
>  <at> prefix <at>  instead of  <at> cpu <at> , since that's how all the rest of the code generates
> the "XXX_init_idesc_table" name.
>
>   I haven't tested this much yet except that it fixes a discrepancy between
> the prototype generated in the decode.h and the function call in the mloop.c
> files for the private port I'm working on.  I think that sh64 is the only
> target where there actually is any difference between  <at> prefix <at>  and  <at> cpu <at>  in
> practice, so I tried regenerating it and it seemed to compile ok, or at any
> rate without any missing or duplicated symbols.  I couldn't get the tests to
> run, they all fail with an error that suggests the testsuite is attempting to
> run target binaries on the host machine:
>
>   
>> spawn /sgun/tools/obj.sh64/ld/ld-new andb.cgs.o -m shelf32 -o andb.cgs.x
>>      andb.cgs.x
>> spawn andb.cgs.x
>> andb.cgs.x: andb.cgs.x: cannot execute binary file
>> FAIL: sh5 andb.cgs (execution)
>> Testing andi.cgs on machine sh5.
>>     
>
>   So whatever that is, I'd guess it's not related.  Here's a changelog entry,
> if you want the patch:
>
> cgen/ChangeLog:
>
> 	* sim-model.scm ( <at> cpu <at> _prepare_run): Use  <at> prefix <at> , not  <at> cpu <at> .
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Evans | 5 Oct 2009 20:22

Re: ALIAS instructions are messed up?

Joern Rennecke wrote:
>> Whether to disallow alias insns entirely is a separate question. Dunno.
>> [We could still keep it for macro-insns.
>> And I realize there are a few ports that currently use it, or at 
>> least specify > it.]
>
> Currently, macro-instructions can't be used in all instances where
> it should be natural to use them.
> When you want to set a multi-ifield to a constant, you end up with
> the entire costant being added in in the bit position of each of
> constituent simple bitfields.

Let's fix this.  Do you have an example readily available?

>
> By adding an ALIAS instruction by hand, you can at least work around
> the problem by setting only simple bitfields to constants.

Good point.
Permalink | Reply | 1 comment |
headers
Joern Rennecke | 5 Oct 2009 23:42
Favicon

Re: ALIAS instructions are messed up?

Quoting Doug Evans <dje <at> sebabeach.org>:
> Let's fix this.  Do you have an example readily available?

The port where I have most recently encountered this is under NDA,
so I just made up a relevant macro insn for the frv:

Index: frv.cpu
===================================================================
RCS file: /cvs/src/src/cpu/frv.cpu,v
retrieving revision 1.25
diff -u -r1.25 frv.cpu
--- frv.cpu     7 Jan 2009 01:09:24 -0000       1.25
+++ frv.cpu     5 Oct 2009 21:36:15 -0000
 <at>  <at>  -5786,6 +5786,12  <at>  <at> 
  (register-transfer-spr movgs OP_03 OPE1_06 GRj spr u-gr2spr  
"transfer gr->spr")
  (register-transfer-spr movsg OP_03 OPE1_07 spr GRj u-spr2gr  
"transfer spr->gr")

+(dnmi movgs_pcsr ""
+       ()
+       ("movgs_pcsr$pack $GRj")
+       (emit movgs pack GRj (spr 1))
+)
+
  ; Integer Branch Conditions
  (define-pmacro (Inev cc) (const BI 0))
  (define-pmacro (Ira  cc) (const BI 1))
[bld-frv]$ cat tst.S
movgs sp,pcsr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Evans | 6 Oct 2009 17:30

regenerating simulator files

Hi.

fyi, I've been planning on regenerating all the gdb simulator files,
but there's one blocking patch: I'm hoping a lot of the "have all bits
been tested" tests are redundant and can be removed.
Permalink | Reply | 0 comments |

Gmane