하드웨어 이해하기

전 위의 글을 쓴 사람입니다! 제 아는 분들도 이곳을 방문하는 관계로 실명을 공개치 못한데 대해서는 죄송하게 생각합니다. 그리고 아래에 몇분들이 답글을 주셔서 참 고맙습니다.아직까지 갈피를 못잡겠는데요, 특히 어디서부터 시작을 할지 감을 못잡겠네요..... "8051 기초 + 알파" 같은 책으로 바로 시작해도 될까요? 그리고 한편으론 내가 잘생각하고 있는건지 하는 걱정도 드네요... 좀더 조언들을 해주시면 안될까요?
그럼 다들 즐거운 하루 되세요!

저두 지식이 부족하여,......, '참고' 정도로 읽어 주세요.
어떤 사람의 이야기를 적어보겠습니다.
전형적인 데이터베이스 응용프로그램만을 개발하시던 분이 있었습니다.
한 10년정도? 대형 프로젝트말고, 중소업체용을 개발하시던 분이었습니다. 규모야 한사람이 수행할 정도의 일이니, 미루어 짐작이 가능하실듯 합니다.
대학전공도 물리학이었구요. 하드웨어? 그건 전자상가에서 업체 운영할때 조립하던 경험과 땜질을 잘하시는 정도였구요.
그 분이 약 3년전에 하드웨어 분야로 전직을 하셨습니다. 자동문을 개발하는 회사였는데요. 자동문의 모터콘트롤(전자제어하는 쪽에서는 아주 크리티컬한 예제라고 합니다. 마치 소프트웨어에서 DB사용하는 정도로 기본이 되기도 하는 분야면서 심도있게 하면 어려운 것이라는 ......) 및 이를 제어하는 시스템으로 원칩컴퓨터 기반에서 개발을 수행하게 되었습니다. 원칩(마이컴등으로 인식해도 될듯합니다만)에서 자동문 비상제어, 리모콘 시그널을 입력받아서 처리, 다수개의 자동문을 원격제어하는 게이트웨이 역할등을 수행하는 프로그램을 개발하게 되었지요. 물론 회로설계 부분과 부수적으로 필요한 칩들의 선정 등 아키텍쳐 설계는 전자쪽일을 수십년한 분이 맡아서 수행했다고 합니다. 일부는 산학협동으로 모대학 대학원생에게 의뢰하고요.
여기서 주 관심사는 그분이 맡은 분야입니다. 아무래도 소프트웨어 했던 분이라 땜질하고 오실로스코프로 디버깅하는 작업은 익숙해지기 어려웠나 봅니다. 그래서 그분은 원칩내에 제어시스템 프로그램을 수행하게 되었습니다. 원칩컴퓨터의 특성상 메모리를 계산해가면서 코딩을 수행해야 했겠지요. 개발은 보통 PC에서 수행했고(MDS장비가 없었습니다--;) PC에서 C언어로 개발하게 되는데, 원칩에 따라서 C언어 라이브러리등이 기존 C언어에 비해 다소 차이가 있기도 합니다. 컴파일러도 당근 차이가 있지요. printf() 같은 함수는 거의 써서는 안되고요(메모리땜시, 단 1KB도 엄청난 메모리라서 아껴야합니다). 해당 컴퓨터의 어셈블리언어와 혼합된 프로그램을 만들게 됩니다.
기존에 사용했던 C컴파일러 라이브러리 중 운영체제가 제공했던것들은(write, malloc등) 거의 사용이 불가합니다. 왜냐면 원칩에는 운영체제가 없기 때문이지요. 다른 이유는 메모리 문제입니다. write라는 시스템 호출조차도 엄청난 메모리(--;)를 차지하기 때문에 링크를 할 수 없습니다.(큰 아픔이지요) 즉, 운영체제 비슷한 루틴조차도 만들어서 넣어야 합니다. 마치 10~15년 전에 도스에서 TSR같은 걸 만들듯 또는 포트를 직접제어해서 IO디바이스 드라이버를 만들듯이 말입니다. 크로스컴파일해서 PC용 에뮬레이터라도 있으면, 돌려보고 디버깅도 해볼수 있습니다만, 제반 하드웨어가 특성이 있을 경우는 이나마도 불가합니다. 따라서 크로스컴파일 한 바이너리프로그램을 보드의 쓰기가능롬으로 다운로드하고 하드웨어를 리셋하여 해당 프로그램을 돌려보고 하드웨어 곳곳에 잭으로 연결하여 오실로스코프 등에서 디버깅 하거나, PC로 데이터를 업로드하게 해서(RS-232등으로 연결, 터미널 프로그램등으로) 디버깅을 해보고 다시 코딩해서 ... 이 작업을 반복적으로 수행하게 되지요.
기존 범용운영체제에서 프로그램을 개발했던 분이라면, 기존 운영체제의 고마움을 실감하게 되고, 감사하게되지요.
왜냐하면, 이러한 시스템개발에서 그나마 소프트웨어쟁이(?)가 할 수 있는 일은 제어프로그램인데, 이 제어프로그램은 운영체제를 아주 아주 간소화해서 특수목적용(이정도가 어울리는 듯, 운영체제란 말은 부적당) 제어프로그램을 개발하는 것이기 때문입니다. 전형적인 소프트웨어프로그래머가 할 수 있는 일은 한가지 정도 더 있습니다. 시스템 개발을 완료하고, 이를 모니터링하는 프로그램을 만들 수 있겠습니다. 즉, 하드웨어 장치로 부터 RS-232등으로 신호를 입력받아 이를 PC등의 컴퓨터에서 통계, 분석, 감사등을 수행하는 용도의 프로그램 개발이랄까요?

* 두서없이 말씀드려 죄송합니다.
* 제 나름대로 정리하면
- 운영체제 비스무리한 것을 만들수 있으면 좋고, 운영체제 수준까지는 안가더라도 개념을 가지고 있으면 좋다.
- 인터럽트, IO방식(memory mapped, programmed, dma)에 대해 알고 있어야 한다. 당근 프로그램도 할수 있어야 한다.
- 고수준 디버깅 수행은 현실적으로 불가능하므로 메모리 덤프에 능할 수록 좋다(당연히 어셈블리 능력이 요구된다)
- 기초적인 자료구조를 아주 효율적으로 만들수 있어야한다. queue, stack등, 링크드리스트는 사용하기 힘들다(메모리, 속도땜시)
- 혹시라도 부자 하드웨어개발에서는 C++등과 같은 도구와 다양한 실시간 운영체제 상에서 작업을 수행할 수도 있다. 이 경우는 아주 행복하다. 그래도 메모리 아끼는 전략은 필수적이다.
- PDA등의 시스템을 위한 프로그램 개발도구를(공개버전도 많아요^^) 사용해서 연습할 수도 있다.(그러나, 이미 업종이 상당히 굳어지겠네요.)
- 소프트웨어 로직으로 구현이 어려운것은( 예. 타이머의 어떤 기능이 필요한데?)등은 불가능할경우 하드웨어로 만들어 달라고 한다.

-----------------------
끝입니다요.

소프트웨어의 복잡도는 하드웨어와 비교할 수 없이 크다고 알고 있습니다.
물론 하드웨어도 논리레벨이 아니라 소자단위로 들어가면 학문적인 깊이가 있겠지만 소프트웨어가 간단하다는 말이 오해의 소지가 있어서 답글달아봤습니다.

겨우 28.6Mhz 짜리 히타치 SH2 씨피유 2개 쓴 거 갖고 성능을 아직 10%밖에 못썼다는 쌩구라를 치다니...정말 엄청 비난을 받을 만 하네요. 하하하. 임베디드 하는 분이라면 잘 알겠지만 그 씨피유는 DSP랑 메모리 컨트롤러 같은 걸 내장한 일종의 SoC형 리스크 프로세서인데, 씨피유 자체 성능만 놓고 보면 i386이랑 성능을 다툴 정도예요. 한마디로 DSP 빼면 꽝이란 얘기죠.

Anonymous wrote...
> 아시다시피 듀얼 CPU에 듀얼 CPU지원 OS깔렸다고 멀쩡한 프로그램이 갑자기 듀얼로 돌아가는것은 절대 아닙니다. 아무런 차이 없습니다.
>
> 프로그램 10개 돌릴떼 5개, 5개씩 나누어 돌리는것이 아닙니다. 프로그램 하나가 아주 특별하게 듀얼에 맞게 컴파일 되어야 하는데 제가 내공이 부족하여 아직은 그런것은 포트란 밖에 못봤습니다.
>
> 듀얼에 맞게 코딩한다... 이런것은 하드웨어 레벨에서 알아서 작업을 나눠주는 방식이어야하지 개발자에게 첨단기술이니 배워...라고 하면 안된다고 생각합니다.

듀얼에 맞게 코딩하는 걸 어려운 말로 쓰레드라고 합니다. -_-;;

>
> 옛날에 세가 새턴이라고 듀얼 CPU달린 게임기가 있었죠. 버파2를 익식하면서 당시 제가 존경하는 PD분께서 우리는 이 기계의 성능을 어아직 10%밖에 쓰지 못했다...라고 했다가 나중에 엄청 비난을 받았던 걸로 아는데, 그때 느낀점은 좋은 기계는 대충해도 좋은 성능이 나오고 바쁜기계는 열심히 해도 그런 성능이 나오지 못한다는 것입니다.
>

성능의 10%밖에 못썼으면 실제 성능은 펜티엄 4 3Ghz보다 더 빠르겠네요?
그 PD(방송국 PD인가?) 좀 허풍이 심하신 분 같습니다.

> 최적의 상태를 사람이 맞추면 안됩니다. 컴파일러가 만들어 주는게 맞습니다. 왜냐하면 파이프라인이나 지연분기, 분기 예측까지 같은 코드라도 반도체 레벨에서 설계가 다르면 성능도 달라집니다. AMD와 INTEL이 다르고 P3와 P4가 다릅니다.
>
> 요즘 386급이상에서 사용하는 컴파일러가 만들어 내는 수준의 명령어는 학교 실습 시간에 쓰는 8088셈과는 수준이 다릅니다. x86이 아닌것 같은 듣도 보도 못한 황당한 명령어 조합을 생성해 냅니다. (디버그 모드와 릴리즈모드에서 생성되는 어셈이 완전히 다릅니다) 바로 CPU에 최적화된 코드입니다.
>

듣도 보도 못한 황당한 명령어 조합의 예를 한가지만 들어주세요. x86
어셈블리를 10년 넘게 해왔지만 그런 얘기는 첨 듣네요.

세가세턴은 듀얼CPU와 여러개의 범용DSP칩이 달린 기계인걸로 압니다만, 성능이 떨어졌다기보다는 (3D 성능이 플레이스테이션에 비해 떨어진건 사실입니다만), 제 생각엔 마켓팅 못했고 .. 그리고, 세가새턴의 개발환경이 플레이스테이션보다 않좋았다는게 더 큰 원인이 아닐까요.

플레이스테이션의 경우는 쓸만한 OS와 런타임라이브러리와 매뉴얼이 있다고 들었는데요, 세가새턴의 경우는 그런 툴킷의 이야기를 들어본적이 없거든요. - 나중에 말기직전에 나온 '그란디아' 같은걸 보면, 새턴의 3D가 그렇게 부족한건 아닌데 .. 역시 저정도로 뽑아낼 수 있다는건 개발사의 저력이었겠죠.

파이프라인 : 하나의 명령을 처리를 여러 스텝으로 나누고, 여러 명령어를 각 스텝에 분리해서 실행합니다. 스텝이 잘게 나누어져 있으면 CPU의 전체 속도 올리기도 좋습니다. (예를들어 세탁이 끝난 후 탈수기를 돌릴때, 다른 세탁물을 세탁기에 넣고 돌리면 같은 시간에 더 많은 양의 일을 할 수 있죠)

스퍼스칼라 : 파이프라인을 동시에 여러개를 실행시키는 겁니다. (예를 들면 세탁기와 탈수기를 2대씩 사면 이론상 2배의 능률을 올릴수 있겠죠)

OOO(OutOfOrder) : 특정 레지스터나 메모리에 쓰기 명령이 끝나기 전에는 그와 상관있는 레지스터나 메모리를 읽어들일 수 없도록 하는 안전을 확보하는 기술입니다. 아무리 효율적인 코드가 생성되어도 실행중에 OOO걸리면 말짱 꽝이죠. (얼음을 넣기전에 팥과 과일을 넣는다면 제대로된 팥빙수가 될 수 없겠죠)

VLIW : 스퍼스칼라가 실시간으로 CPU에서 명령어를 조합하는 기술인데 반해 VLIW는 미리 컴파일러에서 명령어 묶음을 생성해 내는 기술입니다. CPU가 명령어 골라내는 뺑이를 치지 않고 자료처리에만 집중할 수 있도록 하는 기술입니다. 점점 발열로 고생하는 CPU에 회로가 한뭉치 빠지면 발열량도 원천적으로 줄어들겠죠. (중국집에서 면은 필요한 만큼 뽑아도 짜장 양념은 미리 뽑아두는 것과 같은 원리죠)

예측분기 : 분기명령을 만나면 파이프라인이 비어버립니다. 이런 일을 막기 위해 CPU는 미리 코드를 읽어들입니다. 그런데 엉뚱한쪽의 코드를 읽어들이면 파이프라인을 지우고 처음부터 다시 읽어 들여야 하죠. 엄청난 시간 손실이 발생합니다. 펜4같이 파이프라인이 20단 정도되는 CPU는 죽음입니다. 팬4가 팬3만 못하다는 얘기가 여기서 나옵니다. (나폴레옹이 부하들에게 이렇게 말했습니다. "이 산이 아닌게벼")

지연분기 : x86은 아니고 SPARC나 MIPS에서 쓰는 기술입니다. 어셈블리 수준에서 분기 명령어와 바로 앞의 명령어의 순서가 바뀝니다. 파이프라인을 효율적으로 쓰기 위한 것입니다. 대신 이런 어셈 코드를 읽거나 작성하려면 정말 머리깨지죠.

RISC : x86은 명령어가 많아서 골라쓴 ㄴ맛이 있는데 반해 RISC계열은 명령을 조합해 써야 합니다. 개발자가 볼때 직관적이 못하고 황당한 명령어 여럿 있죠. 같은 코드가 x86이 MOV AX, BX리면 sparc은 ORR r1, r2, r2라는 OR연산을 씁니다. SPARC, MIPS같은 경우에는 MOV명령이 아예 없죠.

플래그 : RISC에서는 플래그 연산을 선택적으로 실행합니다. x86에서는 SUB명령을 하면 자동으로 모든 플래그가 설정되지만, sparc는 sub명령이 플래그 설정과 비설정으로 2개가 준비되어 있습니다. MIPS정도되면 아예 플래그 레지스터가 없고 범용 레지스터를 플래그 레지스터로 씁니다.

기타등등 이유는 수도없이 많지만 별로 아는게 없어서 이만 줄입니다.