Re: problem with 64-bit arch

[Doug Evans <dje at sebabeach dot org>]

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 
to fix in the opcodes support.  Working on a fix but I'm busy over the 
weekend so it'll be next week before the fix is checked in.
The cast bug is related to the above "todo" item in that the fix will 
touch the same areas (the rtl->c generator for shifts doesn't properly 
handle 64-bit values).

Blech, I wish I didn't have to use bfd for bfd_vma, bfd_uint64_t -like 
things, or reinvent all the work bfd has to put into those types.