123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138 |
- * License
- ## 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/>.
- * Start HERE
- For those of you who wish to hack on and improve this code base,
- there are a few structural and organizational things you should be aware of.
- ** structural
- *** What are the stages?
- Stage0 are the single core bootstrap binary at the heart of any port or bootstrap.
- These are to be as small as possible and generally 512 bytes is considered
- the upper limit for these sorts of programs (Excluding NOP or ZERO packing).
- Stage1 programs are those that can be written by the stage0 hex monitor in a
- moderate amount of effort or can be implemented by another stage1 program which
- can be built from the stage0 hex monitor. These tools will be among the most
- difficult to write as this is usually the stage where you are bringing up your
- first text editor and tools to calculate relative displacements for you. The
- last program to be written in this group is your assembler (the most primitive
- one that makes sense on your platform).
- Stage2 programs are those that can be written in the stage1 assembler syntax
- which was made available to you upon the completion of stage1. This is where
- your first high level languages start to appear. You probably want to keep your
- programs under 8KLOC as hand written assembly can have hard to trace bugs.
- Further stages will be described as they are discovered as this is a learning
- process about the full source bootstrap from nothing process.
- *** How are the files organized?
- Custom ports are listed in their own folders, right now there is only the x86
- port which is currently on hold until someone chooses to pick it up again.
- To allow people to independently produce the bootstrap stage0 binary, we have
- the Linux Bootstrap folder which contains several tools that may be of use to
- produce a hex assembler capable of making any stage0 binary.
- In the root directly, you will find a collection of *.c, *.py and vm.h these are
- the core files needed to build and debug hex and assembly programs written for
- the virtual machine specification documented in ISA_HEX_Map.org
- In the public directory, you will find the javascript and css files which
- improve the user experience of the Web IDE as implemented by User_Interface.py,
- Knight.py and the libvm.so file (built from wrapper.c vm_instructions.c
- vm_decode.c vm.h tty.c) which are started with a command like:
- python3 Knight.py -M 4M -R rom
- All of the bootstrap programs are inside of the stage directories that directly
- correspond with the infrastructure required to enable their functionality.
- The Library function prototypes folder contains library functions that were
- thought to be useful or commonly used.
- *** Where should I put this file?
- If it is for a stage0 port, put it in that ports own folder structure. If it is
- not a port, is it a bootstrapping file? If so place it in the stage folder which
- matches the level of bootstrapping requirements it has. If it is a library
- function please put it in that folder, for extensions or enhancements to the
- virtual machine, debugging or IDE place it in the root directory. If it is a
- high level prototype, place it in the relevent high level prototype folder.
- *** WIll you accept my custom licensed program?
- No. We only accept programs which have licenses that have been classified as
- free by the Free Software Foundation (FSF) and have complete and corresponding
- source code.
- ** organizational
- *** How can I join?
- Choose to contribute to the project and then let us know about the cool stuff
- that you are doing. Testers, developers, bug finders, documentation writers,
- artists, poets, painters, relay enginners and you are free to contribute
- whatever you think will help but please understand, it will be only accepted
- if others also find it useful/helpful/good.
- *** How do I get my changes merged?
- Send one of the developers a pull request or patches. They will either review
- them and merge them, tell you why they didn't merge them or point you at the
- person that you should be sending your changes to.
- *** Can I license my changes differently?
- No, all code in this project are to be licensed GPLv3 or Later. Exceptions are
- only granted in the case of project collective approval (70% or higher of
- contributors agree).
- *** What classifies someone as a contributor?
- They have joined the project and have either:
- 1) Created changes that were considered useful and merged into the master
- 2) Performed functions for the project considered essential and are generally
- recognized by community members as helpful to the project.
- AND to be considered a contributor for the purpose of voting, you must have
- performed one of the above in the last 1 year as those who have not contributed
- in that timefrmae are to be considered former contributors and thus are unable
- to vote on issues critical to the project.
- *** What is the process for a rule change?
- A request for rule change must be sent out to all active contributors of the
- project, stating exactly the change to be made (Diffs are valid) and a proposed
- vote deadline (Must be atleast 2 weeks from the date of formal annoucement). If
- no request for rescheduling has been made 24 hours prior to the proposed voting
- deadline, the voting will be done by the proposed deadline.
- Should the vote result in a 70% or higher acceptence of active contributors, the
- changes will be merged into the master.
- *** How is voting done?
- All voting is to be public, with only one of the following responses:
- Approve, Full support
- Approve
- Approve, Conditional support
- Obstain, Biased
- Obstain
- Obstain, No confidence
- Reject, Conditional
- Reject
- Reject, Unacceptable
- Failure to vote by the deadline is to be counted as an Obstain.
- *** What areas need the most help?
- Finding and reporting bugs
- Documentation
- Project organization
- Art work
- Porting to new hardware platforms
|