@ -19,7 +19,7 @@ In this project we will recreate the necessary tools to run a more elaborate ver
### Game dynamics
At its very base the game consists on having two or more programs (written by the contestants) that will be executed by the Virtual Machine in an arena (a sandbox memory space).
At its very base the game consists of having two or more programs (written by the contestants) that will be executed by the Virtual Machine in an arena (a sandbox memory space).
We will call those programs the "players" from now on since they will be the ones playing. Their creators won't have any possibility to interact with them or the arena during the match.
@ -33,22 +33,22 @@ The winner will be the last player notifying the arena it was alive before the g
The Virtual Machine is a simplified reproduction of how a CPU works.
It will execute the binary code (the players) in the arena in cycles.
At the start of the game each player will have one process, and this process will be placed at the start of each player memory space (the current place of a process is called program counter, or pc).
At the start of the game each player will have one process, and this process will be placed at the start of each player memory space (the current place of a process is called program counter, or PC).
Each process will also have a private memory space (the registers) and a carry.
A carry is a special flag that may be changed by the result of some instructions, it can be used in many clever ways.
The players will be able to create new processes using special instructions, it is worth nothing though that every instruction takes a certain amount of cycles to be executed, and creating a new process is the most expensive one.
The players will be able to create new processes using specific instructions, it is worth noting though that every instruction takes a certain amount of cycles to be executed, and creating a new process is the most expensive one.
#### End game
There is a special instruction, called `live` that notifies the VM one player is still healthy and doing well.
Every once in a while the VM will check if the players made such instruction, if they didn't all the processes created by this player will be instantly killed.
Every once in a while the VM will check if the players executed such instruction and, if they didn't, all the processes created by this player will be instantly killed.
Once there is no more active processes the VM stops execution and the last player that notified it was alive is the winner of the match.
The VM will use some rules to decrease the elapsed time since the last check up to 0, this means the games can never be infinite and all processes will be killed at one point.
The VM will use some rules to decrease the elapsed time since the last check down to zero, this means the games can never be infinite and all processes will be killed at one point.
### The Assembler
@ -62,7 +62,7 @@ You should follow those specifications:
- The assembler takes a `file.s` as input.
- It return a `file.cor` as output.
- `file.s` is a regular and boring text file.
- `file.cor` is a binary file, in order to inspect it we suggest you to use commandtools like `hexdump`.
- `file.cor` is a binary file, in order to inspect it we suggest you to use command-tools like `hexdump`.
- If there is any error in the source file the Assembler should exit with an error code, print a message on `stderr` (the more specific the better) and do not create any `file.cor`.
- The binary must be written in big-endian.
@ -84,8 +84,8 @@ You should follow those specifications:
- Only when executing the instruction the VM will check for the parameters it may have and it will execute it only if the parameters are correct, otherwise it will print an error on `stderr` and continue to execute.
- If an instruction has incorrect parameters the PC will be moved forward according to the size of the parameters.
- If the instruction doesn't exist in the instruction set the PC will be moved forward of 1 byte.
- When a new process is forked it will be placed at the end of the processes and start its execution at the start of the next cycle (which means it will be the first one being executed on the next round).
- The entire execution is deterministic, this means with the same inputs you must always have the same outputs.
- When a new process is forked it will be placed at the end of the processes and start its execution at the start of the next cycle (which means it will be the first one being executed on the next cycle).
- The entire execution is deterministic, so with the same inputs you must always have the same outputs.
- The VM assumes the binary is in big-endian and read it accordingly.
Those are the cases were a file is considered corrupted:
@ -99,7 +99,7 @@ Those are the cases were a file is considered corrupted:
Every `CYCLE_TO_DIE` the VM will check for every player if it signaled it was alive at least once, if it didn't all processes created by this player will be immediately killed.
To avoid infinite games `CYCLES_TO_DIE` will be decremented by `CYCLE_DELTA` under certain conditions:
To avoid infinite games,`CYCLES_TO_DIE` will be decremented by `CYCLE_DELTA` under certain conditions:
- If during the last life loop there were at least `NBR_LIVE` successfully executed by the players.
- If it has been `MAX_CHECKS` life loops since it was decremented last time.
@ -108,37 +108,213 @@ To avoid infinite games `CYCLES_TO_DIE` will be decremented by `CYCLE_DELTA` und
### The Assembly language
In the assembly file there must be a `.name "[Name of the player]"` field and a `.description "[Description of the player]"` before any instruction.
Every instruction has to be on a single line and may be preceded by a label declaration.
The instruction name is separated from the optional label and the parameters by one or more spaces.
The parameters are separated from each other by `,`.
The instructions will be of different sizes depending on the number of type of parameters passed.
#### Labels
Labels are also called pseudo instructions, in the sense they won't be translated into binary code.
They are widely used to help programmers creating assembly code without needing to remember and count relative memory positions.
So when looking in the binaries the labels will be replaces in order to match their relative position in bytes from the place they were used.
As an example in the `ameba.s` player `zjmp %:hello` is exactly the same of `zjmp %-5` (`-5` being `ff fb` in hexadecimal notation).
Thi is because from the `zjmp` you will need to go back 5 bytes in order to match the label `hello:` declarations.
> Notice that labels can be declared at the start of an instruction or on their own line.
#### Parameters types
- Register parameter
Each process has its own registers (from 1 to `REG_NUMBER`).
Each of those registers can hold 32 bits, but the register number itself is written in only 8 bits (which are enough to go from 1 to 16).
They are formatted as `r1`, `r2`, `...`, `r16`.
- Direct parameter
A direct parameter is a value that represents itself, it is formatted by using `%` before the value. So `%10` will represent the number ten.
- Indirect parameter
An indirect parameter will give you the relative position of the address where to look for the value, think of it as an ancestor of the raw pointers.
In this case `10` will say to the VM to look ten bytes forward the current instruction and take the value from there.
> Don't be scared to use the provided Asm and VM to play with those different parameters in order to be sure you understood properly their behavior.
#### Instruction Set
| Name | Description | Nb Params | Opcode | Nb Cycles | Has Pcode | Has Idx | Params |
| zjmp | Jump if the value passed is zero | 1 | 9 | 20 | false | true | Direct |
| ldi | Load the value at the address of arg1 + arg2 in arg3 | 3 | 10 | 25 | true | true | [Register, Indirect, Direct]<br> [Register, Direct] |
| sti | Store the value of arg1 at the address of arg2 + arg3 | 3 | 11 | 25 | true | true | Register<br> [Register, Indirect, Direct]<br> [Register, Direct] |
| fork | Spawn a new process | 1 | 12 | 800 | false | true | Direct |
- `live`: says to the VM the player with the id matching the opposite of the first parameter is alive. If the first parameter is `-2` it means player 2 is alive.
- `ld`: loads the first parameter into the registry passed as second parameter. (If the first parameter is Indirect, the VM will apply `% IDX_MOD` to it)
- `st`: writes the value in the registry passed as the first parameter into the second parameter. (If the second parameter is Indirect, the VM will apply `% IDX_MOD` to it)
- `add`: sums the first two arguments and writes the result into the third one.
- `sub`: subtract the first two arguments and writes the result into the third one.
- `and`, `or`, `xor`: apply the respective bitwise operation to the first two parameters and saves it in the third one. (If the first and/or second parameters are Indirect, the VM will apply `% IDX_MOD` to them)
- `zjmp`: moves the PC adding the value passed as the first parameter. (The VM will always apply `% IDX_MOD` to the first parameter)
- `ldi`: writes the value contained at the address obtained by summing the first two arguments into the register in the third argument. (the VM will apply `% IDX_MOD` to the obtained address)
- `sti`: writes the value of the register passed as the first argument into to address obtained by summing the last two arguments. (the VM will apply `% IDX_MOD` to the obtained address)
- `fork`: creates a new process which will be an exact (deep) copy of the current one except for the PC which will be at the address specified in the argument. (the VM will apply `% IDX_MOD` to the first argument)
- `lld`, `lldi`, `lfork`: those instructions are the long versions of `ld`, `ldi` and `fork`, which means the addresses won't be truncated by `IDX_MOD`. (since those instructions are "long" the modulo operation won't be applied on them)
- `nop`: this operation do nothing, it can still take one argument and has a pcode so be careful on how you implement it.
> All addresses are relative to the current PC of the process.
#### The `IDX_MOD` constant usage
Some instructions have to truncate the addresses they are given by applying modulo `IDX_MOD`.
This feature prevent players from reaching spaces in memory that are too far from the current PC, which means processes won't be able to attack each other straight away but will need to move by doing smaller steps, this help having more balanced games.
#### Pcode field
Some instruction may accept different kind of parameters, and those parameters may require different sizes.
For those instructions the assembler will use a byte after the opcode to inform the VM which kind of parameters to expect.
Every two bits of this byte will inform the VM about the type of a parameter.
- `01` will be used for a register parameter.
- `10` will be used for a direct parameter.
- `11` will be used for an indirect parameter.
Here is an example of a pcode byte `01111000`:
This means the first parameter is expected to be a register, the second should be an indirect value and the third a direct value.
> Those numbers are in binary base, for example `10` in binary is `2` in decimal.
#### Has IDX field
Some instruction will sum up direct values and/or use them as addressed to lookup into the arena memory space. For this reason we know that a full 32 bits integer won't be necessary and to save space we do save direct values on only two bytes in those cases.
You have `Had Idx` column in the Instruction Set table, when it is true you must save and read direct parameters on two bytes, when false they will be saved on four bytes as usual.
#### The Carry flag
In all processors you will find a carry which is a flag that notify some edge case states to allow special operations, ensure security and serve many others functionalities.
The Carry of the processes in the VM is in that sense a simplified version of this concept.
The following commands will modify the carry of the process executing them: `ld`, `add`, `sub`, `and`, `or`, `xor`.
Those commands will set the carry to `true` if the result of their respective operations is `0`, and set it back to `false` otherwise.
Only one command reads the carry and it's `zjmp`, if will do the jump if the carry is true and will do nothing otherwise.
#### The file signature
The signature, also called magic, of a file is a particular value written at the start of a binary. This signature has the role to help the OS understand which kind of file it is and how to execute it. For the `.cor` files the signature is provided in the config file.
### Your player
While the main focus for now is to create an Asm and a VM, you should provide a basic player that should be able to fight and win against the `ameba.s`, this player will be tested in the provided VM during evaluation.
### Resources
#### Config file
The specification requires a lot of constants, it would be tedious to define them in the subject every time they are mentioned.
For this reason we provide a [config file](data/config.md) which includes all the required constants. Some of them are specific to the Asm, some others to the VM, the vast majority will be helpful to both.
> While the file is language agnostic, it would be very easy to translate it to a specific language. We suggest you to do so in order to centralize the configuration, it will help to debug and extend easily your programs if needed.
#### A basic player
To help understand better how the Asm and the VM works let's deep dive into the assembly code with a very basic player:
```
.name "ameba"
.description "not doing much"
sti r1,%:hello,%1
and r1,%0,r1
hello: live %1
zjmp %:hello
```
This player is one of the most basic living things you can imagine, it just says it is alive.
Here is how it proceeds in order to do so:
- The `sti` instruction will copy the value in the first register (which is the opposite of its id, so `-1` if this player is the first one).
- It is interesting that this number will be copied at the address in memory corresponding to the label `hello` + 1 byte.
- Said in other words this instruction is changing the argument of the `live` statement.
- The `and` instruction will copy the result of the logic AND operator into the first register.
- This result will be zero since any number AND 0 is zero. This have the side effect of setting the carry of this process to true.
- The `live` statement notify the VM ameba is alive. Notice the specific value of the argument is irrelevant in this context since the `sti` instruction override it before the `live` is executed.
- The `zjmp` brings the PC back to the start of the live instruction (creating a loop).
- Notice `zjmp` only operates the jump if the carry is not equal to zero. This is why we executed the `and` instruction before.
Now let's what this player binary looks like with `hexdump -C ameba.cor`:
- At the start of each line there is the position of the first byte of the line in hexadecimal.
- This means that for the second line `10` hex is actually 16 in decimal notation.
- The right panel shows a `.` if the byte is not a valid ASCII character.
- Repeated lines are aggregated under `*`, this is why we pass from `10` to `80`.
- Each `xx` is a byte (a byte is 8 bits, `ff` in hexadecimal is `1111 1111` in binary, `255` in decimal).
Let's read it through:
- The first 4 bytes `00 ea 83 f3` are the program signature (also called the magic), this is a 32 bits integer, represented as four 8 bits slices.
- Then the next 128 bits are for the name of the program, the first five `61 6d 65 62 61` are the actual name, the others are zeros because we don't actually need it.
- The we have 4 bytes `00 00 00 17` (so 23) which will be a 32 bits integer with the size in bytes of the program to be executed in the arena of the VM (so only the size of the instructions, without the name, description, signature and so on).
- Then we have the description which works exactly the same as the name but it will adds a four bytes padding at the end of it.
The actual instructions starts from there:
- The instruction `sti` is made by those bytes: `0b 68 01 00 0f 00 01`.
- `0b` is the opcode, `68` is the pcode, `00 0f`, `01` is the first parameter, is the second parameter and `00 01` is the third parameter.
- Notice the last two parameters are written on two bytes each because `sti` has `Has Idx` set to true.
- Next instruction is `and`, and it is `06 64 01 00 00 00 00 01`.
- `06` is the opcode, `64` is the pcode, the first parameter is `01`, the second one is `00 00 00 00` and the third one is `01`.
- Here comes the `live` instruction: `01 00 00 00 01`.
- `01` is the opcode, `00 00 00 01` is the first parameter, notice the parameter memory space will be overridden by the `sti` instruction.
- The last instruction is `zjmp`: `09 ff fb`.
- `01` is the opcode while `ff fb` is the first parameter (on two bytes because of `Has Idx` once again).
#### Testing environment
You will be provided with a [playground]() containing:
@ -150,8 +326,21 @@ You will be provided with a [playground]() containing:
> The provided VM has an extra flag `-v` which you can use to print the state of the VM at every cycle, this should greatly help you during development and debugging.
#### Some advices for the road
### Some advices for the road
While the functioning of the VM and the Assembler may seems quite strange and obscure it is a perfect scenario to reproduce a CPU and understand what a computer really does at its core.
While the functioning of the VM and the Assembler may seems quite strange and obscure, it is a perfect scenario to reproduce a CPU and understand what a computer really does at its core.
In this project you are indeed creating a Turing Complete machine largely inspired by Von Neumann architecture (which is still how today's processors works).
### How your programs will be tested
#### Bonus
Those bonus will be evaluated only if the Assembler and the VM are perfect.
You can use external libraries (for example graphic libraries) in order to achieve them.
- Create a disassembler that will take binary as input and return a `.s` file as output.
- Create a visualizer to show what is happening in the VM in real time.
mikysett
1 year ago
committed by