[U-Boot] Building for da830 fails

[Nick Thompson]

On 11/05/10 11:39, Wolfgang Denk wrote:
> Dear Nick,
> 
> In message <4BE91C64.9050402 at ge.com> you wrote:
>>
>> True, but the extra library (and abi workaround) bloat is not necessary in
>> this particular case.
> 
> I agree that we can avoid the 64 bit division here - at the cost of
> code that becomes much more difficult to read and understand.
> 
> Look at code like this:

Yes, I wrote (some of) it :-)

> 
> +	f = size & ((1ULL << d) - 1);
> ...
> -	if(size % d) {
> -		m = (10 * (size - (n * d)) + (d / 2) ) / d;
> +	if (f) {
> +		m = (10ULL * f + (1 << (d - 1))) >> d;
> 
> 
> We make things more easy for the compiler at the cost of making it
> way more difficult for us humans.  I think this is a move in the wrong
> direction.  Normally we try to go exactly the opposite direction.

I've certainly made your point here. It's taken me 3 version to make it work,
but, maybe with with a little commenting, I think that's readable. I'm not
sure that:

	n = size / d;

	if(size % d) {
		m = (10 * (size - (n * d)) + (d / 2) ) / d;
		...

is really any more readable is it?

Me: What is '(size - (n * d))'? Oh, its just '(size % d)'. Why is it
calculating that twice???

Maybe I'm just allergic to divides - especially when working with variables 
containing powers of two. That's what I get for working on ARM processors for
so long...

How about:

	n = size >> d
	f = size & ((1ULL << d) - 1);

	/* If there's a remainder, deal with it */
	if (f) {
		roundup = 1 << (d - 1); /* 0.5 << d */
		m = (10ULL * f + roundup) >> d;
		...

?

[...]

>> or avoid using features not available in all toolchains that you wish to support.
> 
> We never claimed to support "all toolchains" - for example, recent
> versions of U-Boot cannot be compiled any more with gcc-2.95.x - but
> is this really an issue?  I don't think so.

I didn't say "all toolchains", but "all toolchains that you wish to support".
In this case, both MontaVista and CodeSourcery's latest ARM compilers don't work.

Should you treat the cause or the symptom? Personally, I prefer the former. The
eabi compat function feels more like the latter.

In the interests of not holding back other CPU's though, I guess I can live with
it.

[...]

>> The eabi stub you submitted is only good as long as C++ and exceptions are not
>> used by U-Boot. Exceptions in particular are a powerful way to clean up error
>> handling code - can we ever say never?
> 
> No, we cannot. But we do :-)
>
>
> <asbestos underwear>

Blimey. I can hear the chafing from here ;-)

Regards,
Nick.