技术说明 1
5 分钟阅读
Technical Note 1 技术说明 1
Last update: Sun Feb 11 18:45:01 EDT 2001 by lhf.
Minimal Lua 3.2 installations 极简 Lua 3.2 安装
This note explains how to build Lua for environments that do not have much memory.
本说明解释了如何在内存不足的环境中构建 Lua。
As explicitly stated in the welcome page, one of the goals of our Lua implementation is low embedding cost. This means two things: first, it should be easy to embed Lua in an application; second, the additional code for Lua should not be too large.
正如欢迎页面中明确指出的，我们 Lua 实现的目标之一是降低嵌入成本。这意味着两件事：首先，Lua 应该很容易嵌入到应用程序中；其次，Lua 的附加代码不应该太大。
The first requirement is fulfilled by the simplicity of Lua’s C API. The second requirement is fulfilled by demonstration, as follows.
第一个要求由 Lua 的 C API 的简单性来满足。第二个要求由演示来满足，如下所示。
Here are a few numbers for Lua 3.2, compiled in an Intel machine running Linux (the numbers for other platforms will be different, but probably roughly the same in relative terms):
以下是一些在运行 Linux 的 Intel 机器上编译的 Lua 3.2 的数字（其他平台的数字会有所不同，但相对而言可能大致相同）：
% size liblua.a liblualib.a
text data bss dec hex filename
4483 121 0 4604 11fc lapi.o (ex liblua.a)
1037 0 0 1037 40d lauxlib.o (ex liblua.a)
345 0 0 345 159 lbuffer.o (ex liblua.a)
5193 272 0 5465 1559 lbuiltin.o (ex liblua.a)
3183 0 0 3183 c6f ldo.o (ex liblua.a)
381 0 0 381 17d lfunc.o (ex liblua.a)
1363 0 0 1363 553 lgc.o (ex liblua.a)
5429 108 0 5537 15a1 llex.o (ex liblua.a)
222 0 0 222 de lmem.o (ex liblua.a)
686 156 0 842 34a lobject.o (ex liblua.a)
8560 244 0 8804 2264 lparser.o (ex liblua.a)
446 4 0 450 1c2 lstate.o (ex liblua.a)
1845 36 0 1881 759 lstring.o (ex liblua.a)
1109 0 0 1109 455 ltable.o (ex liblua.a)
1293 202 0 1495 5d7 ltm.o (ex liblua.a)
2035 0 0 2035 7f3 lundump.o (ex liblua.a)
4864 8 0 4872 1308 lvm.o (ex liblua.a)
336 0 0 336 150 lzio.o (ex liblua.a)
25 0 0 25 19 linit.o (ex liblualib.a)
1489 56 0 1545 609 ldblib.o (ex liblualib.a)
4236 264 0 4500 1194 liolib.o (ex liblualib.a)
1651 184 0 1835 72b lmathlib.o (ex liblualib.a)
5277 88 0 5365 14f5 lstrlib.o (ex liblualib.a)
In this listing, text actually is the size of the code in bytes. We conclude that the Lua core (liblua.a) takes 42810 bytes and that the Lua standard libraries (liblualib.a) take 12678 bytes. So, the whole Lua code takes 55488 bytes, or less than 54K. In other words, the impact of Lua in an application is 54K of additional code, which is quite small. (Of course, Lua will use memory at run-time – but how much depends on the application.)
在此列表中， text 实际上是代码的字节大小。我们得出结论，Lua 核心（ liblua.a ）占用 42810 字节，Lua 标准库（ liblualib.a ）占用 12678 字节。因此，整个 Lua 代码占用 55488 字节，或不到 54K。换句话说，Lua 在应用程序中的影响是 54K 的附加代码，这非常小。（当然，Lua 在运行时会使用内存——但具体使用多少取决于应用程序。）
54K seem very little in these days that machines have many megabytes of main memory, but they might make a difference for someone trying to use Lua in a microwave oven or in a robot. So, let’s see how to reduce these 54K to even less. (Even if you’re not using Lua in embedded systems, you might learn something from the description below.)
如今，机器拥有许多兆字节的主内存，54K 似乎非常少，但对于尝试在微波炉或机器人中使用 Lua 的人来说，它们可能会有所不同。因此，让我们看看如何将这 54K 减少到更少。（即使您不在嵌入式系统中使用 Lua，您也可能会从以下描述中学到一些东西。）
The first thing is to remove any standard libraries that are not needed. For instance, ldblib.o will probably not be needed in most applications. But removing standard libraries will not get you very far, because they are small already. So, let’s look at the numbers for the core again, but now sorted by size:
首先要删除任何不需要的标准库。例如， ldblib.o 可能在大多数应用程序中都不需要。但删除标准库并不能让您走得太远，因为它们已经很小了。因此，让我们再次查看内核的数字，但现在按大小排序：
text %core %whole filename
222 1% 0% lmem.o
336 1% 1% lzio.o
345 1% 1% lbuffer.o
381 1% 1% lfunc.o
446 1% 1% lstate.o
686 2% 1% lobject.o
1037 2% 2% lauxlib.o
1109 3% 2% ltable.o
1293 3% 2% ltm.o
1363 3% 2% lgc.o
1845 4% 3% lstring.o
2035 5% 4% lundump.o
3183 7% 6% ldo.o
4483 10% 8% lapi.o
4864 11% 9% lvm.o
5193 12% 9% lbuiltin.o
5429 13% 10% llex.o
8560 20% 15% lparser.o
This listing tells us that the lexer (llex.o) and the parser (lparser.o) represent 33% of the core (and 25% of the whole). So, they are the main candidates for removal. An application that does not need to compile Lua code at run-time does not need the lexer and the parser.
此列表告诉我们词法分析器 ( llex.o ) 和解析器 ( lparser.o ) 占核心部分的 33%（占整体的 25%）。因此，它们是移除的主要候选对象。不需要在运行时编译 Lua 代码的应用程序不需要词法分析器和解析器。
We have designed the code so that it is easy to remove these two modules. Only one module (ldo.o) calls the parser, which has only one public function (luaY_parser). The only module that calls the lexer is the parser, except for an initialization function (luaX_init) used in lua_open. So, to remove the lexer and the parser, you only need to add the code below to your application (you can extract it from lua/src/luac/stubs.c, where it is disabled by default):
我们设计了代码，以便轻松移除这两个模块。只有一个模块 ( ldo.o ) 调用解析器，该解析器只有一个公共函数 ( luaY_parser )。除了在 lua_open 中使用的初始化函数 ( luaX_init ) 外，调用词法分析器的唯一模块是解析器。因此，要移除词法分析器和解析器，您只需将以下代码添加到您的应用程序中（您可以从 lua/src/luac/stubs.c 中提取它，默认情况下它被禁用）：
#include "llex.h"
#include "lparser.h"void luaX_init(void){}TProtoFunc* luaY_parser(ZIO *z) {
lua_error("parser not loaded");
return NULL;
}
An application that contains this code will not link llex.o or lparser.o, and trying to load Lua source code will generate an error. But then, you ask, how does the application load Lua code at all? The answer is: by loading precompiled chunks instead of source code. Precompiled chunks are created with luac, which will contain the lexer and the parser, but which is an external application. The module that loads precompiled chunks is lundump.o, which is small enough.
包含此代码的应用程序将不会链接 llex.o 或 lparser.o ，并且尝试加载 Lua 源代码将生成错误。但是，您可能会问，应用程序如何加载 Lua 代码？答案是：通过加载预编译块而不是源代码。预编译块使用 luac 创建，其中将包含词法分析器和解析器，但它是一个外部应用程序。加载预编译块的模块是 lundump.o ，它足够小。
Although lua_dofile and dofile automatically detect precompiled chunks, one convenient way is to use lua_dobuffer with precompiled chunks statically linked to your application (you will find lua/etc/bin2c.c useful for this), because embedded systems don’t even have filesystems. (This is a fast solution, but it will increase the size of your application and it may be too inflexible for you.)
虽然 lua_dofile 和 dofile 会自动检测预编译块，但一种方便的方法是将 lua_dobuffer 与静态链接到应用程序的预编译块一起使用（您会发现 lua/etc/bin2c.c 对此很有用），因为嵌入式系统甚至没有文件系统。（这是一个快速的解决方案，但它会增加应用程序的大小，并且可能对您来说过于不灵活。）
Removing the lexer and the parser leaves us with a core of just 28821 bytes, a little more than 28K. This is tiny indeed for a powerful language like Lua! Note also that this reduction was done without touching the source code; we just need a little help from the linker.
去掉词法分析器和解析器后，我们只剩下一个 28821 字节的核心，略多于 28K。对于像 Lua 这样强大的语言来说，这确实很小！还要注意，这种缩减是在不触碰源代码的情况下完成的；我们只需要链接器提供一点帮助。
The other candidate for removal is lbuiltin.o, which contains the built-in functions. Like the standard libraries, an application that needs a slim Lua should consider which built-in functions it really needs. It is easy to go through lbuiltin.c and remove the functions that are not needed. They are divided into blocks, marked with matching {...} inside comments, and so are easily identified. If no built-in functions are required, then the easiest way is to add
另一个可以去掉的候选是 lbuiltin.o ，其中包含内置函数。与标准库一样，需要精简 Lua 的应用程序应考虑它真正需要的内置函数。很容易遍历 lbuiltin.c 并去掉不需要的函数。它们被分成几个块，在注释中用匹配的 {...} 标记，因此很容易识别。如果不需要任何内置函数，那么最简单的方法是添加
#include "lbuiltin.h"
void luaB_predefine(void){}
to the stub code above and rely on the linker not to load lbuiltin.o.
到上面的存根代码并依靠链接器不加载 lbuiltin.o 。
This note has focused on reducing the amount of code added to the application by the Lua library. Applications that need this will probably also prefer to use integers instead of floating-point numbers for the numbers in Lua. (Does a microwave oven need floating-point?) This should be simple to do, as described in lua/config, but the details will probably be discussed in another LTN.
本文重点介绍了通过 Lua 库减少添加到应用程序中的代码量。需要此功能的应用程序可能还更喜欢对 Lua 中的数字使用整型而不是浮点型数字。（微波炉需要浮点型吗？）这应该很容易做到，如 lua/config 中所述，但详细信息可能会在另一篇 LTN 中讨论。