Notes, scratchspace, and collaborative wiki for our endeavors in HPC Systems and Networking

Linkage http://homepage.ntlworld.com/cyborgsystems/CS_Main/6502/6502.htm

As mentioned, there are commonly 4 methods of addressing, which we will find CPUs break out separate instruction variations for:

• register- register-to-register operation. Internal.
• immediate- constant(-to-register)… ability to provide a fixed value (like the number 3), as an operand
• memory- pull some (or all– depends on CPU) information to be processed from memory (address provided as operand to instruction; also adds to the instruction size)
• indirect- pull data from the memory address specified in index/pointer registers (we do not specify memory address, it has already been loaded into existing registers)

Due to the script-centric nature of the simulator, for our core ALU functionality, we really don't need to implement these specific actions… we can merely create temporary register files, loading any of this data in and then doing the register-to-register operation; but for practice individuals can choose to implement this functionality (like having an add.sh for reg-to-reg, addimm.sh for immediate, addmem.sh for memory interaction, and addind.sh for indirection).

Also, if context is unclear, always assume a register is the medium to be used.

Functionality that needs to be implemented:

• adding (ALU/add.sh)
  • register to register - wedge
  • do we need any of the other forms with proper mangling?
• subtracting
• multiplication
• division
• modulus
• bit shifting
  • left
  • right
• bit rotation
  • left
  • right
• bitwise logic
  • AND
  • OR
  • NOT
  • exclusive-OR (XOR, or as we may see it called: EOR)
  • others?
• flags register
  • check current state
    • zero (ALU/checkZero.sh) - wedge
    • sign
    • carry
    • overflow
    • parity
    • …
  • set flag state
    • zero (ALU/setZero.sh)
    • sign (ALU/setSign.sh)
    • carry
    • overflow
    • parity
    • …
  • clear flag state
    • zero (ALU/clearZero.sh)
    • sign
    • carry
    • overflow
    • parity
    • …
• Compare (basically, instigate checks that could adjust flags register bits)

The datamanip/ directory will contain helper programs/scripts to aid us to juggling data around, both for our interacting-with-simulator uses, but also core CPU functionality that just focuses an data manipulation, but may not otherwise invoke ALU functionality (like adjusting flags register)

• load (datamanip/load.sh) - wedge
  • load will load a byte located at the specified memory address and output it in register format
• store
  • store will take a byte (in register format) and store it at the specified memory address
• data juggling – these are largely to assist us, especially when implementing other core functionality.
  • hex2reg.sh - wedge
    • reads hex value from STDIN, outputs it in our “ASCII-ized binary” register format
  • dec2reg.sh - vcordes1
  • oct2reg.sh - vcordes1
  • mem2reg
  • hex2mem
  • dec2mem
  • oct2mem
  • reg2mem
  • oct2hex
  • dec2hex
  • reg2hex
  • mem2hex
  • hex2oct
  • dec2oct
  • reg2oct
  • mem2oct
  • hex2dec
  • oct2dec
  • reg2dec
  • mem2dec
• core I/O functionality
  • stdin.c - wedge
  • stdout.c - wedge
  • stderr.c - wedge

Functionality related to memory (RAM/ROM), which the CPU treats as external and non-primary storage.

It is stored in a binary file (in an attempt to conceptually distinguish it from the “easy-to-read” ASCII-ized binary of our registers), so we have to access it in more specific ways

• memget.sh - wedge
  • may not be fully functional, likely needs some tweaks
  • basically, we provide it with the path to the memory file and the address, and it should produce a byte of information (in register format?)
• memgetbyte.c - wedge
  • an attempt at (re-)implementing core memory interactions. This program specifically will grab and return (in hex) the byte of memory at indicated memory address
  • logic currently assumes all bytes are 8-bits (not really a problem for our current endeavor)
• meminit.sh - wedge
  • bootstrap script on simulator start that will read simulator config files and generate appropriate memory files (and initialize to initial values? All zeros right now)
• memput.sh - wedge
  • the opposite of memget; memput will take a byte of data from a register and is responsible for placing it into memory at an indicated address

The point of memget/memput is that all other simulator functions needing to interact with memory should rely on these to do their heavy lifting. Nothing else should touch memory but these. Everything else that needs it uses these scripts.

Utility scripts related to registers.

• regdisp.sh - wedge
  • yes, little more than a cat of an indicated register file, but as is the spirit with the memget/memput, EVERYTHING should use regdisp.sh to display the contents of the register (many of the samples I already wrote do not do this, so they will need to be updated accordingly)
• reginit.sh - wedge
  • a simulator bootstrap script, which reads config files and creates the necessary register files (under sim/reg/)

The sim/ directory is for the runtime of the configured machine in question (our 6502 CPU + related hardware components, including any “software” we wish to run on them).

It consists of several subdirectories:

• etc/ - simulator config files
  • instructions.conf - mapping of hex opcodes to assembly mneumonics and instruction size/cycle info
    • this is meant as a database to assist with simulator operations (and reference for us when implementing things)
  • io.conf - mapping of memory addresses to I/O; a way of letting us hook device access into memory
  • memory.conf - memory layout
  • registers.conf - register layout
  • simulator.conf - intended top-level config for simulator
  • simvar.sh - bootstrap script setting important variables
    • may also provide some simulator-environment library functions
• ops/ - simulator CPU instruction scripts
  • named for the hex value they represent, there is one script per individual instruction. The script's purpose is to use the existing scripts/programs (ALU, datamanip, memory, register, etc.) along with whatever specific logic is necessary to accomplish the desired task at hand)
• code/ - programs to run on the simulator
• sbin/ - simulator binaries… the scripts and compiled sources of the various utility functions

To acclimate everyone, we will be covering the basics, and attempting to provide everyone with ample opportunities to have a hand in helping to implement core simulator functionality.

Sort of the tinderbox approach (exposure to ideas that may spark understanding)

Each week we may stop and focus on a particular aspect of the simulator (such as take an instruction, and suss out what needs to happen for it to work).

The general trend is that this stuff is so stupidly simple and obvious it is hard to comprehend just how simple and obvious it is. We are used to things being far more complex.

That is one of the things I love about Computer Organization / this project… I get to see people experiencing those moments of clarity, and slowly realizing more and more what is going on (the stark simplicity, but vast redundancy of the whole thing).