Thank you Gregory for your reply. I will definitely examine all the links
that you provided.
I'm familiar with ARM address access limitations and also with more exotic
ARC architecture where I first met .sdata and .sbss sections usage for data
that are located near GP. But as you already pointed out that is usually
handled by the compiler or by inserting a proper inline assembly code.
With FAR and NEAR I have more practical questions because those we are
handling manually in NuttX code. I will give you one example: In
libs/libc/dirent/lib_scandir.c there is "scandir" function that performs
next calls:
//-----start code---------------------------------------------
FAR struct dirent *dnew;
FAR struct dirent **list = NULL;
...
/* Grow the directory entry list, if required. */
if (cnt == listsize)
{
struct dirent **newlist;
...
newlist = lib_realloc(list, listsize * sizeof(*list));
...
list = newlist;
}
...
dnew = lib_malloc(dsize);
...
list[cnt] = dnew;
//-----end code---------------------------------------------
So when I review code like this I start asking myself "Is everything right
here?", because:
1. it seems to me that "lib_malloc" / "lib_realloc" return pointer to "FAR"
memory.
2. "newlist" is declared as "NEAR" pointer.
3. "list" -- seems to be a "NEAR" pointer to "FAR" data.
So either my assumption that "lib_realloc" / "lib_malloc" return "FAR"
pointers is wrong or we are missing "FAR struct dirent * FAR *list = NULL;"
and "struct dirent * FAR *newlist;".
I'm feeling like my example might look like a trivial case for a person who
is strongly familiar with the "FAR" / "NEAR" concept, so I will go and read
some papers before continuing this discussion :) I just want to describe
you were my intention comes from.
Best regards,
Petro
нд, 27 бер. 2022 р. о 22:42 Gregory Nutt <spudan...@gmail.com> пише:
> 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.
> >
> >
> ARM does not have near and far qualifier, but it does have some similar
> memory-related issues. The range of a subroutine call via a BL or branch,
> B, is only +/- 32Mb. That is usually large enough if you are executing
> out of a single, contiguous FLASH memory space. But if, for example, you
> are running an ELF module in RAM at, say, 0x20000000 and calling into the
> OS in FLASH, at 0x00000000, it is not enough range. There are no FAR
> pointers, but there is a long call compiler option(-mlong-calls) that is
> necessary to get the full 32-bit range of function calls and branches.
>
