• State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 21 subscribers
  • Views 3976 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

Question about StellarisWare, SW-RDK-S2E, stellarisif.c

John Linq

stellarisif.c

static err_t
stellarisif_transmit(struct netif *netif, struct pbuf *p)
{
  int iBuf;
  unsigned char *pucBuf;
  unsigned long *pulBuf;
  struct pbuf *q;
  int iGather;
  unsigned long ulGather;
  unsigned char *pucGather;

........................... [omitted]

    /* Initialze a long pointer into the pbuf for 32-bit access. */
    pulBuf = (unsigned long *)&pucBuf[iBuf];

    /**
     * Copy words of pbuf data into the Tx FIFO, but don't go past
     * the end of the pbuf.
     *
     */
    while((iBuf + 4) <= q->len) {
      HWREG(ETH_BASE + MAC_O_DATA) = *pulBuf++;
      iBuf += 4;
    }

The above code is part of the latest version of the TI/Luminary StellarisWare.

I think it is a bug? And I hope to fix it with

  __packed unsigned long *pulBuf;


in the KEIL toolchain. (Tested.)

But due to my very limited C programming skill, I am afraid that, I might be doing something stupid. So I would like to learn something from our experts, please kindly give me some advices.

Is that, the __packed qualifier (in this case) leads to the lower performance?

Parents
  • 0 in reply to Jeremiha Simmonnson

    It's isn't the casting of a byte pointer to a word pointer in itself that causes undefined behaviour and is not permitted.

    It's the casting of a pointer with wrong alignment.

    A random byte pointer have 50% probability to point at an odd address, which may fail for processors that can't do 16-bit accesses to odd addresses. And it have 75% probability to not be aligned base 4, introducing problems for 32-bit accesses.

    But in existing code, the byte pointers are often not random. malloc() for example always returns the best required alignment for any object size. So if the code gets a pointer that must have come from malloc(), that pointer can be cast to any other access size without a problem. A pointer from malloc() that someone have done ++ with, will on the other hand get incorrect alignment depending on the type of pointer, i.e. how many char steps the ++ increments it.

    So if the code is valid or not will depend on two things:
    - if the processor supports unaligned access
    - if the omitted code does something that guarantees that the address is always correctly aligned.

Reply
  • 0 in reply to Jeremiha Simmonnson

    It's isn't the casting of a byte pointer to a word pointer in itself that causes undefined behaviour and is not permitted.

    It's the casting of a pointer with wrong alignment.

    A random byte pointer have 50% probability to point at an odd address, which may fail for processors that can't do 16-bit accesses to odd addresses. And it have 75% probability to not be aligned base 4, introducing problems for 32-bit accesses.

    But in existing code, the byte pointers are often not random. malloc() for example always returns the best required alignment for any object size. So if the code gets a pointer that must have come from malloc(), that pointer can be cast to any other access size without a problem. A pointer from malloc() that someone have done ++ with, will on the other hand get incorrect alignment depending on the type of pointer, i.e. how many char steps the ++ increments it.

    So if the code is valid or not will depend on two things:
    - if the processor supports unaligned access
    - if the omitted code does something that guarantees that the address is always correctly aligned.

Children