🚀 go-pugleaf

In article <sPe0a.827$AO5.797@newssvr16.news.prodigy.com>,
 "Raymond" <ray@powerproduction.com> wrote:


Yes  I'll ask that this be revisited.

Ron

>RE: 1-28735400
>-----------------
>
>Ron
>
>Thank you very much for looking into this.
>Unfortunately I made the mistake of simplifying my problem into Sample Code.
>
>I do not believe the problem is with the flaws in this sample.
>
>The problem is:
>When I pass a 64bit value, the HIGH 32bits disappear. In the MW Debugger, I
>can see the 64bit value is valid in the Caller, but the Callee does not
>receive the full 64bits.
>I have decided that this *is* a bug for the following reason:
>-- If I create a variable (in the callee) which receives the Address of the
>64bit value everything magically works
>-- -- (See variable named "magically_makes_things_work" )
>
>     void callee (unsigned long long important_value )
>     {
>     unsigned long long* magically_makes_things_work = (&important_value);
>
>          //some code using important_value
>     }
>
>If the variable "magically_makes_things_work" is not present, then
>"important_value" will not be accurate.
>When the variable "magically_makes_things_work" is present, the value
>of"important_value" is accurate.
>-- I believe the variable "magically_makes_things_work" forces
>"important_value" to be kept outside of the registers. Without the variable
>"magically_makes_things_work," the MW Compiler tries to keep
>"important_value" in the register and perhaps there is a bug in passing
>64bits through the register.
>
>So I hear you Ron (and your support agents) that creating a ULL the way I
>demonstrated in the sample is nonstandard. I fully accept the responsibility
>for creating a bogus sample. Sorry. But I was trying to demo the behavior I
>was seeing in my more complicated program.
>-- I feel my real issue was ignored because my demo program was flawed.
>
>Can you see past my flawed sample and look at this issue again?
>Thank you for your time
>ray
>
>
>
>"MW Ron" <mwron@metrowerks.com> wrote in message
>news:mwron-AEB1B3.15564629012003@enews.newsguy.com...
>> In article <iwXX9.1384$Xh6.582263850@newssvr13.news.prodigy.com>,
>>  "Raymond" <ray@n0.sp4m.powerproduction.n0.sp4m.com> wrote:
>>
>> >Jason
>> >
>> >I had a similar problem and MW support tried to pacify me by saying I was
>> >doing something wrong, and finally blew me off.
>> >-- (MWRon, see: MW Tech support # 1-28735400)
>>
>> I looked into this and support thought that you had understood the
>> question.  Here is a fuller description of why this is not an error and
>> your code is non conformant.
>>
>> Ron
>>
>>    a left shift, can only operate in the context of the bits in the
>>    part being shifted. So shifting a 32-bit value by a value of 32
>>    or greater is undefined in the language standard.
>>
>>    a constant like 5, is an int and will not get promoted to
>>    a "long long" or "unsigned long long" unless the code explicitly
>>    uses the long long (or unsigned long long) form of the constant:
>>
>>    5LL or 5ULL
>>
>>    or if there is an explicit type casting:
>>
>>    (long long) 5 or (unsigned long long) 5
>>
>>    When assigning a computation to a variable the implicit type convert
>>    happens after the expression is evaluated.
>>
>>    so on PowerPC:
>>
>>    (5 << 32) | (32777)
>>
>>    produces either: 0x8009 or 0x800d
>>
>>    In the first case the IR optimizer treated the undefined value
>>    as 0 (5 << 32) == 0. In the second case the code generator ANDed
>>    the shift amount with 31 such that (5 << 32) becomes (5 << 0) == 5.
>>
>>    It will never produce 0x500008009, and even then the example
>>    is wrong as 0x500008009 & 0xFFFF000000000000 produces 0.
>>
>>    Neither behavior will produce the results expected by the code
>> example:
>>
>>    void  main ( void )
>>    {
>>       UInt64 value;
>>
>>       value =  ( ( 5 << 32 ) | ( 32777 ) );
>>       Routine_1( value );
>>    }
>>
>>    void  Routine_1 ( UInt64 value )
>>    {
>>       Routine_2( value );
>>    }
>>
>>    void  Routine_2 ( UInt64 value )
>>    {
>>       if( value & 0xFFFF000000000000 )
>>       {
>>          return; //no problems
>>       }
>>       else
>>       {
>>          complain(__LINE__);
>>       }
>>    }
>>
>>
>> therefore your code must be written like:
>>
>>    void  main ( void )
>>    {
>>       UInt64 value;
>>
>>       value =  ( ( ((UInt64)5) << 32 ) | ( 32777 ) );
>>       Routine_1( value );
>>    }
>>
>>    void  Routine_1 ( UInt64 value )
>>    {
>>       Routine_2( value );
>>    }
>>
>>    void  Routine_2 ( UInt64 value )
>>    {
>>       if( value & 0xFFFFFFFF00000000 )
>>       {
>>          return; //no problems
>>       }
>>       else
>>       {
>>          complain(__LINE__);
>>       }
>>    }
>>
>> --
>>      Free Programming Courses at CodeWarrior U
>>           <http://www.codewarrioru.com>
>>
>>  Metrowerks, maker of CodeWarrior  -  "Software Starts Here"
>> Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com
>
>

-- 
     Free Programming Courses at CodeWarrior U
          <http://www.codewarrioru.com>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  
Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com