mmxvii / mmix Goto Github PK

It might be a little to early for that, but since we want to publish our software on crates.io in the end, we have to commit to an open-source license.

And since we are all authors, we have to find one together.

(I created this issue, so we won't forget!)
(Okay, I did also test issues with this issue...)

machine::state::types is the only module which is fully implemented. We need tests. A very basic example tests already exists in pull request #4.

At the moment, our project is a library project. At the moment, the idea is that we have both, a library and a binary. How should that work?

See the module machine::behavior::is, line 23. Implement the constant array which maps the opcodes to the functions.

The user should be able to interact with the virtual machine. How should we do that? What should they be able to see?

Which types should implement Display?

We need write unit-tests for the changes made in PR #30.

We MMIX works with binaries that store the data and text section. We have to think how these binaries should look like and how we load them.

Question 1: Should we use the file type specified by Donald Knuth? Or should we invent our own simpler format?

This includes the information which register be accessed by the programmer using PUT. See page 21 in THE BOOK.

In PR #36 the constant array SYMBOLICS was added to machine/behavior/is/mod.rs which maps an opcode to a str specifying the instruction's name.
The pathnames should be removed and the instruction names should be in capital letters.

Example: "arithmetic::addi" -> "ADDI"

There is a variable that stores the authors names and email addresses in Cargo.toml. We have to add the missing ones...

We (obviously) need to construct these types and access their fields somehow. We could either declare their respective field public, or implement "constructor-methods" and get-/set-methods. Opinions?
@jaborn @KarolinePlum @teiesti

Edit: added implementation of ldb for clarification
currently, we can't access res.0, construct ByteAt(a), ....

`/// load byte
pub fn ldb(state: &mut State, x: u8, y: u8, z: u8) {

let op1: u64 = state.gpr[y].into();
let op2: u64 = state.gpr[z].into();
let a = op1.wrapping_add(op2);
let address = ByteAt(a);
let res = state.mem[address];
let max_val = u8::max_value();
if res.0 > max_val / 2 {
    let to_subtract = max_val - res.0;
    state.gpr[x] = Octa(u64::max_value() - (to_subtract as u64))
} else {
    state.gpr[x] = Octa(res.0 as u64);
}

}`

• arithmetic ( #26 ) merged
• bitwise ( #24 ) merged
• bytewise ( #29 ) merged
• conditional ( #28 ) merged
• control ( #39 ) merged
• float ( #37 ) merged
• immediate ( #32 ) merged
• interrupt
• memory ( #33 ) merged
• other ( #38 ) merged
• subroutine (work in progress)
• system ( #41 ) merged

https://docs.google.com/presentation/d/10Q4alPT1JtenX5l_0Hrj5PelZK5oHgwLUus3uOaq6UY/edit?usp=sharing

As the functions need doc-comments at the end I suggest to write them directly after the implementation. In this way we get a overview which functions still need to be implemented.

Currently, all output types are set to Byte, although they should differ, depending on the requested size (Byte, Wyde, Tetra or Octa).