水木社区手机版
首页
|版面-编程技术(Programming)|
新版wap站已上线
返回
1/1
|
转到
主题:现在写程序是不是可以不再考虑大端计算机的存在了?
5楼
|
z16166
|
2025-12-03 17:38:55
|
展开
这么大的历史包袱是没可能甩掉的,或者说,这么基础又广泛使用的规范,早已深入到每台cpu和每根网络链路里。
按规范来,就肯定没问题;不按规范来,得自己保证没问题就行,use it at your own risk。
--
修改:z16166 FROM 61.48.128.*
FROM 61.48.128.*
16楼
|
z16166
|
2025-12-05 09:51:38
|
展开
发不出,那就搞个图。
【 在 buildtolast 的大作中提到: 】
: 不是不可能,不然linus也不会倡议,比如ip header里面有一些冗余的bit,表面是大端还是小端什么的,然后就可以慢慢演进,直到淘汰老协议。
:
:
--
FROM 61.48.128.*
17楼
|
z16166
|
2025-12-05 10:29:37
|
展开
网络通信时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.*
19楼
|
z16166
|
2025-12-05 12:25:34
|
展开
技术需要的是严谨
如果娱乐的话,别的版面和论坛、群,大把的呀
【 在 buildtolast 的大作中提到: 】
: 你有点过激了,我并不是要证明自己多牛,或者抬出权威来压制人。我只是隐约有这个印象,所以随口说一嘴。我自觉自己技术能力和职业生涯都比较一般,所以来论坛就是抱着学习和娱乐的态度,并没有想争论什么。争赢了又能怎么样,在生活中还不是继续板砖?
: 感觉你挺严谨认真,有时候别人随口说句话,你就要搜到出处。有时候生活中不必那么端着,时时用恶意去揣度别人。
:
--
FROM 61.48.128.*
21楼
|
z16166
|
2025-12-05 12:28:04
|
展开
哈哈,那就一起灌灌水好了
【 在 buildtolast 的大作中提到: 】
: 不行,就不走
:
--
修改:z16166 FROM 61.48.128.*
FROM 61.48.128.*
29楼
|
z16166
|
2026-02-24 22:29:51
|
展开
你说的是没出单个机器的边界的情况。
边界之内看硬件,边界之外看协议
一、数据没出单个系统的,用LE还是BE取决于cpu。
二、数据出了单个系统的,
1、如果是走网络,协议头(比如IP头)毫无疑问BE(网络序);自己的应用层payload可以自行选LE或者BE,看哪个开销小。
2、如果是走file,用啥格式“后果自负”,取决于采用的文件格式。
【 在 kingkang 的大作中提到: 】
: 现在的编译器会自动识别大小端的,程序几乎不用特别处理
--
FROM 123.115.128.*
32楼
|
z16166
|
2026-02-24 22:34:18
|
展开
应该没任何问题,只要你的app涉及到的cpu没BE的,或者BE的那些机器是弱势的。
【 在 hgoldfish 的大作中提到: 】
: 我打算未来出机器边界的时候也直接传小端。
: 除了旧的网络协议那一票,仍然得兼容,不然以后都直接用小端。不管大端了。
:
--
FROM 123.115.128.*
35楼
|
z16166
|
2026-02-25 13:32:52
|
展开
所以可以结帖了
【 在 hgoldfish 的大作中提到: 】
: 就像我上面说的,现在哪来的 BE 机器啊。
: 如果有也都是非常古老的跑了几十年谁都不敢动的那种。
:
--
FROM 123.115.128.*
1/1
|
转到
选择讨论区
首页
|
分区
|
热推
BYR-Team
©
2010.
KBS Dev-Team
©
2011
登录完整版