project:ledum:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| project:ledum:start [2025/07/03 22:31] – [ISA Description] Description of garbage collector yokotashi | project:ledum:start [2025/07/18 09:46] (current) – [Inctructions and assembly] sachy | ||
|---|---|---|---|
| Line 134: | Line 134: | ||
| * process creator | * process creator | ||
| - | Note: | + | Notes: |
| - | Any fiber can provide those services to others using it's resources. But the initial providers have all available resources and ability ru run privileged instructions if it's needed for their jobs. | + | # Any fiber can provide those services to others using it's resources. But the initial providers have all available resources and ability ru run privileged instructions if it's needed for their jobs. |
| + | # Process hierarchy, memory quota hierarchy and IO hierarchy are completely independent. | ||
| Terminology | Terminology | ||
| * thread - X has asked scheduler to create it. X is it's parent and can see it's whole memory. | * thread - X has asked scheduler to create it. X is it's parent and can see it's whole memory. | ||
| - | * process - X has asked process creator to create it. Process creator is it' parent and can see it's whole memory. X is it's parent process in process creator' | + | * process - X has asked process creator to create it. Process creator is it' parent and can see it's whole memory. X is it's parent process in process creator' |
| * fiber - any thread or process | * fiber - any thread or process | ||
| * There may be more process creators. Therefore the same fiber may be viewed as thread (from it's process creator and it's parent threads) and as process (from another process under the same process creator). | * There may be more process creators. Therefore the same fiber may be viewed as thread (from it's process creator and it's parent threads) and as process (from another process under the same process creator). | ||
| Line 182: | Line 183: | ||
| Weak pointers will be needed probably. | Weak pointers will be needed probably. | ||
| + | |||
| + | == process creator == | ||
| + | * from the scheduler' | ||
| + | * creates and destroys a processes when asked | ||
| + | * creates channels between parent and child process | ||
| + | * stores process hierarchy similarly as scheduler stores fiber hierarchy and memory allocator stores quota hierarchy | ||
| + | |||
| + | There may be more process creators. | ||
| + | The main reason for existence of process creator is possibility to create a child without being able to travel down through it's memory. Process creator will have this ability of course, but it should be small, simple and well audited. | ||
| + | |||
| + | ==== Inctructions and assembly ==== | ||
| + | |||
| + | * Fixed-length instructions (64 bit) - decoder simplicity | ||
| + | * Instructions aligned to 64 bit addresses - decoder simplicity | ||
| + | * First 8 b is an opcode | ||
| + | * Macro-instructions (???) | ||
| + | * Single instruction is unrolled into multiple instuctions by instruction decoder and then executed by the CPU as if coded by hand | ||
| + | * Increased code density - things like clearing multiple registers by single "XRM 1,15" (Xor Register - Multiple reg_n, | ||
| + | * Hardcoded in CPU wiring | ||
| + | * Supervisor Call Instructions | ||
| + | * Instruction passed outside of fiber/CPU and result passed back into specified register | ||
| + | * Raw-content register communication only, no way to pass memory | ||
| + | * Things like: | ||
| + | * Get current timestamp from BIOS or whomever | ||
| + | * Power management - tell the motherboard to sleep/turn off | ||
| + | * lowlevel ioctl used by hardware broker task | ||
| + | * VM communication? | ||
| + | * Allow itself being debugged? | ||
| + | * Message passing between fibers and basic services | ||
| + | * Inter-CPU communication (multicore, multisocket) | ||
| + | * Supported instruction set | ||
| + | * Derived from real-life massive applications by statistical analysis of used instructions | ||
| + | * Go along Parret rule that 20 % instructions do 80 % work - optimize that, ignore specialties | ||
| + | * Semaphores instructions | ||
| + | * Compare-swap | ||
| + | * ST0 - Store 0 or set condition code; ST1 - Store 1 or set condition code - if the memory was already non-zero (non-one), soft fail - atomic locking | ||
| + | * Vector processing | ||
| + | * Register treated as a vector of 4/8/16/32b long values | ||
| + | * Constant-time processing | ||
| + | * Compare-sort - order 4 registers by value in HW | ||
| + | * Hashing primitives | ||
| + | * Encrypt/ | ||
| + | * Inctruction naming convention to be defined | ||
| + | * Hex representation and opcode allocation to be defined | ||
| + | * Unused opcodes for future use | ||
| + | |||
| + | |||
| ==== Electronic Circuit Design ==== | ==== Electronic Circuit Design ==== | ||
project/ledum/start.1751581891.txt.gz · Last modified: 2025/07/03 22:31 by yokotashi