Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve instruction decoding & evaluation #38

Open
marcinbugaj opened this issue Jun 13, 2022 · 0 comments
Open

Improve instruction decoding & evaluation #38

marcinbugaj opened this issue Jun 13, 2022 · 0 comments
Assignees

Comments

@marcinbugaj
Copy link

marcinbugaj commented Jun 13, 2022

Make sure that only instructions specified in instruction set can be decoded successfully. Instruction set is described in: https://www.scipr-lab.org/doc/TinyRAM-spec-2.000.pdf (section 7 in particular) Currently the validity of some fields is not checked:

  • Field # 5 (padding) should be always 0
  • Field # 4 (register name operand) should be 0 if not used. It is not used iff Field # 2 (flag) is set to 1
  • Field # 6 (immediate value of register name operand). If it is register name operand then the value of the field should indicate valid register number. (e.g. if machine has 16 registers then the value of the field should be in the range 0-15).

Currently decodeInstruction function in TinyRAM.DecodeInstruction module never fails. Given encoded instruction it always produces value of Instruction data type. That should not be the case. This function should fail if the WordSize is not a valid instruction encoding. Thus the function should either throw or return Maybe/Either of Instruction.

Start off with revising Instruction data type. This data type is supposed to represented decoded and valid instruction. That's because Instruction value is produced by instruction decoding process. Propose new Instruction data type so that invalid instructions are not representable. Now one can construct following value: Instruction 20 (IsImmediate (Word 3276)) (Register 100) (Register 500). Such value represent JMP to adress 3276 but other constructor parameters does not make much sense: Register 100 and Register 500 (fields ri and rj) are not used by the instruction (and should be set to 0 in binary encoding). That's why it should be sufficient to provide jump destination address only to construct Instruction value that represents jump instruction.

Yet another way of looking at Instruction data type is the following. Currently structure of Instruction data type is very similar to binary encoding of instruction (see table 2 in the aforementioned tinyram paper). What we want is that Instruction can be constructed in a similar way as we write assembly mnemonics for it. JMP is a good example: binary encoding has a lot of bit fields that are not relevant to the instruction but assembly mnemonic needs only one parameter - destination address.

Then align the rest of code to use new Instruction data type (lot of work).

Then remove assembler and translate textual testcases into haskell testcases. Each testcases becomes Haskell list of Instruction values.

@derekverbrugge , DM me if you have any questions. You can start with defining revised Instruction datatype. Then we will discuss it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants