4 ms·
Sigh - people still don't understand this ..... many (many .... many!) years ago I did my first Unix port (very early 80s) it was of V6 to the Vax, my code ran
by Taniwha 6y ago
Sigh - people still don't understand this ..... many (many .... many!) years ago I did my first Unix port (very early 80s) it was of V6 to the Vax, my code ran as a virtual machine under VMS - Unix kernel running in supervisor mode in place of the VMS's shell. Ported the kernel and the C compiler at the same time (NEVER do this, it is hell).
Anyway I came upon this comment in the swap in code a bunch of times, never understand it, until I came to it from the right place and it was obvious - a real aha! moment.
So here's the correct explanation - V6 was a swapping OS, only needed a rudimentary MMU, no paging. When you did a fork the current process was duplicated to somewhere else in memory .... if you didn't have enough spare memory the system wrote a copy of the current process to swap and created a new process entry pointing at the copy on disk as if it was swapped out and set that SSWAP flag. In the general swap-in code a new process would have that flag set, it would fudge the stack with that aretu, clear the flag and the "return(1)" would return into a different place in the code from where the swapin was called - that '1' that has "has many subtle implications" is essentially the return from newproc() that says that this is the new process returning from a fork. Interestingly no place that calls the swap in routine that's returning (1) expects a return value (C had rather more lax syntax back then, and there was no void yet), it's returned to some other place that had called some other routine in the fork path (probably newproc() from memory).
A lot of what was going on is tied up in retu()/aretu() syntax, as mentioned in the attached article, it was rather baroque and depended heavily on hidden details of what the compiler did (did I mention I was porting the compiler at the same time ....) - save()/restore() (used in V7) hadn't been invented yet and that's what was used there.
- isuckatcoding 6y agoFeel like I need a diagram to truly understand this
- Taniwha 6y agoheh, probably - the hard part is the code that's hacking the stack pointer and return address on the stack out from underneath you when they do a context switch (rather than V7's C-standard setjmp()/longjmp() semantics). That part needs diagrams. The easier part I was trying to explain was the meaning of the SSWAP and the return(1) which effectively bring you back somewhere different returning a 1 where another routine returns a 0 (a bit like setjmp/longjmp) - this routine when called to do a context switch usually doesn't return anything
- herodoturtle 6y agoThis was such an insightful comment (and based on such specialised knowledge) that my first feeling was one of sadness that it'll get buried in the sands of HN. It would be cool if we could tag comments such as this one for intuitive retrieval later down the line. Thanks for sharing your experience, and point taken regarding porting a kernel and C compiler simultaneously ^_^
- kelnos 6y ago> It would be cool if we could tag comments such as this one for intuitive retrieval later down the line. You can click on the message timestamp, which will take you to a page just with that message, which has more options. One of them is "favorite" which will add it to your personal favorites list.
- herodoturtle 6y agoExcellent! Thanks for the tip :)
- pferde 6y agoOr even bookmark the comment's URL locally in your browser.
- naedish 6y agoExcellent idea. I've bookmarked your comment so I know how to bookmark other comments in the future. Thanks :)
- pferde 6y agoHey, it's not about knowing everything. It's about knowing how to find information on how to find information on things when you need to be informed on things! :)
- password4321 6y agoEach comment id also has an id within the page so you can bookmark within the context of the discussion if you want: https://news.ycombinator.com/item?id=24846987#24853698 https://news.ycombinator.com/item?id=24846987#24853698