어제의 이야기

어제 공부한 것

...
깃북 Introduction 읽다가
궁금해서 한번 돌려봤는데
project3은 처음부터 다 뻑이 나길래
놀라서 project2를 다시 돌려보니 잘되더라

human...

이제보니 load 하는 형식 자체가 다르기때문에
뻑나는거더라...

그래서 깃북 Introduction읽고?
Memory mangement 읽고?

강의 두개인데 40분, 30분이라
헉....했는데

그리고 웬만하면 개념 코어를 빨리하고 코드 짜고 싶으시대서
이렇게 많은 개념을 하루만에....?! 하고 쫄았으나

다행히 저녁 전에 그래도 그
짧은 파트.. 앞부분이라고 할만한 파트를 골라내어
코어를 할수 있었다...

근데 읽어보니
전부 완성해야 애초에 디버깅이 가능한 어쩌고라
난이도가 어렵다고 한 이유가 이해가 된다...

강의는 memeoryo manegement 파트만,
그러니까 project3의 1 부분만 봤는데
겹치는 부분이 많고, 막 여기서만 알수있는 알고리즘 이런건 특별히 없었어서
(물론 보는게 좋긴 할듯..)
(하지만 함수명이 아예 다르니 오히려 헷갈릴수도.)
보는데 오래 걸리진 않았음.

저녁 7시 코어 는 30분 만에 끝났고
나도 한번 짜볼수 있을거같아서 짜보는데

이제 보니 page fault까지 한번에 짜는건 무리라
git book 순서대로 차근차근
frame manegement까지 코드를 채우긴 해서

디버깅도 안되고..
다음 anonymous page 읽으려다
다른 팀 코어 놀러가서 va의 구조에 대한 것과
offset이 왜 12비트이고 여러가지 accessed bit 등이 있는지
(페이지 단위가 4KB이기때문에 어차피 2의 12승으로
뒤의 12개의 0의 비트는 쓰지 않기때문에 빈자리로 쓴다.)

페이지를 여러개쓰면
(2의 9승)9승... 식으로 되어 훨씬 많은 양을 다룰 수 있으나
타고 들어가야하기때문에 시간 복잡도가 O(1)이 아닌 O(4)가 되는데
작은 숫자처럼 느껴져도 많은 양의 데이터가 이걸 거친다면
상당히 큰 메리트가 되는데, 다행히 그것에 관해서는
TLB가 가지고 있다면 미리 반환해주는 케이스를 속도를 극복..

그리고 실제 페이지 번호들을 찾아갈때
자기가 해당하는 페이지 외에는 &연산자로
나머지를 다 0으로 만들어서 찾아가는 거라든가..

를 들어서

나도 우리팀 코어에서 했던걸 공유했다..
supplement(철자 맞나) page table의 존재 의의나
구현 방법... 뭐 그런 거.
그래서 page fault handler의 역할 위주로 설명했음..

그거 하니 11시 40분이라 초과근무로 퇴근.

소감

흠
오히려 내가 짠 코드가 맞는지도 모르겠고
디버깅도 못해서 개념을 빨리 보게 되는군

뭐 어때

오늘의 계획

변경 사항 및 일정

밤에 집에감..
코어는 할지 말지 모르겠음.(못할거같긴한데.)

오전

깃북 anonymous 읽기

낮

깃북 anonymouse 파트
강의에서 찾아보기

슈도 코드 써보기

저녁

양이 생각외로 많다면 그거 하고
아니면 다음 단락도 보기

오늘의 다짐

알고리즘 한다며
그러게요