HACKING 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138
  1. * License
  2. ## Copyright (C) 2016 Jeremiah Orians
  3. ## This file is part of stage0.
  4. ##
  5. ## stage0 is free software: you can redistribute it and/or modify
  6. ## it under the terms of the GNU General Public License as published by
  7. ## the Free Software Foundation, either version 3 of the License, or
  8. ## (at your option) any later version.
  9. ##
  10. ## stage0 is distributed in the hope that it will be useful,
  11. ## but WITHOUT ANY WARRANTY; without even the implied warranty of
  12. ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  13. ## GNU General Public License for more details.
  14. ##
  15. ## You should have received a copy of the GNU General Public License
  16. ## along with stage0. If not, see <http://www.gnu.org/licenses/>.
  17. * Start HERE
  18. For those of you who wish to hack on and improve this code base,
  19. there are a few structural and organizational things you should be aware of.
  20. ** structural
  21. *** What are the stages?
  22. Stage0 are the single core bootstrap binary at the heart of any port or bootstrap.
  23. These are to be as small as possible and generally 512 bytes is considered
  24. the upper limit for these sorts of programs (Excluding NOP or ZERO packing).
  25. Stage1 programs are those that can be written by the stage0 hex monitor in a
  26. moderate amount of effort or can be implemented by another stage1 program which
  27. can be built from the stage0 hex monitor. These tools will be among the most
  28. difficult to write as this is usually the stage where you are bringing up your
  29. first text editor and tools to calculate relative displacements for you. The
  30. last program to be written in this group is your assembler (the most primitive
  31. one that makes sense on your platform).
  32. Stage2 programs are those that can be written in the stage1 assembler syntax
  33. which was made available to you upon the completion of stage1. This is where
  34. your first high level languages start to appear. You probably want to keep your
  35. programs under 8KLOC as hand written assembly can have hard to trace bugs.
  36. Further stages will be described as they are discovered as this is a learning
  37. process about the full source bootstrap from nothing process.
  38. *** How are the files organized?
  39. Custom ports are listed in their own folders, right now there is only the x86
  40. port which is currently on hold until someone chooses to pick it up again.
  41. To allow people to independently produce the bootstrap stage0 binary, we have
  42. the Linux Bootstrap folder which contains several tools that may be of use to
  43. produce a hex assembler capable of making any stage0 binary.
  44. In the root directly, you will find a collection of *.c, *.py and vm.h these are
  45. the core files needed to build and debug hex and assembly programs written for
  46. the virtual machine specification documented in ISA_HEX_Map.org
  47. In the public directory, you will find the javascript and css files which
  48. improve the user experience of the Web IDE as implemented by User_Interface.py,
  49. Knight.py and the libvm.so file (built from wrapper.c vm_instructions.c
  50. vm_decode.c vm.h tty.c) which are started with a command like:
  51. python3 Knight.py -M 4M -R rom
  52. All of the bootstrap programs are inside of the stage directories that directly
  53. correspond with the infrastructure required to enable their functionality.
  54. The Library function prototypes folder contains library functions that were
  55. thought to be useful or commonly used.
  56. *** Where should I put this file?
  57. If it is for a stage0 port, put it in that ports own folder structure. If it is
  58. not a port, is it a bootstrapping file? If so place it in the stage folder which
  59. matches the level of bootstrapping requirements it has. If it is a library
  60. function please put it in that folder, for extensions or enhancements to the
  61. virtual machine, debugging or IDE place it in the root directory. If it is a
  62. high level prototype, place it in the relevent high level prototype folder.
  63. *** WIll you accept my custom licensed program?
  64. No. We only accept programs which have licenses that have been classified as
  65. free by the Free Software Foundation (FSF) and have complete and corresponding
  66. source code.
  67. ** organizational
  68. *** How can I join?
  69. Choose to contribute to the project and then let us know about the cool stuff
  70. that you are doing. Testers, developers, bug finders, documentation writers,
  71. artists, poets, painters, relay enginners and you are free to contribute
  72. whatever you think will help but please understand, it will be only accepted
  73. if others also find it useful/helpful/good.
  74. *** How do I get my changes merged?
  75. Send one of the developers a pull request or patches. They will either review
  76. them and merge them, tell you why they didn't merge them or point you at the
  77. person that you should be sending your changes to.
  78. *** Can I license my changes differently?
  79. No, all code in this project are to be licensed GPLv3 or Later. Exceptions are
  80. only granted in the case of project collective approval (70% or higher of
  81. contributors agree).
  82. *** What classifies someone as a contributor?
  83. They have joined the project and have either:
  84. 1) Created changes that were considered useful and merged into the master
  85. 2) Performed functions for the project considered essential and are generally
  86. recognized by community members as helpful to the project.
  87. AND to be considered a contributor for the purpose of voting, you must have
  88. performed one of the above in the last 1 year as those who have not contributed
  89. in that timefrmae are to be considered former contributors and thus are unable
  90. to vote on issues critical to the project.
  91. *** What is the process for a rule change?
  92. A request for rule change must be sent out to all active contributors of the
  93. project, stating exactly the change to be made (Diffs are valid) and a proposed
  94. vote deadline (Must be atleast 2 weeks from the date of formal annoucement). If
  95. no request for rescheduling has been made 24 hours prior to the proposed voting
  96. deadline, the voting will be done by the proposed deadline.
  97. Should the vote result in a 70% or higher acceptence of active contributors, the
  98. changes will be merged into the master.
  99. *** How is voting done?
  100. All voting is to be public, with only one of the following responses:
  101. Approve, Full support
  102. Approve
  103. Approve, Conditional support
  104. Obstain, Biased
  105. Obstain
  106. Obstain, No confidence
  107. Reject, Conditional
  108. Reject
  109. Reject, Unacceptable
  110. Failure to vote by the deadline is to be counted as an Obstain.
  111. *** What areas need the most help?
  112. Finding and reporting bugs
  113. Documentation
  114. Project organization
  115. Art work
  116. Porting to new hardware platforms