🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac.programmer.codewarrior
Article #858

Re: Long long, optimization and weird debugger errors

#858
From: Raymond
Date: Wed, 05 Feb 2003 20:51
157 lines
6538 bytes
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
Technical Details
Message-ID: <sPe0a.827$AO5.797@newssvr16.news.prodigy.com>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr16.news.prodigy.com.POSTED!74667d8b!not-for-mail
References: <BA54E438.7596%jbotwick@nc.rr.com> <iwXX9.1384$Xh6.582263850@newssvr13.news.prodigy.com> <mwron-AEB1B3.15564629012003@enews.newsguy.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10bcce,9970b840368bc3e
X-Google-Attributes: gid10bcce,public
X-Google-Thread: f635e,9970b840368bc3e
X-Google-Attributes: gidf635e,public
X-Google-Thread: fd047,9970b840368bc3e
X-Google-Attributes: gidfd047,public
X-Google-ArrivalTime: 2003-02-05 12:55:11 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr16.news.prodigy.com.POSTED!74667d8b!not-for-mail
Reply-To: "Raymond" <ray@powerproduction.com>
From: "Raymond" <ray@powerproduction.com>
Newsgroups: comp.sys.mac.programmer.codewarrior,codewarrior.mac,codewarrior.windows
References: <BA54E438.7596%jbotwick@nc.rr.com> <iwXX9.1384$Xh6.582263850@newssvr13.news.prodigy.com> <mwron-AEB1B3.15564629012003@enews.newsguy.com>
Subject: Re: Long long, optimization and weird debugger errors
Lines: 159
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <sPe0a.827$AO5.797@newssvr16.news.prodigy.com>
NNTP-Posting-Host: 66.127.56.119
X-Complaints-To: abuse@prodigy.net
X-Trace: newssvr16.news.prodigy.com 1044478296 ST000 66.127.56.119 (Wed, 05 Feb 2003 15:51:36 EST)
NNTP-Posting-Date: Wed, 05 Feb 2003 15:51:36 EST
Organization: Prodigy Internet http://www.prodigy.com
X-UserInfo1: [[O]S\OEWJSWS_X[N[O@_WH@YR_B@EXLLBWLOOAFBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN
Date: Wed, 05 Feb 2003 20:51:36 GMT