- 主题:原来risc-v支持大端结构
实在话,小端设计反人类!
gcc11支持
RISC-V
Support address sanitizer for RISC-V.
Support big-endian for RISC-V, thanks to Marcus Comstedt.
发自「今日水木 on PBCM10」
--
修改:txgx FROM 61.158.146.*
FROM 61.158.146.*
RISC-V的big-endian和bi-endian是非标准的。
【 在 txgx (纸上谈医) 的大作中提到: 】
: 实在话,小端设计反人类!
: gcc11支持
: RISC-V
: ...................
--
FROM 103.90.178.*
网络通讯Big Endian用得比较多吧
【 在 txgx (纸上谈医) 的大作中提到: 】
: 实在话,小端设计反人类!
: gcc11支持
: RISC-V
: ...................
--
FROM 24.56.40.30
明显大端反人类,
0X7B 0X00 0X00 0X00这个序列小端按int8 int16 int32理解都同一个数,这多好。
【 在 txgx 的大作中提到: 】
: 实在话,小端设计反人类!
:
: gcc11支持
: ...................
--
FROM 120.204.150.*
以前unix小型机都是大端,所以网络用大端。
【 在 chenpp 的大作中提到: 】
: 网络通讯Big Endian用得比较多吧
:
--
FROM 120.244.24.*
按这个逻辑,最好的方案是 byte 内部也反过来, LSB 在最前。
【 在 oncancel (千杯不醉) 的大作中提到: 】
: 明显大端反人类,
: 0X7B 0X00 0X00 0X00这个序列小端按int8 int16 int32理解都同一个数,这多好。
--
FROM 73.158.11.*
这是站在编译器角度思考而已。
大端模式明显参考人类阅读模式,最高位放在最前面。
【 在 oncancel 的大作中提到: 】
: 明显大端反人类,
: 0X7B 0X00 0X00 0X00这个序列小端按int8 int16 int32理解都同一个数,这多好。
:
: ...................
--来自微水木3.5.10
--
FROM 223.104.210.*
一看就是代码写得少
小端减少了各种长度的类型之间转换的开销
【 在 foliver 的大作中提到: 】
: 这是站在编译器角度思考而已。
: 大端模式明显参考人类阅读模式,最高位放在最前面。
:
--
FROM 124.64.17.*