나빌레라의 블로그

나빌레라의 이미지

임베디드에서 소프트웨어 베이스 메모리 테스트

꽤 오래간만에 KLDP에 글을 올리는 것 같습니다. 먹고 사느라 바쁘군요...^^;
얼마전에 찾은 좋은 문서가 있길래 번역해 봤습니다. 나중에라도 누군가가 필요하면 도움이 되겠지요.

이 글은 http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-memory-testing.html 의 내용을 제 맘대로 번역한 글입니다. 번역의 품질이 매우 허접하므로 정확한 내용을 원하시는 분은 원문 링크로 들어가서 원문을 확인하시길 바랍니다.

나빌레라의 이미지

나의 삽질 유산 답사기... #2. 멀티 쓰레드에서 정적 객체를 사용할 땐 조심해야 합니다.


2편은 쓸지 안쓸지 몰랐는데 2편도 씁니다. 과연 3편은 쓸지 모르겠습니다. 모이다 보면 어떤 사람들에겐 꿀 팁이 될지도 모르고 어떤 사람들에겐 별것 아닌 글만 올리는 것이 될 수도 있다는 생각이 드네요.

그래도 별것 아닌 삽질이지만 기억해 둘 만한 꺼리라고 생각되어 정리합니다.

동시에 동작하는 멀티 쓰레드 프로그래밍에서 다수의 쓰레드가 하나의 정적 객체에 접근할 때, 특정 상황에서 신경써야 할 부분이 있습니다. 어떤 상황이냐면, 쓰레드의 로컬 데이터를 정적 객체에 던져주고 그 데이터를 정적 객체가 사용할 때입니다.

문장으로 써 놓으니 제가 생각해도 의미 전달이 다 안된것 같군요. 그럼 코드를 봅시다. 코드는 편의상 의사코드로 작성했습니다. 제가 삽질했던 코드를 가져올 순 없는 상황이네요..^^;

나빌레라의 이미지

나의 삽질 유산 답사기... #1. QEMU에서 0x00000000에 이미지를 올리고 싶었습니다.

무슨 바람이 불었는지 삽질하다 말고 삽질 내용을 KLDP에 올리고 싶다는 생각이 들어서 키보드에 손가락을 올려 놓습니다. 별 내용은 아닌데 구글링하다가 답을 못 찾고 직접 삽질한 내용이라 기록을 남기는 의미에서라도 어딘가에 적어 놓고 싶었거든요. 그럴 공간이 제게 KLDP 말고 또 어디가 있겠습니까..

이 글을 시리즈로 올릴 생각은 없는데 그래도 혹시 모르니까 #1 이라고 번호를 붙였습니다. #2는 아마 또 쓸지 안쓸지 저도 모릅니다.

지난번에 제가 올렸던 글에서 밝혔던 대로 저는 요즘 취미 삼아 시간 나는 대로 RTOS를 하나 새로 만들고 있습니다. 타겟 보드는 보다 많은 사람들이 접근할 수 있도록 실물 보드를 쓰지 않고 QEMU를 사용합니다. 훌륭한 에뮬레이터이지요. 게다가 오픈 소스라서 어떤 문제가 생겼거나 원하는 동작을 이끌어 낼 방법을 찾지 못했을 때 마지막 수단으로 QEMU 자체의 소스 코드를 뜯어 볼 수 있어서 좋습니다. 이 글의 내용이 바로 그 QEMU 내부 코드 중 "아주 극히 매우" 일부를 분석해 본 내용입니다.

나빌레라의 이미지

OS만들기 2판을 쓰고 있습니다.

KLDP에 매일 한 번 이상씩 들어오긴 하는데, 이상하게 글은 잘 안쓰게 됩니다.

예전에 활기차던 KLDP가 그립습니다.

막상 글을 쓰려니 쓸 글도 없는게 문제네요..ㅠㅠ

회사에서 일 하다가 모르는게 있어서 구글 검색을 하니, 제가 모르는 문제의 답이 제가 오래전에 쓴 KLDP의 강좌에 있는걸 보고 예전에 알았던 것을 지금은 왜 모르는가...

하는 철학적 고민을 하다 갑자기 KLDP에 글 하나 쓰고 싶어졌습니다...^^;

KLDP에 강좌를 연재한건 2008년이고 그 강좌가 OS 책으로 나온건 2009년이네요. 책이 나온지도 5년이 지났습니다. 강산이 반쯤 변했겠군요.

그래서 마음먹고 2판을 쓰고 있습니다. 한 달 정도 지났는데요. 2009년에 나온 책에서 다루지 않았던 내용들을 모두 포함해서 쓰려고 계획중입니다. 물론 무슨 출판사랑 계약이 되고 이런건 아니고요. 일단 다 쓰고 나면 출판사 알아봐야죠. 2009년에 나온 책도 그렇고 지금 쓰고 있는 것도 그렇고 이게 뭐 얼마나 팔리겠어요? 출판사에 손해나 안끼치면 다행이지요.

나빌레라의 이미지

제가 쓴 두 번째 책이 나왔습니다.

이곳 KLDP에 '컴퓨터를 만듭시다. 참쉽죠' 라는 제목으로 아주 오래전에 연재 했던 글이 책으로 나왔습니다.

라면 받침으로 아주 좋아요~^^

http://www.yes24.com/24/goods/7859338?scode=032&OzSrank=1

그리고 절판이 될지도 모르는 아주 오래된 제 첫 번째 책도 관심있으시면 봐 주세요~^^

http://www.yes24.com/24/Goods/3337559?Acode=101

=3==3

나빌레라의 이미지

재미있는 놀이: C, Python, Erlang으로 50000! 해보기 #3

-분할 정복-
디바이드 앤 컨쿼를 번역해서 분할 정복이라고 책에 많이 써 있다. 디바이드앤 컨쿼라는 영어 단어를 그대로 직역한 것이다. 어떤 커다란 계산이 필요한 문제가 있을 때, 이 문제를 잘게 쪼개서 개별적으로 계산한 다음 그 계산 결과를 합쳐서 최종 결과를 만들어내는 접근 방법의 통칭이다. 쉽게 말해 각개격파하는 것이다. 한 덩어리로 계산하면 땀나고 빡센 문제를 작게 쪼개서 빨리 빨리 계산함으로써 전체적인 효율을 높인다는 전략이다. 아주 좋은 전략이고 실제로 효과도 있다. 하지만 컴퓨터 프로그램을 만들면서 마주하는 많은 문제들을 모두 디바이드앤 컨쿼 전략으로 해결할 수 없다. 디바이드앤 컨쿼가 되는 문제가 있고 안되는 문제가 있다. 다행이도 지금 계속하고 있는 팩토리얼 문제는 디바이드앤 컨쿼 전략에 아주 잘 어울린다. 사실 디바이드앤 컨쿼 하려고 일부러 팩토리얼을 골랐다. :-)

나빌레라의 이미지

재미있는 놀이: C, Python, Erlang으로 50000! 해보기 #2

지난 글을 쓰고 댓글에 python도 gmp를 쓰면 빠르다라는 댓글이 있었다. 뭐 그런 댓글이야 당연히 달릴 수 있다고 생각한다. 난 파이썬은 빅넘버를 지원하니까, gmp가 라이브러리로 따로 있으리라고 생각 자체를 안했으니까.

그런데 그 댓글의 말투(어투? 글투?)가 아주 기분 나빴다. 아니 기분 나쁜 정도를 떠나서 예의가 없었다. 아무리 우리가 전산쟁이고, 실력이 중요한 사람들이라지만 실력에 앞서 예의가 가장 중요하다. 욕을 한바가지 하고 싶었으나 참았다. 나도 같은 수준이 되기 싫어서.

그래서 아예 그냥 이 글을 때려 치우고 말아버릴까 싶었지만, 이왕 시작한 글이고, 또 재미있게 봐 주시는 분들도 있으니 느리긴 하지만 끝까지 써보려 한다.

제가 쓰는 글이 완전할 수는 당연히 없습니다. 전 아는 것도 없고 실력도 없는 하수니까요. 댓글에 본문의 부족한 부분을 지적하고 채워 주시는 것은 아주 좋습니다. 그렇게 하여 글이 더 풍부하고 완전해 지니까요. 하지만 글을 쓸 때 최소한의 예의는 지켜주시길 부탁드립니다.

나빌레라의 이미지

재미있는 놀이: C, Python, Erlang으로 50000! 해보기 #1

#1. 시퀀셜
난 사실 리컬시브니 디바이드앤 퀀커니 하는 이런저런 기법과 알고리즘을 잘 못한다. 머리가 나빠서인게 가장 큰 이유이고 오류가 없는 코드는 가장 단순한 코드라는 확실한 믿음 때문이다. 코드의 특정 부분에서 성능 최적화를 '반드시'할 필요가 있을 때에나 이런 저런 시도를 하면서 코드에 여러 기법들을 적용해 보지만 어지간해서는 기본적인 문법과 기본적이고 직관적인 코드 이상은 잘 작성하지 않는다.

프로그래밍 언어론에서 프로그래밍 언어의 요소를 구분할 때 일반적으로 반복문, 제어문, 산술문 정도로 구분한다. 그중 반복문은 전체 프로그램의 성능에 가장 큰 영향을 미치는 부분이다. C언어라면 대표적으로 for문과 while문이 있다.

문법에서 제공하는 반복문을 사용하는 방법 말고 반복(루프, loop)을 구현하는 다른 방법으로는 리컬시브가 있다. 이 글을 읽는 사람들 중 리컬시브가 뭔지 모르시는 분들은 얼른 공부하고 오시길 바란다. 리컬시브로 구현한 50000!은 다음 시간에~^^

나빌레라의 이미지

재미있는 놀이: C, Python, Erlang으로 50000! 해보기 #0

재미있는 놀이: C, Python, Erlang으로 50000! 해보기
#0. 동기, 그리고 삽질.

-프롤로그-
나는 1996년부터 C언어를 사용했고, 2001년부터 파이썬을 사용했다. 그리고 2011년 12월 17일부터 얼랭(Erlang) 책을 읽기 시작했고, 2011년 12월 20일에 얼랭으로 처음 코딩을 해 봤다.(얼랭이라는 언어를 안건 2009년 즈음이다.) 이 글을 쓰고 있는 현재 나는 얼랭이란 언어를 본격적으로 공부해야겠다라고 다짐한지 3일이 지났다.

정리해보면, 이 글을 쓰고 있는 현 시점 기준으로

* C언어: 15년
* Python: 10년
* Erlang: 3일

의 경력을 가지고 있다.

나빌레라의 이미지

언제 다음편이 올라올지 모르는 ARM Architecture 이야기 #1

#1. ARM 아키텍처 소개 Part.1


ARM의 역사
대부분 이런 류의 책이나 글을 거창하게 시작할 때는 역사 혹은 지금까지 발전해온 길을 쭉 훑으면서 시작한다. 물론 나도 이 글이 책으로 나오게 된다면 그 부분을 어떻게 해서든 찾아서 채워 놓을 것이다. 하지만 이 글에서는 그렇게 하지 않을 것이다. KLDP 블로그에 올리는 이 글은 원고의 초고이며 그렇기 때문에 나는 보다 자유롭고 편안하게 쓰고 싶다. 이 글을 읽는 여러분께 이야기하듯 쓰고 싶다. 따라서 아무리 내가 애를 써도 이해가 안되거나 쓰기 싫거나 불필요하다고 생각되는 내용은 쓰지 않을 것이다. ARM의 역사 같은 것은 위키페디아의 관련 페이지만 구글링해서 들어가면 아주 잘 설명되어 있다. 내가 굳이 여기에 또 옮겨 적을 필요는 없다고 생각한다.

페이지

RSS - 나빌레라의 블로그 구독하기