我正在做一些关于 8086 实模式的工作。我习惯于在汇编中这样做,但想尝试一下 C 编译器。在我看来,编译器假定所有段寄存器都具有相同的值。我的情况并非如此; SS为0x4C0,而DS = ES = CS = 0x800。
所以下面的编译时,生成的代码没有考虑 SS <> DS 的事实。
[来源:here ]
uint8 ch;
void main()
{
uint8 hexchars[] = {'0','1','2','3','4','5','6','7','8','9','A','B',
'C','D','E','F'};
uint8 i = 0;
ch = hexchars[i];
}
编译后,作业生成:[完整来源:here ]
// ch = hexchars[i];
00000156 8A46FF mov al,[bp-0x1] ; 'i' is at [BP - 0x1]
00000159 30E4 xor ah,ah
0000015B 89C7 mov di,ax
0000015D 89EE mov si,bp
0000015F 89FB mov bx,di
00000161 8A40EF mov al,[bx+si-0x11 ; 'hexchars[0] is at [BP - 0x11]
00000164 A28401 mov [0x184],al ; 'ch' is at location 0x184
因为没有明确提到SS,所以DS会被汇编器假定。
如上文所述,在我的案例中 SS <> DS,因此 AL 现在具有来自错误地址的值。
MOV AL, DS:[BX + SI - 0x11] <> MOV AL, SS:[BX + SI - 0x11]
我试过的编译器:
<强>1。 GCC 版本 6.2.0(Sourcery CodeBench Lite 2016.11-64)
ia16-elf-gcc -Wall main.c -o main.com -T main.ld
链接器文件如下:
OUTPUT_FORMAT(binary)
SECTIONS
{
. = 0x0;
.text :
{
*(.text);
}
.data :
{
*(.data);
*(.bss);
*(.rodata);
}
_heap = ALIGN(4);
/DISCARD/ :
{
*(.eh_frame)
}
}
<强>2。 Bruce 的 C 编译器 [与 BCC 一起使用的完整源代码 here ]
bcc -ansi -0 -W -c main.c -o main.o
ld86 -d main.o -o main.com -T000
更新: 试过 SmallerC.这里编译器再次假设 SS = DS。
<强>3。较小的 C [来源 here ]
smlrc -seg16 -Wall main.c main.s
nasm -f bin main.s -o main.com
两个编译器的结果大致相同。 从堆栈读取时没有编译器明确指定 SS。问题是有办法将约束通知编译器,我是不是做错了什么。
最佳答案
您是否尝试过 watcom 或 borland 编译器? Watcom 把它扔过栅栏/很久以前就开源了他们的套件。他们有 16 位多模型编译器。我不知道borlands的状态;但是如果你能找到一个图像,你在 qemu 下运行它的速度可能比它在真实机器上运行的速度更快。
它们支持多种内存模型;您可能想要的是紧凑型:16 位代码指针,32 位数据指针。这里有一个引用:What the... .
即使你完成了这些,取决于你尝试做什么,你可能会得到这些奇怪的东西,称为段修复,它允许在 1mb 地址空间内有限地重定位程序。这些很快就会变老。
为了让生活更轻松,您可以使用微型模型(生成真实图像);并使所有外部数据都由显式远指针引用。这是一个奇怪的 hack,你最终可能会得到:
const char far const * const far *p;
不是开玩笑。 80 年代和 90 年代见证了 C 和 C++ 之间的赛马,以创建对程序员最敌对的语法。显然 C++ 赢了,但 ISO-C 委员会拒绝认输,每隔几年就会让世界变得更加疯狂。
一点建议:将机器切换到 32 位模式,并使用一些明智的工具。
关于gcc - C 交叉编译器中的分段内存模型,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57242511/