현재 위치

홈 ›› Forums ›› 재미 ›› 자유 게시판

리눅스에서 어셈블리로 작업해보신 경험이 있으신가요?

gurugio의 이미지
글쓴이: gurugio / 작성시간: 목, 2005/03/17 - 3:02오후

학교 수업시간에 학부 2~3학년을 대상으로

어셈블리를 소개하는 시간에 발표할 주제를 찾는데요

현재 필드에 계신 분들께서 어셈블리로 작업하신

경험이 있으신지 있으시면 어떤 일에 사용하셨는지

알게되면 많은 도움이 될것 같습니다.

조금이라도 어셈블리를 이용해서 작업을 하셨었거나

이런 주제로 어셈블리를 소개하면 좋겠다는 의견이라도

써주시면 큰 도움이 되겠습니다.

Forums: 
자유 게시판
dotri의 이미지

글쓴이: dotri / 작성시간: 목, 2005/03/17 - 4:25오후

리눅스에서는 어셈블리로 코딩하는것이 의미 없다고 생각합니다.
어차피 커널 서비스를 호출하는 문장의 연속이니..

saxboy의 이미지

글쓴이: saxboy / 작성시간: 목, 2005/03/17 - 4:46오후

부트로더와 MMU관련 코드는 어셈블리를 쓰지 않고는 만들 방법이 없지요.

cjh의 이미지

글쓴이: cjh / 작성시간: 목, 2005/03/17 - 5:04오후

lilo 부팅 코드같은게 도움이 되지 않을까요?

--
익스펙토 페트로눔

IsExist의 이미지

글쓴이: IsExist / 작성시간: 목, 2005/03/17 - 5:34오후

암호 알고리즘 구현.

---------
간디가 말한 우리를 파괴시키는 7가지 요소

첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스

이익추구를 위해서라면..

다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치

urmajest의 이미지

글쓴이: urmajest / 작성시간: 목, 2005/03/17 - 5:47오후

OS를 만들 때 필수이겠죠.

context switching이라던가 paging은

어셈블리언어가 꼭 필요하겠죠.

gurugio의 이미지

글쓴이: gurugio / 작성시간: 금, 2005/03/18 - 11:22오전

MMX/SSE로 작업할 때

임베디드 보드에서 커널 코드나 드라이버 수정할 때

stdc에 정의된 인라인 매크로들

멀티 쓰레드에서 데드락 피할 때

제가 조사한 것은 이정도 입니다만

외국 문서에서 조사한 거라 다른 걸까요?

왜 실제 업무에서 작업하시면서 사용하시는 분이 안계신지..

나는오리의 이미지

글쓴이: 나는오리 / 작성시간: 금, 2005/03/18 - 12:43오후

gurugio wrote:
왜 실제 업무에서 작업하시면서 사용하시는 분이 안계신지..
초보라 자세히는 모르겠습니다만 사람이 작성한것보다 컴파일러가 해준것이 더 좋을수도 있기때문이 아닐까요?
codebank의 이미지

글쓴이: codebank / 작성시간: 금, 2005/03/18 - 12:50오후

욕심많은오리 wrote:
gurugio wrote:
왜 실제 업무에서 작업하시면서 사용하시는 분이 안계신지..
초보라 자세히는 모르겠습니다만 사람이 작성한것보다 컴파일러가 해준것이 더 좋을수도 있기때문이 아닐까요?

편리성면에서는 그럴지 모르지만 컴파일러가 만들어준것은 범용적인 형태라
쓸데없는 부분이 들어갈 수도 있습니다.
실제로 사람이 만든 코드와 컴파일러가 작성한 코드에는 결과적으로는 같지만
실제 코드양에는 차이점이 있어서 예전에는 필요한 어셈코드를 직접 작성해서
사용하기도 했었죠.

------------------------------
좋은 하루 되세요.

voider의 이미지

글쓴이: voider / 작성시간: 금, 2005/03/18 - 1:32오후

솔직히 어셈블리를 사용할 일은 많이 없다고 봅니다.

하지만 알고 있다면 모르고 있을때 그냥 넘어갔던 일들에 대해 다시 한번 생각하게 됩니다.

-- 아쉬운 하루 되세요 --

ashuaria의 이미지

글쓴이: ashuaria / 작성시간: 금, 2005/03/18 - 2:29오후

init만들때 써본적은 있습니다.
libc없이 용량 작은 init을 원했거든요.
결과는 900byte짜리 init을 만들었죠.

<FONT face="Times New Roman" size=4>שלום צליכם מאת ארוננו ישוצ המשיח</FONT>

gurugio의 이미지

글쓴이: gurugio / 작성시간: 금, 2005/03/18 - 7:59오후

어셈블리를 쓸 일이 매우 한정적이라는 것을

알지만 그래도 경험담을 듣고 싶습니다.

그래야 학생들에게 어셈블리를 현실에 맞게 소개할 수 있을 것 같아서요.

일단 거의 없다고 말해줄 수 밖에 없네요.

init이라면..정말 특별한 경우네요.

Necromancer의 이미지

글쓴이: Necromancer / 작성시간: 금, 2005/03/18 - 8:33오후

http://www.linuxassembly.org

리눅스에서 어셈블리를 할때 중요한 것은 시스템 콜인데..
이게 int 80h로 구현되어 있습니다. 위 사이트에서 거기에
대한 문서를 찾으실 수 있습니다.

그리고 추가로 말씀드리자면 glibc에서 제공하는 각종
유용한 기능들 (당장에 급한게 있다면 malloc()과 free()가
있겠습니다)을 못 씁니다. 이것들도 직접 구현을 해야
가능하죠... 예전에 malloc() 하는 어셈코드 짜려했다가
포기했었는데... 물론 링커에서 glibc 링크하도록 강제
지정하고, calling convention을 안다면 glibc와 링크시켜서
쓰는 것이 가능하기는 하지만 C처럼 디폴트로 링크되는건
아니라는 얘기죠.

개인적으로 리눅스 어셈 강좌를 쓸려 하는데 시간이 없다는 -_-;

Written By the Black Knight of Destruction

saxboy의 이미지

글쓴이: saxboy / 작성시간: 토, 2005/03/19 - 12:59오후

Quote:
어셈블리를 쓸 일이 매우 한정적이라는 것을

알지만 그래도 경험담을 듣고 싶습니다.

그래야 학생들에게 어셈블리를 현실에 맞게 소개할 수 있을 것 같아서요.

일단 거의 없다고 말해줄 수 밖에 없네요.

init이라면..정말 특별한 경우네요.

리눅스에서 x86 어셈블리를 사용할 일은 사실 그다지 많지 않지만 요즘은 리눅스를 전혀 모르다가도 임베디드 시스템 때문에 리눅스를 대상으로 개발하시는 분도 많습니다. 최근에는 arm 코어를 많이 사용하고 있으니 arm 부트코드와 MMU코드를 arm 어셈블리로 직접 작업해야 하는 경우는 생각보다 많이 생깁니다. x86 어셈블리만 어셈블리라고 말할 수 있는 것은 당연히 아닐테니까요. :-)

MMX/SSE같은 instruction set도 그렇지만 이것과 비슷하게 (소프트웨어코덱을 사용하는 경우라면) 동영상코덱이나 사운드코덱의 중요한 연산 부분(주로 DCT나 FFT겠지요) 을 최적화시키기 위해 직접 어셈블리를 사용하게 되는 경우도 생깁니다.

또, 아주 열악한 환경에서 작업을 하기 때문에 어쩔 수 없이 어셈블리에 Thumb코드를 이용해 작업하는 경우도 생기게 되겠지요. 대부분 칩에 같이 납풉되는 펌웨어의 경우이지만... 지나가면서 들었던 이야기이지만 스마트카드의 암호화루틴 따위는 어셈블리로 직접 작성하는 일이 많다고 합니다.

물론 이런 경우들은 제가 직접 경험했던 경우도 있습니다. 8)

임베디드 시스템에 초점을 맞추신다면 이러한 예를 찾기가 쉬우실 것 같군요. 어셈블리는 칩의 종류만큼 존재합니다.

siabard의 이미지

글쓴이: siabard / 작성시간: 일, 2005/03/20 - 12:07오전

nVidia에서 Cg내놓기 전에 Shader네 뭐네 하며 특수기술써야했을때 어셈블러로 작업해야했었습니다. 그거 생각하면 지금도 이마에 힘줄이 돋습니다. 특히나 광원효과나 그림자 만들때.. 이거 지금 다시 작업하라고하면 책상 몇번 뒤집어야할듯... Cg.. DirectX 9.. 정말 이럴때 고맙더군요. 흑흑..

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

siabard의 이미지

글쓴이: siabard / 작성시간: 일, 2005/03/20 - 12:13오전

아.. 그러고보니 PS, PS2는 상당부분을 어셈블러로 작성해야합니다. PS3야 앞으로 C/C++을 지원하고 그래픽 효과에서 nVidia의 Cg를 지원한다고하지만 현재 콘솔머신-특히나 일본에서 나오는 PS/PS2나 Cube-는 어셈블러는 필수입니다.

여기에 더해서 소형전자기기에서 C나 어셈블러는 굉장히 많이 쓰입니다. 반쯤 농담이지만 프로그램에서 메모리사용량이 증가할수록 배터리 소모량이 증가한다는 이유때문에 어셈블러를 써가며 프로그램 크기를 줄였던 아픈 기억이 있기도.. ㅠ.ㅠ

사족입니다면 이전 PS/PS2게임에서의 대사창은 전부 비트맵 이미지였습니다. 폰트를 사용해서 출력하면 속도가 느린데다가 그거 랜더링하는데 필요한 메모리를 쓸바에야 대사창을 그냥 비트맵으로 출력하는게 더 효율적이라는 말도 안되는 이유가 있었죠. 그래서 파이널 판타지 7편해보면 대사를 몇줄 내외로 출력하는 모습을 볼 수 있습니다. PS 개발 포럼갔다가 반쯤 우스개식으로 들은거지만 막상 개발했을때는 참 절절했죠.. ㅠ.ㅠ
파이널 판타지 7 한글화 못한 이유는.. 저 비트맵 이미지 바꾸는 시간이 너무 막노동이라 그냥 영문판 내놨다는.. 그랬다는 전설이 있습니다.

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

ixevexi의 이미지

글쓴이: ixevexi / 작성시간: 일, 2005/03/20 - 12:13오후

Quote:
사족입니다면 이전 PS/PS2게임에서의 대사창은 전부 비트맵 이미지였습니다. 폰트를 사용해서 출력하면 속도가 느린데다가 그거 랜더링하는데 필요한 메모리를 쓸바에야 대사창을 그냥 비트맵으로 출력하는게 더 효율적이라는 말도 안되는 이유가 있었죠. 그래서 파이널 판타지 7편해보면 대사를 몇줄 내외로 출력하는 모습을 볼 수 있습니다. PS 개발 포럼갔다가 반쯤 우스개식으로 들은거지만 막상 개발했을때는 참 절절했죠.. ㅠ.ㅠ
파이널 판타지 7 한글화 못한 이유는.. 저 비트맵 이미지 바꾸는 시간이 너무 막노동이라 그냥 영문판 내놨다는.. 그랬다는 전설이 있습니다.

관심있어서 질문드립니다만,
PS/PS 게임의 대사창이 전부 비트맵 이미지란 말씀입니까?

제가 알기론 DVD 자막과 같이 폰트자체가 비트맵일뿐 대사창 자체가
비트맵은 아닌걸로 알고있는데요... 그래서 한글은 글자 수가 너무 많아서
기존 영어나 일어로 된 글자 비트맵을 치환하기가 어려워서 한글화가
어렵다고 들었습니다. 영어는 총해봐야 100개도 안될것이고...

C++, 그리고 C++....
죽어도 C++

siabard의 이미지

글쓴이: siabard / 작성시간: 일, 2005/03/20 - 6:19오후

예.. FF7은 아마 폰트를 이용한 조합방식이었을겁니다. 안그랬으면 이름을 정하지 못했을겁니다.

그리고 대화창 출력방식은..

두가지 다 있었습니다 .글자하나하나를 비트맵으로 만들고 그것을 조합해서 올리는 방법이 있었고, 대화창 전체를 아예 통이미지로 만드는 방법도 있었습니다. 후자의 경우는 메모리 사용량이나 디스크 사용량이 급격히 증가했지만 대화량이 적은 경우에 사용이 간단해서 종종 썼습니다.

일반적인 RPG에서는 전자를, 슈팅이나 액션등의 그다지 대화량이 많지 않은 게임에서는 후자를... 하지만 이제 이것도 추억속의 고생인듯 싶네요. 요즘 PS2게임 개발하는 사람들 얘기들어보면 개발킷이나 시스템이 많이 좋아져서 예전처럼 최적화하느라 씨름하는 일은 상당히 줄었다고 하네요..

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

둘러보기