You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Currently
decodeInstruction
function inTinyRAM.DecodeInstruction
module never fails. Given encoded instruction it always produces value ofInstruction
data type. That should not be the case. This function should fail if theWordSize
is not a valid instruction encoding. Thus the function should either throw or returnMaybe
/Either
ofInstruction
.Start off with revising
Instruction
data type. This data type is supposed to represented decoded and valid instruction. That's becauseInstruction
value is produced by instruction decoding process. Propose newInstruction
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 representJMP
to adress 3276 but other constructor parameters does not make much sense:Register 100
andRegister 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 constructInstruction
value that represents jump instruction.Yet another way of looking at
Instruction
data type is the following. Currently structure ofInstruction
data type is very similar to binary encoding of instruction (see table 2 in the aforementioned tinyram paper). What we want is thatInstruction
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.The text was updated successfully, but these errors were encountered: