11-12-2022, 01:43 AM
Hi!
Reading byte by byte is not a problem, as you can read a byte on any boundary. Just personal experience, some years ago I wrote a FAT filesystem driver for an embedded device that was a bit of a headache. The FAT table has lots of word values (i.e. two-byte fields) that are unaligned. Trying to read those words on that device (a Renesas H8S) on unaligned boundaries caused CPU faults. I had to read all those unaligned words as two individual bytes, and then reconstruct the word value merging the two bytes. A simple word read should be much more elegant.
On Intel CPUs you won't have any problem. But if your format ever goes to ARM (cell phones, etc) developers writing a PAL64 handler will face these kind of problems:
https://developer.arm.com/documentation/ka003038/latest
So for portability and ease of implementation, I recommend you to place data fields on aligned boundaries relative to their natural data size
Reading byte by byte is not a problem, as you can read a byte on any boundary. Just personal experience, some years ago I wrote a FAT filesystem driver for an embedded device that was a bit of a headache. The FAT table has lots of word values (i.e. two-byte fields) that are unaligned. Trying to read those words on that device (a Renesas H8S) on unaligned boundaries caused CPU faults. I had to read all those unaligned words as two individual bytes, and then reconstruct the word value merging the two bytes. A simple word read should be much more elegant.
On Intel CPUs you won't have any problem. But if your format ever goes to ARM (cell phones, etc) developers writing a PAL64 handler will face these kind of problems:
https://developer.arm.com/documentation/ka003038/latest
So for portability and ease of implementation, I recommend you to place data fields on aligned boundaries relative to their natural data size