Literal pool

From HandWiki
Revision as of 14:09, 6 February 2024 by Raymond Straus (talk | contribs) (over-write)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

In computer science, and specifically in compiler and assembler design, a literal pool is a lookup table used to hold literals during assembly and execution.

Multiple (local) literal pools are typically used only for computer architectures that lack branch instructions for long jumps, or have a set of instructions optimized for shorter jumps. Examples of such architectures include the IBM System/360 and its successors, which had a number of instructions which took 12-bit address offsets. In this case, the compiler would create a literal table on every 4K page; any branches whose target was less than 4K bytes away could be taken immediately; longer branches required an address lookup via the literal table. The entries in the literal pool are placed into the object relocation table during assembly, and are then resolved at link edit time.

The ARM architecture also makes use of multiple local pools,[1] as does AArch64, the 64-bit extension to the original ARM.[2]

Another architecture making use of multiple local pools is C-SKY, a 32-bit architecture designed for embedded SoCs.[3][4]

In certain ways, a literal pool resembles a TOC or a global offset table (GOT), except that the implementation is considerably simpler, and there may be multiple literal tables per object.

Perhaps the most common type of literal pool are the literal pools used by the LDR Rd,=const pseudo-instruction in ARM assembly language[5][6] and similar instructions in IBM System/360 assembly language,[7] which are compiled to a LOAD with a PC-relative addressing mode and the constant stored in the literal pool.

On the IBM S/390 and zSeries architecture, the GNU assembler, "as" (which is invoked during the gcc build process) will use general-purpose register R13 to store a pointer to the literal pool.[8][9]

Often some particular constant value will be used multiple times in a program. Many linkers, by default, store each unique constant once, in a single combined literal pool; that improves code size.[10]

The Java virtual machine has a "string literal pool" and a "class constant pool". [11]

References