Éric Vyncke wrote:
> 2) I find puzzling the absence of betoh16() in the presence of htobe16()
> functions.
Since the implementation is identical, I believe it wouldn't make sense to
use up another instruction with the same implementation.
Table 6 in section 4.2 uses the direction-agnostic description for TO_BE of
"convert between host byte order and big endian" which I think is good.
But then it says:
> {END, TO_BE, ALU} with 'imm' = 16/32/64 means:
>
> dst = htobe16(dst)
> dst = htobe32(dst)
> dst = htobe64(dst)
Where section 2.2 confusingly defines it as direction-specific as you noted:
> htobe16: Takes an unsigned 16-bit number in host-endian format and
> returns the equivalent number as an unsigned 16-bit number in big-endian format.
Whereas bswap16 is direction agnostic:
> bswap16: Takes an unsigned 16-bit number in either big- or little-endian format
> and returns the equivalent number with the same bit width but opposite endianness.
I think the right way to address your comment is to change 2.2 and perhaps
the function name to be direction agnostic and match the description in table 6.
For example:
* bebswap16: Takes an unsigned 16-bit number and converts it between host byte
order and big endian. That is, on a big-endian platform the value is left unchanged
and on a little-endian platform the behavior is the same as bswap16.
Dave
