On 10/30/2011 04:59 PM, Blue Swirl wrote: > > > > There is no direct use of signed arithmetic in the API (just in the > > implementation). Aliases can cause a region to move in either the > > positive or negative direction, and this requires either signed > > arithmetic or special casing the two directions. > > > > Signed arithmetic is not the only motivation - overflow is another. > > Nothing prevents a user from placing a 64-bit 4k BAR at address > > ffff_ffff_ffff_f000; we could move to base/limit representation, but > > that will likely cause its own bugs. Finally, we should be able to > > represent both a 0-sized region and a 2^64 sized region. > > It looks like 64 bit saturating arithmetic could also work.
Depends when you saturate. The standard example (vga) takes a alias of (say) 0xe01a0000 and aliases it into 0x000a0000. So you need to adjust addresses downwards by -0xe0100000. That brings the start of the real region (0xe0000000) into the negative territory. Saturating it there would break it. > It should > also be possible to work only with (start, end) address pairs and > never with start + size, then 2^64 shouldn't be an issue. Then 0 becomes an issue (end < start). -- error compiling committee.c: too many arguments to function
