Volatile now required for access to SRAM/VRAM unlike past versions

Post Reply
Dwedit
Posts: 42
Joined: Sun Jan 06, 2008 4:06 am

Volatile now required for access to SRAM/VRAM unlike past versions

Post by Dwedit » Mon May 23, 2022 7:36 pm

I just wanted to give a heads up to anyone experiencing this. I only caught this because of warnings from the NO$GBA debugger.

In past versions of DevKitArm, you could write code like this:

Code: Select all

void ByteSet(char *p, char value, int size)
{
    while (size)
    {
        *p++ = value;
        size--;
    }
}
In past versions of DevKitArm, this code would compile so that only 8 bit memory access would be performed to that memory, so you could use such code for the SRAM memory area.
This is no longer the case. The compiler will now either replace this with a call to "memset", or will generate code that does 32-bit writes to memory. So this code can no longer be used as-is to access the SRAM memory area.

You now need to use "volatile" on your pointer to prevent the compiler from being allowed to use a larger read or write size.

This even applies to VRAM, in some cases, the compiler will decide to perform 8-bit writes, even if your code did not use any such writes.
A snippet of some code:

Code: Select all

u16 *here=(u16*)0x06000000+(row&0x1F)*32;
int i = 0;
u16 space;
...
for(;i<29;i++)
{
	here[i] = space;
}
In this snippet, the compiler detected a series of writes in a loop, and changed it to memset. The code inside memset saw that the pointer was not aligned to a dword boundary, so it performed 8 bit writes to VRAM.

So now all access to VRAM or SRAM must be done through volatile pointers, otherwise the compiler is free to pick memory access that is incompatible with the actual hardware.

edea
Posts: 1
Joined: Mon Jun 13, 2022 11:59 pm

Re: Volatile now required for access to SRAM/VRAM unlike past versions

Post by edea » Tue Jun 14, 2022 12:57 am

Unfortunately this is wrong.
You don't really understand the semantics of "volatile" and how C looks at the memory access.
All memory locations accessed by C code are uniformly from the point of view of the C compiler,This is often referred to as uniform memory access(UMA).
The "uniform" here means that all these memory locations can be accessed at any time by any load/store instruction.
The "volatile" just tell the compiler that you must generate real load/store instructions.
However,the compiler can still use any type of load/store instruction for performance as long as the result is consistent with the semantics expressed by the C code.
So the problem here is not the behavior of the C compiler but which memory locations you access cannot be treated uniformly,so these memory locations should not be accessed by C code.
You should write the C ABI compliant assembler to access these memory locations and provide the C function interfaces,then use these functions to indirectly access those memory locations instead of directly by C code.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest