我不适合在任何情况下编写操作系统，但这是假设性的。
我想用汇编语言从几乎绝对的零开始创建一个简单的操作系统。怀着远大的抱负，我希望它尽可能地优化执行。我还希望代码对于多种架构（尤其是 x86 和 x64 可互换）具有相当的可移植性。我觉得有点极简主义，所以让我们抛弃软件“膨胀”。
我正在寻找的是一个可以符合这个标准的汇编程序。显然，我想要一个正式或非正式记录得当的，并且我需要它是众所周知的（即我不希望在互联网撒哈拉沙漠中找到“ΣASM”。）
user1124893
问问题
471 次
2 回答
3
你是在极大地自相矛盾。优化 x86 上的执行是不可能的，每个系列都可以/确实以截然不同的速度执行相同的二进制文件，尤其是如果您要在 32 位和 64 位之间跳转。如果您的目标是 x86 上的速度，请不要用 asm 编写，请使用 C，然后让编译器针对它所在的平台进行优化。对于大型项目，您将无法与编译器竞争。对于简短的编译器生成的代码序列，是的，您有时可以更好/更快地手动组装一些东西。对于 x86，编译器在 x86 上的平均速度可能比您做得更好。膨胀不一定来自编译器或语言，而是来自所选语言的设计和实现。很容易将臃肿的 asm 变成臃肿的 C 或其他。
其次，如果您使用汇编语言编写。这段代码中有多少是指令，你希望有多少是汇编程序特定的指令和其他细微差别？您至少可以尝试使用这些汇编程序共享的最少数量的指令来编写适用于不同汇编程序的可移植 asm，其余的是指令。不幸的是，x86 在这里也有问题，首先是 intel vs at&t 语法问题，然后是字节 ptr 和近/远项目告诉汇编器特定指令的哪种风格甚至仅限于 intel 语法可能无法从一个移植x86 汇编器到另一个。你可以花 25 美元买一个树莓派，或者花 90 美元买一个 beaglebone。
x86 组装充其量是可怕的，几十年的创可贴在创可贴之上（从原来的创可贴开始）。如果您觉得需要做一个大小合适的汇编项目，（与 C 等更有用的东西相比）特别是如果您的目标是速度，那么选择更好的处理器和指令集。我不知道你的项目的大小。如果足够小，则为 thumb 或 thumb2 或 arm 或 avr 或 msp430，如果足够大，则为 arm 或 mips。可悲的是，对于大多数你可能会使用 gnu binutils 的人来说。对于 x86，如果您真的认为需要为此使用该指令集和该硬件，我同意 Jerry，请使用 nasm。
于 2012-07-01T06:09:43.093 回答
3
在您指定的情况下，NASM 可能是最佳选择。它有合理的记录，相当广泛的使用和大量的测试。它也是为数不多的可以直接生成原始二进制输出文件的文件之一，其中大多数文件都需要您通过链接器跳过箍来获得它。对于操作系统本身来说，这对于引导加载程序来说并不是一个问题，但是（无论出于何种原因）大多数在操作系统上工作的人自己也至少编写了一些玩具引导加载程序。
于 2012-07-01T05:45:04.420 回答