其实PC上的编译器（至少VC是）也可以通过选项指定默认的char
是signed还是unsigned，只不过未指定时默认为signed罢了。

【 在 feiy (null) 的大作中提到: 】
: 竟然被转到这个版面来，还被顶上了十大，那么：
: 1、先说一下，这个题目是智能硬件嵌入式固件背景，随便考一下相关经验的，请不要忘
: 记了这个前提。
: ...................
--
FROM 183.156.100.*

这个8位 16位 32位搬运指令混合只是实现过程中的优化带来的。所以他说的是memcpy的“最朴素”实现。
32位系统当然会尽可能发挥位宽优势，一般是用8位对齐，之后32位批量搬运，最后再8位解决剩下的。这个实现并不影响逻辑上的定义。

【 在 feiy 的大作中提到: 】
: 你可找台电脑或单片机板，自己分析对应的汇编看看。你可能看到8位 I6位 32位搬运指令混合都有。当然，若不支持8位，自然也不会有8位的。
: 单片机板上可尝试用这个函数读写flash或eeprom试试。说不清楚，自己试了就明白了。
: 若还想讨论，建议转去embedded版吧，那里更相关。否则，影响这里非底层开发的版友阅读。
: ...................
--
FROM 180.111.50.*

比较窄的领域里甚至可能没有太多动力像通用领域那样去
充分吸收编程语言理论和软工的一些实践去改进开发工具

【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 整个趋势的走向是上层工具会越来越多的摆平所有底层问题，需要精通底层的人会越来越少。
: 但，世界是复杂的，发展是曲折的。
: 做个比喻，我们现在用一个工具，是不会从挖矿这种细节开始的。
: ...................
--
FROM 183.156.100.*

嗯C里char就是1 byte，所以16位char就意味着所有叫"byte"的都是16位，至少按照C标准来说应该是。

【 在 lvsoft 的大作中提到: 】
: 这个8位 16位 32位搬运指令混合只是实现过程中的优化带来的。所以他说的是memcpy的“最朴素”实现。
: 32位系统当然会尽可能发挥位宽优势，一般是用8位对齐，之后32位批量搬运，最后再8位解决剩下的。这个实现并不影响逻辑上的定义。
:
--
FROM 114.86.93.*

主要是没想到现在在售的硬件也有。
不过好像也不错，比如你只有16位地址线但你就是需要寻址256K*8bit，那么一个简单的解决办法就是...

【 在 adoal 的大作中提到: 】
: 我只知道上古平台有char可能是6或者7 bit的，还真不知道有>8的
--
修改:ilovecpp FROM 114.86.93.*
FROM 114.86.93.*