On Thursday 28 February 2008 12:17, Michael Schnell wrote: > > Enable_Mode : Enable_Set; // bit 14 .. 15/leftmost bits > > With an x86 the "leftmost bits" will be in the "rightmost" (second) > of the two bytes, > > with an 68K the "leftmost bits" will be in the "leftmost" (first) of > the two bytes,
Yes, bad example, because we already crossed the byte boundary. The real question about leftmost and rightmost was on which "data line" each bit would appear. (Usually it's called most significant bit, but as we're talking about hardware bits, not numbers, I wouldn't use that term. In this context, no bit is necessarily more significant than the other.) > So the two can't communicate this record via files or via network. > > If you want to have them understand each other, you need to define > the edianess of the record independently of that of the processor. Yes. That's what {$BIT_ORDER} would stand for (still, it would not change *byte* order). > Enumerated types don't help here. They weren't meant to solve the issue, they were meant to help to understand the issue I was trying to point out. The question was, how to interpret the enumeration values, if their bit order could/would differ from that of the record they're in. Should they be put in as is or swapped accordingly? Vinzent. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel