Changeset dcfcf368 for doc/theses/jiada_liang_MMath/background.tex

Timestamp:

Sep 14, 2024, 5:07:55 PM (5 weeks ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Children:

8c79dc3c

Parents:

3733643

Message:

final proofread of thesis

File:

• doc/theses/jiada_liang_MMath/background.tex (modified) (3 diffs)

doc/theses/jiada_liang_MMath/background.tex

@@ -15 +15 @@
 \item
 For @#define@, the programmer must explicitly manage the constant name and value.
-Furthermore, these C preprocessor macro names are outside the C type system and can unintentionally change semantics of a program.
+Furthermore, these C preprocessor macro names are outside the C type system and can unintentionally change program text.
 \item
 The same explicit management is true for the @const@ declaration, and the @const@ variable cannot appear in constant-expression locations, like @case@ labels, array dimensions,\footnote{
@@ -136 +136 @@
 A ``plain'' @int@ object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range @INT_MIN@ to @INT_MAX@ as defined in the header @<limits.h>@).~\cite[\S~6.2.5(5)]{C11}
 \end{quote}
-However, @int@ means 4 bytes on both 32/64-bit architectures, which does not seem like the ``natural'' size for a 64-bit architecture.
-% Whereas @long int@ means 4 bytes on a 32-bit and 8 bytes on 64-bit architectures, and @long long int@ means 8 bytes on both 32/64-bit architectures, where 64-bit operations are simulated on 32-bit architectures.
+\VRef[Table]{t:IntegerStorageSizes} shows integer storage sizes.
+On UNIX systems (LP64), @int@ means 4 bytes on both 32/64-bit architectures, which does not seem like the ``natural'' size for a 64-bit architecture.
+Whereas @long int@ means 4 bytes on a 32-bit and 8 bytes on 64-bit architectures, and @long long int@ means 8 bytes on both 32/64-bit architectures, where 64-bit operations are simulated on 32-bit architectures.
+On Windows systems (LLP64), @int@ and @long@ mean 4 bytes on both 32/64-bit architectures, which also does not seem like the ``natural'' size for a 64-bit architecture.
 \VRef[Figure]{f:gccEnumerationStorageSize} shows both @gcc@ and @clang@ partially ignore this specification and type the integral size of an enumerator based on its initialization.
 Hence, initialization in the range @INT_MIN@..@INT_MAX@ results in a 4-byte enumerator, and outside this range, the enumerator is 8 bytes.
 Note that @sizeof( typeof( IMin ) ) != sizeof( E )@, making the size of an enumerator different than its containing enumeration type, which seems inconsistent.
+
+\begin{table}
+\centering
+\caption{Integer Storage Sizes (bytes)}
+\label{t:IntegerStorageSizes}
+\begin{tabular}{@{}rcc@{}}
+Type                            & LP64  & LLP64 \\
+@char@                          & 1             & 1             \\
+@short@ @int@           & 2             & 2             \\
+@int@                           & 4             & 4             \\
+@long@ @int@            & 8             & 4             \\
+@long@ @long@ @int@     & 8             & 8             \\
+pointer                         & 8             & 8
+\end{tabular}
+\end{table}
 
 \begin{figure}
@@ -483 +500 @@
 More type assertions mean more constraints on argument types, making the function less generic.
 
-\CFA defines two special cost values: @zero@ and @infinite@.
-A conversion cost is @zero@ when the argument and parameter have an exact match, and a conversion cost is @infinite@ when there is no defined conversion between the two types.
+\CFA defines two special cost values: 0 and @infinite@.
+A conversion cost is 0 when the argument and parameter have an exact match, and a conversion cost is @infinite@ when there is no defined conversion between the two types.
 For example, the conversion cost from @int@ to a @struct S@ is @infinite@.