Use the QVM build toolchain from ioq3

This commit is contained in:
Izuru Yakumo
2025-07-15 15:09:05 -03:00
parent 733fac10f2
commit e8a6db7830
32 changed files with 1982 additions and 1955 deletions

View File

@@ -41,7 +41,7 @@ and insisted that pointers fit in unsigned integers (see Sec. 5.1 of <cite>A Ret
C Compiler</cite>). These assumptions simplified the compiler, and were suitable for
32-bit architectures. But on 64-bit architectures, such as the DEC ALPHA, it's natural to
have four sizes of integers and perhaps three sizes of floats, and on 16-bit
architectures, 32-bit pointers don't fit in unsigned integers. Also, the 3.x constaints
architectures, 32-bit pointers don't fit in unsigned integers. Also, the 3.x constraints
limited the use of lcc's back ends for other languages, such as Java.</p>
<p>Version 4.x removes all of these restrictions: It supports any number of sizes for
@@ -99,7 +99,7 @@ the symbol's <code>type</code> field.</p>
<h2><a NAME="operators">5.5 Dag Operators</a></h2>
<p>The <code>op</code> field a of <code>node</code> structure holds a dag operator, which
<p>The <code>op</code> field of a <code>node</code> structure holds a dag operator, which
consists of a generic operator, a type suffix, and a size indicator. The type suffixes
are:</p>
@@ -516,14 +516,14 @@ e.g.,</p>
<p>The type suffix for a conversion operator denotes the type of the result and the size
indicator gives the size of the result. For example, <code>CVUI4</code> converts an
unsigned (<code>U</code>) to a 4-byte signed integer (<code>I4</code>). The <code>syms[0]</code>
field points to a symbol-table entry for a integer constant that gives the size of the
field points to a symbol-table entry for an integer constant that gives the size of the
source operand. For example, if <code>syms[0]</code> in a <code>CVUI4</code> points to a
symbol-table entry for 2, the conversion widens a 2-byte unsigned integer to a 4-byte
signed integer. Conversions that widen unsigned integers zero-extend; those that widen
signed integers sign-extend.</p>
<p>The front end composes conversions between types <em>T</em><sub>1</sub> and <em>T</em><sub>2</sub>
by widening <em>T</em><sub>1</sub> to it's &quot;supertype&quot;, if necessary, converting
by widening <em>T</em><sub>1</sub> to its &quot;supertype&quot;, if necessary, converting
that result to <em>T</em><sub>2</sub>'s supertype, then narrowing the result to <em>T</em><sub>2</sub>,
if necessary. The following table lists the supertypes; omitted entries are their own
supertypes.</p>