On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Kenneth Zadeck <zad...@naturalbridge.com> writes: >> I would like you to respond to at least point 1 of this email. In it >> there is code from the rtl level that was written twice, once for the >> case when the size of the mode is less than the size of a HWI and once >> for the case where the size of the mode is less that 2 HWIs. >> >> my patch changes this to one instance of the code that works no matter >> how large the data passed to it is. >> >> you have made a specific requirement for wide int to be a template that >> can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I >> would like to know how this particular fragment is to be rewritten in >> this model? It seems that I would have to retain the structure where >> there is one version of the code for each size that the template is >> instantiated. > > I think richi's argument was that wide_int should be split into two. > There should be a "bare-metal" class that just has a length and HWIs, > and the main wide_int class should be an extension on top of that > that does things to a bit precision instead. Presumably with some > template magic so that the length (number of HWIs) is a constant for: > > typedef foo<2> double_int; > > and a variable for wide_int (because in wide_int the length would be > the number of significant HWIs rather than the size of the underlying > array). wide_int would also record the precision and apply it after > the full HWI operation. > > So the wide_int class would still provide "as wide as we need" arithmetic, > as in your rtl patch. I don't think he was objecting to that.
That summarizes one part of my complaints / suggestions correctly. In other mails I suggested to not make it a template but a constant over object lifetime 'bitsize' (or maxlen) field. Both suggestions likely require more thought than I put into them. The main reason is that with C++ you can abstract from where wide-int information pieces are stored and thus use the arithmetic / operation workers without copying the (source) "wide-int" objects. Thus you should be able to write adaptors for double-int storage, tree or RTX storage. > As is probably obvious, I don't agree FWIW. It seems like an unnecessary > complication without any clear use. Especially since the number of Maybe the double_int typedef is without any clear use. Properly abstracting from the storage / information providers will save compile-time, memory and code though. I don't see that any thought was spent on how to avoid excessive copying or dealing with long(er)-lived objects and their storage needs. > significant HWIs in a wide_int isn't always going to be the same for > both operands to a binary operation, and it's not clear to me whether > that should be handled in the base class or wide_int. It certainly depends. Richard. > Richard