问题标签 [i386]

我想知道如何为 /bin 的程序支持 i386 和 ppc 架构。

例如我跑

我明白了

程序如何在源代码中支持 i386 和 ppc？

换句话说，如果您删除对 ppc 架构的支持，您可以删除哪些组件，例如 /bin/amber 中的哪些组件？

我正在尝试将以下内容从 AT&T 程序集转换为 Intel 程序集：

现在编译为：

但无论我尝试什么，我都无法在 Intel synax 中得到相同的结果，我尝试过：

所以我没有线索，什么是“pushl 2000”的等价物？

我正在寻找一种将局部变量分配给寄存器的方法。我知道有几种严肃的方法可以做到这一点（即Wikipedia 上提到的那些），但我坚持“溢出”是如何完成的。此外，相关文献相当吓人。我希望有一些更简单的东西可以满足我的优先事项：

1. 正确性——无论有多少局部变量，都会生成正确代码的算法。
2. 简单——我不需要阅读太多文献就能理解的东西。
3. 效率——它需要比目前的方法更好，即：

将操作转换x = y # z为：

由于我的目标是 Intel 386，一些相关的限制是：

• 二元运算有两个参数，其中一个是源和目标。一元运算采用单个参数。
• 操作只能访问一个内存位置；因此，二进制操作至少需要一个寄存器中的参数。
• 最多有六个寄存器可用：%eax %ebx %ecx %edx %esi %edi. （%ebp也可以作为最后的手段。）
• 有一些特殊情况，例如整数除法和返回寄存器，但我现在可以忽略它们。

编译器目前需要完成三个步骤：

• i386ification：所有操作都转换为一种形式a = a # b（或a = #a一元操作）。
• 活度分析：确定每次操作前后的活变量集。
• 寄存器分配：建立干扰图并着色。

And then the compiler throws its crayons in the air and doesn't know what to do next.

Example

Here's the rather pretty interference graph for the function, and the CFG with liveness information. The CFG image does require some vertical scrolling, unfortunately.

• Interference graph for a function on 14 variables
• Control-flow graph for a function, with liveness information

Seven colours were used. I would like to spill one of them (or the set of variables assigned that colour). The method of choosing which isn't too important. What gets tricky is how to deal with the spilt variables.

Let's say I spill "pink", which is the set of variables t, $t4, $t7. This means that those operations referring to one of these variables will access it from its position on the stack frame, rather than through a register. This should work for this example.

But what if the program was:

and both a and b had to be spilled? I can't emit an instruction addl b, a with two memory addresses. I would need another spare register to temporarily hold one of the operands, and that means spilling another colour. This suggests a general method of:

1. If all variables can be coloured with r colours, great!
2. Otherwise, spill some colours and their associated variables.
3. If an operation exists that accesses two spilled variables, spill another colour and use the spare register for temporary storage for all such operations.

At this point I would suspect that a lot more stuff is being spilled than necessary, and wonder if there is some smarter way to spill things, such as spilling part of a variable's lifetime, rather than the whole variable itself. Are there some simple(ish) techniques that I could use here? Again, I'm not aiming particularly high -- certainly not high enough to require reading anything too deep. ;-)

Specific problems

The main specific problem is: when a variable is spilled, how does this affect the instructions generated? Do all instructions using that variable need to access it directly in memory (from its stack position) ? How will this work if an operation uses two spilled variables? (The architecture does not permit instructions to access two distinct memory locations.)

Secondary problems are:

• How do I determine where to insert load/store instructions, for correctness (and less importantly, efficiency) ?
• Can I spill a variable for only that part of its lifetime when it is not in immediate use, and unspill it later? So that all instructions act on unspilled registers. A variable might live in different registers at different times.
• Can I be a little more efficient with special cases. For example, %eax is used for the return value, so it would be nice if the variable to be returned happened to be allocated to that register by the time the return was encountered. Similarly, some registers are "callee-save", so if fewer variables happened to be live at the time of a function call, having them allocated to non-callee-save registers would mean I can avoid storing those registers.
• Would SSA form help much (if at all) ? Being able to eliminate common subexpressions and evaluate constants might reduce(?) register pressure, but otherwise would it have any effect?

The aspects I'm not concerned about (right now) are:

• Stack allocation and optimisation: it's implemented naively already, and can be optimised using the interference graph if need be.
• Compile-time efficiency, just as long as it terminates. (NP-completeness does not imply a given algorithm should be avoided.)

Update

Sorry about the downtime -- I've been thinking about the answers given and trying to find an easy approach to take to start implementing some of the ideas. To be honest, I've been procrastinating... :-\

I found the very nice presentation (PPT, sadly):

http://www.cs.princeton.edu/courses/archive/spr05/cos320/notes/Register%20Allocation.ppt

Which answers the question about how to deal with specific operation needs (like using the same register for source and destination; or needing a certain register for some operations). What I'm not sure about is whether the Liveness-Colouring-Allocation cycle terminates.

I'll try to do some actual work soon and hopefully close the question.

在下载Fedora Linux时，他们提供了两个我不知道区别的下载选项：x86 和 i386。那么它们之间有什么区别呢？

我正在尝试使用非本机架构构建 C 库。我正在运行 OSX 10.6（即 x86_64），但我需要为 i386 编译的库。通常，您只需添加编译器标志：-arch i386。但是我正在使用 Autoconf，它会在配置文件中忽略它，如果我尝试运行它也会忽略它：./configure CC="gcc -arch i386"。

我知道它构建 x86_64 目标文件，因为我已经使用 otool 查看了标题。真正的问题是，当 autoconf 写出配置摘要时，它会在 cc 标志中列出 -arch i386。这里发生了什么？？

眼镜：

OSX 10.6.2

GCC 4.2.1

自动配置 2.64

制作 3.81

我目前正在将我们的代码从 alpha (Tru64) 移植到 C 中的 i386 处理器 (Linux)。在我考虑移植我们的异常处理例程之前，一切都进行得很顺利。目前，我们有一个父进程，它产生许多子进程，当这些子进程之一是致命的（未字段）时，我有例程来捕获该进程。

我目前正在努力寻找实现回溯例程的最佳方法，该例程可以列出错误日志中的函数地址，目前我的例程只打印导致异常的信号和异常限定符代码。

任何帮助都会得到很大的帮助，理想情况下我会为所有处理器编写错误处理，但是在这个阶段我只关心 i386 和 x86_64。

谢谢

标记

我今天尝试在我的 Xcode 项目中切换架构，因为我即将使用尚未移植到 64 位的低级 QuickTime 东西。当我之前在 x86_64 上编译时，我的应用程序运行得很好。然后我将拱门切换到 i386 并繁荣，我的应用程序在启动时不断崩溃。

奇怪的是，堆栈跟踪与我自己的代码无关。

有任何想法吗？

如 top 命令所见，在 Snow Leopard（64 位机器）中运行 32 位编译版 python 的单个进程是否可能消耗 > 4GB（例如 5.4GB）的虚拟内存？

我file ...python发现二进制文件不是 x86，但它似乎消耗了超过 5GB 的内存。

我的猜测是，使用的库（RPy）是“mmap”数据块，并且内存缓存出现在我的进程的内存占用下。

或者也许我还没有验证 Python 二进制文件是 32 位的。或者也许有一些 32 位/64 位混合（libffi？）。

完全糊涂了。

随着内存需求的快速增长，如今越来越多的系统需要 64 位机器来访问更大的 RAM。

FWIK 在 386 保护模式下，内存指针由两部分组成：由段选择器指定的基地址（32 位）和添加到基地址的偏移地址（32 位）。

要在 64 位中重新编译所有程序，有很多工作要做，例如对于 C/C++ 程序，依赖于机器的 `int' 类型（在 32 位机器中是 32 位，而在 64 位在 64 位机器中）如果使用不正确会导致问题。即使它正在毫无问题地重建，随着内存需求的不断增长，例如有一天我们将使用 128 位机器，我们是否需要再次重建所有程序以符合新的字长？

如果我们只是将基地址扩展为 64 位，从而在整个 RAM 上创建一个像 4GB 窗口一样的段，我们甚至根本不需要 64 位操作系统，不是吗？大多数应用程序/进程不必在服务器端访问 4G+ 内存，例如，如果文件服务器使用 20GB RAM 进行缓存，它可能会被拆分为 10 个进程，每个进程访问 2GB，因此 32 位指针是足够的。并将每个放在不同的段中以覆盖 20GB 内存。

扩展段限制对上层程序是透明的，要做的只是CPU和操作系统，如果我们能让Linux支持在不同的64位段上分配内存（虽然目前段基地址是32位然而），我们可以轻松地在 32 位机器上使用 1TB RAM，不是吗？

我对吗？

当我在 mac 上使用 qtcreator 时，它会创建通用二进制文件。

有谁知道如何设置它，所以它只是创建一个“本机”二进制文件？（所以在我的情况下是 i386'？）

Qtcreator 使用 qmake 作为构建系统。

到目前为止，谷歌还不是我的朋友，我希望 stackoverflow 会。

编辑：到目前为止我的配置文件：

它仍然在 libmongoclient.a 上给出错误
libboost 库一切正常，但这是因为我使用 +universal 选项从 macports 获取它们。

由于 mongoclient 不支持通用我目前正在删除所有通用的东西。我希望为 boost libs 得到 3 个错误，并且至少；east mongoclient 会链接。那时我可以再次重做整个 macport 的故事，但这次删除了通用。

不幸的是，它似乎仍然构建了一个通用二进制文件，因为我仍然有相同的链接器错误。

谢谢您的帮助