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.
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?
<quote> cast a byte pointer to a word pointer <end quote>
According to the standards, doing this causes undefined behaviour, it is not permitted and cannot be done.
If Hans notices, he will have a fit!
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.
<quote> It's the casting of a pointer with wrong alignment. <end quote>
Actually, the casting operation itself does not cause a problem.
It is the dereferencing of the pointer to the result of the cast that might throw a wobbler.
But hey, let's wait for the legendary anger of Hans ;)