Re: [ECOS] Question CYGNUM_KERNEL_THREADS_DATA_MAX?

[Jonathan Larmour <jifl at eCosCentric dot com>]

Patrick Doyle wrote:
> > > Thats what im relying on. 1<<32 should be 0 on most processors. If so,
> > > it all works out correct. But its not something i would trust unless
> > > it was written down in some standard and gcc actually implements that
> > > standard.
I just looked at the standard to be absolutely sure about this and it 
says: "If the value of the right operand is negative or is greater than or 
equal to the width of the promoted left operand, the behavior is undefined."

> Wandering in here very late in the game, I am wondering why you don't just
> mask the result of the shift with 0xFFFFFFFFu whereever you use it.  On
> 32-bit machines, the optimizer will (presumably) ignore the NOP mask, and on
> other machines, the result will be 0 as you desire.
Well that's true, although it would be nice if we allowed it to work with 
64-bit addresses in future (difficult with the CDL constraint, but whatever).

The following should do it:
cyg_ucount32 Cyg_Thread::thread_data_map = (~CYGNUM_KERNEL_THREADS_DATA_ALL) &
     (1+((cyg_ucount32)(1<<(CYGNUM_KERNEL_THREADS_DATA_MAX-1))-1)<<1);

Icky, but avoids overflow and gets compiled to a constant by the compiler 
(obviously otherwise it wouldn't compile as an initializer!).

I'll check this in.

Jifl
--
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss