这是keil的问题。在1995年8031阶段，keil的c51已经基本成熟并广泛使用。
8031的data空间只有128个，8032才有256个。
RAM和EPROM均需要外置。而8031仅仅的128个data空间还要留出堆栈的空间。
所以KEIL的编译策略是：
在larger模式下，把所有变量放在XDATA中，临时变量和中间变量也放到xdata中。
而data空间只使用8个工作寄存器，这样就造成编译效率低下。
要包容这样的历史包袱就只能这样了。
keil c51的优秀仅仅体现在small模式。还要嵌入汇编。。。
8031 的 data, 是 128 + 128部分SFR
8031 的 idata, 是data的 128/idata
8032 的 data, 是 128 + 128部分SFR
8032 的 idata, 是data的 128/idata + 再增加的高 128 / idata
===idata 是 51/52 的堆栈
现在 STC32的堆栈理论是 64K/edata
差别有这么大?还没有测试过. 这差距也太大了，感觉肯定哪里有点问题。 Snapdragon 发表于 2024-3-11 11:41
这差距也太大了，感觉肯定哪里有点问题。
STC32是强大的 CISC 架构，268条强大的指令，当然空间代码效率高，
复杂的大程序，空间代码效率高大约高 15%， 这是先进性的体现
这是 【STC32 / 268条 强大指令】 PK 【STC8, 111条 8位指令】的
必然胜利
Snapdragon 发表于 2024-3-11 11:41
这差距也太大了，感觉肯定哪里有点问题。
很正常，同样的dhrystone程序，STC32G的代码量还不到STC8的一半 zxcv1973 发表于 2024-3-11 14:05
很正常，同样的dhrystone程序，STC32G的代码量还不到STC8的一半
我去，真的差距这么大呀。还没写过太大的程序，没碰到过。 本来想省点电量,把STC32程序移植到STC8H,没想到几十K的代码怎么也压缩不下来,原来如此 社区闲人 发表于 2024-3-10 19:23
这说明KEILC51在LARGER模式下编译结果非常非常垃圾！！！！！！！！！！！！！！！！！！ ...
不要直接使用LARGE模式(此时变量默认定义在XDATA区,连局部变量也是,效率极低),要用小模式,,显示定义变量,大的不常用的变量定义在XDATA,251效率高是正常的,不然能叫251
页:
1
[2]