用于不同存储器寻址方案的C代码的可移植性

Question

如果我理解正确的话,DCPU-16规格为0x10c描述了一个16位的地址空间,每个偏移地址的16位字,而不是字节,与许多其他存储架构.这有一些奇怪的后果,例如我想象sizeof(char)并且sizeof(short)都会回归1.

在这种不同的内存寻址方案之间保持C代码可移植是否可行？要记住的问题是什么？

编辑:也许我应该给出一个更具体的例子.假设您有一些处理字节流的网络代码.你是通过在每个地址只放一个字节来丢弃你的一半内存,这样代码可以保持不变,或者你是否通过位移来推广所有内容以处理每个偏移的N个字节？

edit2:答案似乎集中在数据类型大小的问题上,这不是重点 - 我甚至不应该提到它.问题是如何应对失去用指针解决内存中任何字节的能力.期望代码对此不可知是否合理？

Answer 1

这完全可行.粗略地说,C的基本整数数据类型具有以下特征:

sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

以上并不完全符合规范,但它很接近.

正如awoodland在评论中指出的那样,你也期望DCPU-16的C编译器具有CHAR_BIT == 16.

不假设DCPU-16会有的奖金sizeof (char) == 2,这是一个常见的谬误.

Answer 2

当你说'失去解决一个字节的能力'时,我认为你的意思是'bit-octet',而不是'char'.便携式代码应该只假设CHAR_BIT >= 8.实际上,没有字节寻址的体系结构通常会定义CHAR_BIT == 8,并让编译器生成访问字节的指令.

我实际上不同意答案暗示:CHAR_BIT == 16作为一个不错的选择.我宁愿:CHAR_BIT == 8与sizeof(short) == 2.在这种情况下,编译器可以处理移位/屏蔽,就像许多RISC架构一样,用于字节访问.

我想Notch将进一步修改和澄清DCPU-16规范; 已经有对中断机制和进一步指令的请求.这是游戏的美学背景,所以我怀疑很快会有官方的ABI规范.也就是说,有人会在努力!

编辑:

考虑charC中的数组.编译器在每个本机16位wordDCPU存储器中打包2个字节.因此,如果我们访问第10个元素(索引9),则获取单词#[9/2] = 4,并提取字节#[9%2] = 1.

设'X'为数组的起始地址,'I'为索引:

SET J, I
SHR J, 1    ; J = I / 2
ADD J, X    ; J holds word address
SET A, [J]  ; A holds word
AND I, 0x1  ; I = I % 2 {0 or 1}
MUL I, 8    ; I = {0 or 8} ; could use: SHL I, 3
SHR A, I    ; right shift by I bits for hi or lo byte.

寄存器A保存'byte' - 它是一个16位寄存器,因此可以忽略上半部分.或者,上半部分可以归零:

AND A, 0xff ; mask lo byte.

这不是优化的,但它传达了这个想法.