水木社区手机版
- 主题:现在写程序是不是可以不再考虑大端计算机的存在了？
- 这么大的历史包袱是没可能甩掉的，或者说，这么基础又广泛使用的规范，早已深入到每台cpu和每根网络链路里。
按规范来，就肯定没问题；不按规范来，得自己保证没问题就行，use it at your own risk。
--
修改:z16166 FROM 61.48.128.*
FROM 61.48.128.* - 发不出，那就搞个图。
【 在 buildtolast 的大作中提到: 】
: 不是不可能，不然linus也不会倡议，比如ip header里面有一些冗余的bit，表面是大端还是小端什么的，然后就可以慢慢演进，直到淘汰老协议。
:
:
--
FROM 61.48.128.* - 网络通信时LE和BE转换有开销，但是这个开销跟其他环节的开销相比很小。
Linus在那个帖子里也说了，这个开销跟其他环节（比如内存子系统）的开销相比很小。
而且LE的risc-v可以通过Zbb扩展把这个转换操作用单条指令实现，提高效率。
如果没有Zbb扩展，LE的risc-v的这个转换可能要n条指令。
Linus反对的是把对BE的cpu的（实验性）支持搞到linux kernel的主线代码（稳定代码）里，
也就是不要拿稳定代码来做试验。
也反对risc-v的cpu支持BE模式，认为现今的任何cpu都不应该再设计为BE的。
也就是说，risc-v只要支持LE + Zbb扩展即可。
所以，引用Linus的东西，要先搞明白他在说什么
【 在 buildtolast 的大作中提到: 】
: 不是不可能，不然linus也不会倡议，比如ip header里面有一些冗余的bit，表面是大端还是小端什么的，然后就可以慢慢演进，直到淘汰老协议。
:
:
--
修改:z16166 FROM 61.48.128.*
FROM 61.48.128.* - 技术需要的是严谨
如果娱乐的话，别的版面和论坛、群，大把的呀
【 在 buildtolast 的大作中提到: 】
: 你有点过激了，我并不是要证明自己多牛，或者抬出权威来压制人。我只是隐约有这个印象，所以随口说一嘴。我自觉自己技术能力和职业生涯都比较一般，所以来论坛就是抱着学习和娱乐的态度，并没有想争论什么。争赢了又能怎么样，在生活中还不是继续板砖？
: 感觉你挺严谨认真，有时候别人随口说句话，你就要搜到出处。有时候生活中不必那么端着，时时用恶意去揣度别人。
:
--
FROM 61.48.128.* - 哈哈，那就一起灌灌水好了
【 在 buildtolast 的大作中提到: 】
: 不行，就不走
:
--
修改:z16166 FROM 61.48.128.*
FROM 61.48.128.* - 你说的是没出单个机器的边界的情况。
边界之内看硬件，边界之外看协议
一、数据没出单个系统的，用LE还是BE取决于cpu。
二、数据出了单个系统的，
1、如果是走网络，协议头（比如IP头）毫无疑问BE（网络序）；自己的应用层payload可以自行选LE或者BE，看哪个开销小。
2、如果是走file，用啥格式“后果自负”，取决于采用的文件格式。
【 在 kingkang 的大作中提到: 】
: 现在的编译器会自动识别大小端的，程序几乎不用特别处理
--
FROM 123.115.128.* - 应该没任何问题，只要你的app涉及到的cpu没BE的，或者BE的那些机器是弱势的。
【 在 hgoldfish 的大作中提到: 】
: 我打算未来出机器边界的时候也直接传小端。
: 除了旧的网络协议那一票，仍然得兼容，不然以后都直接用小端。不管大端了。
:
--
FROM 123.115.128.* - 所以可以结帖了
【 在 hgoldfish 的大作中提到: 】
: 就像我上面说的，现在哪来的 BE 机器啊。
: 如果有也都是非常古老的跑了几十年谁都不敢动的那种。
:
--
FROM 123.115.128.* - 这种选择不存在对错
也不会有啥普通应用对性能的要求会达到了要仔细抠“BE <-> LE”的地步。
所以最好的方式是看谁地位高、嗓门大，不行就找地位更高的人仲裁，或者锤子剪刀布解决
【 在 zylthinking2 的大作中提到: 】
: 我也是， 为此12年前还与一个同事吵了一架，丫非要脱裤子放屁， 关键是两端都是Intel 的cpu
:
--
修改:z16166 FROM 123.115.128.*
FROM 123.115.128.*