| |
|
|
|
Chapter One Constants, Variables, and Data Types
Volume One discussed the basic format for data in memory. Volume Two covered how a computer system physically organizes that data. This chapter finishes this discussion by connecting the concept of data representation to its actual physical representation. As the title implies, this chapter concerns itself with three main topics: constants, variables and data structures. This chapter does not assume that you've had a formal course in data structures, though such experience would be useful.
1.1 Chapter Overview
This chapter discusses how to declare and use constants, scalar variables, integers, reals, data types, pointers, arrays, and structures. You must master these subjects before going on to the next chapter. Declaring and accessing arrays, in particular, seems to present a multitude of problems to beginning assembly language programmers. However, the rest of this text depends on your understanding of these data structures and their memory representation. Do not try to skim over this material with the expectation that you will pick it up as you need it later. You will need it right away and trying to learn this material along with later material will only confuse you more.
1.2 Some Additional Instructions: INTMUL, BOUND, INTO
This chapter introduces arrays and other concepts that will require the expansion of your 80x86 instruction set knowledge. In particular, you will need to learn how to multiply two values; hence the first instruction we will look at is the intmul (integer multiply) instruction. Another common task when accessing arrays is to check to see if an array index is within bounds. The 80x86 bound instruction provides a convenient way to check a register's value to see if it is within some range. Finally, the into (interrupt on overflow) instruction provides a quick check for signed arithmetic overflow. Although into isn't really necessary for array (or other data type access), its function is very similar to bound, hence the presentation at this point.
The intmul instruction takes one of the following forms:
// The following compute destreg = destreg * constant intmul( constant, destreg16 ); intmul( constant, destreg32 ); // The following compute dest = src * constant intmul( constant, srcreg16, destreg16 ); intmul( constant, srcmem16, destreg16 ); intmul( constant, srcreg32, destreg32 ); intmul( constant, srcmem32, destreg32 ); // The following compute dest = dest * src intmul( srcreg16, destreg16 ); intmul( srcmem16, destreg16 ); intmul( srcreg32, destreg32 ); intmul( srcmem32, destreg32 );Note that the syntax of the intmul instruction is different than the add and sub instructions. In particular, note that the destination operand must be a register (add and sub both allow a memory operand as a destination). Also note that intmul allows three operands when the first operand is a constant. Another important difference is that the intmul instruction only allows 16-bit and 32-bit operands; it does not allow eight-bit operands.
intmul computes the product of its specified operands and stores the result into the destination register. If an overflow occurs (which is always a signed overflow, since intmul only multiplies signed integer values), then this instruction sets both the carry and overflow flags. intmul leaves the other condition code flags undefined (so, for example, you cannot check the sign flag or the zero flag after intmul and expect them to tell you anything about the intmul operation).
The bound instruction checks a 16-bit or 32-bit register to see if it is between one of two values. If the value is outside this range, the program raises an exception and aborts. This instruction is particularly useful for checking to see if an array index is within a given range. The bound instruction takes one of the following forms:
bound( reg16, LBconstant, UBconstant ); bound( reg32, LBconstant, UBconstant ); bound( reg16, Mem16[2] );1 bound( reg32, Mem32[2] );2The bound instruction compares its register operand against an unsigned lower bound value and an unsigned upper bound value to ensure that the register is in the range:
lower_bound <= register <= upper_boundThe form of the bound instruction with three operands compares the register against the second and third parameters (the lower bound and upper bound, respectively)3. The bound instruction with two operands checks the register against one of the following ranges:
Mem16[0] <= register16 <= Mem16[2] Mem32[0] <= register32 <= Mem32[4]If the specified register is not within the given range, then the 80x86 raises an exception. You can trap this exception using the HLA try..endtry exception handling statement. The excepts.hhf header file defines an exception, ex.BoundInstr, specifically for this purpose. The following code fragment demonstrates how to use the bound instruction to check some user input:
program BoundDemo; #include( "stdlib.hhf" ); static InputValue:int32; GoodInput:boolean; begin BoundDemo; // Repeat until the user enters a good value: repeat // Assume the user enters a bad value. mov( false, GoodInput ); // Catch bad numeric input via the try..endtry statement. try stdout.put( "Enter an integer between 1 and 10: " ); stdin.flushInput(); stdin.geti32(); mov( eax, InputValue ); // Use the BOUND instruction to verify that the // value is in the range 1..10. bound( eax, 1, 10 ); // If we get to this point, the value was in the // range 1..10, so set the boolean "GoodInput" // flag to true so we can exit the loop. mov( true, GoodInput ); // Handle inputs that are not legal integers. exception( ex.ConversionError ) stdout.put( "Illegal numeric format, reenter", nl ); // Handle integer inputs that don't fit into an int32. exception( ex.ValueOutOfRange ) stdout.put( "Value is *way* too big, reenter", nl ); // Handle values outside the range 1..10 (BOUND instruction) /* exception( ex.BoundInstr ) stdout.put ( "Value was ", InputValue, ", it must be between 1 and 10, reenter", nl ); */ endtry; until( GoodInput ); stdout.put( "The value you entered, ", InputValue, " is valid.", nl ); end BoundDemo; Program 1.1 Demonstration of the BOUND InstructionThe into instruction, like bound, also generates an exception under certain conditions. Specifically, into generates an exception if the overflow flag is set. Normally, you would use into immediately after a signed arithmetic operation (e.g., intmul) to see if an overflow occurs. If the overflow flag is not set, the system ignores the into instruction; however, if the overflow flag is set, then the into instruction raises the HLA ex.IntoInstr exception. The following code sample demonstrates the use of the into instruction:
program INTOdemo; #include( "stdlib.hhf" ); static LOperand:int8; ResultOp:int8; begin INTOdemo; // The following try..endtry checks for bad numeric // input and handles the integer overflow check: try // Get the first of two operands: stdout.put( "Enter a small integer value (-128..+127):" ); stdin.geti8(); mov( al, LOperand ); // Get the second operand: stdout.put( "Enter a second small integer value (-128..+127):" ); stdin.geti8(); // Produce their sum and check for overflow: add( LOperand, al ); into(); // Display the sum: stdout.put( "The eight-bit sum is ", (type int8 al), nl ); // Handle bad input here: exception( ex.ConversionError ) stdout.put( "You entered illegal characters in the number", nl ); // Handle values that don't fit in a byte here: exception( ex.ValueOutOfRange ) stdout.put( "The value must be in the range -128..+127", nl ); // Handle integer overflow here: /* exception( ex.IntoInstr ) stdout.put ( "The sum of the two values is outside the range -128..+127", nl ); */ endtry; end INTOdemo; Program 1.2 Demonstration of the INTO Instruction1.3 The QWORD and TBYTE Data Types
HLA lets you declare eight-byte and ten-byte variables using the qword, and tbyte data types, respectively. Since HLA does not allow the use of 64-bit or 80-bit non-floating point constants, you may not associate an initializer with these two data types. However, if you wish to reserve storage for a 64-bit or 80-bit variable, you may use these two data types to do so.
The qword type lets you declare quadword (eight byte) variables. Generally, qword variables will hold 64-bit integer or unsigned integer values, although HLA and the 80x86 certainly don't enforce this. The HLA Standard Library contains several routines to let you input and display 64-bit signed and unsigned integer values. The chapter on advanced arithmetic will discuss how to calculate 64-bit results on the 80x86 if you need integers of this size.
The tbyte directive allocates ten bytes of storage. There are two data types indigenous to the 80x87 (math coprocessor) family that use a ten byte data type: ten byte BCD values and extended precision (80 bit) floating point values. Since you would normally use the real80 data type for floating point values, about the only purpose of tbyte in HLA is to reserve storage for a 10-byte BCD value (or other data type that needs 80 bits). Once again, the chapter on advanced arithmetic may provide some insight into the use of this data type. However, except for very advanced applications, you could probably ignore this data type and not suffer.
1.4 HLA Constant and Value Declarations
HLA's CONST and VAL sections let you declare symbolic constants. The CONST section lets you declare identifiers whose value is constant throughout compilation and run-time; the VAL section lets you declare symbolic constants whose value can change at compile time, but whose values are constant at run-time (that is, the same name can have a different value at several points in the source code, but the value of a VAL symbol at a given point in the program cannot change while the program is running).
The CONST section appears in the same declaration section of your program that contains the STATIC, READONLY, STORAGE, and VAR, sections. It begins with the CONST reserved word and has a syntax that is nearly identical to the READONLY section, that is, the CONST section contains a list of identifiers followed by a type and a constant expression. The following example will give you an idea of what the CONST section looks like:
const pi: real32 := 3.14159; MaxIndex: uns32 := 15; Delimiter: char := `/'; BitMask: byte := $F0; DebugActive: boolean:= true;Once you declare these constants in this manner, you may use the symbolic identifiers anywhere the corresponding literal constant is legal. These constants are known as manifest constants. A manifest constant is a symbolic representation of a constant that allows you to substitute the literal value for the symbol anywhere in the program. Contrast this with READONLY variables; a READONLY variable is certainly a constant value since you cannot change such a variable at run time. However, there is a memory location associated with READONLY variables and the operating system, not the HLA compiler, enforces the read-only attribute at run-time. Although it will certainly crash your program when it runs, it is perfectly legal to write an instruction like "MOV( EAX, ReadOnlyVar );" On the other hand, it is no more legal to write "MOV( EAX, MaxIndex );" (using the declaration above) than it is to write "MOV( EAX, 15 );" In fact, both of these statements are equivalent since the compiler substitutes "15" for MaxIndex whenever it encounters this manifest constant.
If there is absolutely no ambiguity about a constant's type, then you may declare a constant by specifying only the name and the constant's value, omitting the type specification. In the example earlier, the pi, Delimiter, MaxIndex, and DebugActive constants could use the following declarations:
const pi := 3.14159; // Default type is real80. MaxIndex := 15; // Default type is uns32. Delimiter: := `/'; // Default type is char. DebugActive: := true; // Default type is boolean.Symbol constants that have an integer literal constant are always given the type uns32 if the constant is zero or positive, or int32 if the value is negative. This is why MaxIndex was okay in this CONST declaration but BitMask was not. Had we included the statement "BitMask := $F0;" in this latter CONST section, the declaration would have been legal but BitMask would be of type uns32 rather than byte.
Constant declarations are great for defining "magic" numbers that might possibly change during program modification. The following provides an example of using constants to parameterize "magic" values in the program.
program ConstDemo; #include( "stdlib.hhf" ); const MemToAllocate := 4_000_000; NumDWords := MemToAllocate div 4; MisalignBy := 62; MainRepetitions := 1000; DataRepetitions := 999_900; CacheLineSize := 16; begin ConstDemo; //console.cls(); stdout.put ( "Memory Alignment Exercise",nl, nl, "Using a watch (preferably a stopwatch), time the execution of", nl "the following code to determine how many seconds it takes to", nl "execute.", nl nl "Press Enter to begin timing the code:" ); // Allocate enough dynamic memory to ensure that it does not // all fit inside the cache. Note: the machine had better have // at least four megabytes free or virtual memory will kick in // and invalidate the timing. malloc( MemToAllocate ); // Zero out the memory (this loop really exists just to // ensure that all memory is mapped in by the OS). mov( NumDWords, ecx ); repeat dec( ecx ); mov( 0, (type dword [eax+ecx*4])); until( !ecx ); // Repeat until ECX = 0. // Okay, wait for the user to press the Enter key. stdin.readLn(); // Note: as processors get faster and faster, you may // want to increase the size of the following constant. // Execution time for this loop should be approximately // 10-30 seconds. mov( MainRepetitions, edx ); add( MisalignBy, eax ); // Force misalignment of data. repeat mov( DataRepetitions, ecx ); align( CacheLineSize ); repeat sub( 4, ecx ); mov( [eax+ecx*4], ebx ); mov( [eax+ecx*4], ebx ); mov( [eax+ecx*4], ebx ); mov( [eax+ecx*4], ebx ); until( !ecx ); dec( edx ); until( !edx ); // Repeat until EAX is zero. stdout.put( stdio.bell, "Stop timing and record time spent", nl, nl ); // Okay, time the aligned access. stdout.put ( "Press Enter again to begin timing access to aligned variable:" ); stdin.readLn(); // Note: if you change the constant above, be sure to change // this one, too! mov( MainRepetitions, edx ); sub( MisalignBy, eax ); // Realign the data. repeat mov( DataRepetitions, ecx ); align( CacheLineSize ); repeat sub( 4, ecx ); mov( [eax+ecx*4], ebx ); mov( [eax+ecx*4], ebx ); mov( [eax+ecx*4], ebx ); mov( [eax+ecx*4], ebx ); until( !ecx ); dec( edx ); until( !edx ); // Repeat until EAX is zero. stdout.put( stdio.bell, "Stop timing and record time spent", nl, nl ); free( eax ); end ConstDemo; Program 1.3 Data Alignment Program Rewritten Using CONST Definitions1.4.1 Constant Types
Manifest constants can be any of the HLA primitive types plus a few of the composite types this chapter discusses. Volumes One and Two discussed most of the primitive types; these primitive types include the following:
- Boolean constants (true or false)
- Uns8 constants (0..255)
- Uns16 constants (0..65535)
- Uns32 constants (0..4,294,967,295)
- Int8 constants (-128..+127)
- Int16 constants (-32768..+32767)
- Int32 constants (-2,147,483,648..+2,147,483,647)
- Char constants (any ASCII character with a character code in the range 0..255)
- Byte constants (any eight-bit value including integers, booleans, and characters)
- Word constants (any 16-bit value)
- DWord constants (any 32-bit value)
- Real32 constants (floating point values)
- Real64 constants (floating point values)
- Real80 constants (floating point values)
In addition to the constant types appearing above, the CONST section supports six additional constant types:
- String constants
- Text constants
- Enumerated constant values
- Array constants
- Record/Union constants
- Character set constants
These data types are the subject of this Volume and the discussion of most of them appears in later chapters. However, the string and text constants are sufficiently important to warrant an early discussion of these constant types.
1.4.2 String and Character Literal Constants
HLA, like most programming languages, draws a distinction between a sequence of characters, a string, and a single character. This distinction is present both in the type declarations and in the syntax for literal character and string constants. Until now, this text has not drawn a fine distinction between character and string literal constants; now it is time to do so.
String literal constants consist of a sequence of zero or more characters surrounded by the ASCII quote characters. The following are all examples of legal literal string constants:
"This is a string" // String with 16 characters. "" // Zero length string. "a" // String with a single character. "123" // String of length three.A string of length one is not the same thing as a character constant. HLA uses two completely different internal representations for character and string values. Hence, "a" is not a character value, it is a string value that just happens to contain a single character.
Character literal constants take a couple forms, but the most common consist of a single character surrounded by ASCII apostrophe characters:
`2' // Character constant equivalent to ASCII code $32. `a' // Character constant for lower case `A'.As noted above, "a" and `a' are not equivalent.
Those who are familiar with C/C++/Java probably recognize these literal constant forms, since they are similar to the character and string constants in C/C++/Java. In fact, this text has made a tacit assumption to this point that you are somewhat familiar with C/C++ insofar as examples appearing up to this point use character and string constants without an explicit definition of them4.
Another similarity between C/C++ strings and HLA's is the automatic concatenation of adjacent literal string constants within your program. For example, HLA concatenates the two string constants
"First part of string, " "second part of string"to form the single string constant
"First part of string, second part of string"Beyond these few similarities, however, HLA strings and C/C++ strings are different. For example, C/C++ strings let you specify special character values using the escape character sequence consisting of a backslash character followed by one or more special characters; HLA does not use this escape character mechanism. HLA does provide, however, several other ways to achieve this same goal.
Since HLA does not allow escape character sequences in literal string and character constants, the first question you might ask is "How does one embed quote characters in string constants and apostrophe characters in character constants?" To solve this problem, HLA uses the same technique as Pascal and many other languages: you insert two quotes in a string constant to represent a single quote or you place two apostrophes in a character constant to represent a single apostrophe character, e.g.,
"He wrote a ""Hello World"" program as an example."He wrote a "Hello World" program as an example. `'''The above is equivalent to a single apostrophe character.
HLA provides a couple of other features that eliminate the need for escape characters. In addition to concatenating two adjacent string constants to form a longer string constant, HLA will also concatenate any combination of adjacent character and string constants to form a single string constant:
`1' `2' `3' // Equivalent to "123" "He wrote a " `"' "Hello World" `"' " program as an example."Note that the two "He wrote..." strings in the above examples are identical to HLA.
HLA provides a second way to specify character constants that handles all the other C/C++ escape character sequences: the ASCII code literal character constant. This literal character constant form uses the syntax:
#integer_constantThis form creates a character constant whose value is the ASCII code specified by integer_constant. The numeric constant can be a decimal, hexadecimal, or binary value, e.g.,
#13 #$d #%1101 // All three are the same character, a // carriage return.Since you may concatenate character literals with strings, and the #constant form is a character literal, the following are all legal strings:
"Hello World" #13 #10 // #13 #10 is the Windows newline sequence // (carriage return followed by line feed). "Error: Bad Value" #7 // #7 is the bell character. "He wrote a " #$22 "Hello World" #$22 " program as an example."Since $22 is the ASCII code for the quote character, this last example is yet a third form of the "He wrote..." string literal.
1.4.3 String and Text Constants in the CONST Section
String and text constants in the CONST section use the following declaration syntax:
const AStringConst: string := "123"; ATextConst: text := "123";Other than the data type of these two constants, their declarations are identical. However, their behavior in an HLA program is quite different.
Whenever HLA encounters a symbolic string constant within your program, it substitutes the string literal constant in place of the string name. So a statement like "stdout.put( AStringConst );" prints the string "123" (without quotes, of course) to the display. No real surprise here.
Whenever HLA encounters a symbolic text constant within your program, it substitutes the text of that string (rather than the string literal constant) for the identifier. That is, HLA substitutes the characters between the delimiting quotes in place of the symbolic text constant. Therefore, the following statement is perfectly legal given the declarations above:
mov( ATextConst, al ); // equivalent to mov( 123, al );Note that substituting AStringConst for ATextConst in this example is illegal:
mov( AStringConst, al ); // equivalent to mov( "123", al );This latter example is illegal because you cannot move a string literal constant into the AL register.
Whenever HLA encounters a symbolic text constant in your program, it immediately substitutes the value of the text constant's string for that text constant and continues the compilation as though you had written the text constant's value rather than the symbolic identifier in your program. This can save some typing and help make your programs a little more readable if you often enter some sequence of text in your program. For example, consider the nl (newline) text constant declaration found in the HLA stdio.hhf library header file:
const nl: text := "#$d #$a"; // Windows version. Linux is just a line feed.Whenever HLA encounters the symbol nl, it immediately substitutes the value of the string "#$d #$a" for the nl identifier. When HLA sees the #$d (carriage return) character constant followed by the #$a (line feed) character constants, it concatenates the two to form the string containing the Windows newline sequence (a carriage return followed by a line feed). Consider the following two statements:
stdout.put( "Hello World", nl ); stdout.put( "Hello World" nl );(Notice that the second statement above does not separate the string literal and the nl symbol with a comma.) In the first example, HLA emits code that prints the string "Hello World" and then emits some additional code that prints a newline sequence. In the second example, HLA expands the nl symbol as follows:
stdout.put( "Hello World" #$d #$a );Now HLA sees a string literal constant ("Hello World") followed by two character constants. It concatenates the three of them together to form a single string and then prints this string with a single call. Therefore, leaving off the comma between the string literal and the nl symbol produces slightly more efficient code. Keep in mind that this only works with string literal constants. You cannot concatenate string variables, or a string variable with a string literal, by using this technique.
Linux users should note that the Linux end of line sequence is just a single linefeed character. Therefore, the declaration for nl is slightly different in Linux.
In the constant section, if you specify only a constant identifier and a string constant (i.e., you do not supply a type), HLA defaults to type string. If you want to declare a text constant you must explicitly supply the type.
const AStrConst := "String Constant"; ATextConst: text := "mov( 0, eax );";1.4.4 Constant Expressions
Thus far, this chapter has given the impression that a symbolic constant definition consists of an identifier, an optional type, and a literal constant. Actually, HLA constant declarations can be a lot more sophisticated than this because HLA allows the assignment of a constant expression, not just a literal constant, to a symbolic constant. The generic constant declaration takes one of the following two forms:
Identifier : typeName := constant_expression ; Identifier := constant_expression ;Constant expressions take the familiar form you're used to in high level languages like C/C++ and Pascal. They may contain literal constant values, previously declared symbolic constants, and various arithmetic operators. The following lists some of the operations possible in a constant expression:
Arithmetic Operators - (unary negation) Negates the expression immediately following the "-". * Multiplies the integer or real values around the asterisk. div Divides the left integer operand by the right integer operand producing an integer (truncated) result. mod Divides the left integer operand by the right integer operand producing an integer remainder. / Divides the left numeric operand by the second numeric operand producing a floating point result. + Adds the left and right numeric operands. - Subtracts the right numeric operand from the left numeric operand. Comparison Operators =, == Compares left operand with right operand. Returns TRUE if equal. <>, != Compares left operand with right operand. Returns TRUE if not equal. < Returns true if left operand is less than right operand. <= Returns true if left operand is <= right operand. > Returns true if left operand is greater than right operand. >= Returns true if left operand is >= right operand. Logical Operators5: & For boolean operands, returns the logical AND of the two operands. | For boolean operands, returns the logical OR of the two operands. ^ For boolean operands, returns the logical exclusive-OR. ! Returns the logical NOT of the single operand following "!". Bitwise Logical Operators: & For integer numeric operands, returns bitwise AND of the operands. | For integer numeric operands, returns bitwise OR of the operands. ^ For integer numeric operands, returns bitwise XOR of the operands. ! For an integer numeric operand, returns bitwise NOT of the operand. String Operators: `+' Returns the concatenation of the left and right string operands.The constant expression operators follow standard precedence rules; you may use the parentheses to override the precedence if necessary. See the HLA reference in the appendix for the exact precedence relationships between the operators. In general, if the precedence isn't obvious, use parentheses to exactly state the order of evaluation. HLA actually provides a few more operators than these, though the ones above are the ones you will most commonly use. Please see the HLA documentation for a complete list of constant expression operators.
If an identifier appears in a constant expression, that identifier must be a constant identifier that you have previously defined in your program. You may not use variable identifiers in a constant expression; their values are not defined at compile-time when HLA evaluates the constant expression. Also, don't confuse compile-time and run-time operations:
// Constant expression, computed while HLA is compiling your program: const x := 5; y := 6; Sum := x + y; // Run-time calculation, computed while your program is running, long after // HLA has compiled it: mov( x, al ); add( y, al );HLA directly interprets the value of a constant expression during compilation. It does not emit any machine instructions to compute "x+y" in the constant expression above. Instead, it directly computes the sum of these two constant values. From that point forward in the program, HLA associates the value 11 with the constant Sum just as if the program had contained the statement "Sum := 11;" rather than "Sum := x+y;" On the other hand, HLA does not precompute the value 11 in AL for the MOV and ADD instructions above6, it faithfully emits the object code for these two instructions and the 80x86 computes their sum when the program is run (sometime after the compilation is complete).
In general, constant expressions don't get very sophisticated. Usually, you're adding, subtracting, or multiplying two integer values. For example, the following CONST section defines a set of constants that have consecutive values:
const TapeDAT := 1; Tape8mm := TapeDAT + 1; TapeQIC80 := Tape8mm + 1; TapeTravan := TapeQIC80 + 1; TapeDLT := TapeTravan + 1;The constants above have the following values: TapeDAT = 1, Tape8mm = 2, TapeQIC80 = 3, TapeTravan = 4, and TapeDLT = 5.
1.4.5 Multiple CONST Sections and Their Order in an HLA Program
Although CONST sections must appear in the declaration section of an HLA program (e.g., between the "PROGRAM pgmname;" header and the corresponding "BEGIN pgmname;" statement), they do not have to appear before or after any other items in the declaration section. In fact, like the variable declaration sections, you can place multiple CONST sections in the declaration section. The only restriction on HLA constant declarations is that you must declare any constant symbol before you use it in your program.
Some C/C++ programmers, for example, are more comfortable writing their constant declarations as follows (since this is closer to C/C++'s syntax for declaring constants):
const TapeDAT := 1; const Tape8mm := TapeDAT + 1; const TapeQIC80 := Tape8mm + 1; const TapeTravan := TapeQIC80 + 1; const TapeDLT := TapeTravan + 1;The placement of the CONST section in a program seems to be a personal issue among programmers. Other than the requirements of defining all constants before you use them, you may feel free to insert the constant declaration section anywhere in the declaration section. Some programmers prefer to put all their CONST declarations at the beginning of their declaration section, some programmers prefer to spread them throughout declaration section, defining the constants just before they need them for some other purpose. Putting all your constants at the beginning of an HLA declaration section is probably the wisest choice right now. Later in this text you'll see reasons why you might want to define your constants later in a declaration section.
1.4.6 The HLA VAL Section
You cannot change the value of a constant you define in the CONST section. While this seems perfectly reasonable (constants after all, are supposed to be, well, constant), there are different ways we can define the term constant and CONST objects only follow the rules of one specific definition. HLA's VAL section lets you define constant objects that follow slightly different rules. This section will discuss the VAL section and the difference between VAL constants and CONST constants.
The concept of "const-ness" can exist at two different times: while HLA is compiling your program and later when your program executes (and HLA is no longer running). All reasonable definitions of a constant require that a value not change while the program is running. Whether or not the value of a "constant" can change during compilation is a separate issue. The difference between HLA CONST objects and HLA VAL objects is whether the value of the constant can change during compilation.
Once you define a constant in the CONST section, the value of that constant is immutable from that point forward both at run-time and while HLA is compiling your program. Therefore, an instruction like "mov( SymbolicCONST, EAX );" always moves the same value into EAX, regardless of where this instruction appears in the HLA main program. Once you define the symbol SymbolicCONST in the CONST section, this symbol has the same value from that point forward.
The HLA VAL section lets you declare symbolic constants, just like the CONST section. However, HLA VAL constants can change their value throughout the source code in your program. The following HLA declarations are perfectly legal:
val InitialValue := 0; const SomeVal := InitialValue + 1; // = 1 const AnotherVal := InitialValue + 2; // = 2 val InitialValue := 100; const ALargerVal := InitialValue; // = 100 const LargeValTwo := InitialValue*2; // = 200All of the symbols appearing in the CONST sections use the symbolic value InitialValue as part of the definition. Note, however, that InitialValue has different values at different points in this code sequence; at the beginning of the code sequence InitialValue has the value zero, while later it has the value 100.
Remember, at run-time a VAL object is not a variable; it is still a manifest constant and HLA will substitute the current value of a VAL identifier for that identifier7. Statements like "MOV( 25, InitialValue );" are no more legal than "MOV( 25, 0 );" or "MOV( 25, 100 );"
1.4.7 Modifying VAL Objects at Arbitrary Points in Your Programs
If you declare all your VAL objects in the declaration section, it would seem that you would not be able to change the value of a VAL object between the BEGIN and END statements of your program. After all, the VAL section must appear in the declaration section of the program and the declaration section ends before the BEGIN statement. Later, you will learn that most VAL object modifications occur between the BEGIN and END statements; hence, HLA must provide someway to change the value of a VAL object outside the declaration section. The mechanism to do this is the "?" operator.
Not only does HLA allow you to change the value of a VAL object outside the declaration section, it allows you to change the value of a VAL object almost anywhere in the program. Anywhere a space is allowed inside an HLA program, you can insert a statement of the form:
? ValIdentifier := constant_expression ;This means that you could write a short program like the following:
program VALdemo; #include( "stdlib.hhf" ); val NotSoConstant := 0; begin VALdemo; mov( NotSoConstant, eax ); stdout.put( "EAX = ", (type uns32 eax ), nl ); ?NotSoConstant := 10; mov( NotSoConstant, eax ); stdout.put( "EAX = ", (type uns32 eax ), nl ); ?NotSoConstant := 20; mov( NotSoConstant, eax ); stdout.put( "EAX = ", (type uns32 eax ), nl ); ?NotSoConstant := 30; mov( NotSoConstant, eax ); stdout.put( "EAX = ", (type uns32 eax ), nl ); end VALdemo; Program 1.4 Demonstration of VAL Redefinition Using "?" OperatorYou probably won't have much use for VAL objects at this time. However, later on you'll see (in the chapter on the HLA compile-time language) how useful VAL objects can be to you.
1The "[2]" suggests that this variable must be an array of two consecutive word values in memory.
2Likewise, this memory operand must be two consecutive dwords in memory.
3This form isn't a true 80x86 instruction. HLA converts this form of the bound instruction to the two operand form by creating two readonly memory variables initialized with the specified constant.
4Apologies are due to those of you who do not know C/C++/Java or a language that shares these string and constant definitions.
5Note to C/C++ and Java users. HLA's constant expressions use complete boolean evaluation rather than short-circuit boolean evaluation. Hence, HLA constant expressions do not behave identically to C/C++/Java expressions.
6Technically, if HLA had an optimizer it could replace these two instructions with a single "MOV( 11, al );" instruction. HLA v1.x, however, does not do this.
7In this context, current means the value last assigned to a VAL object looking backward in the source code.
|
| |
|
|
|