102 lines
		
	
	
		
			3.6 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			102 lines
		
	
	
		
			3.6 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| # Emulator events
 | |
| 
 | |
| The events processed by the emulator are described in each model.
 | |
| Unrecognized events will cause a panic and stop the emulator in most
 | |
| cases.
 | |
| 
 | |
| The events may have additional arguments in the payload, which are also
 | |
| described. To this end, a simple language was created to specify the
 | |
| format of each event in a concise declaration.
 | |
| 
 | |
| Additionally, a printf-like string is declared for each event, so they
 | |
| can be explained in plain English. The values of the arguments are also
 | |
| substituted in the description of the event following a extended printf
 | |
| format described below.
 | |
| 
 | |
| ## Event format
 | |
| 
 | |
| The events are defined by a small language that defines the MCV of an event, if
 | |
| is a jumbo and the arguments in the payload (if any).
 | |
| 
 | |
| The grammar of this language is as follows in [ABNF][abnf].
 | |
| 
 | |
| [abnf]: https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form
 | |
| 
 | |
| ```ABNF
 | |
| event-definition = event-mcv event-type [ "(" argument-list ")" ]
 | |
| event-mcv = VCHAR VCHAR VCHAR
 | |
| event-type = [ '+' ]
 | |
| argument-list = argument-type " " argument-name [ ", " argument-list ]
 | |
| argument-name = 1*(CHAR / DIGIT)
 | |
| argument-type = type-signed | type-unsigned | type-string
 | |
| type-signed = "i8" | "i16" | "i32" | "i64"
 | |
| type-unsigned = "u8" | "u16" | "u32" | "u64"
 | |
| type-string = "str"
 | |
| ```
 | |
| 
 | |
| The `event-type` defines the type of event. Using the symbol `+` defines
 | |
| the event as jumbo. Otherwise, if not given it is considered a normal
 | |
| event.
 | |
| 
 | |
| Here are some examples:
 | |
| 
 | |
| - `OHp`: A normal event with `OHp` MCV and no payload.
 | |
| 
 | |
| - `OAs(i32 cpu)`: A normal event with `OAs` MCV that has the cpu stored in
 | |
|   the payload as a 32 bits signed integer.
 | |
| 
 | |
| - `OHC(i32 cpu, u64 tag)`: A normal event with `OHC` MCV that has two
 | |
|   arguments in the payload: the cpu stored as a 32 bit signed integer,
 | |
|   and a tag stored as a 64 bit unsigned integer.
 | |
| 
 | |
| - `VYc+(u32 typeid, str label)`: A jumbo event with `VTc` MCV that has in the
 | |
|   jumbo payload a 32 bits unsigned integer for the typeid followed by the label
 | |
|   null-terminated string of variable size.
 | |
| 
 | |
| ## Event description
 | |
| 
 | |
| To describe the meaning of each event, a description follows the event
 | |
| declaration. This description accepts printf-like format specifiers that
 | |
| are replaced with the value of the argument they refer to.
 | |
| 
 | |
| The formats are specified as follows:
 | |
| 
 | |
| ```ABNF
 | |
| format-specifier = "%" [ printf-format] "{" argument-name "}"
 | |
| argument-name = 1*(CHAR / DIGIT)
 | |
| ```
 | |
| 
 | |
| Where the optional `printf-format` is any string accepted by the format
 | |
| specifier of `printf()`, as defined in the manual `printf(3)`. If the
 | |
| `printf-format` is not given, the default format for the argument type
 | |
| is used.
 | |
| 
 | |
| Here are some examples of event descriptions of the previous events:
 | |
| 
 | |
| ```c
 | |
| { "OHp", "pauses the execution" },
 | |
| { "OAs(i32 cpu)", "switches it's own affinity to the CPU %{cpu}" },
 | |
| { "OHC(i32 cpu, u64 tag)", "creates a new thread on CPU %{cpu} with tag %#llx{tag}" },
 | |
| { "VYc+(u32 typeid, str label)", "creates task type %{typeid} with label \"%{label}\"" },
 | |
| ```
 | |
| 
 | |
| Which would be printed with ovnidump like:
 | |
| 
 | |
| ```nohighlight
 | |
| OHp  pauses the execution
 | |
| OAs  switches it's own affinity to the CPU 7
 | |
| OHC  creates a new thread on CPU 3 with tag 0x7f9239c6b6c0
 | |
| VYc  creates task type 4 with label "block computation"
 | |
| ```
 | |
| 
 | |
| ## Model version
 | |
| 
 | |
| When adding new events of changing the format of already existing
 | |
| events, the version of the model that defines the event must be changed
 | |
| accordingly to the rules of [Semantic Versions](https://semver.org).
 | |
| 
 | |
| In general, adding new events will cause a minor increase in the
 | |
| version, while changing events will cause a major increase. Notice that
 | |
| the emulator will reject a stream which contains events from a model
 | |
| which is not compatible with the current model version.
 |