I've never heard of a CPU that can switch its endianess.

This link doesn't mention endianness, but it is from the manufacturer.

http://www.arm.com/products/CPUs/ARM720T.html

I thought ARMs were all little endian.  If one is, then to be assembly level
compatible, they would all need to be.

HTH,
Aaron R>


On 6/28/07, Fleming, Craig <[EMAIL PROTECTED]> wrote:

I'm fairly certain that the DS is little-endian, but all my Googling
hasn't given me a solid statement like "The Nintendo DS is a
little-endian machine...".

My reasoning:
1. If I try to compile with -mbig-endian the linker complains about
"compiled for a big-endian system and the target is little-endian". This
is because DevKitPro isn't designed to be linked to big-endian object
code, which I assume is because the DS isn't big-endian.
2. One page said that the GBA (which used a single ARM7 cpu) was
permenantly set to little-endian. This is again an assumption - no idea
if the same holds for the DS.
3. Some code I found to check told me it wasn't :P.

int IsBigEndian(void) {
        long l = 0x00000001;
        char *pc = (char *)&l;
        return ((*pc)==0x00);
}
IsBigEndian() == 0

But in the end, I don't actually know for certain. LITTLE_ENDIAN is
defined as 1 in platform_config.h.

Something I was playing with...I looked at the memory locations that are
"switching around". If I view them as halfwords, they appear as they are
being printed out - incorrectly. If I view them as words, they appear
correctly. I've been trying to figure out if there is something that is
changing how the data is "viewed" within the executable, but am still
poking around. :)

Thanks
Craig

-----Original Message-----
From: Lawrie Griffiths [mailto:[EMAIL PROTECTED]
Sent: 2007-Jun-28 11:29 AM
To: Fleming, Craig; [email protected]
Subject: Re: [Lejos-discussion] Compiling Lejos for the Nintendo DS

Does the Nintendo DS chip run little-endian or big-endian? I believe ARM
chips can run either way. Do you have the correct setting in
platform_config.h?

Lawrie

----- Original Message -----
From: "Fleming, Craig" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 28, 2007 6:23 PM
Subject: Re: [Lejos-discussion] Compiling Lejos for the Nintendo DS


>
> I found something new and interesting!
>
> I changed the %ld's to %lx's so I could see what memory address I was
> dealing with and plug that into my emulator for perhaps some new
> information. What I printed was (using same numbering scheme as
before):
>
> (1) Displays "StackFrameArray: 0 IsArray: 0 StackArray: 0 IsArray: 0".
> (2) Displays "StackFrameArray: 201773a IsArray: 1 StackArray: 0
IsArray:
> 0".
> (3) Displays "StackFrameArray: 773a0201 IsArray: 0 StackArray: 201770e
> IsArray: 1".
> (4) Displays "StackFrameArray: 773a0201 IsArray: 0 StackArray:
770e0201
> IsArray: 0".
> (5) Execution dies here with assertion violation 20 as it should.
>
> So taking StackFrameArray as an example, 0201 773a becomes 773a 0201,
> swapping the half words around!
>
> I still have no idea why this happens or how to fix it, but at least
> there is a pattern now :).
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Fleming, Craig
> Sent: 2007-Jun-27 3:14 PM
> To: [email protected]
> Subject: Re: [Lejos-discussion] Compiling Lejos for the Nintendo DS
>
> Thanks for the suggestion. I downloaded the NXJ code and had it
> compiling with my code in a couple minutes - a testament to the
> modularity of the code you folks have written :)
>
> Unfortunately I'm having the same error, but with slightly different
> symptoms. Here is the same chunk of code, but with slightly better
> descriptive printfs. (1), (2), etc have been added in this e-mail to
aid
> in description.
>
> (1)  printf( "StackFrameArray: %ld IsArray: %d StackArray: %ld
IsArray:
> %d\n",
> thread->stackFrameArray,
> is_array(word2obj(thread->stackFrameArray)),
> thread->stackArray,
> is_array(word2obj(thread->stackArray) ) );
>
>  // Allocate space for stack frames.
>  thread->stackFrameArray = ptr2word (new_primitive_array
(T_STACKFRAME,
> INITIAL_STACK_FRAMES));
>  if (thread->stackFrameArray == JNULL)
>    return false;
> (2)  printf( "StackFrameArray: %ld IsArray: %d StackArray: %ld
IsArray:
> %d\n",
> thread->stackFrameArray,
> is_array(word2obj(thread->stackFrameArray)),
> thread->stackArray,
> is_array(word2obj(thread->stackArray) ) );
>
>  // Allocate actual stack storage (INITIAL_STACK_SIZE * 4 bytes)
>  thread->stackArray = ptr2word (new_primitive_array (T_INT,
> INITIAL_STACK_SIZE));
> (3)  printf( "StackFrameArray: %ld IsArray: %d StackArray: %ld
IsArray:
> %d\n",
> thread->stackFrameArray,
> is_array(word2obj(thread->stackFrameArray)),
> thread->stackArray,
> is_array(word2obj(thread->stackArray) ) );
>
> (4) printf( "StackFrameArray: %ld IsArray: %d StackArray: %ld
> IsArray: %d\n",
> thread->stackFrameArray,
> is_array(word2obj(thread->stackFrameArray)),
> thread->stackArray,
> is_array(word2obj(thread->stackArray) ) );
>
>  if (thread->stackArray == JNULL)
>  {
>    free_array (ref2obj(thread->stackFrameArray));
>    thread->stackFrameArray = JNULL;
>    return false;
>  }
>
>  gThreadCounter++;
>
>  #ifdef VERIFY
> (5)  assert (is_array (word2obj (thread->stackFrameArray)), THREADS0);
>  assert (is_array (word2obj (thread->stackArray)), THREADS1);
>  #endif
>
> (1) Displays "StackFrameArray: 0 IsArray: 0 StackArray: 0 IsArray: 0"
as
> you would expect.
> (2) Displays "StackFrameArray: 33650490 IsArray: 1 StackArray: 0
> IsArray: 0", again, looks good.
> (3) Displays "StackFrameArray: 2000290305 IsArray: 0 StackArray:
> 33650446 IsArray: 1". Here is where problems start. StackFrameArray
has
> changed without being touched at all. StackArray looks good however.
> (4) Displays "StackFrameArray: 2000290305 IsArray: 0 StackArray:
> 1997406721 IsArray: 0". Just one line later StackArray has gone awry.
> StackFrameArray displays the same number it did at the start.
> (5) Execution dies here with assertion violation 20 as it should.
>
> How it differs from the RCX code is that at (4), StackArray would
> display correctly, and would have IsArray=1. Now the pointers are
> changing consistently at least :).
>
> Any advice would be appreciated. In my normal world of Java and C#,
> pointers don't just change from line to line unless there is a thread
> race condition. :)
>
> Thanks,
> Craig
>
>
> -----Original Message-----
> From: Lawrie Griffiths [mailto:[EMAIL PROTECTED]
> Sent: 2007-Jun-26 9:39 AM
> To: Fleming, Craig; [email protected]
> Subject: Re: [Lejos-discussion] Compiling Lejos for the Nintendo DS
>
> The NXT version of the VM has some fixes for alignment problems on the
> ARM chip. What chip is the Nintendo DS?
>
> Lawrie
>
> ----- Original Message -----
> From: "Fleming, Craig" <[EMAIL PROTECTED]>
> To: "Lawrie Griffiths" <[EMAIL PROTECTED]>;
> <[email protected]>
> Sent: Tuesday, June 26, 2007 4:17 PM
> Subject: Re: [Lejos-discussion] Compiling Lejos for the Nintendo DS
>
>
>> I'm currently using the RCX code because that was the first thing I
>> downloaded. Is there an important difference?
>>
>> -----Original Message-----
>> From: Lawrie Griffiths [mailto:[EMAIL PROTECTED]
>> Sent: 2007-Jun-26 8:16 AM
>> To: Fleming, Craig; [email protected]
>> Subject: Re: [Lejos-discussion] Compiling Lejos for the Nintendo DS
>>
>> Craig,
>>
>> Are you using the RCX code or the NXT code?
>>
>> Lawrie
>>
>> ----- Original Message -----
>> From: "Fleming, Craig" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Monday, June 25, 2007 11:48 PM
>> Subject: [Lejos-discussion] Compiling Lejos for the Nintendo DS
>>
>>
>>> Hello everyone,
>>>
>>> I know that a similar topic was brought up many years ago, and I
>>> don't know if that was anything other than one developers little pet
>> project,
>>> or even if anyone who reads this is interested in this. But I had
>>> some free time and a desire to see if I could do it, so here it is.
>>> If
>> there
>>> is no interest, that's quite alright - I'll just keep plugging away
>> here
>>> :). I've run into a confusing problem and I had hoped someone in
here
>
>>> might be able to help me out. Unfortunately C/C++ is not my native
>>> language - I know how to write some small programs but most of the
>> Lejos
>>> code is beyond me.
>>>
>>> I've managed to write/copy enough code to get Lejos to compile using
>>> DevKitPro/DevKitArm. I've been through a couple days of debugging,
>>> making steady progress until today. I'm in threads.c, in
>>> init_threads( Thread *thread ). What happens is:
>>>
>>> 1. A successful call is made to new_primitive_array, assigning to
>>> thread->stackFrameArray.
>>> 2. A successful call is made to new_primitive_array, assigning to
>>> thread->stackArray
>>> 3. An assertion exception 20 is thrown.
>>>
>>> I've been printfing my way around the code, and I've determined that
>>> thread->stackFrameArray is somehow corrupted between the second call
>> to
>>> new_primitive_array and the first line of this call. There is no
code
>
>>> except the two printfs between the point of corruption. I fixed this
>>> problem by assigning to a temporary variable and then after the
>>> second call to new_primitive_array, I assign that temporary variable
>>> to
>>> thread->stackFrameArray.
>>>
>>> Still with me? :) This work-around keeps the pointers from being
>>> corrupted, but doesn't solve the problem! If I do this, a call to
>>> is_array still returns false, throwing the assertion 20. A few more
>>> printfs give me the reason I'm writing this - a strange situation
>>> that is beyond my knowledge.
>>>
>>> 1. A call to is_array just after the assignment to
thread->stackArray
>
>>> returns 1.
>>> 2. A call to is_array just after THAT call to is_array returns 0!
>>>
>>> Here is the offending section of code, including the "work-around"
>>> (which is a problem I don't understand by itself), and the final two
>>> printfs. The first displays "1 1", the second displays "0 0".
>>>
>>>  JINT stackFrameArray = ptr2word (new_primitive_array (T_STACKFRAME,
>>> INITIAL_STACK_FRAMES));  if (stackFrameArray == JNULL)
>>>    return false;
>>>
>>>  // Allocate actual stack storage (INITIAL_STACK_SIZE * 4 bytes)
>>> thread->stackArray = ptr2word (new_primitive_array (T_INT,
>>> INITIAL_STACK_SIZE));  thread->stackFrameArray = stackFrameArray;
>>> printf( "%d %d\n", is_array( word2obj(thread->stackFrameArray) ),
>>> is_array( word2obj(thread->stackArray) ) );  printf( "%d %d\n",
>>> is_array( word2obj(thread->stackFrameArray) ), is_array(
>>> word2obj(thread->stackArray) ) );  if (thread->stackArray == JNULL)
{
>>>    free_array (ref2obj(thread->stackFrameArray));
>>>    thread->stackFrameArray = JNULL;
>>>    return false;
>>>  }
>>>
>>>  gThreadCounter++;
>>>
>>>  #ifdef VERIFY
>>>  assert (is_array (word2obj (thread->stackFrameArray)), THREADS0);
>>> assert (is_array (word2obj (thread->stackArray)), THREADS1);  #endif
>>>
>>> Thanks for reading.
>>>
>>> Craig
>>>
>>>
>>
----------------------------------------------------------------------
>> --
>> -
>>> This SF.net email is sponsored by DB2 Express Download DB2 Express C
>>> - the FREE version of DB2 express and take control of your XML. No
>>> limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> Lejos-discussion mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/lejos-discussion
>>>
>>>
>>> --
>>> Internal Virus Database is out-of-date.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.472 / Virus Database: 269.8.0/818 - Release Date:
>> 25/05/2007
>>> 12:32
>>>
>>>
>>
>>
>>
----------------------------------------------------------------------
>> --- This SF.net email is sponsored by DB2 Express Download DB2
Express
>
>> C - the FREE version of DB2 express and take control of your XML. No
>> limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Lejos-discussion mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/lejos-discussion
>>
>>
>> --
>> Internal Virus Database is out-of-date.
>> Checked by AVG Free Edition.
>> Version: 7.5.472 / Virus Database: 269.8.0/818 - Release Date:
>> 25/05/2007
>> 12:32
>>
>>
>
>
>
------------------------------------------------------------------------
> -
> This SF.net email is sponsored by DB2 Express Download DB2 Express C -
> the FREE version of DB2 express and take control of your XML. No
limits.
> Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Lejos-discussion mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lejos-discussion
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Lejos-discussion mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lejos-discussion
>
>
> --
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.5.472 / Virus Database: 269.8.0/818 - Release Date:
25/05/2007
> 12:32
>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Lejos-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lejos-discussion

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Lejos-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lejos-discussion

Reply via email to