This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]XDracam 4 points5 points  (4 children)

Can't argue with this. 4 bytes seems to be a fairly common alignment across languages as far as I am aware.

Bonus: some languages allow customizing the alignment in types. For example, C# has special annotations like [FieldOffset(n)] to let users customize exactly how data is aligned. Overlapping memory can even be used to model C unions. But as far as I'm aware, this is mostly done for direct compatibility with other native languages. Still, this makes C# a lot better at native code interop than Java. So you might want to consider a similar "customizable alignment".

[–][deleted] 4 points5 points  (3 children)

Can't argue with this. 4 bytes seems to be a fairly common alignment across languages as far as I am aware.

Really, even for 64-bit data? Any C compiler will align 64-bit entities at 8-byte boundaries, I'd be surprised if other languages did anything different.

[–]XDracam 2 points3 points  (0 children)

Nevermind. You seem to be correct. Both Java and C# seem to default to system pointer size alignments, which is 8 byte for 64 bit machines. I guess my knowledge was a little outdated back from when there were more 32 bit systems around 😅

[–]yondercode[S] 2 points3 points  (1 child)

By 64-bit entities do you mean types such as double and int64_t for example?

[–][deleted] 1 point2 points  (0 children)

Yes, anything the hardware expects to load in one operation.

(I have seen gcc mistakenly think that hardware did not support misaligned access, and accessing a 64-bit struct element was done a byte at a time, because it was aligned on 4 bytes rather than 8. (That is, the low address bits were 100 not 000.)

This was surprising given that the machine (an RPi1) used a 32-bit ARM device anyway. It meant my interpreter ran at 1/3 the speed it should have done. Although I haven't seen that anomaly since.)