diff --git a/README.md b/README.md index 576cad5072..eca93a7ef7 100644 --- a/README.md +++ b/README.md @@ -51,8 +51,8 @@ Here is the plan for writing the decompiler: GOAL Runtime -------------- -The "runtime" will be a replacement for: -- The "C Kernel" which contains +The "runtime" will be a replacement for all of the C/C++ code of the original game. There is C/C++ code that runs on the main processor (EE) and the separate I/O processor (IOP). +- The "C Kernel", which runs on the EE and contains - [ ] File I/O (for debugging, not used by retail game) - [x] Initialization to boostrap the GOAL Kernel and start the game engine - [x] Connection to compiler for debugging/live code patching @@ -64,20 +64,20 @@ The "runtime" will be a replacement for: - [x] GOAL printf (called `format`) implementation - [x] GOAL hash/symbol table implementation - [x] Implementation of some built-in GOAL methods/functions -- The "OVERLORD" IOP driver, which ran on the PS2's separate I/O Processor +- The "OVERLORD" IOP driver, which ran on the PS2's separate I/O Processor for loading things off the DVD and doing sound things - [x] DGO loader - [x] File system for loading from DVD or "fakeiso" mode for loading from a folder - [x] "ISOThread" queue system for prioritizing reads - [ ] Sound stuff - [ ] Streaming animation stuff - [ ] Ramdisk stuff (implemented but totally untested) -- The "989_snd" sound driver (no progress has been made here) +- The "989_snd" sound driver (no progress has been made here, the rough plan is to do a high level emulation of the sound system) - Sony libraries - [x] SIF (interface between EE/IOP for sending data, receiving data, and making remote procedure calls) - [x] IOP Kernel (single-processor non-preemptive multitasking) - [x] stubs for stuff that doesn't really matter -The "Sony libraries" are a simple wrapper around my `system` library. +The "Sony libraries" are a simple wrapper around my `system` library, which implements the threading/communication stuff. Likely there will be sound/graphics code in here at some point, but this part is not fully planned yet. @@ -85,15 +85,17 @@ GOAL Compiler --------------- The GOAL compiler will target x86-64. At first just Linux. There is a macro language called GOOS which is basically just Scheme but with a few bonus features. -The compiler will reuse a significant amount of code from my existing LISP compiler for x86-64. I have a very bad WIP combination which is capable of building a modified `gkernel.gc` for x86 as a proof of concept. An important part of the compiler is the test suite. Without tests the compiler will be full of bugs. So every feature should have a good set of tests. +The compiler will reuse a significant amount of code from my existing LISP compiler for x86-64. I have a very bad WIP combination which is capable of building a modified `gkernel.gc` for x86 as a proof of concept. It can create and run functions in threads. + +An important part of the compiler is the test suite. Without tests the compiler will be full of bugs. So every feature should have a good set of tests. The major components are -- [ ] GOAL-IR, a linear intermediate representation for GOAL code +- [ ] GOAL-IR, a typed linear intermediate representation for GOAL code - [ ] "Environment" - [ ] "Ref" - [ ] Constant propagation of integers/floats - - [ ] Constant propagation of memory locations + - [ ] Constant propagation of memory locations (this is required to make sure bitfields updates know where to write their result) - [ ] Ref `in_gpr` - [ ] The type system @@ -119,7 +121,7 @@ The major components are - [x] Reader text db (for error messages that point to a specific line) - [x] Scheme interpreter -- [ ] Front-end (convert s-expressions to GOAL-IR) +- [ ] Front-end (convert s-expressions (a tree structure) to GOAL-IR (a linear representation)) - [ ] Parsing helpers - [ ] Macro expansion - [ ] Control flow/block forms @@ -139,7 +141,9 @@ The major components are - [ ] `xmm` and `gpr` promotion/demotions for EE 128-bit register usage -- [ ] Codegen (convert GOAL-IR + register allocations to x86 object file format) +- [ ] Codegen / Emitter (convert GOAL-IR + register allocations to x86 object file format) + - [ ] Emitter (convert GOAL-IR to instructions) + - [ ] x86-64 instruction generation (actually generate the machine code) - [ ] Linking data - [ ] 64-bit GPR - [ ] 32-bit float @@ -147,6 +151,7 @@ The major components are - [ ] 32-bit float x4 vector register - [ ] function prologue/epilogue - [ ] stack spilling + - [ ] static object and static object links - [ ] Listener/REPL - [ ] Network connection @@ -159,7 +164,9 @@ The major components are Asset Extraction Tool ----------------------- -Not started yet. The simplest version of this tool is just to use the decompiler logic to turn the level/art-group/texture/TXT files into GOAL source code, and copy all STR/sound/visibility files. +Not started yet. The simplest version of this tool is just to use the decompiler logic to turn the level/art-group/texture/TXT files into GOAL source code, and copy all STR/sound/visibility files, as these don't need to be modified. + +Eventually this should export to a more useful format. File formats: - [ ] Art group (a GOAL object format) @@ -179,5 +186,7 @@ File formats: Asset Packing Tool ----------------------- -Packs together all assets into a format that can be played. The simplest version to go with the simplest extraction tool will just pass the level/art-group/texture/TXT files to the compiler, and copy STR/sound/visbility files into the fakeiso. Then pack in CGOs/DGOs. +Packs together all assets/compiled code/runtime into a format that can be played. The simplest version to go with the simplest extraction tool will just pass the level/art-group/texture/TXT files to the compiler, and copy STR/sound/visbility files into the fakeiso. Then pack in CGOs/DGOs. + +It's important that the asset extraction/packing can be automated so we can avoid distributing the assets, which are large and probably not supposed to be distributed.