Re: problem with 64-bit arch

[Doug Evans <dje at sebabeach dot org>]

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;
>         value = (() (((value) - (pc))) >> (2));
>         errmsg = insert_normal (cd, value,
> 0|(1<<CGEN_IFLD_SIGNED)|(1<<CGEN_IFLD_PCREL_ADDR), 0, 8, 24, 32,
> total_length, buffer);
>       }
>       break;
>
> Note the missing type in the cast before assigning to value. Also 
> using a long type for value will cause problems when running on a 
> 32-bit host, since it operates on 64-bit values.
>
> I had a quick look at the other two archs that use word-bitsize 64, 
> ie. sparc64 and ia64, and it seems they use multi-ifields for this 
> kind of PC-relative field, which may be an artificial way of avoiding 
> the problem.
>
> Is there an obvious fix to this problem?

Obvious?  Possibly.

For reference sake, there are several separate notions here: data word 
bitsize, and instruction word bitsize.
sparc64 has 64/32, ia64 has 64/64 [IIUC, and I'm leaving out "bundles", 
I don't know ia64 that well]

[For completeness sake, there's also data address and instruction 
address word bitsize.  I'm guessing they're 64 here, same as data word 
bitsize, so we can ignore them.]

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

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.

(*1): It would foreclose using such ports on hosts that don't have 
64-ints, but I don't mind, personally.
[I wonder if someday we'll want to use SI/DI/etc. to represent 
instructions.  That's *way* down the road, if ever.]