• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 9 replies
  • Subscribers 350 subscribers
  • Views 17614 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C Programming and pointer sizes on ARM processors.

asp

Hi,

I've a question regarding C programming on ARM processors. can I ALWAYS assume that the sizeof(function_pointers) == sizeof(void *) == sizeof(char *)? Also I read in a blog (Caches and Self-Modifying Code) that "ARM architecture is often considered to be a Modified Harvard Architecture" does this mean the instructions are placed in a different memory space than the data memory space?  If so again how can we guarantee the sizeof (function_pointer) == sizeof(data_pointer)?

Thanks.

Parents
  • 0 in reply to Yasuhiko Koumoto

    There are parts of my reply that are not always valid, and parts of your reply, which also are valid in some cases. Why I mention the structure, is because it's likely that aps would store a pointer to something as a structure member or directly in memory.

    I've used structures to hold some data, which could be of different types myself.

    Personally, I avoid typecasting if possible.

    Here's my solution to a problem where I need to supply a pointer to memory, but I do not know what datatype it actually points to; it can be one of 3 types:

    typedef struct GDevice GDevice;

    struct GDevice

    {

       GDevice *next;

       union{

           void *address;

           uint32_t *address32;

           uint16_t *address16;

           uint8_t  *address8;

       };

    };

    Now the above is not critical code, and all pointers are of the same size. But I do not have to typecast at all. When I set the address, I write to 'address'. When I need the 32-bit pointer, I read address32. When I need the 16-bit pointer, I read address16.

    I can do this, because I know the memory location will always be divisible by 4.

    If I had to typecast, my code would look very messy (I actually cleaned up typecasting this way; it can make a huge difference in how your code look).

    Another advantage is that you do not have to go through every reference in case you one day need to change a uint16_t to a pixel16_t. You don't need to fix up all the type-casts. (Yes, in the particular code, I use pixel8_t, pixel16_t and pixel32_t now, plus a pixel_t of course).

Reply
  • 0 in reply to Yasuhiko Koumoto

    There are parts of my reply that are not always valid, and parts of your reply, which also are valid in some cases. Why I mention the structure, is because it's likely that aps would store a pointer to something as a structure member or directly in memory.

    I've used structures to hold some data, which could be of different types myself.

    Personally, I avoid typecasting if possible.

    Here's my solution to a problem where I need to supply a pointer to memory, but I do not know what datatype it actually points to; it can be one of 3 types:

    typedef struct GDevice GDevice;

    struct GDevice

    {

       GDevice *next;

       union{

           void *address;

           uint32_t *address32;

           uint16_t *address16;

           uint8_t  *address8;

       };

    };

    Now the above is not critical code, and all pointers are of the same size. But I do not have to typecast at all. When I set the address, I write to 'address'. When I need the 32-bit pointer, I read address32. When I need the 16-bit pointer, I read address16.

    I can do this, because I know the memory location will always be divisible by 4.

    If I had to typecast, my code would look very messy (I actually cleaned up typecasting this way; it can make a huge difference in how your code look).

    Another advantage is that you do not have to go through every reference in case you one day need to change a uint16_t to a pixel16_t. You don't need to fix up all the type-casts. (Yes, in the particular code, I use pixel8_t, pixel16_t and pixel32_t now, plus a pixel_t of course).

Children