💾 Archived View for vierkantor.com › xukut › manual › syscall.gmi captured on 2024-05-26 at 14:51:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
Een syscall wordt uitgevoerd met de instructie `svc #imm'.
In principe wordt elk register bewaard, behalve de registers die de uitkomst bevatten.
Platte registers en objectregisters moeten de juiste inhoud hebben,
anders kan je proces een fout verwachten.
Systemcalls maken geen gebruik van register `p0', op `svc 0' na.
Hierdoor werkt `mov p0, syscallnummer; svc 0' zoals het hoort.
`svc 0': Kies
-------------
Voer syscall met nummer `p0' uit.
`svc 0' werkt alsof `svc $p0' werd aangeroepen.
Als `p0' gelijk is aan `0' gebeurt er geen coole recursie ofzo, maar krijg je een fout.
p0: nummer syscall
registers: zie `svc $p0'
`svc 1': Zelfidentificatie
--------------------------
Geef het nummer van het huidige proces.
Een procesnummer identificeert elk proces uniek en is verder in principe betekenisloos.
Je kan het procesnummer bijvoorbeeld gebruiken om berichten naar te sturen (zie ook de syscall `stuur').
p0: (=1?) -> behouden
p1: ? -> procesnummer
rest: behouden
`svc 2': Vork
--------------
Start een nieuw proces op.
Op dit moment delen alle processen hun geheugen met elkaar,
zodra dit niet zo is, zal deze syscall ook iets anders doen.
De procestoestand wordt overgenomen uit een procesobject.
In dit procesobject wordt het procesnummer neergezet.
o0: procesobject -> behouden (object wordt wel aangepast, zie beschrijving hierboven)
p0: (=2?) -> behouden
p1: 0 -> procesnummer
rest: behouden
`svc 3': Stop
-------------
Stop met het uitvoeren van het huidige proces.
p0: (=3?) -> nvt.
rest: nvt.
`svc 4' : Bericht sturen
------------------------
Stuur een bericht naar het proces met gegeven procesnummer.
Het bericht moet een geldig object zijn. TEDOEN: omschrijf wat er gebeurt zo niet. (geheugenbeveiliging)
Het gegeven proces krijgt toegang tot dat object, inclusief al het geheugen waar het object naar (door-)verwijst.
Zowel de afzender en ontvanger kunnen lezen en schrijven in dit object.
Let op dat twee processen die naar hetzelfde object schrijven erg lastig te begrijpen zijn!
(Zie documentatie over processen en berichten voor goede strategieën om daarmee om te gaan.)
Vanwege goede overwegingen is er geen feedback over het succes van verzenden.
In het bijzonder mag de ontvanger een niet-bestaand procesnummer hebben (zoals 0),
en krijgt het proces geen foutmelding.
o0: bericht -> behouden
p0: (=4?) -> behouden
p1: procesnummer -> behouden
rest: behouden
`svc 5' : Bericht ontvangen
---------------------------
Geef de lijst van ontvangen berichten sinds de vorige `ontvang'-operatie.
Indien de lijst leeg is, wachten we maximaal `p1' tijdseenheden op een bericht.
(Let op dat dit niet heel precies gemeten wordt, dus je kunt beter iets anders gebruiken om precies af te tellen.)
Tijdens het wachten krijgen andere (niet-wachtende) processen de kans om te draaien.
Er is geen speciale optie om zonder bovengrens te wachten, immers zijn `2**64' tijdseenheden meer dan genoeg voor iedereen.
De overgebleven wachttijd komt terug in `p1'.
Het is goed mogelijk dat er meerdere berichten binnenkomen zelfs als we in het begin moesten wachten.
o0: ? -> berichten
p0: (=5?) -> behouden
p1: wachttijd -> overgebleven wachttijd
rest: behouden
Put the current process in a waiting state, not returning from the system call until the specified timestamp occurs. The timestamp is specified in arbitrary units, see `xukut:timer:get-now' for determining an origin for these units and functions in the `xukut:sleep-duration:' for an offset. This system call is used to implement the `xukut:wait-precise' and `xukut:sleep-precise' functions; these should present a more friendly user-interface.
=> process.gmi See the manual section on processes for more information about the meaning of a waiting process.
n0: (=6?) -> preserved
n1: waking time -> preserved
rest: preserved
This is a very low-level system call used by the garbage collector. If you are unsure whether you want to use this call, you probably don't.
If the given virtual memory address is backed by a physical memory page, unmap the memory and return the page to the freelist. This will obliterate any data still stored in the page, so only use this system call on memory that has been deallocated (or moved, or swapped out). The intended use of this systemcall is that it is invoked by the garbage collector on deallocated memory, so that it can be re-used for new allocations.
This system call is internal, and details of its operation may change whenever the needs of the system change with it.
n0: (=7?) -> preserved
n1: virtual address -> 0 if page was not present, 1 if page was present
rest: preserved
Put the current process in a blocked state, not returning from the system call until it gets notified (for example by receiving a message).
=> process.gmi See the manual section on processes for more information about the meaning of a blocked process.
n0: (=8?) -> preserved
rest: preserved
Assign a new memory allocator to the process.
=> memory.gmi
val: ignored -> allocator
n0: (=9?) -> preserved
rest: preserved
Assign a free memory region to the process. This region can be passed to an allocator to use it to obtain memory for storing objects.
Each region is subdivided into a constant number of pieces, each of size `block scale * block unit'. Thus, the total amount of memory assigned to the region is `block scale * region unit'.
=> memory.gmi
val: ignored -> region
n0: (=10?) -> preserved
n1: log(block scale) -> preserved
rest: preserved
Any questions? Contact me:
By email at vierkantor@vierkantor.com