os project

Hello, dear All! X-TRADE!!!! AWWWWWWWWWWWWWWWWWWWWWWWWWWWWW! How are things going with the subject? Or are you currently working on Storm2? And here I sketched something in my spare time, a type of priority process manager. It turned out that _everything_ is really possible write the kernel without a single DI. But for this you need to implement scheme to protect non-reentrants parts of code. This is where it begins problem. This is what I came up with. The so-called semaphore structure: lab2 ei ; so that if it’s busy, then switch ;processes occurred by INT ld hl,semaphore ;semaphore byte address lab1 bit 0,(hl) ;look at the semaphore jr nz,lab1 ;busy - hang around here until they release di ;critical area. necessary ;if the semaphore is reset and the command on lab1 catches it, ;but there was an interruption on the command jr nz,lab1 and ;a process switch occurred, and someone ;the semaphore was set again. bit 0,(hl); repeat the operation to confirm jr nz,lab2 ;omissions :) semaphore set 0,(hl) ;occupy semaphore ei; then let them switch - the code is ours! ;hereinafter the non-reentrant piece ;if someone wants to execute this piece of code, ;it will spin on label lab1 until ;lower semaphore. ;unlock the semaphore xor a ld (semaphore),a Advantages of the method: 1. simplicity. Disadvantages of the method:1. DI for several instructions is required. 2. There is no queue of people arriving. Those. if lab1 is spinning several processes, not necessarily the one that will come out was the first to arrive. Anyway, does anyone have any thoughts? Bye, √a└e┌┐┼!┌┐ P!┌┬┐e┌┐0√

Hello Valentin! Once upon a time, 13-08-98, 00:58:00, Valentin Pimenov wrote to All, about [os project] VP> X-TRADE!!!! AUUUUUUUUUUUUUUUUUUUUUUUUUUU! VP> How are things going with the subject? VP> Or are you currently engaged in Storm2. They also wanted to make an editor for GMX. Have you forgotten? [] VP> lab2 ei ;so that if busy, then switch VP> ;processes occurred by INT VP> ld hl,semaphore ;semaphore byte address VP> lab1 bit 0,(hl) ;look at the semaphore VP> jr nz,lab1 ;busy - hang around here until they release VP> di ;critical section. necessary VP> ;if the semaphore is reset, and the command on lab1 caught it, VP> ;but an interruption occurred on the command jr nz,lab1 and VP> ;a process switch occurred, and someone this VP> ;semaphore set again. VP> bit 0,(hl) ;repeat the operation to confirm VP> jr nz,lab2 ;omissions :) semaphore VP> set 0,(hl) ;occupy semaphore VP> ei ;then let them switch - the code is ours! VP> ;hereinafter non-reentrant piece VP> ... VP> ;if someone wants to execute this piece of code, VP> ;it will spin on label lab1 until VP> ;omit semaphore. VP> ... VP> ;unlock semaphore VP> xor a VP> ld (semaphore),a VP> ... VP> Advantages of the method: VP> 1. simplicity. VP> Disadvantages of the method: VP> 1. DI for several instructions is required. VP> 2. There is no queue of people arriving. Those. if you spin on lab1 VP> several processes, not necessarily the one that will come out VP> arrived first. VP> Anyway, who has any thoughts? ld hl,lab1+1 lab1 jr lab1; it's better that way ; .......... ; unlocking ld(hl),0 ; close the move ld(hl),0-2 [] See you soon. PHOENIX.

Hello, hello Valentin! One day, in the chilly summer, something around (13-08-98/00:58:00) Valentin Pimenov once wrote to All. VP> X-TRADE!!!! AUUUUUUUUUUUUUUUUUUUUUUUUUUU! Don't shout - we don't live in the forest... VP> How are things going with the subject? The subject is temporarily frozen VP> Or are you currently engaged in Storm2. Who... We i.e. I'm currently digging through Descent sources... VP> And here I sketched something in my spare time VP> type priority process manager. VP> It turned out that _everything_ is really possible VP> write the kernel without a single DI. Supervisor + kernel (low level) have been ready for a long time. Everything (seems) works - multitask and so on. Structures, etc. developed. for virtual memory. I'm stumped on the internal GUI design. Existing options are difficult to apply to spec - they consume a lot of memory, and The performance of the processor should not be poor... Although now I have some ideas on this topic: how to do cheaper, but angrier. The kernel contains everything a normal multitasking kernel needs. **lowest level** - working with lists - task scheduler/switcher - signals/messages/semaphores total 24 functions **higher level** - universal memory manager 3 functions so faras well as adding a task/interserver (without removing it yet) accordingly, so far only 2 functions and even 29 entry points = 1.5-2k code. VP> But for this you need to implement VP> scheme for protecting non-reentrants VP> code parts. This is where it begins So far I have no non-reentrant parts at all. And no SelfMod code. VP> problem. This is what happened to me. VP> The so-called semaphore structure: VP> lab2 ei ;so that if busy, then switch VP> ;processes occurred by INT VP> ld hl,semaphore ;semaphore byte address VP> lab1 bit 0,(hl) ;look at the semaphore VP> jr nz,lab1 ;busy - hang around here until they release No idle cycles. WaitSem() and that's it. VP> di ;critical section. necessary VP> ;if the semaphore is reset, and the command on lab1 caught it, VP> ;but an interruption occurred on the command jr nz,lab1 and VP> ;a process switch occurred, and someone this VP> ;semaphore set again. VP> bit 0,(hl) ;repeat the operation to confirm VP> jr nz,lab2 ;omissions :) semaphore VP> set 0,(hl) ;occupy semaphore VP> ei ;then let them switch - the code is ours! VP> ;hereinafter non-reentrant piece VP> ... VP> ;if someone wants to execute this piece of code, VP> ;it will spin on label lab1 until VP> ;omit semaphore. VP> ... VP> ;unlock semaphore VP> xor a VP> ld (semaphore),a VP> ... VP> Advantages of the method: VP> 1. simplicity. VP> Disadvantages of the method: VP> 1. DI for several instructions is required. VP> 2. There is no queue of people arriving. Those. if you spin on lab1 VP> several processes, not necessarily the one that will come out VP> arrived first. When using standard functions, the one who has higher priority. And no loops, no DI. VP> Anyway, who has any thoughts? When entering time-critical/non-interruptible sections of code, we do: Forbid() ;disable preemptive multitasking Permit() ;enable preemptive multitasking By the way, in kernel mode the task is not interrupted. I should leave it bit, what type when exiting the function you need to independently will switch (after all, if Int drops out only then, when the program runs in kernel mode, it never switches won’t happen), but I haven’t done it yet. Yes, you can almost forget about the DI team. With non-preemptive greetings evil Vitalik AKA Dark / X-Trade

Hi Valentin, In a message of to All (), you wrote: VP> ;unlock semaphore VP> xor a VP> ld (semaphore),a VP> Disadvantages of the method: VP> 1. DI for several instructions is required. VP> 2. There is no queue of people arriving. Those. if you spin on lab1 VP> several processes, not necessarily the one that will come out VP> arrived first. VP> Anyway, who has any thoughts? just on the topic: my nmi handler closes something like this design (which not only helps against reentry, but also allows painless bullet and block): Sio_IntHook: push af push hl ld hl, _sio_int_flag inc(hl) jr z, @@free dec (hl) pop hl pop af ret @@free: push de push bc [...] pop bc pop de ld hl, _sio_int_flag dec (hl) pop hl pop af ret Bye, Michael.

I'm joining the conversation Michael Kondratyev and Valentin Pimenov on the topic "os project" Hello Michael! [about reenter...] VP>> Anyway, who has any thoughts? MK> just on the topic: my nmi handler closes something like this MK> construction (which not only helps from the reenter, but also allows MK> painless bullet and block): MK> Sio_IntHook: push af MK> push hl MK> ld hl, _sio_int_flag MK> inc (hl) MK> jr z, @@free MK>dec (hl) MK> pop hl MK> pop af MK> ret MK> @@free: push de MK> push bc MK> [...] MK> pop bc MK> pop de MK> ld hl, _sio_int_flag MK>dec (hl) MK> pop hl MK> pop af MK> ret Good stuff. I was thinking about something similar myself... The point is that the subject is multitasking... so way using your method from the reenter defend only 255 tasks; or maybe you don’t need more? ld hl, semaphore call capture_semaphore ;[...rulez...] ;piece protected from reentrant ld hl, semaphore dec(hl); "free_semaphore" inline function capture_semaphore inc(hl) ret z dec (hl) call ;switch processes jr capture_semaphore Did I understand correctly? p.s.: what is “bullet”? I don't know... Bye, √a└e┌┐┼!┌┐ P!┌┬┐e┌┐0√

Hello, hello Valentin! One day, in the chilly summer, something around (22-08-98/02:57:00) Valentin Pimenov once wrote to Michael Kondratyev. VP> [about reenter...] MK>> just on topic: my nmi handler closes something like this MK>> construction (which not only helps from the reenter, but also allows MK>> painless bullet VP> and block): [everything here was heavily covered in code] VP> The point is that the subject is multitasking... like this VP> in a way using your method from the reenter VP> protect only 255 tasks; or maybe you don’t need more? All >255 tasks move simultaneously along the same section self-modifying code.... This is hardly possible do it on purpose... VP> ld hl,semaphore VP> call capture_semaphore VP> ;[...rulez...] VP> ;piece protected from reenter VP> ld hl,semaphore VP> dec (hl) ; "free_semaphore" inline function VP> ... VP> capture_semaphore VP>inc (hl) VP> ret z VP>dec (hl) VP> call ;switch processes VP> jr capture_semaphore By the way, now imagine what will happen if all 255 tasks will spin in such cycles - it will take a lot of time context switching. Those. for the work frame we get unknown number of frames of unnecessary switches. At this rate, the semaphore will not be released even in half an hour... My semaphore is a more complex structure rather than just a byte. In general, it is for similar purposes not intended, but I will still mention this matter. As far as I remember (too lazy to look at the source), a semaphore is: byte nest_counter - the same byte. By the way, Vin95 seems to be a byte... byte number_of_task_in_list list waiting_tasks disadvantages: - higher overhead costs if the semaphore is busy. (you need to put the task to sleep and add it to the waiting_tasks list) - larger amount of memory required. advantages: - tasks are processed according to their priorities. - high speed of response to semaphore release, theoretically equal to the task's wake-up time. - no time wasted on empty switching, which globally affects the overall system performance. Although, for such simple cases as the example given,One byte is enough. By the way, 255 tasks on the Spectrum are quite possible if they everyone (except one) will sleep... Simply evil Vitalik AKA Dark / X-Trade

Hello, hello Valentin! One day, in the chilly summer, something around (17-08-98/23:17:00) Valentin Pimenov once wrote to Vitaly Vidmirov. [skip anti-gravitator] VV>> We i.e. I'm currently digging through Descent sources... VP> probably this is a disassembler...? or maybe a debugger? What the hell kind of debugger!!! Descent - I love this Game!!! By the way, Descent is also available on the AMIGA... VV>> Supervisor + kernel (low level) _ready_ for a long time. VV>> I stumbled on the internal GUI design. Existing [...] VP> i.e., if it is (in the sense of os), then the GUI will be glued VP> tightly? or what? Gui is only partially related to the kernel. The point is that I would like the GUI to consist of two parts: * GDI - as in Windows - the module responsible for drawing graphics in windows. It is written based on specific iron, as well as the core. those. if the hardware supports block transfer via DMA, either hardware windows (the same sprinter) or something else, then only this part will be subject to modification. Thus it is hardware dependent. Therefore, it can be integrated with the kernel. Or maybe non-integration... * Support library. But now she is responsible for the appearance of the GUI, shape of windows, etc. VV>> ** higher level ** VV>> - universal memory manager VP> what does universal mean? lower + upper in one bottle? Got it right. VP> or virtual (such as continuous pieces of 100 kilos)? And I got it right. Continuous pieces, possibly with display to files (which, by the way, is done quite simply), so on the screw xxMB chunks are theoretically possible!!! VV>> as well as adding a task/interserver (without removing yet) VP> and don’t forget masking... Of course... [...] VV>> And no SelfMod code. VP> but it is quite possible that it will appear later. You know, I had to come here just now for my insidious needs recycle the unpacking procedure from ZXUNZIP(explode), so, she was all about S.M. code - after which I a little optimized and removed all self-modification for nothing. Due to why it began to work at least 1.5 times faster and take up less memory. VP> by the way, you don’t have any VP> of a piece of code that works at absolute addresses? I didn't understand this ^^^. Maybe I'm a fool? VP> and as for memory allocation, the tables are different Everything is dynamic except kernel variables. VP>, etc. If one process changes what VP> another climbs right away? [little skip] And here are the answers to your ^^^ question: VV>> When entering time-critical/non-interruptible sections of code, we do: VV>> Forbid() ;disable preemptive multitasking VV>> ... do something //INT works, but there is no context switching. VP> interesting time critical interval... what if I didn't use the word "time critical" quite correctly. I meant the one that is incorrect to interrupt (note that I say: not “fatal” but “incorrect”). VP> you suspended the chain of int handlers, and they VP> do they eat half a frame? In severe cases, interruptions are masked... VP> This is, of course, simpler. But it’s prettier with semaphores VP> i.e. parallel tasks are still executed VP> in parallel (switching by int remains). * Let me explain: The Forbid/Permit brackets are most often used when any context switch can be fatal for system or for one of the tasks consequences. In milder cases, and especially in long-term (over time) Semaphores should be used in areas. VV>> Permit() ;enable preemptive multitasking VP> ps: Yes, it seems like you have Amiga ideas... But we have Uniga ideas :) It's good that it's not WindowsNT :) PS: And the scheduler will have to be rewritten... but that will come later... Operationally evil Vitalik AKA Dark / X-Trade

I'm joining the conversation Vitaly Vidmirov and Valentin Pimenov on the topic "os project" Hello, Vitaly! [skip_driver < code_and_other] VV> All ..>255 tasks simultaneously proceed along the same section VV> self-modifying code.... This is hardly possible VV> do not specifically... Not necessarily self-modified, maybe it has absolute addresses works... VP>> ld hl,semaphore VP>> call capture_semaphore VP>> ;[...rulez...] VP>> ;piece protected from reentering VP>> ld hl,semaphore VP>> dec (hl) ; "free_semaphore" inline function VP>> ... VP>> capture_semaphore VP>>inc (hl) VP>> ret z VP>>dec (hl) VP>> call ;switch processes VP>> jr capture_semaphore VV> By the way, now imagine what will happen if all 255 tasks VV> will spin in such cycles - it will take a lot of time VV> context switching. Those. for the work frame we get VV> unknown number of frames of unnecessary switches. VV> At this rate, the semaphore will not be released even in half an hour... Of course it is, but you exaggerated it a little... 1.context switches do not take much time 2.call works quickly and does not wait for int. 3.some of the processes are _usually_ in a blocked state to receive messages (different servers, drivers...). [skip_driver < semaphore_structure] It is clear that there will be so many competitors at the same time brake Someone needs to be put to sleep :) By the way, how many processes (tasks) have you set as maximum? i.e. Is the identifier 1 or 2 bytes? Bye, √a└e┌┐┼!┌┐ P!┌┬┐e┌┐0√