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?
"TI/Luminary StellarisWare"
It's TI/Luminary code - so why not post on the TI/Luminary forum?
It's their code; they wrote the code, so they should know why they did this!
You are right that it is not generally safe to arbitrarily cast a byte pointer to a word pointer - but maybe the rest of their code should ensure that, in this particular case, it is OK...?
I hope to fix it with
You really need to check with TI/Luminary whether that is compatible with what they are trying to achieve here!
Note: unlike Keil, TI/Luminary technical staff do monitor their forum and do respond to issues like this!
So post this on the TI/Luminary forum: e2e.ti.com/.../default.aspx
Being sure, of course, to include a link to this thread, and give a link here to the thread over there...
why are you posting here?
Due to my very limited C programming skill, I am afraid that, I might be doing something stupid.
Many Thanks for your help, Andy.
"Due to my very limited C programming skill, I am afraid that, I might be doing something stupid."
But that would apply equally to whichever forum - so why did you specifically choose this forum - rather than the TI forum?
And, no - it wasn't a stupid question!
<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!
Posted on the TI/Luminary forum.
e2e.ti.com/.../261784.aspx
Hi Andy,
Because You and Per.
I understand that, the above answer is bad. But I do believe that, you will correct me and then teach me something, if I did something stupid.
John,
As far as I am concerned, the only true stupid thing you can do is not to be sure about something and don't dare to ask! Remember: the one that asks the question (might) look stupid for 5 minutes; the one that does not dare asking remains stupid for eternity!
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 ;)