These are pretty standard C compiler concepts, although people used to working with pure 32-/64-bit CPUs may not have experience with them. They used to be very standard like in x86 real mode.
Since they are standard concepts, you can probably get the more authoritative information by Googling, like https://www.google.com/search?q=far+near+C+qualifers . That brings up dozens of technical articles on near and far pointers. The first hit gives a pretty concise definition: https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86002268-209/section-000066613.html The second hit, I think, answers all of you questions in the context of some Renesas CPU: http://tool-support.renesas.com/autoupdate/support/onlinehelp/csp/V4.01.00/CS+.chm/Compiler-CCRL.chm/Output/cd_EXP_LANG8.html There is a lot more info out there. On Sun, Mar 27, 2022 at 2:21 PM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > Hi, > > I want to improve my knowledge about FAR usage in NuttX code. I've already > read some initial information related to "Far memory" and "3-byte pointers > to access extended memory spaces", but still lacking a practical experience > with a real compiler and device use case. My main question is about FAR > usage notation, because currently it seems to me very confusing. I assume > that notation is very similar to "const", but do not have a way to prove > it, so I'm asking for help from people that have more practical experience. > So I will go with few examples: > > 1. FAR char *p; -- that is fully understood. Generate code to use a 3-bytes > pointer to char. > 2. FAR char **p; -- here where my understanding ends. Is this a 3-byte > pointer to an array of traditional 2-byte pointers or traditional 2-byte > pointer to an array of 3-byte pointers? Or even a 3-byte pointer to an > array of 3-byte pointers? > 3. The answer to this will come from answer on 2, but still: is "FAR char * > FAR *p;" valid? > > I'm asking this because sometimes I modify common code that is equipped > with "FAR" and want to be sure that my changes will not break things. > > Best regards, > Petro >
