Broke out Knight information to enable proper architecture development

ISA_HEX_Map.org → Knight Reference/ISA_HEX_Map.org

@@ -1,4 +1,4 @@
-## Copyright (C) 2016 Jeremiah Orians
+## Copyright (C) 2016,2020 Jeremiah Orians
 ## This file is part of stage0.
 ##
 ## stage0 is free software: you can redistribute it and/or modify
@@ -14,88 +14,6 @@
 ## You should have received a copy of the GNU General Public License
 ## along with stage0.  If not, see <http://www.gnu.org/licenses/>.
 
-* High level programming information that is likely useful
-** M0
-*** What is it?
-M0 is the most minimal macro-assembler possible to self bootstrap on the Knight ISA specification.
-In fact it is so minimal that a definition file or individual definitions need to be prepended to source files for it to work.
-And example of a definitions is the following:
-DEFINE ADD 05000
-
-*** What are its assumptions?
-- all numbers outside of quotes are to be converted to 4 hex nybbles.
-- all strings are to be converted into hex form and start with a " and end with a ", no nesting
-- all definitions need to be applied if possible.
-- definitions can not be recursive or nested
-- all other details about the resulting binary will be handled by a hex2 assembler or better.
-- Line comments start with # or ; and continue to the end of the line and are not output
-
-*** How to use it
-Simply create a definition, such as
-DEFINE ADD 05000
-and then use ADD where you need 05000
-That is it.
-
-*** Does it provide any error checking?
-No
-
-**** Seriously?
-M0 assumes you write perfect code and never make a single mistake.
-If you want an macro assembler that helps to catch dumb mistakes, use something else.
-
-*** Can I use M0 without stage0 vm?
-Yes, that is why https://github.com/oriansj/MESCC_Tools exists
-
-** Hex2
-*** What is it?
-Hex2 is a standard set of rules that are architecture dependent which when combined with an implementation that support it functions like an advanced hex assembler.
-The goal behind hex2 is that any programmer should be able to implement a compatable implemention within a couple hours in C,
-or a couple of days in assembly or a couple of weeks if they hand encode it in hex itself.
-Its design is optimal for instruction sets that are nybble aligned or at worst verbose for instruction sets that are byte aligned.
-
-*** What are its assumptions?
-The most important assumption is that ALL labels are globally unique and should have only 1 instance.
-
-Hex2 only assumes 4 types of inputs:
-1) Hex nybbles to be assembled
-2) Line comments beginning with # or ; to be ignored and dropped
-3) Labels that begin with :
-4) Pointers to labels that start with @,$ or &
-
-For pointers starting with @, it is assumed that the user wants the 16bit relative displacement required by the preceeding instruction to the label;
-this is primarily used for jump, calli address immediates and PC relative loads and stores.
-For pointers starting with $, it is assumed that the user wants the 16bit absolute address of the label;
-this is primarily used for pointer comparisons involving hand encoded objects.
-For pointers starting with &, it is assumed that the user wants the 32bit absolute address of the label;
-this is primarily for hand encoding objects or instructions that want 32bit absolute addresses
-
-Should one wish to manually calculate the displacement field of an instruction, simply subtract the address of the byte after the immediate from the address of the target.
-
-*** More advanced?
-It is possible for a hex2 assembler to support more than just the minimal set as defined above and is frequently the case on complicated instruction sets.
-However, to be considered hex2 compliant a program should not depend on those additions.
-However, a hex assembler which supports those extensions can be considered fully compliant as long as hex2 compliant programs can be compiled correctly.
-
-*** How to use it
-In theory, you should never have to use hex2 directly as it is a rather tedious language to program in.
-Its primary design is to allow extremely low level and auditable bootstrap programs.
-But should you wish to do so, it'll probably be advisable for it to look something like this:
-:Store_String_0
-05049045                # STOREX8 R0 R4 R5 ; Store the Byte
-42100100                # FGETC ; Get next Byte
-0F550001                # ADDUI R5 R5 1 ; Prep for next loop
-C306 @Store_String_0    # CMPJUMPI.NE R0 R6 @Store_String_0 ; Loop if matching not found
-
-With very clear label names, a mixture of low and high level comments. It does become possible to write fixable code.
-But lets be honest, the only time you need to write hex2 is:
-When bootstrapping something new/ugly without M0
-OR
-All of stage0 was lost due to a category 5 disaster.
-
-*** Should you use it?
-Only if engaged in low level bootstrapping with the desire to defend against the trusting trust attack in an auditable fashion.
-Otherwise, just use gcc or llvm and save yourself alot of responsibility.
-
 * Instruction Listing
 ** 00 xx xx xx :: NOP
 | Hex         | Name            | Comment                                                                   |
@@ -842,7 +760,6 @@ This ordering was selected simply because makes the starting IP address 0 and is
 |     0D | Integer group  |               4 |
 
 *** Class E 2OPI
-This is a very rare and special group as each entry consumes a piece of the precious 256 entry opcode space.
 |--------------+------------+------------+------------+------------------|
 | opcode 8bits | XOP 16bits | Reg0 4bits | Reg1 4bits | Immediate 16bits |
 |--------------+------------+------------+------------+------------------|
@@ -860,7 +777,6 @@ This is a very rare and special group as each entry consumes a piece of the prec
 |--------+----------------+-----------------|
 | E0     | Integer group  |               6 |
 
-
 *** Class G 0OPI
 |--------------+-----------+------------------|
 | opcode 8bits | XOP 8bits | Immediate 16bits |

Knight Reference/Proposal for change.org

@@ -0,0 +1,135 @@
+## Copyright (C) 2016,2020 Jeremiah Orians
+## This file is part of stage0.
+##
+## stage0 is free software: you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation, either version 3 of the License, or
+## (at your option) any later version.
+##
+## stage0 is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with stage0.  If not, see <http://www.gnu.org/licenses/>.
+
+* Unreviewed
+** Unified Floating Point/Integer Registers
+*** Benefits
+Removes need for instructions that copy values between floating point and integer register sets.
+Allows all registers to be used when performing floating point or integer heavy code bases.
+
+*** Disadvantages
+This requires a single register file to have sufficient read and write ports to support both the integer execution unit and the floating-point unit.
+The connections for each port is an additional capacitive load that must be driven by register memory cell.
+This makes it more difficult to build high frequency superscalar implementations.
+Requires registers to be large enough to hold floating point types supported. eg 32bit, 64bit, 128bit, etc
+
+*** Supporting material
+Real world example: Motorola 88000, DEC Alpha 21264
+Real world counter example: Intel x86, Motorola 68000
+Adding an entire new set of registers, which means that operating system software needs to be modified to preserve additional CPU state information.
+To reduce the number of registers to save, an additional register (RSAVE) can be added to track which registers have been modified - unmodified registers don't need to be stored.
+Even a seperate FRSAVE for floats and VRSAVE for vectors, if they are seperate register files.
+In DEC Alpha 21264 used seperate Integer register files for each execution unit. Writes to any of the register files thus have to be synchronized, which required a clock cycle to complete, negatively impacting performance by one percent.
+
+* Reviewed
+* In Debate
+* Voting on
+* Denied
+** Add Condition Code Register
+*** Benefits
+Allows one to remove need for encoding a condition register in instructions that effect conditional states and thus have more compact representations.
+Removes need to spend limited registers on storing conditional states.
+
+*** Disadvantages
+Requires additional transistors in minimal implementations.
+In pipelined processors, such as superscalar and speculative processors, this can create hazards that slow processing or require extra hardware to work around them.
+Requires additional instructions to save and restore its contents.
+
+*** Supporting material
+Real world example: Intel x86, AMD AMD64, ARM ARM 32bit architecture
+Real world counter example: Stanford MIPS and DEC Alpha
+The use of condition registers can be avoided by the use of compare-branch and compare-jump instructions; which can be expanded into seperate instructions internally.
+
+*** Reason for Denial
+Not compatible with historical Knight implementations.
+The advantages of a Dedicated Condition Code register; like MIPS Dedicated Multiply/Divide registers are not worth the trouble they provide.
+
+** Make all instructions have conditional execution
+*** Benefits
+Conditional execution of instructions reduces branch overhead and compensates for the lack of a branch predictor in minimal chips.
+Reduces the number of branch, jump and skip instructions.
+
+*** Disadvantages
+Increases the size of all instructions.
+Significantly increases complexity of OoO implementations.
+Requires a Condition Code Register to not have to encode an additional register with all instructions.
+Hyper-majority of all instructions will be always execute.
+Induces implementation complexity that costs additional transistors.
+
+*** Supporting material
+Real world example: ARM 32bit, x86 CMOV
+Real world counter example: Most reasonable architectures
+Predicates are basically a way to make an OoO machinerun very slowly: they generate unbreakable data dependencies in ways a branch does not.
+So a predicate makes perfect sense in an in-order machine that is statically scheduled.
+
+*** Reason for Denial
+The disadvantages outweigh the advantages.
+It tries to be too clever by half and fails on all accounts.
+
+** include shifts and/or rotates into arithmetic instructions
+*** Benefits
+Barrel shifter can be used without performance penalty with most arithmetic instructions and address calculations.
+Reduces the number of instructions required in crypto object code.
+
+*** Disadvantages
+Requires additional bits in the instructions to encode the shift/rotate immediate
+Adds additional complexity in decode and execute phases.
+
+*** Supporting material
+Real world example: ARM 32bit
+Real world counter example: Most CPU architectures
+Requiring a barrel shifter in the execution path extends the pipeline lenght or reduces the clock speed of the execute stage.
+One must either include duplicate instructions to perform the shift before and after the operation; otherwise half the benefit is lost.
+EG i = a + b << 4 or i = (a + b) << 4 or i = (a << 4) + b all produce different results and which is implied excludes the others.
+
+*** Reason for Denial
+Use in ARM demonstrates the infrequency of use.
+Implementation complexity in ARM relating to implementation of this feature indicates a waste of transistors and encoding bits.
+
+** Implement single instruction size
+*** Benefits
+Fixed-length instructions simplify fetch, decode, and issue logic considerably.
+Simplifies assembler implementation.
+
+*** Disadvantages
+A single fixed size results in reduced code density, which is more adverse a characteristic in embedded computing than it is in the workstation and server markets.
+Makes inefficient use of L1/L2 cache space.
+
+*** Supporting material
+Real world example: Stanford MIPS, Berkeley SPARC
+Real world counter example: MIPS16 instructions, Berkeley RISC II
+Instruction-format expanders which invisibly "up-convert" instructions to larger internal representations are cheap to implement; thus making the complexity of supporting smaller instruction formats cheap.
+Programs for the original Berkeley RISC I were only about 30% larger than the VAX but very close to that of the Z8000, validating the argument that the higher code density of CISC designs was not actually all that impressive in reality.
+
+*** Reason for Denial
+Wastes valuable opcode space.
+Limits future instruction set evolution.
+
+* Approved
+** Add PC-Relative addressing
+*** Benefits
+This makes position independent code, as is often used in shared libraries and code loaded at run time, more efficient.
+
+*** Disadvantages
+Requires additional instructions as PC is not part of the general register set.
+
+*** Supporting material
+Real world example: Motorola 6809, AMD AMD64
+Real world counter example: Intel x86, MIPSv5
+This can be approximated with a fake function call in order to obtain the return value on stack (x86) or in a special register (PowerPC, SPARC, MIPS)
+
+*** Reason for Approval
+Historically included in Knight implementations

Programming notes.org

@@ -0,0 +1,98 @@
+## Copyright (C) 2016 Jeremiah Orians
+## This file is part of stage0.
+##
+## stage0 is free software: you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation, either version 3 of the License, or
+## (at your option) any later version.
+##
+## stage0 is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with stage0.  If not, see <http://www.gnu.org/licenses/>.
+
+* High level programming information that is likely useful
+** M0
+*** What is it?
+M0 is the most minimal macro-assembler possible to self bootstrap on the Knight ISA specification.
+In fact it is so minimal that a definition file or individual definitions need to be prepended to source files for it to work.
+And example of a definitions is the following:
+DEFINE ADD 05000
+
+*** What are its assumptions?
+- all numbers outside of quotes are to be converted to 4 hex nybbles.
+- all strings are to be converted into hex form and start with a " and end with a ", no nesting
+- all definitions need to be applied if possible.
+- definitions can not be recursive or nested
+- all other details about the resulting binary will be handled by a hex2 assembler or better.
+- Line comments start with # or ; and continue to the end of the line and are not output
+
+*** How to use it
+Simply create a definition, such as
+DEFINE ADD 05000
+and then use ADD where you need 05000
+That is it.
+
+*** Does it provide any error checking?
+No
+
+**** Seriously?
+M0 assumes you write perfect code and never make a single mistake.
+If you want an macro assembler that helps to catch dumb mistakes, use something else.
+
+*** Can I use M0 without stage0 vm?
+Yes, that is why https://github.com/oriansj/mescc-tools exists
+which will also provide some basic error checking (duplicate definitions, missing labels, duplicate labels, etc)
+
+** Hex2
+*** What is it?
+Hex2 is a standard set of rules that are architecture dependent which when combined with an implementation that support it functions like an advanced hex assembler.
+The goal behind hex2 is that any programmer should be able to implement a compatable implemention within a couple hours in C,
+or a couple of days in assembly or a couple of weeks if they hand encode it in hex itself.
+Its design is optimal for instruction sets that are nybble aligned or at worst verbose for instruction sets that are byte aligned.
+
+*** What are its assumptions?
+The most important assumption is that ALL labels are globally unique and should have only 1 instance.
+
+Hex2 only assumes 4 types of inputs:
+1) Hex nybbles to be assembled
+2) Line comments beginning with # or ; to be ignored and dropped
+3) Labels that begin with :
+4) Pointers to labels that start with @,$ or &
+
+For pointers starting with @, it is assumed that the user wants the 16bit relative displacement required by the preceeding instruction to the label;
+this is primarily used for jump, calli address immediates and PC relative loads and stores.
+For pointers starting with $, it is assumed that the user wants the 16bit absolute address of the label;
+this is primarily used for pointer comparisons involving hand encoded objects.
+For pointers starting with &, it is assumed that the user wants the 32bit absolute address of the label;
+this is primarily for hand encoding objects or instructions that want 32bit absolute addresses
+
+Should one wish to manually calculate the displacement field of an instruction, simply subtract the address of the byte after the immediate from the address of the target.
+
+*** More advanced?
+It is possible for a hex2 assembler to support more than just the minimal set as defined above and is frequently the case on complicated instruction sets.
+However, to be considered hex2 compliant a program should not depend on those additions.
+However, a hex assembler which supports those extensions can be considered fully compliant as long as hex2 compliant programs can be compiled correctly.
+
+*** How to use it
+In theory, you should never have to use hex2 directly as it is a rather tedious language to program in.
+Its primary design is to allow extremely low level and auditable bootstrap programs.
+But should you wish to do so, it'll probably be advisable for it to look something like this:
+:Store_String_0
+05049045                # STOREX8 R0 R4 R5 ; Store the Byte
+42100100                # FGETC ; Get next Byte
+0F550001                # ADDUI R5 R5 1 ; Prep for next loop
+C306 @Store_String_0    # CMPJUMPI.NE R0 R6 @Store_String_0 ; Loop if matching not found
+
+With very clear label names, a mixture of low and high level comments. It does become possible to write fixable code.
+But lets be honest, the only time you need to write hex2 is:
+When bootstrapping something new/ugly without M0
+OR
+All of stage0 was lost due to a category 5 disaster.
+
+*** Should you use it?
+Only if engaged in low level bootstrapping with the desire to defend against the trusting trust attack in an auditable fashion.
+Otherwise, just use gcc or llvm and save yourself alot of responsibility.

vm.c

@@ -16,7 +16,6 @@
  */
 
 #include "vm.h"
-#include <getopt.h>
 
 /* Load program tape into Memory */
 size_t load_program(struct lilith* vm, char* rom_name)

vm_instructions.c

@@ -15,7 +15,6 @@
  * along with stage0.  If not, see <http://www.gnu.org/licenses/>.
  */
 
-#define VM_H__VAR_DEF
 #include "vm.h"
 #include <unistd.h>
 #include <sys/stat.h>