This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Problem when max operands > 127


Hello,

In cgen.h,
  if MAX_OPERANDS <= 127 or !defined, CGEN_SYNTAX_CHAR_TYPE 
  is a char.

  if MAX_OPERANDS > 127,  CGEN_SYNTAX_CHAR_TYPE is short.

The problem is the non generated, common cgen files
(cgen-asm.c, cgen-dis.c and cgen-opc.c) do not include
your_port_here-desc.h where MAX_OPERANDS is defined.

So, regardless of what MAX_OPERAND is, these files think
that CGEN_SYNTAX_CHAR_TYPE is a char and the size of the
syntax array is 40 bytes.  If MAX_OPERAND is > 127, the 
syntax array is allocated as 80 bytes. When these common
files attempt to deference the member after the array, 
they die a painful death as they dereference after 40 bytes
not 80. Plus, the syntax array looks pretty weird to them.

Here are a few of solutions (with pros and cons) gathered 
from hall talk / head scratching:

1. have CGEN_SYNTAX_CHAR_TYPE defined as a short (with
   appropriate associated defines modified) in all instance

   Pros: only have to modify cgen.h
      
   Cons: .object files will grow as the syntax array
          doubles in size for each insn.  My table went
          from ~65k to ~115k based on ~1300 instructions
         .may encounter problems where char is used where
          CGEN_SYNTAX_CHAR should (but... I'm going to 
          hit those anyway so it's a moot point)
         .existing ports need not be regenerated but
          probably should

2. generate the common files to include the port specific
   desc.h file (and whatever else is required by this
   file)

   Pros: size of the objs for existing ports stays the same

   Cons: .alters the build structure
         .removes the commonality of the common files 
         .existing ports have to be regenerated


3. merge the common files with their existing *.in file 
   counterparts

   Pros and cons are more or less the same as 2.


Based on this somewhat crude reasoning, it looks as though
solution 1 will correct the problem with the least amount
of pain.   

Comment/suggestions invited.  If I don't hear anything by
the end of the week, I'll submit a patch.

Patrick

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]