[Resent for the 3rd time. I seems I can't write to the list]
David Given wrote:
> Christopher Li wrote:
> [...]
>
>> You are right that point out a bug (assumption) of sparse which byte
is 8 bits.
>> Using bits_in_byte is instead of 8 is better there.
>> Using bits_in_char assumes char has same bits as byte. That is my read
>> of the C spec.
>>
>
> Yes, indeed, I'd managed to get my terminology muddled to the confusion
> of everyone.
>
> Okay, I've gone and looked at the implementation of this stuff; it would
> appear that modifying the code to supply the back end with units scaled
> in something other than C chars is actually quite complicated, so I
> haven't tried to do that. However, I'm enclosing a patch that should,
> hopefully, fix the cases where it's assuming 8 bit bytes. Hopefully I've
> managed to catch all the cases, without breaking the octal parse code...
>
> (I haven't used git before; is this the right format?)
>
Yes, but it would have been better to have kept all the white space
changes for a separate change so we could just see that relevant changes.
This introduces divides all over the place for all users, replacing a
very cheap constant shift with an expensive divide. All sparse users
would be paying the cost for a feature that is useful for 1 user, I
think we should perhaps think carefully about this.
One obvious solution would be to introduce a BITS_IN_CHAR macro in
target.h defaulting to 8 and let "exotic" architectures redefine it to
bits_in_char. This is very similar to the approach GCC is using.
On a completely unrelated node, I'm excited to see your work on using
sparse for compilation. Hopefully your experience will lead to it being
easier for the next guy. I would like to see sparse target for a simple
abstract machine, but I so far haven't had time to work on it.
Tommy
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
