Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: (PR#4038) Multiple starting points for PF
Home

[Freeciv-Dev] Re: (PR#4038) Multiple starting points for PF

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#4038) Multiple starting points for PF
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Tue, 6 May 2003 14:41:01 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Tue, 6 May 2003, Raimar Falke wrote:

> On Tue, May 06, 2003 at 04:33:51AM -0700, Gregory Berkolaiko wrote:
> > 
> > I thought the big reason of having the struct parameter was that we could 
> > put parameters (funnily enough) in there and avoid having different types 
> > of function calls...
> 
> You can't get all ;)

But in this case we can!  I don't see why we shouldn't.

> > > I'm for a new "utiny_t flags" with current 2 bits defined. If you have
> > > rearranged the struct this extra byte will however increase the size
> > > from 16 to 20 bytes (which is also the current size). If you now think
> > > that these 4 bytes increase isn't acceptable for 2 extra bits we have
> > > to go into Rafal-mode ;) and shift and mask the values. In this mode
> > > we would count the bits: 3 (dir)+ 3 (type) + 2 (behavior) + 2 (zoc) +
> > > 1 (start) = 11 bits and would see that 1 short int would be enough.
> > 
> > So how about
> > 
> >    struct pf_node {
> >      int cost;                 /* total_MC */
> >      int extra_cost;           /* total_EC */
> >      utiny_t dir_to_here;              /* direction from which we came */
> > 
> >      /* Cached values */
> >      utiny_t node_known_type;
> >      utiny_t behavior;
> >      utiny_t flags;            /* 0th bit START, 1st bit allied, 
> >                                 * 2nd bit our ZoC */
> >      int extra_tile;           /* EC */
> >    };
> > 
> > ?
> > 
> > It is 16 bytes which is the minimal we can get if we believe what you say 
> > about gcc padding ;)
> > 
> > I believe that putting zoc-info into a bitfield is ok, because it's mined 
> > and managed entirely by the PF-module.  It would be less clean to convert 
> > callback return values to bitfields as well.
> 
> The question how these bits are accesses. But I trust you that you
> don't peek with literal numbers i.e. if(BV_ISSET(p->flags,0)) ;)

Like in the previous patch:

enum node_flag {
  NF_START = 0,
  NF_ALLIED,
  NF_OWNZOC
} 

if (BV_ISSET(p->flags, NF_START)) {
}

G.




[Prev in Thread] Current Thread [Next in Thread]