미츠

같은 Pintos Code를 갖고 EC2와 Docker, WSL에서 각각 다른 Result 가 나오는 경우가 있다. 이는 기본적으로 환경 별로 처리 속도가 다르기 때문인데 단적인 예시로 내 Docker 환경에서는 1초에 2.1억번 정도 loop가 수행된다.// DockerCalibrating timer... 209,715,200 loops/s. 그런데 같은 팀원의 환경에서 돌려본 결과 EC2는 1.3억번, WSL에서 돌려본 결과는 3.1억번 정도가 수행된다.// EC2Calibrating timer... 129,638,400 loops/s// WSLCalibrating timer... 314,163,200 loops/s. 이 때문에 보통 프로그램이 허술하면 EC2에서는 아무런 문제없이 도는데 Doc..

syscall_entry.S는 시스템콜이 호출되었을 때 user mode에서 작동하고 있던 프로세스를 kernel mode로 이동하여 시스템 콜을 수행하고 다시 ret하기까지 수행하는 shell 파일이다.// syscall-entry.S#include "threads/loader.h".text.globl syscall_entry.type syscall_entry, @functionsyscall_entry: movq %rbx, temp1(%rip) movq %r12, temp2(%rip) /* 저장된 레지스터 호출 */ movq %rsp, %rbx /* Store userland rsp */ movabs $tss, %r12 movq (%r12), %r1..

먼저 사전에 알아야 하는 점이 있다. 바로 Pintos 학습자료가 32bit와 64bit로 나뉘어져 있다는 것이다. 아직까지 일부분만 학습하여 32bit와 64bit Pintos의 차이를 전부 알지는 못하지만 thread부분에서 체감할 수 있는 부분이 있었다.바로 all_list가 없다는 것. 이 페이지는 내가 학습한 내용이 너무 방대하여 만들었지만, 현재의 나도 정글의 선배 기수들의 자료들을 많이 참고하며 공부하고 있는데, 언젠가 다른 정글러들이 mlfqs를 구현하고자 하다가 헤메면서 꽁꽁 숨겨져있는 이 page까지 왔다면 아마 이러한 연유로 찾아오지 않았을까 하는 생각이 든다. 만약 MLFQS가 mlfqs-load-1 테스트는 성공했는데 mlfqs-load-60에서 잘 돌다가 120초에서 뜬금없이 에..

다음 함수는 CPU Register를 흉내내어 만들어져 있는 구조체에서 %rsp를 포인터로 사용해 CPU Register로 올리는 함수이다.// thread.cvoid do_iret(struct intr_frame *tf) { /* Structure -> CPU Register로 데이터 이동 (Load) */ __asm __volatile( // 입력한 그대로 사용 "movq %0, %%rsp\n" // 인자 *tf의 주소를 RSP에 저장 이 때, %0을 처음보게 되어 무슨 뜻인지 몰랐었는데, 이는 input operands로 들어온 0번째 인자를 가리키게 되며 컴파일러는 먼저 가서 확인 한 후 돌아와 할당하게 된다. "movq 0(%..

Pintos 주간이 시작됐고 예상대로 너무나 바빠 week 06 log를 쓰지도 못했는데 생각 난 김에07 log부터 쓰기로 했다. 일단 확실하게 느낀 점은 SW정글은 코드를 잘 짜기를 보다는 CS를 배우는 커리큘럼이라는 것과 코드 짜느라 머리털 뜯을 시간에 PINTOS 코드 뜯어보면서 머리털 뜯는 게 낫다는 결론을 냈다. **(탈모는 어차피 온다)** 대신에 PINTOS부터는 내용이 너무 방대하고 기억하고 싶은 내용이 많아 Notion이나 Velog에 WIL나 TIL를 저장하고 싶은 욕심이 생겼는 데, 뭔가 남이 보는 건 부끄러워서 그냥 깃허브정글 아카이브에 마크다운으로 만들까 고민 중에 겸사겸사 로그를 작성했다.

6주차의 정글일지를 쓰는 현재는 무려 17주차 막바지... 팀플이 거의 막바지로 접어들면서 약간 한가해졌다. 그래서 미뤄뒀던 정글일지를 쓰고자 한다. 벌써 2달이 지난 시점이지만 이 때 당시의 기억을 해보면 새록새록 나는 것 같다. 먼저 민방위가 포함되어있는 주차였어서 최대한 빨리 끝내고자 했었다. 팀으로 영민님과 동환님이 배정됐다. 두 분 다 전공자기도 하고 정글내에서 잘하는 사람들로 유명해서 더 어려운 주간, 예를 들면 핀토스 주간에 같은 팀이 되었으면 좋겠다고 생각했었는데, 핀토스 직전에 팀이 돼버려서 조금 아쉬웠다. 여튼 팀이 되자마자 회의를 했는 데, 각각의 일정이 다 있는 상태였어서 같이 점심을 먹을 수 있는 횟수가 3번 정도밖에 되지 않았다. 그러나 모두의 목표는 동일했는데, 바로 자신의 일..

정신 없는 5주차가 지나갔다. malloc lab은 OS에서 malloc이 작동하는 방식을 학습하기 위해 모형을 만들어보고 이해하는 과정이었다. 중간에 EC2가 터지는 불상사가 일어났다. 그래서 Docker로 Ubuntu 환경을 만드는 것에도 도전해봤다. 처음에는 진짜 뭐가 뭔지 Docker를 어떻게 다뤄야 하는지도 몰라서 오랜 시간동안 버벅였다. 그러다 Container를 내가 직접 Docker에서 만드는 것이 아닌VS Code에 내장되어 있는 기능을 이용해서 이미지를 만들고 devcontainer를 구성하는 것이 훨씬 효율적이고 편하다는 것을 알게 됐다. 심지어 devcontainer를 폴더 안에 넣어놓고 VS Code로 실행하기만 해도 알아서 드라이브와 bind 해줄 뿐만 아니라 폴더 내의 환경 변..

4주차가 지나가면서 동기들의 개발일지를 봤는 데 자신이 새로 알게 된 알고리즘이라던가 코드같은 것들을 설명하고 정리하면서 깔끔하게 정리해놨는데, 내 개발일지는 너무 일기장처럼 그냥 느낀 점만 주저리주저리 써놓은 것같아서 조금 부끄러워졌다. 그래서 대신에 백준 알고리즘 리포지토리 외에 정글에 코드 아카이브를 따로 만들어서 새로 짜본 코드라던가 그런 것들을 저장해 놓기로했다. 이번 주에 깃허브의 아카이브에 내가 만든 모든 프로젝트를 삽입하고 싶어서 관련된 기능을 찾아보게 되었는데 깃허브에 subtree와 submodule이라는 기능이 있는 것으 알게 되었다. 이를 사용해 보려고 시도하다가 2시간 정도를 태워 먹었는데, IDE에서 지원해주는 깃허브 관련 기능이 생각보다 많이 없었다는 것을 알게 됐고, 어지간한..

정글의 마지막 알고리즘 주간인 3주차가 지나갔다. 걱정한대로 DP는 정말 지옥이었다. 출제자가 만들어 놓은 점화식을 찾는 다는 것은 생각보다 더 어려운 일이었다. 체감상 그리디 골드3 문제보다 DP 실버5 문제가 더 어려운 느낌. 알고리즘 주간을 진행하며 머리가 가장 아픈 주간이었다. 오죽하면 두통약까지 찾아 먹었다. 문제를 푸는 데도 오래걸려서 모든 주간을 합쳐서 문제의 갯수는 가장 적은데도 불구하고 결국 마지막 문제를 해결하지 못한 채 1주가 지나게 됐다.   알고리즘 주간 통틀어서 시험문제에 대해서도 가장 걱정이 많았다. 아무래도 연습문제도 다 풀지 못했기 때문에 도대체 시험 문제에서는 어떤 문제가 나올까라는 생각을 했다. 시험이 시작됐고 구현 1문제, DP 2문제, 그리디 1문제가 나왔다. 구현 ..

정글에 입소한지 2주차가 됐다. 여전히 알고리즘 주간이기 때문에 알고리즘을 푸는 데 온 힘을 쏟고 있다. 이번주는 Queue, Stack, DFS, BFS, 위상정렬을 학습하는 주인데, 큐와 스택의 경우에 개념 자체는 쉬워서 그런가 문제가 까다로웠고 문제를 푸는 시점 자체를 좀 바꿔서 본다던가 어떠한 형태의 배열을 스택처럼 바꿔서 본다던가 하는 어려움이 있었다. 그래프 탐색 문제는 개념 자체가 어려워서 그런지 문제는 오히려 좀 쉽게 풀었다. 문제를 풀던 중 막히는 문제가 있어 다른 분의 코드를 보면서 공부를 하는 데 정글을 수료하신 분 중 에 블로그에 자신의 코드를 공유하신 분이 있었다. 그 분의 코드는 내가 푸는 방식과 상당히 유사하여 내 코드에 추가하거나 변경하기 좋았고, 그 분의 코드를 보면서 좀 ..