왜 조립식으로 프로그램을 짜나요?

왜 조립식으로 프로그램을 짜나요?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

3년 전에 문을 닫았어요

이 질문을 개선하다

저 밖의 모든 하급 해커들에게 질문이 있어요나는 블로그에서 이 문장을 우연히 발견했다.출처는 별로 중요하지 않다고 생각합니다(정말로 신경 쓴다면 Hack입니다).그것은 일반적인 발언이기 때문입니다.

예를 들어, 많은 현대 3-D 게임들은 고성능 코어 엔진을 C++ 및 어셈블리로 작성했습니다.

어셈블리에 관한 한, 코드는 컴파일러가 추가 명령어를 출력하거나 과도한 바이트를 사용하는 것을 원치 않기 때문에 어셈블리에 기술된 것입니까?아니면 C로 표현할 수 없는(또는 컴파일러가 그것들을 음소거하지 않으면 표현할 수 없는) 더 나은 알고리즘을 사용하고 있습니까?

나는 낮은 수준의 것들을 이해하는 것이 중요하다는 것을 완전히 이해한다.당신이 프로그램을 이해한 후에 조립하는 이유를 알고 싶을 뿐입니다.

내 생각엔 네가 이 진술을 잘못 읽고 있는 것 같아.

예를 들어, 많은 현대 3-D 게임들은 고성능 코어 엔진을 C++ 및 어셈블리로 작성했습니다.

게임(그리고 요즘 대부분의 프로그램)은 C++로 작성되는 것과 같은 방식으로 "어셈블리에 작성"되지 않습니다.이 블로그에서는 게임의 상당 부분이 조립형으로 설계되어 있다거나 프로그래머 팀이 둘러앉아 조립형으로 개발되고 있다고 하는 것은 아닙니다.

이것이 의미하는 것은 개발자들이 먼저 게임을 만들고 C++로 작동시키는 것이다.그런 다음 이를 프로파일링하고 병목 현상을 파악하여 조립 시 최적화할 가치가 있는지 여부를 파악합니다.또한 이미 경험이 있는 경우 어떤 부품이 병목현상이 될 수 있는지 알고 있으며, 자신이 만든 다른 게임으로부터 최적화된 작품들을 얻을 수 있습니다.

어셈블리의 프로그래밍 포인트는 항상 그래왔듯이 속도입니다.어셈블러에 많은 코드를 쓰는 것은 우스운 일이지만 컴파일러가 인식하지 못하는 최적화가 몇 가지 있습니다.그리고 코드 윈도우가 충분히 작으면 인간은 더 잘하게 될 것입니다.

예를 들어 부동 소수점에서는 컴파일러가 상당히 보수적인 경향이 있어 아키텍처의 고급 기능을 인식하지 못할 수 있습니다.에러를 받아들이고 싶다면 보통 컴파일러보다 더 잘 할 수 있습니다.또한 많은 시간을 할애하고 있는 것을 발견하면 어셈블리 내의 코드를 작성할 가치가 있습니다.

다음은 관련된 몇 가지 예를 제시하겠습니다.

게임의 예

• SSE 내장 함수를 사용한 게임 엔진의 최적화에 관한 인텔의 기사.최종 코드에서는 (인라인 어셈블러가 아닌) 내부 함수를 사용하기 때문에 순수 어셈블리의 양은 매우 작습니다.그러나 컴파일러의 어셈블러 출력을 보고 무엇을 최적화해야 하는지 정확히 파악합니다.

• 지진의 빠른 역제곱근입니다.이 루틴에는 어셈블러가 포함되어 있지 않지만 이러한 최적화를 수행하려면 아키텍처에 대해 알아야 합니다.저자는 어떤 연산이 빠르고(멀티, 시프트), 어떤 연산이 느리고(나눗셈, sqrt)를 알고 있습니다.따라서 느린 작업을 완전히 피할 수 있는 매우 까다로운 제곱근 구현 방법을 생각해냈습니다.

하이 퍼포먼스 컴퓨팅

• 게임의 영역 이외에서는, 과학 컴퓨팅에 종사하는 사람들은, 최신의 하드웨어로 신속히 동작시키기 위해서, 사물을 최적화하는 일이 자주 있습니다.물리학을 속일 수 없는 게임이라고 생각하세요.

  이것의 가장 최근의 예는 격자 양자 색역학(Latice QCD)입니다.이 백서에서는 IBM Blue Gene/L의 PowerPC 440에 크게 최적화된 매우 작은 컴퓨터 커널 하나로 이 문제가 요약되는 과정을 설명합니다.각 440에는 2개의 FPU가 있으며 컴파일러가 이용하기 어려운 특수한 3차 연산을 지원합니다.이러한 최적화가 없었다면 Ratis QCD의 실행 속도가 훨씬 느려졌을 것이며, 고가의 머신에서 수백만 시간의 CPU가 필요할 경우 비용이 많이 듭니다.

  만약 이것이 왜 중요한지 궁금하다면, 이 연구에서 나온 Science 기사를 확인해 보세요.이 사람들은 래티스 QCD를 사용하여 첫 번째 원리에서 양성자의 질량을 계산했습니다. 그리고 작년에 질량의 90%가 강한 힘의 결합 에너지에서 나오고 나머지는 쿼크에서 나온다는 것을 보여주었습니다.E=mc가² 작동 중입니다.여기 요약이 있습니다.

위의 모든 경우 어플리케이션은 100% 어셈블리에서 설계 또는 작성되지 않았습니다. 심지어 근접한 설계도 아닙니다.하지만 속도가 정말 필요할 때는 특정 하드웨어 상에서 비행하기 위해 코드의 핵심 부분을 작성하는 데 집중합니다.

저는 첫 직장(80대)부터 어셈블리 언어 전문 프로그래밍을 시작했습니다.임베디드 시스템의 경우 메모리 요구량(RAM 및 EPROM)이 낮았습니다.리소스를 쉽게 사용할 수 있는 엄격한 코드를 작성할 수 있습니다.

80년대 후반에 나는 C로 바꿨다.이 코드는 쓰기, 디버깅 및 유지보수가 용이했습니다.매우 작은 코드 조각이 어셈블러로 작성되었습니다.저에게는 컨텍스트 전환을 롤 유어 오너 RTOS로 작성할 때였습니다.('과학 프로젝트'가 아니면 더 이상 하지 말아야 할 일)

일부 Linux 커널 코드에 어셈블러 스니펫이 표시됩니다.최근에 스핀록이나 다른 동기화 코드로 찾아봤어요.이러한 코드 조각은 원자 테스트 및 세트 작업, 캐시 조작 등에 액세스해야 합니다.

대부분의 일반 프로그래밍에서 최신 C 컴파일러를 최적화하는 것은 어려운 일이라고 생각합니다.

저는 @altCognito의 의견에 동의합니다.당신의 시간은 문제에 대해 더 잘 생각하고 일을 더 잘 하는 데 쓰입니다.프로그래머들은 어떤 이유에서인지 마이크로 효율에 초점을 맞추고 매크로 효율은 무시합니다.성능을 향상시키기 위한 어셈블리 언어는 미세 효율입니다.시스템을 더 넓게 보기 위해 뒤로 물러서면 시스템의 매크로 문제가 노출될 수 있습니다.매크로 문제를 해결하면 성능을 향상시킬 수 있는 경우가 많습니다.매크로 문제가 해결되면 마이크로 레벨로 축소합니다.

마이크로 문제는 한 명의 프로그래머와 더 작은 영역에 있는 것 같습니다.매크로 레벨에서의 동작을 변경하려면 , 보다 많은 사람들과의 커뮤니케이션이 필요합니다.이것은 일부 프로그래머가 회피하는 것입니다.카우보이 vs 팀 문제 말이야

수년 동안 어셈블리 언어로 코드화하지 않았지만, 자주 보는 몇 가지 이유를 들 수 있습니다.

• 모든 컴파일러가 특정 CPU 최적화 및 명령 세트(인텔이 가끔 추가하는 새로운 명령 세트 등)를 사용할 수 있는 것은 아닙니다.컴파일러 라이터가 따라잡기를 기다리는 것은 경쟁 우위를 잃는 것을 의미합니다.

• 기존의 CPU 아키텍처 및 최적화와 실제 코드를 일치시키는 것이 용이합니다.예를 들어 가져오기 메커니즘, 캐싱 등에 대해 알고 있는 사항입니다.이것은 개발자에게 투명해야 하지만 사실은 그렇지 않기 때문에 컴파일러 라이터가 최적화할 수 있습니다.

• 특정 하드웨어 레벨의 액세스는 어셈블리 언어(예: 장치 드라이버 쓰기)를 통해서만 가능/실용적입니다.

• 코드의 최종 레이아웃 또는 거의 최종 레이아웃을 이미 알고 있기 때문에 어셈블리 언어에서는 고급 언어보다 형식 추론이 실제로 더 쉬울 수 있습니다.

• API가 없는 상황에서 특정 3D 그래픽 카드(1990년대 후반)를 프로그래밍하는 것은 어셈블리 언어에서 더 실용적이고 효율적이며 다른 언어에서는 불가능할 수 있습니다.하지만 이 역시 액셀러레이터 아키텍처를 기반으로 한 전문가 수준의 게임입니다. 예를 들어 데이터를 특정 순서로 수동으로 주고받는 것과 같습니다.

높은 수준의 언어가 가능할 때 어셈블리 언어를 사용하는 사람은 많지 않을 것입니다. 특히 그 언어가 C일 때는 더욱 그렇습니다.대량의 범용 코드를 수동으로 최적화하는 것은 비현실적입니다.

요즘은 적어도 시퀀셜 코드의 경우, 괜찮은 컴파일러는 거의 항상 경험이 풍부한 어셈블리 언어 프로그래머를 능가한다.하지만 벡터 코드에 대해서는 다른 이야기입니다.예를 들어 널리 배포된 컴파일러는 x86 SSE 유닛의 벡터 패럴렐 기능을 활용하는 데 그다지 큰 도움이 되지 않습니다.저는 컴파일러 라이터이며 SSE를 이용하는 것이 컴파일러를 신뢰하는 것이 아니라 독자적으로 사용해야 하는 이유 중 하나입니다.

게임은 퍼포먼스에 대한 욕구가 매우 높고, 그 사이에 옵티마이저는 꽤 훌륭하지만, 「마스터·프로그래머」는 조립중의 올바른 부품을 손으로 코딩하는 것으로, 한층 더 퍼포먼스를 짜낼 수 있습니다.

프로그램 최적화를 시작할 때는 반드시 프로파일링을 실시합니다.프로파일링 후 병목현상을 특정할 수 있어야 하며, 더 나은 알고리즘 등을 찾아도 병목현상이 해소되지 않을 경우 조립 시 몇 가지 사항을 코드화할 수 있습니다.

회사 내 소스에 어셈블러 루틴이 서너 개 있습니다(약 20MB 소스).모두 SSE(2)로, 2400 x 2048 이상의 이미지 조작과 관련되어 있습니다.

취미로 저는 컴파일러 작업을 하고 있는데, 거기에 조립자가 더 있습니다.런타임 라이브러리는 이러한 라이브러리로 가득 찬 경우가 많습니다.대부분의 라이브러리는 통상적인 절차 체계를 거스르는 것(예외의 도우미 등)과 관련되어 있습니다.

내 마이크로컨트롤러를 위한 어셈블러가 없다.대부분의 최신 마이크로 컨트롤러에는 많은 주변기기 하드웨어(인터럽트 제어 카운터, 심지어 직교 인코더 전체 및 시리얼 빌딩 블록)가 탑재되어 있기 때문에 어셈블러를 사용하여 루프를 최적화할 필요가 없어졌습니다.현재의 플래시 가격으로는 코드 메모리도 마찬가지입니다.또, 핀 대응 디바이스의 범위가 있는 경우가 많기 때문에, 시스템적으로 CPU의 전원이나 플래시 용량이 부족해도 업스케일링은 문제가 되지 않는 경우가 많습니다.

100,000대의 디바이스와 프로그래밍 어셈블러가 플래시 칩에 작은 카테고리를 끼워 넣는 것만으로 큰 비용을 절감할 수 있는 경우가 아니라면 말입니다.하지만 난 그런 부류에 속하지 않아.

많은 사람들이 임베디드가 어셈블러의 핑계라고 생각하지만, 그 컨트롤러는 Unix가 개발한 머신보다 CPU 파워가 높습니다.(마이크로칩은 40, 60 MIPS 마이크로컨트롤러가 10달러 이하에 부속되어 있습니다).

그러나 마이크로칩 아키텍처를 바꾸는 것은 쉽지 않기 때문에 많은 사람들이 레거시를 떠안고 있습니다.또한 HLL 코드는 아키텍처에 매우 의존합니다(하드웨어 주변기기, 레지스터를 사용하여 I/O를 제어하기 때문입니다).따라서 어셈블러에서 프로젝트를 계속 유지해야 하는 타당한 이유가 있을 수 있습니다(새로운 아키텍처에 대한 업무를 처음부터 셋업할 수 있었던 것은 행운이었습니다).하지만 사람들은 종종 조립공이 정말 필요하다고 스스로를 속인다.

GOTO를 사용할 수 있는지 물어봤을 때 교수님이 주신 답변은 여전히 마음에 듭니다(그것도 ASSEMBLER로 읽을 수 있습니다.이 기능이 필요한 이유에 대해 3페이지 분량의 에세이를 쓸 가치가 있다고 생각되면 사용할 수 있습니다. 결과와 함께 에세이를 제출해 주세요. "

나는 그것을 낮은 수준의 기능에 대한 지침으로 사용해 왔다.너무 비좁아 사용하지 말고, 제대로 된 동기를 부여하세요.심지어 (에세이처럼) 인위적인 장벽을 한두 개 던져 복잡한 추론을 정당화하지 않도록 하세요.

만약 당신이 Y2K의 모든 교정 노력에 함께 있었다면, 당신은 의회를 알았더라면 많은 돈을 벌 수 있었을 것입니다.그 주변에는 여전히 많은 레거시 코드가 쓰여져 있고, 때때로 그 코드는 유지보수가 필요합니다.

"그렇습니다." 하지만 어셈블러에서 코드를 작성하면 얻을 수 있는 이점은 거의 없습니다.조립해서 쓴 것에 대한 보답은 단순히 문제에 대해 더 열심히 생각하고 더 나은 방법을 생각하면서 시간을 보내는 것보다 적은 경향이 있다.

이 책에서는 Quake와 아이디 게임 엔진에 들어간 고성능 코드를 작성하는데 큰 역할을 한 존 카맥과 마이클 애브러쉬가 자세히 설명합니다.

또한 오늘날 컴파일러는 매우 스마트하고 숨겨진 아키텍처의 이점을 활용하는 많은 기술을 채택하고 있다는 Olafur Waage의 의견에 동의합니다.

보통 일반인의 어셈블리는 C보다 느리지만(C의 최적화로 인해) 많은 게임(Doom)은 어셈블리에 특정 섹션이 있어야 일반 머신에서 원활하게 실행할 수 있습니다.

여기 내가 언급하고 있는 예가 있다.

어셈블러 프로그래밍에는 다른 사람이 언급하지 않은 한 가지 측면이 있습니다. 즉, 애플리케이션 내의 모든 바이트가 컴파일러가 아닌 자신의 노력의 결과라는 만족감을 얻을 수 있습니다.80년대 초반처럼 앱 전체를 어셈블러로 다시 쓰고 싶지는 않지만, 가끔 그 느낌이 그립기도 합니다.

많은 사람들이 어셈블리 언어를 폄하하는 것을 좋아한다. 왜냐하면 그들은 어셈블리 언어를 코드화하는 법을 배운 적이 없고 단지 어렴풋이 접했을 뿐이기 때문이다. 그리고 그것은 그들을 아연실색하게 하거나 다소 겁먹게 만들었다.진정한 재능 있는 프로그래머들은 C나 어셈블리를 칭찬하기 때문에 비판하는 것은 무의미하다는 것을 이해할 것이다.사실 한쪽의 장점은 다른 한쪽의 단점이다.C의 조직화된 구문 규칙은 명확성을 향상시키지만 동시에 구조적인 규칙이 없는 전원 어셈블리의 모든 기능을 포기합니다.C 코드 명령은 논블로킹 코드를 생성하도록 되어 있습니다.이 코드는 프로그래밍 의도를 명확히 할 필요가 있다고 주장될 수 있지만 이는 전력 손실입니다.C에서 컴파일러는 if/elseif/else/end 내부로의 점프를 허용하지 않습니다.또는 서로 겹치는 다른 변수에 대해 2개의 for/end 루프를 쓸 수 없습니다.자기 수정 코드를 쓸 수 없습니다(또는 매끄러운 방법으로 쓸 수 없습니다).기존의 프로그래머들은 위의 것에 겁을 먹고 있으며, 그들이 전통적인 규칙을 따르도록 길러졌기 때문에 이러한 접근법의 힘을 어떻게 사용하는지조차 모를 것이다.진실은 다음과 같습니다. 오늘날 우리는 컴퓨팅 능력을 가진 기계가 우리가 사용하는 애플리케이션보다 훨씬 더 많은 것을 할 수 있지만 인간의 뇌는 규칙 없는 코딩 환경(= 어셈블리)에서 그것들을 코드화할 수 없기 때문에 스펙트럼을 크게 줄이고 코딩을 단순화하는 제한적인 규칙을 필요로 합니다.상기 한계로 인해 매우 비효율적으로 되지 않고서는 C코드로 쓸 수 없는 코드를 직접 작성하였습니다.그리고 대부분의 사람들이 조립에 쓰는 주된 이유라고 생각하는 속도에 대해서는 아직 이야기하지 않았습니다만, 만약 당신이 C에서 생각하는 것에 한정된다면 당신은 영원히 컴파일러의 노예가 될 것입니다.저는 항상 체스선수의 달인이 이상적인 어셈블리 프로그래머라고 생각했습니다만, C프로그래머는 그냥 "게임"을 플레이합니다.

이전 프로그래머가 C로 기술되어 있던 톤 검출 로직을 제외하고 주로 어셈블리 코드로 기술되어 있던 DSP 프로젝트를 부동 소수점(DSP! 고정 소수점)으로 계승한 적이 있습니다.톤 검출 로직은, 리얼 타임의 약 1/20으로 동작했습니다.

나는 결국 거의 모든 것을 처음부터 다시 썼다.일부 작은 인터럽트 핸들러와 인터럽트 처리 및 저레벨 주파수 검출과 관련된 수십 줄의 코드를 제외하고 거의 모든 것이 C에 있었습니다.이 코드는 이전 코드보다 100배 이상 빠르게 실행됩니다.

특히 손으로 쓴 어셈블러가 레지스터에 모든 것을 넣을 수 있지만 컴파일러가 잘 관리하지 못하는 경우, 많은 경우 큰 루틴보다 작은 루틴으로 속도를 높일 수 있는 기회가 더 많다고 생각합니다.루프가 충분히 커서 모든 것을 레지스터에 저장할 수 없다면 개선할 기회는 훨씬 적습니다.

오류는 행별로 실행되는 경향이 있습니다(문장, 코드 포인트 등).대부분의 문제에서 어셈블리는 상위 레벨의 언어보다 훨씬 더 많은 행을 사용하는 것이 사실이지만, 때때로 가장 적절한(가장 간결하고 가장 적은 행) 문제를 해결하는 경우가 있습니다.이러한 케이스의 대부분은, 임베디드 시스템의 드라이버나 비트 뱅킹등의 일반적인 용의자가 관련하고 있습니다.

적어도 MSVC에서는 SSE 코드가 컴파일러 내장 함수보다 어셈블리에서 더 잘 작동합니다.(즉, 추가 데이터 복사본을 만들지 않습니다.)

일부 지침/플래그/컨트롤은 단순히 C레벨이 아닙니다.

예를 들어 x86의 오버플로우 체크는 단순한 오버플로우 플래그입니다.이 옵션은 C에서는 사용할 수 없습니다.

또 다른 이유는 사용 가능한 컴파일러가 아키텍처에 적합하지 않고 프로그램에 필요한 코드의 양이 프로그래머가 아키텍처에서 길을 잃을 정도로 길거나 복잡하지 않은 경우입니다.임베디드 시스템에 마이크로 컨트롤러를 프로그래밍해 보십시오.일반적으로 조립이 훨씬 쉬워집니다.

다른 것들과 더불어 모든 상위 언어에는 일정한 제한이 있다.그렇기 때문에 ASM에서 프로그래밍하여 코드를 완전히 제어하도록 선택하는 사람도 있습니다.

20~60KB 범위의 매우 작은 실행 파일을 즐기는 사람도 있습니다.예를 들어 HiEdit 컨트롤의 작성자가 구현한 HiEditor를 체크해 주세요.HiEdit 컨트롤은 구문 강조 표시와 탭이 50KB까지밖에 되지 않습니다.제 컬렉션에는 ssheets나 html 렌더링과 같은 Excell의 골드 컨트롤이 20개 이상 있습니다.

많은 게임 개발자들이 이 정보에 놀랄 것이라고 생각합니다.

내가 아는 대부분의 게임들은 가능한 한 적은 조립품을 사용한다.경우에 따라서는 전혀 없고, 최악의 경우 1~2개의 루프 또는 기능이 있습니다.

그 인용문은 지나치게 일반화되어 있으며, 10년 전만큼 사실이라고는 할 수 없다.

하지만 단순한 사실이 진정한 해커의 집결을 방해해서는 안 돼;)

128바이트의 RAM과 4K의 프로그램 메모리를 탑재한 로우엔드 8비트 마이크로컨트롤러를 프로그래밍하는 경우 어셈블리를 사용할 수 있는 방법은 많지 않습니다.단, 보다 강력한 마이크로컨트롤러를 사용할 때는 정확한 시간에 어떤 액션이 필요할 수 있습니다.어셈블리 언어는 명령을 카운트하여 코드에서 사용되는 클럭 사이클을 측정할 수 있으므로 유용합니다.

매우 작은 CPU로 매우 작은 프로젝트를 진행하는 것 외에는 프로젝트 전체를 어셈블리로 프로그래밍하는 일은 없을 것입니다.단, 일부 내부 루프의 전략적 수동 코딩에 의해 성능 병목 현상을 완화할 수 있다는 것을 알 수 있습니다.

경우에 따라서는 실제로 필요한 것은 일부 언어구조를 옵티마이저가 사용방법을 알아낼 것으로 기대할 수 없는 명령으로 대체하는 것입니다.전형적인 예로는 DSP 어플리케이션에서 벡터 연산과 누적 연산은 옵티마이저가 검출하기 어렵지만 코드를 쉽게 취득할 수 있습니다.

예를 들어 SH4의 일부 모델은 4x4 행렬과 4 벡터 명령을 포함합니다.3x3 매트릭스 상의 등가 C 연산을 적절한 명령으로 대체함으로써 색상 보정 알고리즘의 퍼포먼스가 대폭 향상되는 것을 알 수 있었습니다.하드웨어의 가정과 일치하도록 보정 매트릭스를 4x4로 확대하는 적은 비용으로 실현했습니다.이는 12개 이하의 조립 라인을 작성하고 주변 C 코드의 몇 개소에 관련 데이터 유형 및 스토리지를 일치 조정함으로써 달성되었습니다.

It doesn't seem to be mentioned, so I thought I'd add it: in modern games development, I think at least some of the assembly being written isn't for the CPU at all. It's for the GPU, in the form of shader programs.

This might be needed for all sorts of reasons, sometimes simply because whatever higher-level shading language used doesn't allow the exact operation to be expressed in the exact number of instructions wanted, to fit some size-constraint, speed, or any combination. Just as usual with assembly-language programming, I guess.

Almost every medium-to-large game engine or library I've seen to date has some hand-optimized assembly versions available for matrix operations like 4x4 matrix concatenation. It seems that compilers inevitably miss some of the clever optimizations (reusing registers, unrolling loops in a maximally efficient way, taking advantage of machine-specific instructions, etc) when working with large matrices. These matrix manipulation functions are almost always "hotspots" on the profile, too.

I've also seen hand-coded assembly used a lot for custom dispatch -- things like FastDelegate, but compiler and machine specific.

Finally, if you have Interrupt Service Routines, asm can make all the difference in the world -- there are certain operations you just don't want occurring under interrupt, and you want your interrupt handlers to "get in and get out fast"... you know almost exactly what's going to happen in your ISR if it's in asm, and it encourages you to keep the bloody things short (which is good practice anyway).

I have only personally talked to one developer about his use of assembly. He was working on the firmware that dealt with the controls for a portable mp3 player. Doing the work in assembly had 2 purposes:

1. Speed: delays needed to be minimal.
2. Cost: by being minimal with the code, the hardware needed to run it could be slightly less powerful. When mass-producing millions of units, this can add up.

The only assembler coding I continue to do is for embedded hardware with scant resources. As leander mentions, assembly is still well suited to ISRs where the code needs to be fast and well understood.

A secondary reason for me is to keep my knowledge of assembly functional. Being able to examine and understand the steps which the CPU is taking to do my bidding just feels good.

Last time I wrote in assembler was when I could not convince the compiler to generate libc-free, position independent code.

Next time will probably be for the same reason.

Of course, I used to have other reasons.

No longer speed, but Control. Speed will sometimes come from control, but it is the only reason to code in assembly. Every other reason boils down to control (i.e. SSE and other hand optimization, device drivers and device dependent code, etc.).

If I am able to outperform GCC and Visual C++ 2008 (known also as Visual C++ 9.0) then people will be interested in interviewing me about how it is possible.

This is why for the moment I just read things in assembly and just write __asm int 3 when required.

I hope this help...

I've not written in assembly for a few years, but the two reasons I used to were:

• The challenge of the thing! I went through a several-month period years ago when I'd write everything in x86 assembly (the days of DOS and Windows 3.1). It basically taught me a chunk of low level operations, hardware I/O, etc.
• For some things it kept size small (again DOS and Windows 3.1 when writing TSRs)

I keep looking at coding assembly again, and it's nothing more than the challenge and joy of the thing. I have no other reason to do so :-)

The Dalvik VM that interprets the bytecode for Java applications on Android phones uses assembler for the dispatcher. This movie (about 31 minutes in, but its worth watching the whole movie!) explains how

"there are still cases where a human can do better than a compiler".

I don't, but I've made it a point to at least try, and try hard at some point in the furture (soon hopefully). It can't be a bad thing to get to know more of the low level stuff and how things work behind the scenes when I'm programming in a high level language. Unfortunately time is hard to come by with a full time job as a developer/consultant and a parent. But I will give at go in due time, that's for sure.

ReferenceURL : https://stackoverflow.com/questions/791533/why-do-you-program-in-assembly