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

Figure out the main instruction cycles #14

Open
lastmjs opened this issue Apr 23, 2018 · 4 comments
Open

Figure out the main instruction cycles #14

lastmjs opened this issue Apr 23, 2018 · 4 comments
Assignees

Comments

@lastmjs
Copy link
Owner

lastmjs commented Apr 23, 2018

Let's determine this right now before we go much further. Here's my initial idea:

  1. Opcode
  • fetch the opcode
  1. Parameters
  • based on the opcode, determine the number of parameters
  • Grab the parameters and push them onto the stack (registers)
  1. Compute
  • based on the opcode, grab the parameters from the stack (registers) (pop them off?)
  • based on the opcode, perform a computation and store it somewhere temporarily
  1. Result
  • Push the result onto the stack
@lastmjs
Copy link
Owner Author

lastmjs commented Apr 23, 2018

@electrovir Let's figure this out before we do anything else

@lastmjs
Copy link
Owner Author

lastmjs commented Apr 23, 2018

Looks like we are both agreed on an OPCODE step and a PARAMETERS step

@electrovir
Copy link
Collaborator

electrovir commented Apr 23, 2018

Registers

Assume we have the following registers (this may or may not change). Also assume we have external memory.

  • PC: program counter (for tracking current execution location in memory)
  • MAR: memory address register (for storing the address of the next memory access)
  • MDR: memory data register (for storing memory output)
  • OR: opcode register (for storing the current opcode)
  • Param: param register (for counting the number of parameters)

Naming on the last two registers is open for possible debate.

AFAIK we can't optimize out the MDR or the MAR because they are part of the general model for memory, which we want to interface with.

Instructions

Each numbered item is a clock cycle (bullets do not represent a clock cycle, just groupings of cycles or control explanations).

  • Opcode
    1. load PC into MAR
    2. load memory into MDR, increment PC, load MAR from incremented PC (optimization for the Parameters instruction)
    3. load OR from MDR, load Param from MDR
  • Parameters
    1. load MDR
    2. load MDR into stack, decrement Param, increment PC
      • If Param > 1 (before decrement) loop this instruction.
  • Compute

The Parameters instruction will always take place after the Opcode instruction (right?), thus loading the MAR can be executed at the end of the Opcode instruction.

The contents of the Compute instruction will vary based on the current operation, which is determined by the loaded opcode. The Result instruction (number 4) you included @lastmjs will be part of a given operations's clock cycles. (Not all operations have a result.)

Terminology

The following two words are interchangeable within this context, so I want to solidify how I'm using them:

  • Instruction: high level term for each step in the Opcode-Parameters-Compute cycle.
  • Operation: an actual wasm instruction (such as adding two numbers). One of these will always (and only) be included within the Compute instruction.

Updates

  • Moved load MAR from PC optimization from step 3 of Opcode to step 2. Can't load to and from memory at the same time! (Unless we 2+ buses.)

@electrovir
Copy link
Collaborator

Very rough schematics for what we worked through.

diagrams

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