Version 3.2 Annotated Draft Last Modified: February 2, 1994 Last modified by: Stefan Strack Base draft by: Mark Durham HTML document version: 1.0 HTML Draft Last Modified: February 2, 1995 HTML by: Stephen Beitzel
Internal annotations were removed to clean-up the draft for presentation to the ICWS for comment. These annotations which precede the draft take their place.
Open-ended references were removed to clean-up the draft for presentation to the ICWS for comment. The question of the inclusion or exclusion of various opcodes, modes, etc. has not been closed as of yet. Such additions or deletions should be finalized by the next draft however.
Previously speculative references were either included or removed to clean-up the draft for presentation to the ICWS for comment. See above.
The Load File section was rewritten to aid in the readability of load files. It was deemed best that Load Files be a subset of Assembly Files; therefore Load Files should logically follow the Assembly File section. For that reason, the two sections have been swapped.
Example MARS code is now included. Other parts of the standard, such as validation, remain incomplete. The remaining incomplete sections do not impact on the other sections of the standard and so can be completed even after consideration of the rest of the draft by the ICWS. Alternatively, they could be issued as separate documents.
The MARS code is specifically designed to mirror the draft as closely as possible. There is a multitude of optimizations which could have been made but were not in order that the example code could serve as a possible clarification of obscure parts of the draft. Do not suggest changes to the example code which speed up processing at the expense of mirroring the draft.
Several changes have been made with the goal of expanding the flexibility of Core War without compromising backwards compatibility and without seriously altering the nature of the game. In that vein:
The modulus '%' operator was added to the Assembly File section.
Read and Write limitations with folding have been clarified. These limits allow the possibility of warriors essentially running in a mini-core inside core, folding out-of-bounds access attempts back into accessible memory. The main advantages to folding are: old-style bombers like Dwarf do not unfairly and unknowingly spend cycles doing nothing, and movement to seek and destroy enemy warriors is still encouraged by the limits. The main disadvantage is that limits which are not factors of the size of core lead to unexpected results. Example: a reference to address location -1 is adjusted to M-1 when loaded into core and will not fold to R-1 and/or W-1 if R or W are not factors of M (M is size of core, R is the read limit, and W is the write limit). Of course, if R = W = M, then play is equivalent to ICWS'88 without limits.
In the 5.MARS section of the draft, many of the terms such as A-operand were used both as containers ("Writes to the A-operand") and the contents of those containers ("Compare the A-operand to ..."). Such ambiguous terms and references have hopefully been eradicated.
Although such eradication eliminates ambiguity, it encourages obfuscation and/or the proliferation of terms. A delicate balance has, perhaps, been struck between the two.
The following are terms which are new or may be used differently than in the past. All terms are contents (not containers).
Six opcode modifiers have been added to the Draft. Modifiers are appended to the opcodes with a dot. Example: "MOV.A". The modifiers are:
There could be modifiers (other than .I) which take the modes into account, but their utility may not warrant their inclusion.
The advantages of opcode modifiers include: greatly expanding the function of opcodes without greatly expanding the number of opcodes, separating opcode evaluation from operand evaluation (i.e. the behaviours of the opcodes no longer depend on the modes), rendering moot questions about whether ADD, SUB, etc. should use one or two fields (and if one field, whether to use the A-field or the B-field), adding versatility to the order of task splitting, and providing a "Skip if greater than" equivalent to SLT.
In addition, backwards compatibility with ICWS'88 (and even ICWS'86) is easily accomplished at the assembly level. Any instructions with opcodes without modifiers would be translated to the appropriate opcode.modifier pair. Examples:
"MOV #a, B", which only moves the A-field of the current instruction to the B-field of the instruction pointed to by B, would be translated to "MOV.AB #a, B". Similarly, "MOV a, b", which moves an entire instruction from A to B, becomes "MOV.I a, b". Instructions which were previously impossible, such as moving a B-field to an A-field, are now very simple and intuitive with "MOV.BA A, B". Another example, "MOV.X target, target" takes the place of "XCH target", exchanging fields. Finally, "ADD a, b" would translate to "ADD.F a, b" for ICWS'88 and "ADD.B a, b" for ICWS'86.
There is one negative to one opcode modifier. ".I" only really makes sense for MOV and CMP. It would be possible to define results for arithmetic manipulation and ordinal comparison of opcodes and modes, but it would be very artificial. As an alternative, .I falls back to .F functionality (for opcodes other than MOV and CMP) in this document.
Things which absolutely must be done before final consideration for adoption by the ICWS:
The maximal verbosity of the draft is intentional. Each sentence either presents a new item, a clarification of an item, or an old item in a new context. The goal is that no two reasonable people could arrive at two different interpretations of the draft.
0001 Draft of Proposed 1994 Core War Standard 0002 Version 3.2 0003 Draft Last Modified: February 2, 1995 0004 Last modified by: Stephen Beitzel 0005 Base draft by: Mark Durham 0006 i. Contents 0007 1. Introduction 0008 1. Purpose 0009 2. Overview 0010 3. Acknowledgements 0011 2. Redcode Assembly File Format 0012 1. Purpose 0013 2. Description 0014 3. Grammar 0015 4. Assembly To Object Code Conversion 0016 5. Pseudo-instructions 0017 6. Comment Conventions 0018 7. Example Assembly File 0019 3. Load File Format 0020 1. Purpose 0021 2. Description 0022 3. Grammar 0023 4. Comment Conventions 0024 5. Example Load File 0025 4. Run-time Variables 0026 1. Purpose 0027 2. Variables 0028 3. Standard Variable Sets 0029 5. MARS 0030 1. Purpose 0031 2. Description 0032 3. Address Modes 0033 1. Immediate 0034 2. Direct 0035 3. Indirect 0036 4. Predecrement Indirect 0037 5. Postincrement Indirect 0038 4. Modifiers 0039 1. A 0040 2. B 0041 3. AB 0042 4. BA 0043 5. F 0044 6. X 0045 7. I 0046 5. Instruction Set 0047 1. DAT 0048 2. MOV 0049 3. ADD 0050 4. SUB 0051 5. MUL 0052 6. DIV 0053 7. MOD 0054 8. JMP 0055 9. JMZ 0056 10. JMN 0057 11. DJN 0058 12. CMP 0059 13. SLT 0060 14. SPL 0061 6. Example MARS interpreter 0062 6. Validation Suite 0063 1. Purpose and Requirements 0064 2. Assembly to Load File Test 0065 0066 3. MARS Tests 0067 1. DAT Tests 0068 2. MOV Tests 0069 3. ADD Tests 0070 4. SUB Tests 0071 5. MUL Tests 0072 6. DIV Tests 0073 7. MOD Tests 0074 8. JMP Tests 0075 9. JMZ Tests 0076 10. JMN Tests 0077 11. DJN Tests 0078 12. CMP Tests 0079 13. SLT Tests 0080 14. SPL Tests 0081 7. Glossary and Index 0082 A. Differences Between Standards 0083 1. Purpose 0084 2. Changes 0085 1. Assembly Files 0086 1. ICWS'88 conversion 0087 2. ICWS'86 conversion 0088 2. Load Files 0089 3. MARS 0090 1. Introduction 0091 1.1 Purpose 0092 This standard seeks to fully define and describe the game of Core War. 0093 1.2 Overview 0094 Core War is a game in which programs compete for control of a computer 0095 called MARS (for Memory Array Redcode Simulator). Redcode is the name 0096 of the assembly language in which Core War programs, called warriors, 0097 are written. 0098 In order to play Core Wars, access to a Core War system is required. 0099 A Core War system at a minimum must have a MARS executive function 0100 (interpreter) and a way to load warriors into core (the MARS memory). 0101 Most systems include a Redcode assembler, either separately or as part 0102 of the loader. Also, many systems include a graphical interface and 0103 code debugging features. Some systems have the ability to run 0104 automated tournaments. 0105 1.3 Acknowledgements 0106 This document is the fourth standard for Core War, the first three 0107 being "Core War Guidelines" (March 1984) by D. G. Jones and 0108 A. K. Dewdney, the International Core War Society standard of 1986 - 0109 "Core Wars" (May 1986), principally authored by Graeme McRae and the 0110 "Core Wars Standard of 1988" (Summer 1988), principally authored by 0111 Thomas Gettys. The latter two standards are often referred to as 0112 ICWS'86 and ICWS'88, respectively. 0113 People who contributed to this document (in alphabetical order): 0114 Scott W. Adkins 0115 Mark A. Durham 0116 Anders Ivner 0117 Morten Due Joergensen 0118 Paul Kline 0119 Scott Nelson 0120 Jon Newman 0121 John Perry 0122 Andy Pierce 0123 Wayne Sheppard 0124 William Shubert 0125 Nandor Sieben 0126 Stefan Strack 0127 Mintardjo Wangsaw 0128 Kevin Whyte 0129 2. Redcode Assembly File Format 0130 2.1 Purpose 0131 A Redcode assembly file consists of the information necessary for a 0132 Redcode assembler to produce a load file. A standard assembly file 0133 format allows programmers to exchange warriors in a more meaningful 0134 format than load files. An assembly file, through the use of labels, 0135 arithmetic expressions, and macros can also greatly reduce the work 0136 necessary to produce a particular warrior while enhancing code 0137 readability. 0138 2.2 Description 0139 Each Redcode warrior consists of one or more lines of Redcode. Each 0140 line of Redcode consists of a string of alphanumerals and special 0141 characters. Special characters in Redcode are the addressing mode 0142 indicators for immediate '#', direct '$', indirect '@', predecrement 0143 indirect '<', and postincrement indirect '>' modes, the field 0144 separator (comma) ',', the comment indicator (semicolon) ';', the 0145 arithmetic operators for addition '+', subtraction '-', multiplication 0146 '*', division '/', and modulus '%', and opening '(' and closing ')' 0147 parentheses for precedence grouping. 0148 A line may be blank or consist of an instruction, a 0149 pseudo-instruction, a comment, or an instruction or 0150 pseudo-instruction followed by a comment. Each line is terminated 0151 with a newline. All comments begin with a semicolon. Each 0152 instruction consists of these elements in the following order: a 0153 label, an opcode, an A-operand, a comma, and a B-operand. Each 0154 element may be preceded and/or followed by whitespace other than a 0155 newline. The label is optional. If either operand is blank, the 0156 comma may be omitted. 0157 Pseudo-instructions appear just like instructions but are directives 0158 to the assembler and do not result in object code as an instruction 0159 would. Each pseudo-instruction has a pseudo-opcode which appears 0160 where an opcode would appear in an instruction. The format of the 0161 remainder of the pseudo-instruction depends on which pseudo-opcode is 0162 used. For the remainder of this section (2.2) and the next (2.3), 0163 references to "opcode" include "pseudo-opcode" assembler directives. 0164 A label is any alphanumeric string other than those reserved for 0165 opcodes. Labels are case sensitive, i.e. "start" is different from 0166 "Start". An opcode is any of the following: DAT, MOV, ADD, SUB, MUL, 0167 DIV, MOD, JMP, JMZ, JMN, DJN, CMP, SLT, or SPL. Opcodes may be in 0168 upper or lower case or any combination. An opcode may be followed by 0169 a modifier. A modifier always begins with a dot. A modifier is any 0170 of the following: .A, .B, .AB, .BA, .F, .X, or .I. Modifiers may be 0171 in upper or lower case or any combination. 0172 Each operand is blank, contains an address, or contains an addressing 0173 mode indicator and an address. An address consists of any number of 0174 labels and numbers separated by arithmetic operators and possibly 0175 grouped with parentheses. All elements of an address may be separated 0176 by whitespace. 0177 2.3 Grammar 0178 Tokens are separated by whitespace (space and tab) exclusive of 0179 newline characters, which are used for line termination. End-of-file 0180 should occur only where newline could logically occur, otherwise the 0181 load file has been terminated prematurely. 0182 In the following, 'e' is the "empty" element, meaning the token may be 0183 omitted, a caret '^' means NOT, an asterisk '*' immediately adjacent 0184 means zero or more occurrences of the previous token, and a plus '+' 0185 immediately adjacent means one or more occurrences of the previous 0186 token. The vertical bar '|' means OR. 0187 assembly_file: 0188 list 0189 list: 0190 line | line list 0191 line: 0192 comment | instruction 0193 comment: 0194 ; v* EOL | EOL 0195 instruction: 0196 label_list operation mode field comment | 0197 label_list operation mode expr , mode expr comment 0198 label_list: 0199 label | label label_list | label newline label_list | e 0200 label: 0201 alpha alphanumeral* 0202 operation: 0203 opcode | opcode.modifier 0204 opcode: 0205 DAT | MOV | ADD | SUB | MUL | DIV | MOD | 0206 JMP | JMZ | JMN | DJN | CMP | SLT | SPL | 0207 ORG | EQU | END 0208 modifier: 0209 A | B | AB | BA | F | X | I 0210 mode: 0211 # | $ | @ | < | > | e 0212 expr: 0213 term | 0214 term + expr | term - expr | 0215 term * expr | term / expr | 0216 term % expr 0217 term: 0218 label | number | (expression) 0219 number: 0220 whole_number | signed_integer 0221 signed_integer: 0222 +whole_number | -whole_number 0223 whole_number: 0224 numeral+ 0225 alpha: 0226 A-Z | a-z | _ 0227 numeral: 0228 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 0229 alphanumeral: 0230 alpha | numeral 0231 v: 0232 ^EOL 0233 EOL: 0234 newline | EOF 0235 newline: 0236 LF | CR | LF CR | CR LF 0237 e: 0238 2.4 Assembly To Load File Conversion 0239 A Redcode program can be assembled into a list of MARS instructions. 0240 (When assembled to a file instead of directly to core, the list is 0241 called a load file. See Section 3). Each Redcode instruction 0242 assembles into a MARS instruction of five fields: an opcode.modifier 0243 field, the A-mode field, the A-address field, the B-mode field, and 0244 the B-address field. A missing (null or blank) mode assembles as '$' 0245 does. 0246 If no modifier is present in the assembly instruction, the appropriate 0247 modifier is appended to the opcode. The appropriate modifier depends 0248 upon the opcode, the modes, and which standard (ICWS'86 or ICWS'88) to 0249 consider (ICWS'88 by default). See Appendix A for the appropriate 0250 translations. 0251 The address field values are derived from the numbers, labels, and 0252 arithmetic operators contained in the addresses. Labels are 0253 converted to an address relative to the current instruction. Then 0254 the arithmetic operations are carried out according to the 0255 appropriate operator and parenthetical precedence to determine the 0256 final value. If there is only one operand associated with a DAT 0257 instruction, this operand is assembled into the B-mode and B-address 0258 fields, while #0 is assembled into the A-mode and A-address fields. 0259 For all other instructions with only one operand, this operand is 0260 assembled into the A-mode and A-address fields and #0 is assembled 0261 into the B-mode and B-address fields. 0262 2.5 Pseudo-instructions 0263 Pseudo-opcodes are "ORG", "EQU", and "END". 0264 "ORG" ("ORiGin") is a way for the assembly file to indicate the 0265 logical origin of the warrior. The A-operand contains an offset to 0266 the logical first instruction. Thus "ORG 0" means execution should 0267 start with the first instruction (the default) whereas "ORG 6" means 0268 execution should start with the seventh instruction. Although multiple 0269 ORG instructions are of no additional benefit to the programmer, they 0270 are allowed. When there is more than one ORG instruction in a file, 0271 the last ORG instruction encountered will be the one that takes 0272 effect. 0273 "EQU" ("EQUate") is a simple text substitution utility. Instructions 0274 of the form "label EQU text" will replace all occurrences of "label" 0275 with the (probably longer and more complicated) "text" before any 0276 actual assembly takes place on the file. 0277 "END" indicates the logical end of the assembly file. If END has an 0278 A-operand, then the A-operand indicates the logical origin of the 0279 warrior in the same manner as ORG does. No instruction following END 0280 should be assembled. 0281 2.6 Comment Conventions 0282 ";redcode" as a first line identifies the file as a Redcode 0283 assembly file. The " " is optional and implementation 0284 dependent. 0285 ";strategy " indicates a comment for "public" consumption. 0286 ";name ", ";author ", 0287 ";version ", and ";date " 0288 offer uniform ways of presenting this information. 0289 ";kill " is for removing warriors from ongoing 0290 tournaments. If no is supplied, all of the author's 0291 previous submissions will be removed. 0292 2.7 Example Assembly File 0293 ;redcode 0294 ;name Dwarf 0295 ;author A. K. Dewdney 0296 ;version 94.1 0297 ;date April 29, 1993 0298 ;strategy Bombs every fourth instruction. 0299 ORG start ; Indicates the instruction with 0300 ; the label "start" should be the 0301 ; first to execute. 0302 step EQU 4 ; Replaces all occurrences of "step" 0303 ; with the character "4". 0304 target DAT.F #0, #0 ; Pointer to target instruction. 0305 start ADD.AB #step, target ; Increments pointer by step. 0306 MOV.AB #0, @target ; Bombs target instruction. 0307 JMP.A start ; Same as JMP.A -2. Loops back to 0308 ; the instruction labelled "start". 0309 END 0310 3. Load File Format 0311 3.1 Purpose 0312 A load file represents the minimum amount of information necessary for 0313 a warrior to execute properly and is presented in a very simple format 0314 which is a subset of the assembly file format presented in Section 2. 0315 A standard load file format allows programmers to choose assemblers 0316 and MARS programs separately and to verify assembler performance and 0317 MARS performance separately. Not all Core War systems will necessarily 0318 write load files (for example, those which assemble directly to core), 0319 but all systems should support reading load files. 0320 3.2 Description 0321 Each load file will consist of one or more lines of MARS 0322 instructions or comments. Each line is terminated with a newline. 0323 All comments start with with a semicolon. Each MARS instruction 0324 consists of five fields: an opcode.modifier pair, an A-mode, an 0325 A-field, a B-mode, and a B-field. The A-mode is separated from the 0326 opcode.modifier pair by whitespace and the B-mode is separated from 0327 the A-field by a comma and additional whitespace. Each MARS 0328 instruction may be followed by extraneous information, which is 0329 ignored. Note that the instruction format for load files is more 0330 rigid than for assemply files to simplify parsing. No blank modes or 0331 operands are allowed. 0332 3.3 Grammar 0333 Tokens are separated by whitespace (non-marking characters such as 0334 SPACE and TAB) exclusive of newline characters, which are used for 0335 line termination. End-of-file should occur only where newline could 0336 logically occur, otherwise the load file has been terminated 0337 prematurely. 0338 load_file: 0339 list 0340 list: 0341 line | line list 0342 line: 0343 comment | instruction 0344 comment: 0345 ; v* EOL | EOL 0346 instruction: 0347 opcode.modifier mode number , mode number comment 0348 opcode: 0349 DAT | MOV | ADD | SUB | MUL | DIV | MOD | 0350 JMP | JMZ | JMN | DJN | CMP | SLT | SPL | 0351 ORG 0352 modifier: 0353 A | B | AB | BA | F | X | I 0354 mode: 0355 # | $ | @ | < | > 0356 number: 0357 whole_number | signed_integer 0358 signed_integer: 0359 +whole_number | -whole_number 0360 whole_number: 0361 numeral+ 0362 numeral: 0363 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 0364 v: 0365 ^EOL 0366 EOL: 0367 newline | EOF 0368 newline: 0369 LF | CR | LF CR | CR LF 0370 3.4 Comment Conventions 0371 Comment conventions for load files are the same as for assembly files. 0372 Of particular note are the "; name " and "; author 0373 " comments. These comments provide a more suitable 0374 identification of programs to the MARS than "Warrior #1", "Warrior #2", 0375 etc. It also allows for less cryptic identification than by filename. 0376 3.5 Example Load File 0377 ;redcode 0378 ;name Dwarf 0379 ;author A. K. Dewdney 0380 ;version 94.1 0381 ;date April 29, 1993 0382 ;strategy Bombs every fourth instruction. 0383 ORG 1 ; Indicates execution begins with the second 0384 ; instruction (ORG is not actually loaded, and is 0385 ; therefore not counted as an instruction). 0386 DAT.F #0, #0 ; Pointer to target instruction. 0387 ADD.AB #4, $-1 ; Increments pointer by step. 0388 MOV.AB #0, @-2 ; Bombs target instruction. 0389 JMP.A $-2, #0 ; Loops back two instructions. 0390 4. Run-time Variables 0391 4.1 Purpose 0392 This section describes those variables which are determined just prior 0393 to running a battle by the person running the battle. It also 0394 enumerates some of the standardized sets of variables used for 0395 tournaments. 0396 4.2 Variables 0397 Run-time variables consist of the following: 0398 Core Size: 0399 Core size is the number of instructions which make up core 0400 during the battle. 0401 Cycles Before Tie: 0402 In each cycle, one instruction from each warrior is executed. 0403 This variable determines how many cycles without a winner 0404 should be executed before declaring a tie. 0405 Initial Instruction: 0406 The initial instruction is that instruction which is preloaded 0407 into core prior to loading warriors. In addition to loading 0408 an instruction such as "DAT #0, #0" into all of core, the 0409 initial instruction could be set to "NONE", meaning core should 0410 not be cleared between battles, or "RANDOM", meaning core 0411 instructions are filled with randomly generated instructions. 0412 Instruction Limit: 0413 The maximum number of instructions allowed per load file. 0414 Maximum Number of Tasks: 0415 Each warrior can spawn multiple additional tasks. This 0416 variable sets the maximum number of tasks allowed per warrior. 0417 In other words, this is the size of each warrior's task queue. 0418 Minimum Separation: 0419 The minimum number of instructions from the first instruction 0420 of one warrior to the first instruction of the next warrior. 0421 Read Distance: 0422 This is the range available for warriors to read information 0423 from core. Attempts to read outside the limits of this range 0424 result in reading within the local readable range. The range 0425 is centered on the current instruction. Thus, a range of 0426 500 limits reading to offsets of (-249 -> +250) from the 0427 currently executing instruction. The read limit can therefore 0428 be considered a mini-core within core. An attempt to read 0429 location PC+251 reads location PC-249 instead. An attempt to 0430 read location PC+500 reads location PC instead. 0431 Read distance must be a factor of core size, otherwise the 0432 above defined behaviour is not guaranteed. 0433 Separation: 0434 The number of instructions from the first instruction of one 0435 warrior to the first instruction of the next warrior. 0436 Separation can be set to "RANDOM", meaning separations will be 0437 chosen randomly from those larger than the minimum separation. 0438 Warriors: 0439 The initial number of warriors to battle simultaneously in 0440 core. 0441 Write Distance: 0442 This is the range available for warriors to write information 0443 to core. Attempts to write outside the limits of this range 0444 result in writing within the local writable range. The range 0445 is centered on the current instruction. Thus, a range of 500 0446 limits writing to offsets of (-249 -> +250) from the 0447 currently executing instruction. The write limit can 0448 therefore be considered a mini-core within core. An attempt 0449 to write location PC+251 writes to location PC-249 instead. 0450 An attempt to write to location PC+500 writes to location PC 0451 instead. 0452 Write distance must be a factor of core size, otherwise the 0453 above defined behaviour is not guaranteed. 0454 4.3 Standard Variable Sets 0455 ICWS86: 0456 Core Size: 8192 0457 Cycles Before Tie:<PHONE_NUMBER> Initial Instruction: DAT.F #0, #0 0459 Instruction Limit: 300 0460 Maximum Number of Tasks: 64 0461 Minimum Separation: 300 0462 Read Distance: 8192 0463 Separation: RANDOM 0464 Warriors: 2 0465 Write Distance: 8192 0466 KOTH: 0467 Core Size: 8000 0468 Cycles Before Tie: 80000 0469 Initial Instruction: DAT.F $0, $0 0470 Instruction Limit: 100 0471 Maximum Number of Tasks: 8000 0472 Minimum Separation: 100 0473 Read Distance: 8000 0474 Separation: RANDOM 0475 Warriors: 2 0476 Write Distance: 8000 0477 5. MARS 0478 5.1 Purpose 0479 The Memory Array Redcode Simulator (MARS) is the computer in which 0480 Core War warriors do combat. 0481 5.2 Description 0482 A minimally-complete MARS consists of a core, a loader, task queues, 0483 the MARS executive function, and a way to present the final results of 0484 a battle. Additionally, many MARS provide a "real-time" battle 0485 display and various debugging tools. 0486 The core consists of a cyclic list (0, 1, 2, ..., M-2, M-1, 0, 1, ...) 0487 of M MARS instructions. The integer M is referred to as "core size". 0488 All operations are performed modulo M. Core initialization (the 0489 initial instructions placed in core before loading warriors) is a 0490 run-time variable (see Section 4). 0491 The loader loads warriors into core, converting all negative field 0492 values N to positive field values P such that 0 <= P < M and P = kM 0493 + N for some integer k. Subsequently, all field values G greater 0494 than or equal to M are converted to field values L = G modulo M. 0495 The loader also initializes each warrior's task queue with the 0496 appropriate task pointer. 0497 There is a task queue for each warrior loaded into core. Each task 0498 queue can hold a limited number of task pointers. The "task limit" 0499 (number of tasks an individual warrior's task queue can hold) is a 0500 run-time variable. The task queues are FIFOs (First In, First Out). 0501 Each warrior consists of one task initially. Subsequent tasks are 0502 added to the warrior's task queue using the SPL instruction. 0503 Attempted execution of a DAT instruction by a task effectively removes 0504 that task from the warrior's task queue. 0505 Warriors execute for a specified number of cycles ("time limit", see 0506 Section 4) or until only one warrior is still executing, whichever 0507 occurs first. Each cycle, one instruction from each warrior is 0508 executed. The instruction to execute is the instruction pointed to by 0509 the next task pointer in the warrior's task queue. A warrior is no 0510 longer executing when its task queue is empty. 0511 The following expressions are used in describing the MARS executive 0512 function's operation. 0513 General Definitions: 0514 An instruction consists of an opcode, a modifier, an A-operand, 0515 and a B-operand. 0516 An A-operand consists of an A-mode and an A-number. 0517 An A-mode is the addressing mode of an A-operand. 0518 An A-number is an integer between 0 and M-1, inclusive. 0519 A B-operand consists of a B-mode and a B-number. 0520 A B-mode is the addressing mode of a B-operand. 0521 A B-number is an integer between 0 and M-1, inclusive. 0522 Specific Definitions: 0523 The program counter (PC) is the pointer to the location in core of 0524 the instruction fetched from core to execute. 0525 The current instruction is the instruction in the instruction 0526 register, as copied (prior to execution) from the PC 0527 location of core. 0528 The A-pointer points to the instruction the A-operand of the 0529 current instruction references in core. 0530 The A-instruction is a copy of the instruction the A-pointer 0531 points to in core (as it was during operand evaluation). 0532 The A-value is the A-number and/or the B-number of the 0533 A-instruction or the A-instruction itself, whichever are/is 0534 selected by the opcode modifier. 0535 The B-pointer points to the instruction the B-operand of the 0536 current instruction references in core. 0537 The B-instruction is a copy of the instruction the B-pointer 0538 points to in core (as it was during operand evaluation). 0539 The B-value is the A-number and/or the B-number of the 0540 B-instruction or the B-instruction itself, whichever are/is 0541 selected by the opcode modifier. 0542 The B-target is the A-number and/or the B-number of the instruction 0543 pointed to by the B-pointer or the instruction itself, 0544 whichever are/is selected by the opcode modifier. 0545 All MARS instructions are executed following the same procedure: 0546 1. The currently executing warrior's current task pointer is 0547 extracted from the warrior's task queue and assigned to the 0548 program counter. 0549 2. The corresponding instruction is fetched from core and stored in 0550 the instruction register as the current instruction. 0551 3. The A-operand of the current instruction is evaluated. 0552 4. The results of A-operand evaluation, the A-pointer and the 0553 A-instruction, are stored in the appropriate registers. 0554 5. The B-operand of the current instruction is evaluated. 0555 6. The results of B-operand evaluation, the B-pointer and the 0556 B-instruction, are stored in the appropriate registers. 0557 7. Operations appropriate to the opcode.modifier pair in the 0558 instruction register are executed. With the exception of DAT 0559 instructions, all operations queue an updated task pointer. 0560 (How the task pointer is updated and when it is queued depend on 0561 instruction execution). 0562 All pointers are PC-relative, indicating the offset from the source of 0563 the current instruction to the desired location. All arithmetic is to 0564 be done modulo M, with negative values converted in the same manner as 0565 during loading as discussed above (P = M + N). Additionally, all 0566 reads of core are done modulo the read limit (R) and all writes of 0567 core are done modulo the write limit (W). Read offsets O greater than 0568 R/2 from the current instruction are converted to backwards offsets of 0569 O = O - R. A comparable conversion occurs for write offsets greater 0570 than W/2. 0571 5.3 Address Modes 0572 5.3.1 Immediate 0573 An immediate mode operand merely serves as storage for data. An 0574 immediate A/B-mode in the current instruction sets the A/B-pointer to 0575 zero. 0576 5.3.2 Direct 0577 A direct mode operand indicates the offset from the program counter. 0578 A direct A/B-mode in the current instruction means the A/B-pointer is 0579 a copy of the offset, the A/B-number of the current instruction. 0580 5.3.3 Indirect 0581 An indirect mode operand indicates the primary offset (relative to the 0582 program counter) to the secondary offset (relative to the location 0583 of the instruction in which the secondary offset is contained). An 0584 indirect A/B-mode indicates that the A/B-pointer is the sum of the 0585 A/B-number of the current instruction (the primary offset) and the 0586 B-number of the instruction pointed to by the A/B-number of the 0587 current instruction (the secondary offset). 0588 5.3.4 Predecrement Indirect 0589 A predecrement indirect mode operand indicates the primary offset 0590 (relative to the program counter) to the secondary offset (relative to 0591 the location of the instruction in which the secondary offset is 0592 contained) which is decremented prior to use. A predecrement 0593 indirect A/B-mode indicates that the A/B-pointer is the sum of the 0594 A/B-number of the current instruction (the primary offset) and the 0595 decremented B-number of the instruction pointed to by the A/B-number 0596 of the current instruction (the secondary offset). 0597 5.3.5 Postincrement Indirect 0598 A postincrement indirect mode operand indicates the primary offset 0599 (relative to the program counter) to the secondary offset (relative to 0600 the location of the instruction in which the secondary offset is 0601 contained) which is incremented after the results of the operand 0602 evaluation are stored. A postincrement indirect A/B-mode indicates that 0603 the A/B-pointer is the sum of the A/B-number of the current instruction 0604 (the primary offset) and the B-number of the instruction pointed to by 0605 the A/B-number of the current instruction (the secondary offset). The 0606 B-number of the instruction pointed to by the A/B-number of the current 0607 instruction is incremented after the A/B-instruction is stored, but 0608 before the B-operand is evaluated (for post-increment A-mode), or 0609 the operation is executed (for post-increment indirect B-mode). 0610 5.4 Modifiers 0611 5.4.1 A 0612 Instruction execution proceeds with the A-value set to the A-number of 0613 the A-instruction and the B-value set to the A-number of the 0614 B-instruction. A write to core replaces the A-number of the 0615 instruction pointed to by the B-pointer. 0616 For example, a CMP.A instruction would compare the A-number of the 0617 A-instruction with the A-number of the B-instruction. A MOV.A 0618 instruction would replace the A-number of the instruction pointed to 0619 by the B-pointer with the A-number of the A-instruction. 0620 5.4.2 B 0621 Instruction execution proceeds with the A-value set to the B-number of 0622 the A-instruction and the B-value set to the B-number of the 0623 B-instruction. A write to core replaces the B-number of the 0624 instruction pointed to by the B-pointer. 0625 For example, a CMP.B instruction would compare the B-number of the 0626 A-instruction with the B-number of the B-instruction. A MOV.B 0627 instruction would replace the B-number of the instruction pointed to 0628 by the B-pointer with the B-number of the A-instruction. 0629 5.4.3 AB 0630 Instruction execution proceeds with the A-value set to the A-number of 0631 the A-instruction and the B-value set to the B-number of the 0632 B-instruction. A write to core replaces the B-number of the 0633 instruction pointed to by the B-pointer. 0634 For example, a CMP.AB instruction would compare the A-number of the 0635 A-instruction with the B-number of the B-instruction. A MOV.AB 0636 instruction would replace the B-number of the instruction pointed to 0637 by the B-pointer with the A-number of the A-instruction. 0638 5.4.4 BA 0639 Instruction execution proceeds with the A-value set to the B-number of 0640 the A-instruction and the B-value set to the A-number of the 0641 B-instruction. A write to core replaces the A-number of the 0642 instruction pointed to by the B-pointer. 0643 For example, a CMP.BA instruction would compare the B-number of the 0644 A-instruction with the A-number of the B-instruction. A MOV.BA 0645 instruction would replace the A-number of the instruction pointed to 0646 by the B-pointer with the B-number of the A-instruction. 0647 5.4.5 F 0648 Instruction execution proceeds with the A-value set to both the 0649 A-number and B-number of the A-instruction (in that order) and the 0650 B-value set to both the A-number and B-number of the B-instruction 0651 (also in that order). A write to core replaces both the A-number and 0652 the B-number of the instruction pointed to by the B-pointer (in that 0653 order). 0654 For example, a CMP.F instruction would compare the A-number of the 0655 A-instruction to the A-number of the B-instruction and the B-number of 0656 the A-instruction to B-number of the B-instruction. A MOV.F instruction 0657 would replace the A-number of the instruction pointed to by the 0658 B-pointer with the A-number of the A-instruction and would also replace 0659 the B-number of the instruction pointed to by the B-pointer with the 0660 B-number of the A-instruction. 0661 5.4.6 X 0662 Instruction execution proceeds with the A-value set to both the 0663 A-number and B-number of the A-instruction (in that order) and the 0664 B-value set to both the B-number and A-number of the B-instruction 0665 (in that order). A write to to core replaces both the B-number and 0666 the A-number of the instruction pointed to by the B-pointer (in that 0667 order). 0668 For example, a CMP.X instruction would compare the A-number of the 0669 A-instruction to the B-number of the B-instruction and the B-number of the 0670 A-instruction to A-number of the B-instruction. A MOV.X instruction would 0671 replace the B-number of the instruction pointed to by the B-pointer with the 0672 A-number of the A-instruction and would also replace the A-number of the 0673 instruction pointed to by the B-pointer with the B-number of the 0674 A-instruction. 0675 5.4.7 I 0676 Instruction execution proceeds with the A-value set to the 0677 A-instruction and the B-value set to the B-instruction. A write to 0678 core replaces the entire instruction pointed to by the B-pointer. 0679 For example, a CMP.I instruction would compare the A-instruction to 0680 the B-instruction. A MOV.I instruction would replace the instruction 0681 pointed to by the B-pointer with the A-instruction. 0682 5.5 Instruction Set 0683 5.5.1 DAT 0684 No additional processing takes place. This effectively removes the 0685 current task from the current warrior's task queue. 0686 5.5.2 MOV 0687 Move replaces the B-target with the A-value and queues the next 0688 instruction (PC + 1). 0689 5.5.3 ADD 0690 ADD replaces the B-target with the sum of the A-value and the B-value 0691 (A-value + B-value) and queues the next instruction (PC + 1). ADD.I 0692 functions as ADD.F would. 0693 5.5.4 SUB 0694 SUB replaces the B-target with the difference of the B-value and the 0695 A-value (B-value - A-value) and queues the next instruction (PC + 1). 0696 SUB.I functions as SUB.F would. 0697 5.5.5 MUL 0698 MUL replaces the B-target with the product of the A-value and the 0699 B-value (A-value * B-value) and queues the next instruction (PC + 1). 0700 MUL.I functions as MUL.F would. 0701 5.5.6 DIV 0702 DIV replaces the B-target with the integral result of dividing the 0703 B-value by the A-value (B-value / A-value) and queues the next 0704 instruction (PC + 1). DIV.I functions as DIV.F would. If the 0705 A-value is zero, the B-value is unchanged and the current task is 0706 removed from the warrior's task queue. 0707 5.5.7 MOD 0708 MOD replaces the B-target with the integral remainder of dividing the 0709 B-value by the A-value (B-value % A-value) and queues the next 0710 instruction (PC + 1). MOD.I functions as MOD.F would. If the 0711 A-value is zero, the B-value is unchanged and the current task is 0712 removed from the warrior's task queue. 0713 5.5.8 JMP 0714 JMP queues the sum of the program counter and the A-pointer. 0715 5.5.9 JMZ 0716 JMZ tests the B-value to determine if it is zero. If the B-value is 0717 zero, the sum of the program counter and the A-pointer is queued. 0718 Otherwise, the next instruction is queued (PC + 1). JMZ.I functions 0719 as JMZ.F would, i.e. it jumps if both the A-number and the B-number 0720 of the B-instruction are zero. 0721 5.5.10 JMN 0722 JMN tests the B-value to determine if it is zero. If the B-value is 0723 not zero, the sum of the program counter and the A-pointer is queued. 0724 Otherwise, the next instruction is queued (PC + 1). JMN.I functions 0725 as JMN.F would, i.e. it jumps if both the A-number and the B-number 0726 of the B-instruction are non-zero. This is not the negation of the 0727 condition for JMZ.F. 0728 5.5.11 DJN 0729 DJN decrements the B-value and the B-target, then tests the B-value 0730 to determine if it is zero. If the decremented B-value is not zero, 0731 the sum of the program counter and the A-pointer is queued. 0732 Otherwise, the next instruction is queued (PC + 1). DJN.I functions 0733 as DJN.F would, i.e. it decrements both both A/B-numbers of the B-value 0734 and the B-target, and jumps if both A/B-numbers of the B-value are 0735 non-zero. 0736 5.5.12 CMP 0737 CMP compares the A-value to the B-value. If the result of the 0738 comparison is equal, the instruction after the next instruction 0739 (PC + 2) is queued (skipping the next instruction). Otherwise, the 0740 the next instruction is queued (PC + 1). 0741 5.5.13 SLT 0742 SLT compares the A-value to the B-value. If the A-value is less than 0743 the B-value, the instruction after the next instruction (PC + 2) is 0744 queued (skipping the next instruction). Otherwise, the next 0745 instruction is queued (PC + 1). SLT.I functions as SLT.F would. 0746 5.5.14 SPL 0747 SPL queues the next instruction (PC + 1) and then queues the sum of 0748 the program counter and A-pointer. If the queue is full, only the 0749 next instruction is queued. 0750 5.6 Example MARS Interpreter 0751 /************************************/ 0752 /* */ 0753 /* EMI94.c */ 0754 /* */ 0755 /* Execute MARS Instruction ala */ 0756 /* ICWS'94 Draft Standard. */ 0757 /* */ 0758 /* Last Update: February 2, 94 */ 0759 /* */ 0760 /************************************/ 0761 /* This ANSI C function is the benchmark MARS instruction */ 0762 /* interpreter for the ICWS'94 Draft Standard. */ 0763 /* The design philosophy of this function is to mirror the */ 0764 /* standard as closely as possible, illuminate the meaning */ 0765 /* of the standard, and provide the definitive answers to */ 0766 /* questions of the "well, does the standard mean this or */ 0767 /* that?" variety. Although other, different implemen- */ 0768 /* tations are definitely possible and encouraged; those */ 0769 /* implementations should produce the same results as this */ 0770 /* one does. */ 0771 /* The function returns the state of the system. What the */ 0772 /* main program does with this information is not defined */ 0773 /* by the standard. */ 0774 enum SystemState { 0775 UNDEFINED, 0776 SUCCESS 0777 }; 0778 /* Any number of warriors may be executing in core at one */ 0779 /* time, depending on the run-time variable set and how */ 0780 /* many warriors have failed during execution. For this */ 0781 /* implementation, warriors are identified by the order in */ 0782 /* which they were loaded into core. */ 0783 typedef unsigned int Warrior; 0784 /* An Address in Core War can be any number from 0 to the */ 0785 /* size of core minus one, relative to the current */ 0786 /* instruction. In this implementation, core is an array */ 0787 /* of instructions; therefore any variable types which */ 0788 /* contain an Address can be considered to be of type */ 0789 /* unsigned int. One caveat: for the purposes of this */ 0790 /* standard, unsigned int must be considered to have no */ 0791 /* upper limit. Depending on the size of core, it may be */ 0792 /* necessary to take precautions against overflow. */ 0793 typedef unsigned int Address; 0794 /* The FIFO task queues and supporting functions are not */ 0795 /* presented. The function Queue() attempts to add a task */ 0796 /* pointer to the back of the currently executing warrior's */ 0797 /* task queue. No special actions are to be taken if */ 0798 /* Queue() is unsuccessful, which it will be if the warrior */ 0799 /* has already reached the task limit (maximum allowable */ 0800 /* number of tasks). */ 0801 extern void Queue( 0802 Warrior W, 0803 Address TaskPointer 0804 ); 0805 /* There is one support function used to limit the range of */ 0806 /* reading from Core and writing to Core relative to the */ 0807 /* current instruction. Behaviour is as expected (a small */ 0808 /* core within Core) only if the limits are factors of the */ 0809 /* size of Core. */ 0810 static Address Fold( 0811 Address pointer, /* The pointer to fold into the desired range. */ 0812 Address limit, /* The range limit. */ 0813 Address M /* The size of Core. */ 0814 ) { 0815 Address result; 0816 result = pointer % limit; 0817 if ( result > (limit/2) ) { 0818 result += M - limit; 0819 }; 0820 return(result); 0821 } 0822 /* Instructions are the principle data type. Core is an */ 0823 /* array of instructions, and there are three instruction */ 0824 /* registers used by the MARS executive. */ 0825 enum Opcode { 0826 DAT, 0827 MOV, 0828 ADD, 0829 SUB, 0830 MUL, 0831 DIV, 0832 MOD, 0833 JMP, 0834 JMZ, 0835 JMN, 0836 DJN, 0837 CMP, 0838 SLT, 0839 SPL 0840 }; 0841 enum Modifier { 0842 A, 0843 B, 0844 AB, 0845 BA, 0846 F, 0847 X, 0848 I 0849 }; 0850 enum Mode { 0851 IMMEDIATE, 0852 DIRECT, 0853 INDIRECT, 0854 DECREMENT, 0855 INCREMENT 0856 }; 0857 typedef struct Instruction { 0858 enum Opcode Opcode; 0859 enum Modifier Modifier; 0860 enum Mode AMode; 0861 Address ANumber; 0862 enum Mode BMode; 0863 Address BNumber; 0864 } Instruction; 0865 /* The function is passed which warrior is currently */ 0866 /* executing, the address of the warrior's current task's */ 0867 /* current instruction, a pointer to the Core, the size of */ 0868 /* the Core, and the read and write limits. It returns the */ 0869 /* system's state after attempting instruction execution. */ 0870 enum SystemState EMI94( 0871 /* W indicates which warrior's code is executing. */ 0872 Warrior W, 0873 /* PC is the address of this warrior's current task's */ 0874 /* current instruction. */ 0875 Address PC, 0876 /* Core is just an array of Instructions. Core has been */ 0877 /* initialized and the warriors have been loaded before */ 0878 /* calling this function. */ 0879 Instruction Core[], 0880 /* M is the size of Core. */ 0881 Address M, 0882 /* ReadLimit is the limitation on read distances. */ 0883 Address ReadLimit, 0884 /* WriteLimit is the limitation on write distances. */ 0885 Address WriteLimit 0886 ) { 0887 /* This MARS stores the currently executing instruction in */ 0888 /* the instruction register IR. */ 0889 Instruction IR; 0890 /* This MARS stores the instruction referenced by the */ 0891 /* A-operand in instruction register IRA. */ 0892 Instruction IRA; 0893 /* This MARS stores the instruction referenced by the */ 0894 /* B-operand in statement_Register IRB. */ 0895 Instruction IRB; 0896 /* All four of the following pointers are PC-relative */ 0897 /* (relative to the Program Counter). Actual access of */ 0898 /* core must add-in the Program Counter (mod core size). */ 0899 /* The offset to the instruction referred to by the */ 0900 /* A-operand for reading is Read Pointer A (RPA). */ 0901 Address RPA; 0902 /* The offset to the instruction referred to by the */ 0903 /* A-operand for writing is Write Pointer A (WPA). */ 0904 Address WPA; 0905 /* The offset to the instruction referred to by the */ 0906 /* B-operand for reading is Read Pointer B (RPB). */ 0907 Address RPB; 0908 /* The offset to the instruction referred to by the */ 0909 /* A-operand for writing is Write Pointer B (WPB). */ 0910 Address WPB; 0911 /* Post-increment operands need to keep track of which */ 0912 /* instruction to increment. */ 0913 Address PIP; 0914 /* Before execution begins, the current instruction is */ 0915 /* copied into the Instruction Register. */ 0916 IR = Core[PC]; 0917 /* Next, the A-operand is completely evaluated. */ 0918 /* For instructions with an Immediate A-mode, the Pointer A */ 0919 /* points to the source of the current instruction. */ 0920 if (IR.AMode == IMMEDIATE) { 0921 RPA = WPA = 0; 0922 } else { 0923 /* For instructions with a Direct A-mode, the Pointer A */ 0924 /* points to the instruction IR.ANumber away, relative to */ 0925 /* the Program Counter. */ 0926 /* Note that implementing Core as an array necessitates */ 0927 /* doing all Address arithmetic modulus the size of Core. */ 0928 RPA = Fold(IR.ANumber, ReadLimit, M); 0929 WPA = Fold(IR.ANumber, WriteLimit, M); 0930 /* For instructions with indirection in the A-operand */ 0931 /* (Indirect, Pre-decrement, and Post-increment A-modes): */ 0932 if (IR.AMode != DIRECT) { 0933 /* For instructions with Pre-decrement A-mode, the B-Field */ 0934 /* of the instruction in Core currently pointed to by the */ 0935 /* Pointer A is decremented (M - 1 is added). */ 0936 if (IR.AMode == DECREMENT) { 0937 Core[((PC + WPA) % M)].BNumber = 0938 (Core[((PC + WPA) % M)].BNumber + M - 1) % M; 0939 }; 0940 /* For instructions with Post-increment A-mode, the B-Field */ 0941 /* of the instruction in Core currently pointed to by the */ 0942 /* Pointer A will be incremented. */ 0943 if (IR.AMode == INCREMENT) { 0944 PIP = (PC + WPA) % M; 0945 }; 0946 /* For instructions with indirection in the A-operand, */ 0947 /* Pointer A ultimately points to the instruction */ 0948 /* Core[((PC + PCA) % M)].BNumber away, relative to the */ 0949 /* instruction pointed to by Pointer A. */ 0950 RPA = Fold( 0951 (RPA + Core[((PC + RPA) % M)].BNumber), ReadLimit, M 0952 ); 0953 WPA = Fold( 0954 (WPA + Core[((PC + WPA) % M)].BNumber), WriteLimit, M 0955 ); 0956 }; 0957 }; 0958 /* The Instruction Register A is a copy of the instruction */ 0959 /* pointed to by Pointer A. */ 0960 IRA = Core[((PC + RPA) % M)]; 0961 /* If the A-mode was post-increment, now is the time to */ 0962 /* increment the instruction in core. */ 0963 if (IR.AMode == INCREMENT) { 0964 Core[PIP].BNumber = (Core[PIP].BNumber + 1) % M; 0965 }; 0966 /* The Pointer B and the Instruction Register B are */ 0967 /* evaluated in the same manner as their A counterparts. */ 0968 if (IR.BMode == IMMEDIATE) { 0969 RPB = WPB = 0; 0970 } else { 0971 RPB = Fold(IR.BNumber, ReadLimit, M); 0972 WPB = Fold(IR.BNumber, WriteLimit, M); 0973 if (IR.BMode != DIRECT) { 0974 if (IR.BMode == DECREMENT) { 0975 Core[((PC + WPB) % M)].BNumber = 0976 (Core[((PC + WPB) % M)].BNumber + M - 1) % M 0977 ; 0978 } else if (IR.BMode == INCREMENT) { 0979 PIP = (PC + WPB) % M; 0980 }; 0981 RPB = Fold( 0982 (RPB + Core[((PC + RPB) % M)].BNumber), ReadLimit, M 0983 ); 0984 WPB = Fold( 0985 (WPB + Core[((PC + WPB) % M)].BNumber), WriteLimit, M 0986 ); 0987 }; 0988 }; 0989 IRB = Core[((PC + RPB) % M)]; 0990 if (IR.BMode == INCREMENT) { 0991 Core[PIP].BNumber = (Core[PIP].BNumber + 1) % M; 0992 }; 0993 /* Execution of the instruction can now proceed. */ 0994 switch (IR.Opcode) { 0995 /* Instructions with a DAT opcode have no further function. */ 0996 /* The current task's Program Counter is not updated and is */ 0997 /* not returned to the task queue, effectively removing the */ 0998 /* task. */ 0999 case DAT: 1000 break; 1001 /* MOV replaces the B-target with the A-value and queues */ 1002 /* the next instruction. */ 1003 case MOV: 1004 switch (IR.Modifier) { 1005 /* Replaces A-number with A-number. */ 1006 case A: 1007 Core[((PC + WPB) % M)].ANumber = IRA.ANumber; 1008 break; 1009 /* Replaces B-number with B-number. */ 1010 case B: 1011 Core[((PC + WPB) % M)].BNumber = IRA.BNumber; 1012 break; 1013 /* Replaces B-number with A-number. */ 1014 case AB: 1015 Core[((PC + WPB) % M)].BNumber = IRA.ANumber; 1016 break; 1017 /* Replaces A-number with B-number. */ 1018 case BA: 1019 Core[((PC + WPB) % M)].ANumber = IRA.BNumber; 1020 break; 1021 /* Replaces A-number with A-number and B-number with */ 1022 /* B-number. */ 1023 case F: 1024 Core[((PC + WPB) % M)].ANumber = IRA.ANumber; 1025 Core[((PC + WPB) % M)].BNumber = IRA.BNumber; 1026 break; 1027 /* Replaces B-number with A-number and A-number with */ 1028 /* B-number. */ 1029 case X: 1030 Core[((PC + WPB) % M)].BNumber = IRA.ANumber; 1031 Core[((PC + WPB) % M)].ANumber = IRA.BNumber; 1032 break; 1033 /* Copies entire instruction. */ 1034 case I: 1035 Core[((PC + WPB) % M)] = IRA; 1036 break; 1037 default: 1038 return(UNDEFINED); 1039 break; 1040 }; 1041 /* Queue up next instruction. */ 1042 Queue(W, ((PC + 1) % M)); 1043 break; 1044 /* Arithmetic instructions replace the B-target with the */ 1045 /* "op" of the A-value and B-value, and queue the next */ 1046 /* instruction. "op" can be the sum, the difference, or */ 1047 /* the product. */ 1048 #define ARITH(op) \ 1049 switch (IR.Modifier) { \ 1050 case A: \ 1051 Core[((PC + WPB) % M)].ANumber = \ 1052 (IRB.ANumber op IRA.ANumber) % M \ 1053 ; \ 1054 break; \ 1055 case B: \ 1056 Core[((PC + WPB) % M)].BNumber = \ 1057 (IRB.BNumber op IRA.BNumber) % M \ 1058 ; \ 1059 break; \ 1060 case AB: \ 1061 Core[((PC + WPB) % M)].BNumber = \ 1062 (IRB.ANumber op IRA.BNumber) % M \ 1063 ; \ 1064 break; \ 1065 case BA: \ 1066 Core[((PC + WPB) % M)].ANumber = \ 1067 (IRB.BNumber op IRA.ANumber) % M \ 1068 ; \ 1069 break; \ 1070 case F: \ 1071 case I: \ 1072 Core[((PC + WPB) % M)].ANumber = \ 1073 (IRB.ANumber op IRA.ANumber) % M \ 1074 ; \ 1075 Core[((PC + WPB) % M)].BNumber = \ 1076 (IRB.BNumber op IRA.BNumber) % M \ 1077 ; \ 1078 break; \ 1079 case X: \ 1080 Core[((PC + WPB) % M)].BNumber = \ 1081 (IRB.ANumber op IRA.BNumber) % M \ 1082 ; \ 1083 Core[((PC + WPB) % M)].ANumber = \ 1084 (IRB.BNumber op IRA.ANumber) % M \ 1085 ; \ 1086 break; \ 1087 default: \ 1088 return(UNDEFINED); \ 1089 break; \ 1090 }; \ 1091 Queue(W, ((PC + 1) % M)); \ 1092 break; 1093 case ADD: ARITH(+) 1094 case SUB: ARITH(+ M -) 1095 case MUL: ARITH(*) 1096 /* DIV and MOD replace the B-target with the integral */ 1097 /* quotient (for DIV) or remainder (for MOD) of the B-value */ 1098 /* by the A-value, and queues the next instruction. */ 1099 /* Process is removed from task queue if A-value is zero */ 1100 #define ARITH_DIV(op) \ 1101 switch (IR.Modifier) { \ 1102 case A: \ 1103 if (IRA.ANumber != 0) \ 1104 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.ANumber; \ 1105 break; \ 1106 case B: \ 1107 if (IRA.BNumber != 0) \ 1108 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.BNumber; \ 1109 else goto noqueue; \ 1110 break; \ 1111 case AB: \ 1112 if (IRA.ANumber != 0) \ 1113 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.ANumber; \ 1114 else goto noqueue; \ 1115 break; \ 1116 case BA: \ 1117 if (IRA.BNumber != 0) \ 1118 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.BNumber; \ 1119 else goto noqueue; \ 1120 break; \ 1121 case F: \ 1122 case I: \ 1123 if (IRA.ANumber != 0) \ 1124 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.ANumber; \ 1125 if (IRA.BNumber != 0) \ 1126 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.BNumber; \ 1127 if ((IRA.ANumber == 0) || (IRA.BNumber == 0)) \ 1128 goto noqueue; \ 1129 break; \ 1130 case X: \ 1131 if (IRA.ANumber != 0) \ 1132 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.ANumber; \ 1133 if (IRA.BNumber != 0) \ 1134 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.BNumber; \ 1135 if ((IRA.ANumber == 0) || (IRA.BNumber == 0)) \ 1136 goto noqueue; \ 1137 break; \ 1138 default: \ 1139 return(UNDEFINED); \ 1140 break; \ 1141 }; \ 1142 Queue(W, ((PC + 1) % M)); \ 1143 noqueue: \ 1144 break; 1145 case DIV: ARITH_DIV(/) 1146 case MOD: ARITH_DIV(%) 1147 /* JMP queues the sum of the Program Counter and the */ 1148 /* A-pointer. */ 1149 case JMP: 1150 Queue(W, RPA); 1151 break; 1152 /* JMZ queues the sum of the Program Counter and Pointer A */ 1153 /* if the B-value is zero. Otherwise, it queues the next */ 1154 /* instruction. */ 1155 case JMZ: 1156 switch (IR.Modifier) { 1157 case A: 1158 case BA: 1159 if (IRB.ANumber == 0) { 1160 Queue(W, RPA); 1161 } else { 1162 Queue(W, ((PC + 1) % M)); 1163 }; 1164 break; 1165 case B: 1166 case AB: 1167 if (IRB.BNumber == 0) { 1168 Queue(W, RPA); 1169 } else { 1170 Queue(W, ((PC + 1) % M)); 1171 }; 1172 break; 1173 case F: 1174 case X: 1175 case I: 1176 if ( (IRB.ANumber == 0) && (IRB.BNumber == 0) ) { 1177 Queue(W, RPA); 1178 } else { 1179 Queue(W, ((PC + 1) % M)); 1180 }; 1181 break; 1182 default: 1183 return(UNDEFINED); 1184 break; 1185 }; 1186 break; 1187 /* JMN queues the sum of the Program Counter and Pointer A */ 1188 /* if the B-value is not zero. Otherwise, it queues the */ 1189 /* next instruction. */ 1190 case JMN: 1191 switch (IR.Modifier) { 1192 case A: 1193 case BA: 1194 if (IRB.ANumber != 0) { 1195 Queue(W, RPA); 1196 } else { 1197 Queue(W, ((PC + 1) % M)); 1198 }; 1199 break; 1200 case B: 1201 case AB: 1202 if (IRB.BNumber != 0) { 1203 Queue(W, RPA); 1204 } else { 1205 Queue(W, ((PC + 1) % M)); 1206 }; 1207 break; 1208 case F: 1209 case X: 1210 case I: 1211 if ( (IRB.ANumber != 0) || (IRB.BNumber != 0) ) { 1212 Queue(W, RPA); 1213 } else { 1214 Queue(W, ((PC + 1) % M)); 1215 }; 1216 break; 1217 default: 1218 return(UNDEFINED); 1219 break; 1220 }; 1221 break; 1222 /* DJN (Decrement Jump if Not zero) decrements the B-value */ 1223 /* and the B-target, then tests if the B-value is zero. If */ 1224 /* the result is not zero, the sum of the Program Counter */ 1225 /* and Pointer A is queued. Otherwise, the next */ 1226 /* instruction is queued. */ 1227 case DJN: 1228 switch (IR.Modifier) { 1229 case A: 1230 case BA: 1231 Core[((PC + WPB) % M)].ANumber = 1232 (Core[((PC + WPB) % M)].ANumber + M - 1) % M 1233 ; 1234 IRB.ANumber -= 1; 1235 if (IRB.ANumber != 0) { 1236 Queue(W, RPA); 1237 } else { 1238 Queue(W, ((PC + 1) % M)); 1239 }; 1240 break; 1241 case B: 1242 case AB: 1243 Core[((PC + WPB) % M)].BNumber = 1244 (Core[((PC + WPB) % M)].BNumber + M - 1) % M 1245 ; 1246 IRB.BNumber -= 1; 1247 if (IRB.BNumber != 0) { 1248 Queue(W, RPA); 1249 } else { 1250 Queue(W, ((PC + 1) % M)); 1251 }; 1252 break; 1253 case F: 1254 case X: 1255 case I: 1256 Core[((PC + WPB) % M)].ANumber = 1257 (Core[((PC + WPB) % M)].ANumber + M - 1) % M 1258 ; 1259 IRB.ANumber -= 1; 1260 Core[((PC + WPB) % M)].BNumber = 1261 (Core[((PC + WPB) % M)].BNumber + M - 1) % M 1262 ; 1263 IRB.BNumber -= 1; 1264 if ( (IRB.ANumber != 0) || (IRB.BNumber != 0) ) { 1265 Queue(W, RPA); 1266 } else { 1267 Queue(W, ((PC + 1) % M)); 1268 }; 1269 break; 1270 default: 1271 return(UNDEFINED); 1272 break; 1273 }; 1274 break; 1275 /* CMP compares the A-value and the B-value. If there are */ 1276 /* no differences, then the instruction after the next */ 1277 /* instruction is queued. Otherwise, the next instrution */ 1278 /* is queued. */ 1279 case CMP: 1280 switch (IR.Modifier) { 1281 case A: 1282 if (IRA.ANumber == IRB.ANumber) { 1283 Queue(W, ((PC + 2) % M)); 1284 } else { 1285 Queue(W, ((PC + 1) % M)); 1286 }; 1287 break; 1288 case B: 1289 if (IRA.BNumber == IRB.BNumber) { 1290 Queue(W, ((PC + 2) % M)); 1291 } else { 1292 Queue(W, ((PC + 1) % M)); 1293 }; 1294 break; 1295 case AB: 1296 if (IRA.ANumber == IRB.BNumber) { 1297 Queue(W, ((PC + 2) % M)); 1298 } else { 1299 Queue(W, ((PC + 1) % M)); 1300 }; 1301 break; 1302 case BA: 1303 if (IRA.BNumber == IRB.ANumber) { 1304 Queue(W, ((PC + 2) % M)); 1305 } else { 1306 Queue(W, ((PC + 1) % M)); 1307 }; 1308 break; 1309 case F: 1310 if ( (IRA.ANumber == IRB.ANumber) && 1311 (IRA.BNumber == IRB.BNumber) 1312 ) { 1313 Queue(W, ((PC + 2) % M)); 1314 } else { 1315 Queue(W, ((PC + 1) % M)); 1316 }; 1317 break; 1318 case X: 1319 if ( (IRA.ANumber == IRB.BNumber) && 1320 (IRA.BNumber == IRB.ANumber) 1321 ) { 1322 Queue(W, ((PC + 2) % M)); 1323 } else { 1324 Queue(W, ((PC + 1) % M)); 1325 }; 1326 break; 1327 case I: 1328 if ( (IRA.Opcode == IRB.Opcode) && 1329 (IRA.Modifier == IRB.Modifier) && 1330 (IRA.AMode == IRB.AMode) && 1331 (IRA.ANumber == IRB.ANumber) && 1332 (IRA.BMode == IRB.BMode) && 1333 (IRA.BNumber == IRB.BNumber) 1334 ) { 1335 Queue(W, ((PC + 2) % M)); 1336 } else { 1337 Queue(W, ((PC + 1) % M)); 1338 }; 1339 break; 1340 default: 1341 return(UNDEFINED); 1342 break; 1343 }; 1344 break; 1345 /* SLT (Skip if Less Than) queues the instruction after the */ 1346 /* next instruction if A-value is less than B-value. */ 1347 /* Otherwise, the next instruction is queued. Note that no */ 1348 /* value is less than zero because only positive values can */ 1349 /* be represented in core. */ 1350 case SLT : 1351 switch (IR.Modifier) { 1352 case A: 1353 if (IRA.ANumber < IRB.ANumber) { 1354 Queue(W, ((PC + 2) % M)); 1355 } else { 1356 Queue(W, ((PC + 1) % M)); 1357 }; 1358 break; 1359 case B: 1360 if (IRA.BNumber < IRB.BNumber) { 1361 Queue(W, ((PC + 2) % M)); 1362 } else { 1363 Queue(W, ((PC + 1) % M)); 1364 }; 1365 break; 1366 case AB: 1367 if (IRA.ANumber < IRB.BNumber) { 1368 Queue(W, ((PC + 2) % M)); 1369 } else { 1370 Queue(W, ((PC + 1) % M)); 1371 }; 1372 break; 1373 case BA: 1374 if (IRA.BNumber < IRB.ANumber) { 1375 Queue(W, ((PC + 2) % M)); 1376 } else { 1377 Queue(W, ((PC + 1) % M)); 1378 }; 1379 break; 1380 case F: 1381 case I: 1382 if ( (IRA.ANumber < IRB.ANumber) && 1383 (IRA.BNumber < IRB.BNumber) 1384 ) { 1385 Queue(W, ((PC + 2) % M)); 1386 } else { 1387 Queue(W, ((PC + 1) % M)); 1388 }; 1389 break; 1390 case X: 1391 if ( (IRA.ANumber < IRB.BNumber) && 1392 (IRA.BNumber < IRB.ANumber) 1393 ) { 1394 Queue(W, ((PC + 2) % M)); 1395 } else { 1396 Queue(W, ((PC + 1) % M)); 1397 }; 1398 break; 1399 default: 1400 return(UNDEFINED); 1401 break; 1402 }; 1403 break; 1404 /* SPL queues the next instruction and also queues the sum */ 1405 /* of the Program Counter and Pointer A. */ 1406 case SPL: 1407 Queue(W, ((PC + 1) % M)); 1408 Queue(W, RPA); 1409 break; 1410 /* Any other opcode is undefined. */ 1411 default: 1412 return(UNDEFINED); 1413 }; 1414 /* We are finished. */ 1415 return(SUCCESS); 1416 } 1417 6. Validation Suite 1418 6.1 Purpose and Requirements 1419 This validation suite exists to help developers test the compatibility 1420 of their Core War systems with the requirements set up in this standard. 1421 6.2 Assembly To Load File Test 1422 6.3 MARS tests 1423 6.3.1 DAT Tests 1424 6.3.2 MOV tests 1425 6.3.3 ADD tests 1426 6.3.4 SUB tests 1427 6.3.5 MUL tests 1428 6.3.6 DIV tests 1429 6.3.7 MOD tests 1430 6.3.8 JMP tests 1431 6.3.9 JMZ tests 1432 6.3.10 JMN tests 1433 6.3.11 DJN tests 1434 6.3.12 CMP tests 1435 6.3.13 SLT tests 1436 6.3.14 SPL tests 1437 7. Glossary and Index 1438 alphanumeric Any of the characters A-Za-z0-9 and the underscore. 1439 assembly file A file containing Redcode instructions. 1440 battle A contest between two or more warriors. 1441 core size See section 4.2 1442 Core War A game in which programs compete for control of a 1443 computer called a Memory Array Redcode Simulator. 1444 Core Wars More than one game of Core War. 1445 cycle See section 4.2 1446 Dwarf See sections 2.7 and 3.5 1447 initial instruction 1448 See section 4.2 1449 instruction A line of Redcode or object code indicating an action 1450 for MARS to execute. 1451 instruction limit 1452 See section 4.2 1453 loader A program or that part of a program which loads 1454 warriors into a MARS. 1455 load file A file containing a warrior's instructions in an 1456 assembled format. Any MARS program can be used with 1457 any and all Redcode assemblers which produce load 1458 files, allowing customized Core War systems. 1459 MARS An acronym for Memory Array Redcode Simulator. The 1460 computer in which Core War warriors run. 1461 newline A linefeed, carriage-return, or combination of linefeed 1462 and carriage-return. Whichever newline is native to the 1463 host operating system. 1464 object code The internal representation of a MARS instruction. 1465 read distance See section 4.2 1466 Redcode The assembly language of Core War. 1467 tournament A series of battles in which points, based upon the 1468 degree of success, are awarded for each battle and 1469 accumulated by each warrior (or programmer, depending 1470 upon the type of tournament). 1471 warrior A Redcode program. 1472 whitespace The space and tab character. 1473 write distance See section 4.2 1474 A. Differences Between Standards 1475 A.1 Purpose 1476 This appendix lists some of the major differences between this standard 1477 and those standards which preceded it. The purpose is to help those 1478 who are familiar with a previous standard or standards to quickly 1479 understand those items which are new or have changed. 1480 A.2 Changes 1481 A.2.1 Assembly Files 1482 A comma is required for operand separation. 1483 Parenthetical expressions are allowed. 1484 There is a new pseudo-opcode, ORG, for specifying the first logical 1485 instruction. 1486 There is a new operator, modulus '%', for determining the remainder 1487 of integer division. 1488 A.2.1.1 ICWS'86 to ICWS'94 Conversion 1489 If a modifier is missing, it is assembled according to conversion 1490 rules that depend on whether the ICWS'86 or '88 standard is emulated. 1491 By default, a MARS should use the ICWS'88 conversion rules. Emulation 1492 of ICWS'86 is optional. 1493 Opcode A-mode B-mode modifier 1494 ------------------------------------------------ 1495 DAT #$@<> #$@<> F 1496 MOV,CMP # #$@<> AB 1497 $@<> # B 1498 $@<> $@<> I 1499 ADD,SUB,MUL,DIV,MOD # #$@<> AB 1500 $@<> #$@<> B 1501 SLT # #$@<> AB 1502 $@<> #$@<> B 1503 JMP,JMZ,JMN,DJN,SPL #$@<> #$@<> B 1504 ------------------------------------------------ 1505 A.2.1.2 ICWS'88 to ICWS'94 Conversion 1506 The default modifier for ICWS'88 emulation is determined according 1507 to the table below. 1508 Opcode A-mode B-mode modifier 1509 ------------------------------------------------ 1510 DAT #$@<> #$@<> F 1511 MOV,CMP # #$@<> AB 1512 $@<> # B 1513 $@<> $@<> I 1514 ADD,SUB,MUL,DIV,MOD # #$@<> AB 1515 $@<> # B 1516 $@<> $@<> F 1517 SLT # #$@<> AB 1518 $@<> #$@<> B 1519 JMP,JMZ,JMN,DJN,SPL #$@<> #$@<> B 1520 ------------------------------------------------ 1521 A.2.2 Load Files 1522 A load file format is specified for the first time. (An object code 1523 did exist for ICWS'86). 1524 A.2.3 MARS 1525 There are no illegal instructions. 1526 MUL, DIV, and MOD have been added. 1527 Opcode modifiers have been added. 1528 Read and Write distance limitations have been imposed.


← Back to the list of examples
In this example, you'll learn how to easily define your own icons for use by the markers you put on the map.
View example on a separate page →
To make a custom icon, we usually need two images — the actual icon image and the image of its shadow. For this example, we took the Leaflet logo and created four images out of it — 3 leaf images of different colors and one shadow image for the three:
The white area in the images is actually transparent, and they are saved in the PNG24 format. Notice there's some excessive area on the left of the shadow image — its cropped in such way that if you align the icon and the shadow images on top of each other, the top left corners are in the same spot.
The default marker icons in Leaflet are defined by the L.Icon class. Its instance (new L.Icon()
) is then set by default in the L.Marker
options. So how do we define our own icon class? Inherit from L.Icon
! It's really easy in Leaflet:
var LeafIcon = L.Icon.extend({
iconUrl: '../docs/images/leaf-green.png',
shadowUrl: '../docs/images/leaf-shadow.png',
iconSize: new L.Point(38, 95),
shadowSize: new L.Point(68, 95),
iconAnchor: new L.Point(22, 94),
popupAnchor: new L.Point(-3, -76)
});
Now we've defined a green leaf icon class. The iconSize
and shadowSize
properties are the sizes of the corresponding images in pixels, the iconAnchor
property is the coordinates of the "tip" of our icon, and the popupAnchor
property points to a point from which a marker popup would open relative to the iconAnchor
point.
To use our newly created icon class in a marker, we need to create an instance of that class and pass it to the marker constructor in the options:
var greenIcon = new LeafIcon(),
marker = new L.Marker(new L.LatLng(51.5, -0.09), {icon: greenIcon});
Awesome, it works! But what about the orange and the red ones? You could repeat the whole process above for each of them, but there's a much easier way. Notice that these icons would have the same properties except for one — the iconUrl. Because it's a frequent case, the L.Icon
constructor has an optional argument — an iconUrl to replace the defined one. Let's see:
var greenIcon = new LeafIcon(),
redIcon = new LeafIcon('../docs/images/leaf-red.png'),
orangeIcon = new LeafIcon('../docs/images/leaf-orange.png');
Now we can use all the three icons:
var marker1 = new L.Marker(new L.LatLng(51.5, -0.09), {icon: greenIcon}),
marker2 = new L.Marker(new L.LatLng(51.495, -0.083), {icon: redIcon}),
marker3 = new L.Marker(new L.LatLng(51.49, -0.1), {icon: orangeIcon});
marker1.bindPopup("I am a green leaf.");
marker2.bindPopup("I am a red leaf.");
marker3.bindPopup("I am an orange leaf.");
map.addLayer(marker1).addLayer(marker2).addLayer(marker3);
That's all. Now take a look at the full example, the L.Icon docs, or browse other examples.
© 2011 CloudMade. Map data © 2011 OpenStreetMap contributors, CC-BY-SA.


When you work with us, you are part of a team of committed collaborators. All aspects of of our software development process are integrated, interactive and agile
Our approach unifies design, development and project management to create exceptonal products.
We start each project by understanding your business goals, the user's needs and the product requirements.
Then we help translate into effective and elegant solutions.
Our design practice offers a full range of services including brand strategy, interaction and visual design and user experience testing. Throughout your project, our designers create and implement visual design and workflows, solicit user feedback and work with you to make sure what gets built is what is needed.
All engineers are fluent in the latest enterprise, mobile and web development technologies. They collaborate with your team to write, and improve code on a daily basis, using proven practices such as test-driven development and pair programming.
Planning and development is iterative. Because we are constantly coding and testing, the products we build are always ready to go live. This iterative process allows for changes as business requirements evolve.


|
JavaTM 2 Platform Standard Ed. 5.0 |
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object java.text.AttributedCharacterIterator.Attribute java.awt.font.TextAttribute
public final class TextAttribute
The TextAttribute
class defines attribute keys and
attribute values used for text rendering.
TextAttribute
instances are used as attribute keys to
identify attributes in
AttributedCharacterIterator
,
Font
, and other classes handling text
attributes. Other constants defined in this class are used
as attribute values.
For each text attribute, the documentation describes:
null
value).
null
or not of the proper type
then it has the default effect. The effect of a particular value
can be interpolated, especially in the case of multiple master
fonts. This interpolation is done based on the nearest defined
constants above and below the request:interpolation = (request - below)/(above - below);
AttributedCharacterIterator
,
Font
,
Serialized Form| Field Summary | |
|---|---|
static TextAttribute |
BACKGROUND
Attribute key for the background Paint adornment. |
static TextAttribute |
BIDI_EMBEDDING
Attribute key for the embedding level for nested bidirectional runs. |
static TextAttribute |
CHAR_REPLACEMENT
Attribute key for a user_defined glyph to display in the text in lieu of a character. |
static TextAttribute |
FAMILY
Attribute key for the unlocalized font family name. |
static TextAttribute |
FONT
Attribute key for the font to use to render text. |
static TextAttribute |
FOREGROUND
Attribute key for the foreground paint adornment. |
static TextAttribute |
INPUT_METHOD_HIGHLIGHT
Attribute key for input method highlight styles. |
static TextAttribute |
INPUT_METHOD_UNDERLINE
Attribute key for input method underline adornments. |
static TextAttribute |
JUSTIFICATION
Attribute key for the justification of a paragraph. |
static Float |
JUSTIFICATION_FULL
Justify the line to the full requested width. |
static Float |
JUSTIFICATION_NONE
Do not allow the line to be justified. |
static TextAttribute |
NUMERIC_SHAPING
Attribute key for converting ASCII decimal digits to other decimal ranges. |
static TextAttribute |
POSTURE
Attribute key for the posture of a font. |
static Float |
POSTURE_OBLIQUE
The standard italic posture. |
static Float |
POSTURE_REGULAR
The standard posture, upright. |
static TextAttribute |
RUN_DIRECTION
Attribute key for the run direction of the line. |
static Boolean |
RUN_DIRECTION_LTR
Left-to-right run direction. |
static Boolean |
RUN_DIRECTION_RTL
Right-to-left run direction. |
static TextAttribute |
SIZE
Attribute key for the font size. |
static TextAttribute |
STRIKETHROUGH
Attribute key for the strikethrough adornment. |
static Boolean |
STRIKETHROUGH_ON
A single strikethrough. |
static TextAttribute |
SUPERSCRIPT
Attribute key for super and subscripting. |
static Integer |
SUPERSCRIPT_SUB
Standard subscript. |
static Integer |
SUPERSCRIPT_SUPER
Standard superscript. |
static TextAttribute |
SWAP_COLORS
Attribute key for swapping foreground and background Paints (or Colors). |
static Boolean |
SWAP_COLORS_ON
Swap foreground and background. |
static TextAttribute |
TRANSFORM
Attribute key for the transform of a font. |
static TextAttribute |
UNDERLINE
Attribute key for underline adornments. |
static Integer |
UNDERLINE_LOW_DASHED
Single pixel dashed low underline. |
static Integer |
UNDERLINE_LOW_DOTTED
Single pixel dotted low underline. |
static Integer |
UNDERLINE_LOW_GRAY
Double pixel gray low underline. |
static Integer |
UNDERLINE_LOW_ONE_PIXEL
Single pixel solid low underline. |
static Integer |
UNDERLINE_LOW_TWO_PIXEL
Double pixel solid low underline. |
static Integer |
UNDERLINE_ON
Standard underline at the roman baseline for roman text, and below the decenders for other text. |
static TextAttribute |
WEIGHT
Attribute key for the weight of a font. |
static Float |
WEIGHT_BOLD
The standard bold weight. |
static Float |
WEIGHT_DEMIBOLD
A moderately lighter weight than BOLD. |
static Float |
WEIGHT_DEMILIGHT
An intermediate weight between LIGHT and STANDARD. |
static Float |
WEIGHT_EXTRA_LIGHT
The lightest predefined weight. |
static Float |
WEIGHT_EXTRABOLD
An extra heavy weight. |
static Float |
WEIGHT_HEAVY
A moderately heavier weight than BOLD. |
static Float |
WEIGHT_LIGHT
The standard light weight. |
static Float |
WEIGHT_MEDIUM
An intermediate weight between the REGULAR and BOLD weights. |
static Float |
WEIGHT_REGULAR
The standard weight. |
static Float |
WEIGHT_SEMIBOLD
A moderately heavier weight than REGULAR. |
static Float |
WEIGHT_ULTRABOLD
The heaviest predefined weight. |
static TextAttribute |
WIDTH
Attribute key for the width of a font. |
static Float |
WIDTH_CONDENSED
The most condensed predefined width. |
static Float |
WIDTH_EXTENDED
The most extended predefined width. |
static Float |
WIDTH_REGULAR
The standard width. |
static Float |
WIDTH_SEMI_CONDENSED
A moderately condensed width. |
static Float |
WIDTH_SEMI_EXTENDED
A moderately extended width. |
| Fields inherited from class java.text.AttributedCharacterIterator.Attribute |
|---|
INPUT_METHOD_SEGMENT, LANGUAGE, READING |
| Constructor Summary | |
|---|---|
protected |
TextAttribute(String name)
Constructs a TextAttribute with the specified name. |
| Method Summary | |
|---|---|
protected Object |
readResolve()
Resolves instances being deserialized to the predefined constants. |
| Methods inherited from class java.text.AttributedCharacterIterator.Attribute |
|---|
equals, getName, hashCode, toString |
| Methods inherited from class java.lang.Object |
|---|
clone, finalize, getClass, notify, notifyAll, wait, wait, wait |
| Field Detail |
|---|
public static final TextAttribute FAMILY
Key |
FAMILY |
|---|---|
Value |
String |
Constants |
"Serif", "SansSerif" |
Default |
Host default; |
Description |
The name of the font family. If the family name is not found, the default font is used. The name should not be the full font name or specify other attributes (such as the name "Helvetica Bold"). Such names might result in the default font if the name does not match a known family name. |
public static final TextAttribute WEIGHT
Key |
WEIGHT |
|---|---|
Value |
Float |
Constants |
WEIGHT_EXTRA_LIGHT = 0.5, WEIGHT_LIGHT = 0.75, WEIGHT_DEMILIGHT = 0.875, WEIGHT_REGULAR = 1.0, WEIGHT_SEMIBOLD = 1.25, WEIGHT_MEDIUM = 1.5, WEIGHT_DEMIBOLD = 1.75, WEIGHT_BOLD = 2.0, WEIGHT_HEAVY = 2.25, WEIGHT_EXTRABOLD = 2.5, WEIGHT_ULTRABOLD = 2.75 |
Default |
WEIGHT_REGULAR |
Description |
The value is roughly the ratio of the stem width to that of the regular weight. If the font has a different value for specific constants, then the value is interpolated as described in the class description. |
Fallback |
Currently none. However, in the future, shape
manipulations might be available to simulate weight variations for fonts that don't have them. |
public static final Float WEIGHT_EXTRA_LIGHT
WEIGHT
public static final Float WEIGHT_LIGHT
WEIGHT
public static final Float WEIGHT_DEMILIGHT
WEIGHT
public static final Float WEIGHT_REGULAR
WEIGHT
public static final Float WEIGHT_SEMIBOLD
WEIGHT
public static final Float WEIGHT_MEDIUM
WEIGHT
public static final Float WEIGHT_DEMIBOLD
WEIGHT
public static final Float WEIGHT_BOLD
WEIGHT
public static final Float WEIGHT_HEAVY
WEIGHT
public static final Float WEIGHT_EXTRABOLD
WEIGHT
public static final Float WEIGHT_ULTRABOLD
WEIGHT
public static final TextAttribute WIDTH
Key |
WIDTH |
|---|---|
Value |
Float |
Constants |
WIDTH_CONDENSED = 0.75, WIDTH_SEMI_CONDENSED = 0.875, WIDTH_REGULAR = 1.0, WIDTH_SEMI_EXTENDED = 1.25, WIDTH_EXTENDED = 1.5 |
Default |
WIDTH_REGULAR |
Description |
The value is roughly the ratio of the advance width to that of the regular width. If the font has a different value for specific constants, then the value is interpolated as described in the class description. |
Fallback |
If a Narrow font is available and matches, use that. Otherwise scale with a transform based on the value. |
public static final Float WIDTH_CONDENSED
WIDTH
public static final Float WIDTH_SEMI_CONDENSED
WIDTH
public static final Float WIDTH_REGULAR
WIDTH
public static final Float WIDTH_SEMI_EXTENDED
WIDTH
public static final Float WIDTH_EXTENDED
WIDTH
public static final TextAttribute POSTURE
Key |
POSTURE |
|---|---|
Value |
Float |
Constants |
POSTURE_REGULAR = 0, POSTURE_OBLIQUE = 0.20 |
Default |
POSTURE_REGULAR |
Description |
The value is interpreted generally as a skew slope,
positive leans to the right. If the font has a different value for
specific constants, then the value is interpolated as described in
the class description. With fonts that have italic faces, not only
the skew of the character changes, but also the letter shapes
might change. Notes: To set the value by angle, use: value = new Float(Math.tan(Math.PI*degrees/180.0) To determine the angle from the value, use: angle = Math.atan(value.floatValue())*180/Math.PI |
Fallback |
If an Oblique font is available and matches, use that. Otherwise skew with a transform using the posture value interpreted as run/rise. |
Font.getItalicAngle()
public static final Float POSTURE_REGULAR
POSTURE
public static final Float POSTURE_OBLIQUE
POSTURE
public static final TextAttribute SIZE
Key |
SIZE |
|---|---|
Value |
Float |
Default |
from System Properties |
Description |
Represents point size. Note that the appearance and metrics of a 12pt font with a 2X transform might be different than that of a 24 point font with no transform. |
Fallback |
Scale to provided size. |
public static final TextAttribute TRANSFORM
Key |
TRANSFORM |
|---|---|
Value |
TransformAttribute |
Default |
Identity transform |
Description |
Used to transform glyphs rendered by this font. The primary intent is to support scaling, skewing, and translation. In general, large rotations do not produce very useful results. The transform modifies both the glyph and the advance. The translations in the transform are interpreted as a ratio of the point size. That is, with a point size of 12, a translation of 0.5 results in a movement of 6 points. The advance point of the transformed glyph is the transform of the advance point projected onto the baseline. If the advance ends up to the left (top) of the glyph origin, the two points are swapped.
Example one: The point size is 20, the original advance is 10.0, and the transform is a 60 degree counterclockwise rotation plus an offset up and to the right of 0.1, -0.1. The translation results in an offset of <2.0, -2.0>. The original advance point is <10.0, 0.0>; after the rotation it is <6.0, -8.0>; when adding the offset this becomes <8.0,-10.0>, when projecting on the (horizontal) baseline this becomes the new advance point: <8.0, 0.0>. The advance width is the distance from the origin to the advance point: 8.0. The rotated glyph is rendered two points up and to the right of its origin and rotated. This does not affect the baseline for subsequent glyphs. |
public static final TextAttribute SUPERSCRIPT
Key |
SUPERSCRIPT |
|---|---|
Value |
Integer |
Constants |
SUPERSCRIPT_NONE = 0, SUPERSCRIPT_SUPER = 1, SUPERSCRIPT_SUB = -1 |
Default |
SUPERSCRIPT_NONE |
Description |
Requests that the font display the characters with glyphs at a particular superscript level: 0 = none, 1 = superscript, 2 = superscript of superscript,...-1 = subscript, -2 = subscript of subscript,... Requests that the font display text using default superscript (or subscript) glyphs and/or scaling. |
Fallback |
Use transform with translation of +/-1/2 and scale
of 2/3, progressively for each level. That is, for the transform at
level N (with N != 0): offset = sign(N)*1/2*(2/3)^(abs(N)-1) scale = (2/3)^abs(N) |
public static final Integer SUPERSCRIPT_SUPER
SUPERSCRIPT
public static final Integer SUPERSCRIPT_SUB
SUPERSCRIPT
public static final TextAttribute FONT
Key |
FONT |
|---|---|
Value |
Font |
Default |
None, perform default resolution |
Description |
A way for users to override the resolution of font
attributes into a Font , or force use of a particular
Font instance.
This also allows users to specify subclasses of Font in
cases where a Font can be subclassed. |
public static final TextAttribute CHAR_REPLACEMENT
Key |
CHAR_REPLACEMENT |
|---|---|
Value |
GraphicAttribute |
Description |
Allows the user to specify an empty position plus
metric information. This method is used to reserve space for a graphic
or other embedded component. Required for
correct BIDI position of 'inline' components within a line. An optional
convenience method allows drawing for simple cases. Follows the
Microsoft model: the character that this is applied to should be
\uFFFC . |
public static final TextAttribute FOREGROUND
Key |
FOREGROUND |
|---|---|
Value |
Paint |
Default |
Color.black |
Description |
Specify the foreground Paint (or Color) of the text. |
public static final TextAttribute BACKGROUND
Key |
BACKGROUND |
|---|---|
Value |
Paint |
Default |
null |
Description |
Specify the background Paint (or Color) of the text. |
public static final TextAttribute UNDERLINE
Key |
UNDERLINE |
|---|---|
Value |
Integer |
Constants |
UNDERLINE_ON = 0 |
Default |
none |
Description |
An embellishment added to the glyphs rendered by a font. |
Fallback |
public static final Integer UNDERLINE_ON
UNDERLINE
public static final TextAttribute STRIKETHROUGH
Key |
STRIKETHROUGH |
|---|---|
Value |
Boolean |
Constants |
true = on, false = off |
Default |
off |
Description |
An embellishment added to the glyphs rendered by a font. |
public static final Boolean STRIKETHROUGH_ON
STRIKETHROUGH
public static final TextAttribute RUN_DIRECTION
Key |
RUN_DIRECTION |
|---|---|
Value |
Boolean |
Constants |
RUN_DIRECTION_LTR = true, RUN_DIRECTION_RTL = false |
Default |
Use the default Unicode base direction from the BIDI algorithm. |
Description |
Specifies which base run direction to use when
positioning mixed directional runs within a paragraph. If this value is
RUN_DIRECTION_DEFAULT, This attribute should have the same value over the whole paragraph. |
public static final Boolean RUN_DIRECTION_LTR
RUN_DIRECTION
public static final Boolean RUN_DIRECTION_RTL
RUN_DIRECTION
public static final TextAttribute BIDI_EMBEDDING
Key |
BIDI_EMBEDDING |
|---|---|
Value |
Integer |
Limits |
Positive values 1 through 61 are embedding
levels, negative values through -61 are override levels |
Default |
Use standard BIDI to compute levels from formatting characters in the text. |
Description |
Specifies the bidi embedding level of the character. When this attribute is present anywhere in a paragraph, then the Unicode characters RLO, LRO, RLE, LRE, PDF are disregarded in the BIDI analysis of that paragraph. See the Unicode Standard v. 2.0, section 3-11. |
public static final TextAttribute JUSTIFICATION
Key |
JUSTIFICATION |
|---|---|
Value |
Float |
Limits |
0.0 through1.0 |
Default |
1.0 |
Description |
Specifies which fraction of the extra space to use when justification is requested. For example, if the line is 50 points wide and the margins are 70 points apart, a value of 0.5 means that the line is padded to reach a width of 60 points. This attribute should have the same value over the whole paragraph. |
public static final Float JUSTIFICATION_FULL
JUSTIFICATION
public static final Float JUSTIFICATION_NONE
JUSTIFICATION
public static final TextAttribute INPUT_METHOD_HIGHLIGHT
Values are instances of
InputMethodHighlight
.
These instances should be wrapped in
Annotation
instances
if segments need to be highlighted separately.
Input method highlights are used while text is being composed using an input method. Text editing components should retain them even if they generally only deal with unstyled text, and make them available to the drawing routines.
InputMethodHighlight
public static final TextAttribute INPUT_METHOD_UNDERLINE
Key |
INPUT_METHOD_UNDERLINE |
|---|---|
Value |
Integer |
Constants |
UNDERLINE_LOW_ONE_PIXEL, UNDERLINE_LOW_TWO_PIXEL, UNDERLINE_LOW_DOTTED, UNDERLINE_LOW_GRAY, UNDERLINE_LOW_DASHED |
Default |
no underline |
public static final Integer UNDERLINE_LOW_ONE_PIXEL
INPUT_METHOD_UNDERLINE
public static final Integer UNDERLINE_LOW_TWO_PIXEL
INPUT_METHOD_UNDERLINE
public static final Integer UNDERLINE_LOW_DOTTED
INPUT_METHOD_UNDERLINE
public static final Integer UNDERLINE_LOW_GRAY
INPUT_METHOD_UNDERLINE
public static final Integer UNDERLINE_LOW_DASHED
INPUT_METHOD_UNDERLINE
public static final TextAttribute SWAP_COLORS
Values are instances of Boolean
.
The default is not to swap the foreground and background.
If the foreground and background attributes are both defined,
this causes them to be swapped when rendering text. If either is
defaulted, the exact effect is undefined--generally it will produce
an 'inverted' appearance.
public static final Boolean SWAP_COLORS_ON
public static final TextAttribute NUMERIC_SHAPING
Values are instances of NumericShaping
.
The default is not to perform numeric shaping.
| Constructor Detail |
|---|
protected TextAttribute(String name)
TextAttribute
with the specified name.
name
- the attribute name to assign to this
TextAttribute
| Method Detail |
|---|
protected Object readResolve() throws InvalidObjectException
readResolve
in class AttributedCharacterIterator.Attribute
InvalidObjectException
|
JavaTM 2 Platform Standard Ed. 5.0 |
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Copyright © 2004, 2010 Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.


This page is a util page to use with unit test UrlCodingTest to test server side
uri encoding and decoding. As there oddly enough exists no java method to decode any of the
three options to encode parameters in JavaScript(escape, encodeURI and encodeURIComponent), there is a
proprietary implementation. But this requires JavaScript functions encodeURIComponent
and decodeURIComponent.
So this page has two uses:
1) To generate string that are uriencoded in browser. Use unit test to decode them
and test that the result string is the same used as input in the browser.
2) Use server side code to uri encode below large string. Paste the resulting string into
variable 'encodedServerSide' and there should be a true output in the second text area.


|
ViennaCL - The Vienna Computing Library
1.5.2
|
A proxy class for a single element of a vector or matrix. This proxy should not be noticed by end-users of the library. More...
#include <entry_proxy.hpp>
Public Types | |
| typedef viennacl::backend::mem_handle | handle_type |
Public Member Functions | |
| const_entry_proxy (vcl_size_t mem_offset, handle_type const &mem_handle) | |
| The constructor for the proxy class. Declared explicit to avoid any surprises created by the compiler. | |
| operator SCALARTYPE () const | |
| Conversion to a CPU floating point value. | |
| unsigned int | index () const |
| Returns the index of the represented element. | |
| handle_type const & | handle () const |
| Returns the memory handle. |
A proxy class for a single element of a vector or matrix. This proxy should not be noticed by end-users of the library.
This proxy provides access to a single entry of a vector. If the element is assigned to a GPU object, no unnecessary transfers to the CPU and back to GPU are initiated.
| SCALARTYPE | Either float or double |
| const_entry_proxy | ( | vcl_size_t | mem_offset, |
| handle_type const & | mem_handle | ||
| ) | [inline, explicit] |
The constructor for the proxy class. Declared explicit to avoid any surprises created by the compiler.
| mem_offset | The memory offset in multiples of sizeof(SCALARTYPE) relative to the memory pointed to by the handle |
| mem_handle | A viennacl::ocl::handle for the memory buffer on the GPU. |
| handle_type const& handle | ( | ) | const [inline] |
Returns the memory handle.
| unsigned int index | ( | ) | const [inline] |
Returns the index of the represented element.
| operator SCALARTYPE | ( | ) | const [inline] |
Conversion to a CPU floating point value.
This conversion allows to write something like double test = vector(4); However, one has to keep in mind that CPU<->GPU transfers are very slow compared to CPU<->CPU operations.


Publications
A. Ayanzadeh, H.O. Yağar, Ö.Y. Özuysal, D.P Okvur, B. U. Töreyin, D. Ünay and S. Önal, " Cell Segmentation of 2D Phase-Contrast Microscopy Images with Deep Learning Method", IEEE - TıpTekno, Kuşadası, 2019
R. C. Binici, U. ¸Sahin, A. Ayanzadeh, B. U. Töreyin, S. Önal, D. P. Okvur, Ö.Y. Özuysal and D. Ünay, " Automated Segmentation of Cells in Phase Contrast Optical Microscopy Time Series Images ", IEEE - TıpTekno, Kuşadası, 2019.
Ayanzadeh, Aydin, Shokoufeh Yazdanian, and Ehsan Shahamatnia. "A New Class of Scaling Matrices for Scaled Trust Region Algorithms." arXiv preprint arXiv:1904.09209 (2019).
Ayanzadeh, A., Pourghaemi, H., & Seyfari, Y. (2015, November). A modified ant colony based approach to digital image edge detection., IEEE Conference Publications, In 2015 2nd International Conference on Knowledge-Based Engineering and Innovation (KBEI) (pp. 504-509). IEEE.
Safar Irandoust-Pakchin, Aydin Ayanzadeh, Siamak Beikzadeh. "Gaussian Three-Dimensional kernel SVM for Edge Detection Applications ", the International Conference on New Research of Electrical Engineering and Computer Science ( September 2015).
Published conference paper in the International Congress on Management, Economy and Business Development 28/10/2015, with title: The Investigation and Ranking of The Effective Factors on Customers’ Loyalty of Laleh-Park using AHP
Preprints
Ayanzadeh, A.; Vahidnia, S.. Modified Deep Neural Networks for Dog Breeds Identification. Preprints 2018,<PHONE_NUMBER> (doi: 10.20944/preprints201812.0232.v1).
Contact information: ayanzadeh17@itu.edu.tr.


Next: terpri, Previous: read-char, Up: Streams Dictionary
read-char-no-hang
&optional input-stream eof-error-p
eof-value recursive-p ⇒ char
input-stream – an input stream designator. The default is standard input.
eof-error-p—a generalized boolean. The default is true.
eof-value—an object. The default is nil.
recursive-p—a generalized boolean. The default is false.
char—a character or nil or the eof-value.
read-char-no-hang returns a character from input-stream if such a character is available. If no character is available, read-char-no-hang returns nil.
If recursive-p is true, this call is expected to be embedded in a higher-level call to read or a similar function used by the Lisp reader.
If an end of file_2 occurs and eof-error-p is false, eof-value is returned.
;; This code assumes an implementation in which a newline is not ;; required to terminate input from the console. (defun test-it () (unread-char (read-char)) (list (read-char-no-hang) (read-char-no-hang) (read-char-no-hang))) ⇒ TEST-IT ;; Implementation A, where a Newline is not required to terminate ;; interactive input on the console. (test-it) |> |>>a<<| ⇒ (#\a NIL NIL) ;; Implementation B, where a Newline is required to terminate ;; interactive input on the console, and where that Newline remains ;; on the input stream. (test-it) |> |>>a[<–~]<<| ⇒ (#\a #\Newline NIL)
*standard-input*, *terminal-io*.
If an end of file_2 occurs when eof-error-p is true, an error of type end-of-file is signaled .
read-char-no-hang is exactly like read-char, except that if it would be necessary to wait in order to get a character (as from a keyboard), nil is immediately returned without waiting.
Next: terpri, Previous: read-char, Up: Streams Dictionary


|
libSMCE 0.0
SmartCar Platform Emulator library
|
#include <SD.h>
Public Member Functions | |
| bool | begin (std::uint16_t cspin=0) |
| bool | exists (const char *path) |
| File | open (const char *path, SMCE_FileOpenMode mode=FILE_READ) |
| bool | remove (const char *path) |
| bool | mkdir (const char *path) |
| bool | rmdir (const char *path) |
Friends | |
| class | SMCE_SDImpl |
| bool SDClass::begin | ( | std::uint16_t | cspin = 0 | ) |
| bool SDClass::exists | ( | const char * | path | ) |
| bool SDClass::mkdir | ( | const char * | path | ) |
| File SDClass::open | ( | const char * | path, |
| SMCE_FileOpenMode | mode = FILE_READ |
||
| ) |
| bool SDClass::remove | ( | const char * | path | ) |
| bool SDClass::rmdir | ( | const char * | path | ) |
|
friend |


class="no-js"<% } %> lang="">
This generator is a fork of generator-webapp. Here's a list of some of the more significant additions and modificaitons:
As you can see, this template does not include any significant boilerplate markup, and the .scss files are completely empty. My goal is to provide only the bare necessities. Typical project requirements and conventions vary wildly from organization to organization, so we shouldn't have to worry about deleting 800 lines of unused code every time we start a new project.
If you have any suggestions for improvement or if you encounter a bug, please create a pull request or file an issue on GitHub.


La solicitud para analizar el contenido de la página Web se realizó el {{ webPageRequestItem.requestDate | date: 'dd/MM/yyyy' }}, a las {{ webPageRequestItem.requestDate | date: 'HH:mm:ss' }}
{{ webPageRequestItem.webPageAnalysis.text }}
Named entities specify things such as persons, places and organizations. AlchemyAPI's named entity extraction is capable of identifying people, companies, organizations, cities, geographic features and other typed entities from your HTML, text or web-based content.
Entity extraction can add a wealth of semantic knowledge to your content to help you quickly understand the subject of the text. It is one of the most common starting points for using natural language processing techniques to enrich your content.
| Entidad | Tipo de entidad | Relevancia |
|---|---|---|
| {{entity.text }}{{ entity.count }} | {{ entity.type }} | {{ entity.relevance }} |
Keywords are the important topics in your content and can be used to index data, generate tag clouds or for searching. AlchemyAPI's keyword extraction API is capable of finding keywords in text and ranking them. The sentiment can then be determined for each extracted keyword.
The keyword extraction API works on URLs, HTML documents and plain text. Just like every other feature, AlchemyAPI automatically detects the language of the content and then performs the appropriate analysis.
| Palabra clave | Relevancia |
|---|---|
| {{ keyword.text }} | {{ keyword.relevance }} |


Zelda Slumbers in this Realm
Everything you would like to know about The Legend of Zelda video game series you can find here! From the characters, to creatures, to the level environment, a plethora of information awaits!
...no, Zelda is not the guy
The Legend of Zelda: Majora's Mask was released in 2000 for the Nintendo 64 and 2003 for the Gamecube. The game is set in an alternate reality called Termina doomed to be destroyed by the moon in 3 days. The player is tasked to save Termina from the Skull Kid who took possesion of a powerful artifacts called Majora's Mask.
The Legend of Zelda: Breath of the Wild was released on 2017 for the Nintendo Switch. The game is set in an apocalyptic Hyrule, with Link waking up from a 100 year slumber with no memories. The player is tasked with saving Zelda from Calamity Ganon. This game is the first to utilize an open-air world, very much unlike its predecessors.
The Legend of Zelda: Ocarina of Time was released on 1998 as the first 3D Zelda game. The game is set in Hyrule, with Link tasked to defeat the dark king Ganondorf. Link uses the power to time travel to gain the aid of sages to seal away Ganondorf.


SivaSoft (Training & Development) is An ISO 9001:2008 CERTIFIED Company established in the year 2010 and Expertise in classroom, online, Corporate, weekends & Weekends Workshops training source for quality with realtime examples at a reasonable cost. Our team designed the course modules based on the latest trends..
SivaSoft (Training & Development) is An ISO 9001:2008 CERTIFIED Company established in the year 2010 and Expertise in classroom, online, Corporate, weekends & Weekends Workshops training source for quality with realtime examples at a reasonable cost. Our team designed the course modules based on the latest trends..
SivaSoft (Training & Development) is An ISO 9001:2008 CERTIFIED Company established in the year 2010 and Expertise in classroom, online, Corporate, weekends & Weekends Workshops training source for quality with realtime examples at a reasonable cost. Our team designed the course modules based on the latest trends..


Contact
Blog
Tutorials
Projects
About
Welcome to we_create!
Please visit our new website, https://www.wcaug.com. It is a much nicer, more updated website that will be much more interesting to you.
Projects
Project A
Project B
Project C
Tutorials
Tutorial A
Tutorial B
Tutorial C
Blog
Blog A
Blog B
Blog C


As Carepoynt Support, I want to give poynts to a member manually with a reason why.
As Carepoynt Support, I want to give poynt to an enterprise with a reason why (in case they have trouble buying poynts) and we can somehow invoice them at a later time.
As Carepoynt Support, I want to lock a user out of the system if they are abusing poynts.
As Carepoynt Support, I want to look up a member profile and account activity.


Sorry, Javascript is required
This viewer is an entirely client-side app which makes extensive use of Javascript for its functionality. Javascript must be enabled for it to work.
You can also view the Dart source code for this app, or check out the library that backs it.