어셈블리어 과연 어렵기만 한 것인가?

어셈블리어 과연 어렵기만 한 것인가? - 2009/02/09 16:28

추석에 가족 친지들과 좋은 시간들 보내셨나요?. 고향 먼길 다녀오신 분들 고생 많으셨습니다. 그러면, 오늘의 칼럼을 시작해 보도록 하겠습니다.

어셈블리어 과연 어렵기만 한 것인가?

먼저 재미삼아 저와 함께 문제 풀이를 한번 해 보시져.
(문제1)
struct person{
char name[80];
int old; // int 의 크기는 '4'바이트로 가정
char addr[80];
}
위의 자료구조 'person'는 메모리상에 총 몇바이트를 점유하는가?
그렇다. 164바이트가 정답이다.
그러면 다음 문제를 한번 보도록 하자.
(문제2)
struct person2{
char name[80];
int old; // int 의 크기는 '4'바이트로 가정
char* addr;
}
자료구조 'person2'는 메모리상에 총 몇바이트를 점유하는가?
바로 정답이 나오는 이도 있을것이고 잠깐 생각해 보시고 대답하는 분도 개중에는 있을것이다.

그러면 문제를 몇개 더 보겠다.
(문제3)
char* ptr;
int* pSize;
각각은 메모리상에 몇바이트를 점유하는가?

자! 마지막 질문이다.
(문제4)
struct person* ptr;
struct person** pptr;

나는 C언어를 잘 한다고 생각했는데... 당황하시는 분이 이 글을 읽으시는 분 중에는 반드시 계실 것이다.
하지만 절망 하실 필요는 없다. 그 이유는 지금까지 이것을 몰라도 하시는 일에는 크게 지장이
없으셨을 것이며, 또 딴에는 모른 다고 해도 기실 크게 부끄러워 할 일도 못된다.

다만, 한가지 주목할 만한 점은 위의 문제에 100점이 안 나오신 분들은 아마도 어셈블리를 전혀
경험하지 못하셨거나, 또 경험의 정도가 낮다고 감히 말씀 드릴수 있다.

왜냐하면 어셈블리에서의 간접번지 지정방법이 C언어에서의 포인터 개념과 동일한 것이라고 본다면
기계에 따라 틀리긴 하지만 포인터라는 것이 주소가 기입되는 장소라고 본다면 통상
모든 포인터의 크기는 4바이트라고 봐도 크게 틀리지 않기 때문이다.

그러면 지금까지 사설이 길었는데 위의 답을 열거해 보겠다.
(문제1) 164 BYTE
(문제2) 88 BYTE
(문제3) 각각 4 BYTE
(문제4) 각각 4 BYTE

위의 질문은 오늘의 주제인 '어셈블리어 과연 어렵기만 한 것인가'을 논제로 끄집어 내기 위해서
시작어로 사용되었다.

어셈블리어를 막연히 어렵게(혹은 어렵겠지) 생각하는 이도 물론 있을 것이고, 필요성에 대해서도
그다지 크게 느끼지 못하겠다 라는 분도 이에 못지 않게 많은것으로 생각된다.

그도 그럴것이 현재 임베디드 소프트웨어에서 구현되는 코드의 극히 일부만이 어셈블리로 작성
되는 것을 생각해 본다면 사실 고개가 끄덕여 질 만도 하다.

그러면 지금 이 시간에 제목과 관련 필자가 적어보고 싶은 것은 아마 이런것일 게다.
어셈블리를 꼭 알아야 하는가?. 어느정도 수준까지?. 오늘의 화두(話頭)이다.

우선, 어셈블리어가 무엇인가에 대해서 먼저 이야기 해 보도록 하자

어셈블리어는 임베디드 시스템 소프트웨어의 가장 저수준(LOW LEVEL) 언어이다.
따라서, 하드웨어와 가장 밀접한 프로그램이라고 하겠다. 밀접하다는 말뜻은 서로 상통한다는
의미도 된다. 어셈블리를 통해서 마이크로프로세서의 동작 메커니즘(하드웨어 동작) 실현되는
모습이 미루어 파악 되며 그 반대로 하드웨어 지식으로 그 구체적인 실현방법인 소프트웨어의
이론을 이해 할 수 있다는 말이다.

용어로는 어셈블, 어셈블리(어), 어셈블러 들이 있다.
먼저 어셈블러는 소정의 실행 프로그램이라고 생각하면 된다. 사용자 어셈블리 코드를 기계어 혹은
오브젝트 코드로 만들어 준다. 이때 변환해 주는 바로 이 작업을 어셈블 한다. 라고 한다.
어셈블리 혹은 어셈블리어는 말 그대로 해당 언어 그 자체를 의미한다.

둘째, 어셈블리어는 어떤 것들을 학습해야 하는가이다.

명령어(인스트럭션) 세트를 이해하고 사용한다. 어셈블리 프로그램을 풍부하게 가꾸어 주는 필수
어셈블리 디렉티브즈의 사용법을 어셈블러 사용법과 더불어 익힌다.
어셈블리 주요 어드레싱 모드를 이해하고 사용한다.

셋째, 어셈블리어를 구사하고 숙련되면 얻을수 있는 이익(benefit)은 무엇인가이다.

C언어의 포인터 개념이 머리속에 암기가 아닌 자연스런 모습으로 각인된다.
진정한 코드 최적화가 어떤것인지 이해가 된다.
부트 스타트업 코드를 보고 많은 노력을 안들이고도 단숨에 이해가 된다.
어셈블리코드가 일부로 들어가 있는 C코드를 분석 할 시에 두려움이 없어진다.
아마도 필자의 생각엔 마지막 이익이 가장 큰 것이 아닐지 생각해 본다.

넷째, 어셈블리어를 어느 수준까지 끌어 올려야 하는가이다.

참 어려운 이야기 이다. 하지만, 이야기를 꺼낸이상 대충 얼버 무릴 수는 없다.
필자의 의견은 '익명의 코드를 보고 완전하게 분석 할 수 있는 정도'라고 표현하고 싶다.
80~90년대 만해도 어셈블리로만 코드를 작성하는 경우는 심심치 않게 있었다. 필자도 그중에
하나 였으니 말이다.

하지만 지금은 상황이 다르다. 굳이 그럴 필요도 없을 뿐더러 그렇게 해서는
많은 시간과 대단한 노력이 든다. 작금의 C컴파일러는 양질의 최적화 코드를 만들어 주고 있다.
그리고, 성능 이슈가 있는 곳에는 C코드 대신 어셈블리를 대안으로 하느니 보다는 차라리 CPU를
고성능으로 채택하면 그만 아닌가 말이다. 나도 그 의견에는 대충 찬성이다.

필요하면 달라붙어서 어셈블리어로 프로그램을 짤수 있는 상태. 하지만 굳이 그럴 필요를 느끼지는
않는 바로 그 상태면 이상적인 수준이 아닐까 생각해 보았다.

다섯째, 어셈블리어를 학습 하는 나만의 순서(요령)이다

가.기본명령어(이동,연산,비교,분기) 세트를 빠른시간에 보고 직접 예제 코드 작성후 실행해 본다.

나.(가)를 진행하면서 어셈블러(ASSEMBLER) 사용법과 기타 코드의 어셈블 작업에 꼭 필요한
디렉티브즈들을 함께 익힌다.

다.주요 어드레싱 모드(대략 5가지 정도)를 학습한다.

라.서브루틴 작성법을 학습하고 직접 작성후 실행해 본다.

마.(다)의 어드레싱 모드를 실제 사례별로 예제 작성후 실행해 본다.

바.인터럽트 서비스 루틴을 작성및 실행해보고 인터럽트의 동작 원리를 이해해 본다.

사.이미 익힌 기본명령어를 점차 확장하여 모든 명령어 세트를 이해해 본다.

아.전체 명령어(인스트럭션) 세트 참조 표를 'A4 용지 한장으로 축소 복사하여 놓는다.

이 이후 부터는 어셈블리 프로그램 코드을 작성할때 수시로 이 표를 참고해가며 코딩하여
필수 명령어들을 자연스럽게 암기 한다.

자.부트업 스타트 코드(RTOS, LINUX, 일반 어떤것이라도 무방)를 예제로 생각하고 한번 분석해 본다.

차.어셈블리와 C의 상호 호출 방법을 이해하고 작성해 본다.

카.지역(로컬)변수의 생성과 해제 방법을 익힌다.

타.어셈블리 코드로 모듈별 구조화된 프로그램을 작성하는 방법을 익힌다.

어셈블리를 어렵게 생각하시는 분이나 진행중 포기하셨던 분들은 위의 제시와 같은 방법(순서)을 참고하시길 바라며, 막상 도전해 보시면 놀라웁게도 씹으면 씹을수록 우러나오는 어셈블리의 참 맛(!)을 느끼게 되실 수도 있을 것이라 나혼자 감히 생각해 봄.

지금까지 어셈블리어에 대한 이야기를 두서없이 적어 보았다.

본 컬럼은 필자가 '가일의 기술칼럼'을 진행 하면서 적은 두번째 글이 된다.
나만의 독선과 편견이 글속에 투영 되었을 것을 생각해 보면 조금 두려운 마음도 든다.
이 세상의 모든 지식은 오류속에 함께 뒤엉켜 있을 것임에... 따라서, 물론 나의 글도 100퍼센트 정확하다고 맹신하지는 않기를 진심으로 바란다.

마지막으로 각자의 사고(생각) 수준과 경험에 비추어 나의 글의 맞고 그름을 판별하여 보시면 하는 바램이며 마지막으로 내용중에 혹 잘못된 것은 지적해 주시길 더불어 바란다.

본 컬럼은 나 자신이 옳다고 생각하는 내용을 자유롭게 쓰는 것이니, 현명하신 독자님들께서
이를 널리 혜아려 주실 것을 본인은 틀림없이 믿는다.

-홍익컴닷컴-
http://www.hongikcom.com

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->