| ||||
|
|
|
|
|
This is the R.O.M.E.68000 Manual version 0.51.
This is an experimental version.
Copyright © 1997 by G. Mezzetti; last update: January 1, 1999.
|
| ||||
|
|
|
|
|
|
This is the R.O.M.E.68000 Manual version 0.51.
This is an experimental version.
Copyright © 1997 by G. Mezzetti; last update: January 1, 1999.
The memory array contains not only the code of programs but also, of course, their data. Number-type data must be put into locations of the core that are especially configured to be recognized by the virtual processor as data containers: these are called correct data items (abbreviated as c.d.i.'s). We shall now describe the format that locations reserved to contain number-type data must obey.
In traditional Core Wars, data need not be put in DAT locations: you can happily execute an instruction like
ADD #1,0
to increment the opcode of the instruction itself. Of course, this violates the distinction between number-type and word-type that is made in the 68000 architecture, so it is not allowed in our system. As already said, number-type data, which are 16 bits wide, must be enclosed in a 64-bits-wide ``package''; but how should the remaining 48 bits of the ``package'' be filled up? We cannot simply decide to ignore them, because this would be against elegance and the ``correct = perfect'' aphorism. A good solution seems to state that the datum must be lodged in the less significant 16 bits of a word, and that the other 48 must be set to zero; but this is not the best choice, because if the datum is also zero we get a word having all bits cleared, which cannot be distinguished from an empty one. Once again, the impossibility of this distinction offends the ``correct = perfect'' aphorism. For this reason it is settled that the number-type datum must be put in a specific field, called the value field, of a special structure that we are now going to define: as already said, this structure is called correct data item (c.d.i.), and comes in two varieties: it can be an alterable data item (a.d.i.) or a static data item (s.d.i.).
The format of an alterable data item is shown in fig. 6. As you can see, it is a word in which the 16 less significant bits constitute the value field, that can hence hold a number-type datum, and the other 48 are filled up with a bit pattern (described in hexadecimal digits by the string 000D00000000) that configures the word as an a.d.i.; the presence in this pattern of some bits set to 1 assures that a location containing an alterable data item cannot be confused with a blank location (i.e., an unused one), in which all the 64 bits are cleared to 0.
|
|
The format of a static data item is shown in fig. 7. It is similar to the previous one, except that the bit pattern is slightly different (010D00000000xxxx instead of 000D00000000xxxx).
|
|
Static data items differ from alterable ones in that their value field cannot be changed: you can of course overwrite the whole location (considering its contents as word-type data), but you cannot alter the value field with an instruction that operates on number-type data. This distinction is important only in the context of the Core Cold War. As you can expect, a program will be killed if it tries to alter the single value field of a static data item (hence acting on it regarded as a number-type datum), while it can safely overwrite the whole location, as said. Note, finally, that some kinds of data (for instance, the contents of the registers, that can only be number-type data) must always be kept into alterable data items, even if you never change their value field. This particular cases are specifically annotated in the sequel.
The format of correct data items was chosen to simplify the task of writing the assembler. First of all, let us see how c.d.i.'s are specified in the source code. The following directive reserves within the object code a single location configured as an alterable data item, whose value field is initialised to value:
DATA value
It can also have a label, as in
joe DATA value
and in this case the label can be used to refer to the address of the location exactly in the same way as for any other instruction. In fact, the DATA directive can be regarded (also by the assembler) as a pseudo-instruction having only one operand addressed in direct mode: the instruction key for DATA is $00. The rules for instruction coding (in particular, those on unused operands) assure then that object code will have exactly the format required for an alterable data item. This principle is illustrated in fig. 8, where the general format of an instruction of the ``Control'' class is filled up with the particular values that come out of the source line previously displayed, if the DATA keyword is considered as an instruction rather than as a directive (you will find the key for direct addressing mode in Chapter II). If you adopt this solution, when you write the assembler you must assure that no other addressing mode besides the direct one can be used with the DATA pseudo-instruction.
|
|
Static data items are defined with a directive (or pseudo-instruction) like this:
myAddr STAT value
The value field of the s.d.i. is set to value (and won't change any more). A discussion similar to the previous one applies also to the STAT pseudo-instruction, whose instruction key is $01. Further discussion will follow in Chapter VIII.
Since now, we have seen how correct data items (alterable and static) can be defined in the source code. There is also an instruction that lets you create alterable data items at run-time; more precisely, you can specify the address and the length of a block of words that will be filled up with a.d.i.'s, all with a value field initialized to 0. A similar instruction for static data items is not provided: it would not have any utility at all, since the value field of an s.d.i. cannot be changed after its creation. Another instruction checks a block of words, specified by you in length and address, to see whether it is entirely made up of alterable data items (ignoring the contents of their value fields). This is useful, because it is not easy to verify the integrity of a block of alterable data items by comparing it with a previously made copy, since the values contained in the a.d.i.'s are continuously changing. Again, this is not a problem for static data items, so a similar instruction for them is not provided.
|
|
|
|
|
|
