C와 같은 고급 언어보다 어셈블리 프로그래밍이 더 오래 걸리고 프로그래밍하기가 더 어렵다는 주류 의견 인 것 같습니다. 따라서 이러한 이유로 고급 언어로 작성하는 것이 더 좋습니다. 더 나은 이식성의 이유로.
최근 x86 어셈블리로 글을 쓰고 있는데 이식성을 제외하고는 이러한 이유가 실제로 사실이 아니라는 생각이 들었습니다. 아마도 그것은 친숙하고 어셈블리를 잘 작성하는 방법을 아는 문제 일 것입니다. 또한 어셈블리 프로그래밍은 HLL 프로그래밍과는 상당히 다릅니다. 아마도 경험이 풍부하고 숙련 된 어셈블리 프로그래머는 숙련 된 C 프로그래머가 C로 작성하는 것처럼 쉽고 빠르게 프로그램을 작성할 수 있습니다.
어쩌면 어셈블리 프로그래밍이 HLL과 상당히 다르기 때문에 다른 사고, 방법 및 방법이 필요하기 때문에 익숙하지 않은 프로그램을 작성하는 것이 매우 어색해 보이므로 프로그램 작성에 나쁜 이름을 부여합니다.
이식성이 문제가되지 않는다면 실제로 C가 NASM과 같은 훌륭한 어셈블러를 어떻게 갖추었을까요?
편집 :
그냥 지적하십시오. 어셈블리로 작성하는 경우 명령 코드 만 작성하지 않아도됩니다. 매크로와 프로 시저 및 고유 한 규칙을 사용하여 다양한 추상화를 통해 프로그램을보다 모듈화되고 유지 보수 가능하며 읽기 쉽게 만들 수 있습니다. 이것은 좋은 어셈블리를 작성하는 방법에 익숙해지는 곳입니다.
답변
ASM은이 빈약 한 가독성을 하고 실제로 유지 보수가없는 높은 수준의 언어에 비해.
또한 C와 같이 널리 사용되는 다른 언어보다 ASM 개발자 수가 훨씬 적습니다 .
또한 고급 언어를 사용하고 새로운 ASM 명령어를 사용할 수있게 되면 (예 : SSE) 컴파일러를 업데이트하기 만하면 기존 코드에서 새 명령어를 쉽게 사용할 수 있습니다.
다음 CPU에 두 배의 레지스터가 있으면 어떻게됩니까?
이 질문의 반대는 다음과 같습니다. 컴파일러는 어떤 기능을 제공합니까?
ASM을 gcc -O3
할 수있는 것보다 더 잘 최적화하고 싶거나 최적화해야한다고 의심합니다 .
답변
Hell®, 저는 컴파일러입니다.
이 문장을 읽는 동안 방금 수천 줄의 코드를 스캔했습니다. 수년간의 연구에 기초한 방대한 양의 학술 연구를 기반으로 수백 가지의 다양한 최적화 기술을 사용하여 한 줄의 광고를 최적화 할 수있는 가능성을 탐색했습니다. 3 줄 루프를 수천 개의 명령으로 변환하면 속도가 빨라져 약간의 당혹감도 느끼지 않습니다. 나는 많은 시간 동안 최적화를하거나 가장 더러운 트릭을하는 것이 부끄러운 일이 아닙니다. 그리고 하루나 이틀 정도 날 원하지 않는다면, 내가 원하는대로 행동하고 할 것입니다. 한 줄의 코드를 변경하지 않고도 원하는 때마다 사용중인 메소드를 변환 할 수 있습니다. 코드가 어셈블리에서 어떻게 보이는지 보여줄 수도 있습니다. 다른 프로세서 아키텍처와 운영 체제 및 원하는 경우 다른 어셈블리 규칙에 따라 네, 몇 초만에요. 알다시피, 나는 할 수 있습니다. 알다시피 할 수 없습니다.
PS Oh, 그런데 당신이 작성한 코드의 절반을 사용하지 않았습니다. 나는 당신에게 호의를 베 풀었습니다.
답변
6502, Z80, 6809 및 8086 칩에 대한 어셈블러 헛간을 작성했습니다. 내가 다루는 플랫폼에서 C 컴파일러를 사용할 수있게 되 자마자 그만 두었고 즉시 생산성이 10 배 이상 높아졌습니다. 대부분의 훌륭한 프로그래머는 합리적인 이유로 사용하는 도구를 사용합니다.
답변
어셈블리 언어로 프로그래밍하는 것을 좋아하지만 고급 언어와 동일한 작업을 수행하려면 더 많은 코드가 필요하며 코드 줄과 버그 사이에는 직접적인 상관 관계가 있습니다. (이것은 수십 년 전에 The Mythical Man-Month 에서 설명되었습니다 .)
C를 ‘고수준 어셈블리’라고 생각할 수 있지만 그보다 몇 단계 앞서서 다른 세상에 있습니다. C #에서는 이것을 쓰는 것에 대해 두 번 생각하지 않습니다.
foreach (string s in listOfStrings) { /* do stuff */ }
이것은 어셈블리에 수십 줄, 수백 줄의 코드가있을 것입니다. 각 프로그래머는 다른 접근 방식을 취해야하며 다음 사람이 알아낼 것입니다. 따라서 많은 사람들이 다른 사람들이 읽을 수 있도록 프로그램이 작성되었다고 생각한다면 어셈블리는 일반적인 HLL보다 읽기 어렵습니다.
편집 : 나는 일반적인 작업에 사용되는 개인 코드 라이브러리와 C와 같은 제어 구조를 구현하기위한 매크로를 축적했습니다. 그러나 나는 GUI가 표준이 된 90 년대에 벽을 쳤다. 일상적인 일에 너무 많은 시간이 소비되었습니다.
ASM이 필요한 곳에서 마지막으로 수행 한 작업은 몇 년 전에 맬웨어를 퇴치하는 코드를 작성하는 것이 었습니다. 사용자 인터페이스가 없으므로 팽창이없는 재미있는 부분이었습니다.
답변
가독성, 유지 보수성, 코드 단축 및 버그 감소에 대한 다른 사람들의 답변 외에도 훨씬 쉬운 이유를 추가 할 것입니다.
프로그램 속도.
그렇습니다. 어셈블리에서는 코드를 수동으로 조정하여 모든 마지막주기를 사용하고 실제로 가능한 한 빨리 코드를 만들 수 있습니다. 그러나 누가 시간이 있습니까? 완벽하게 바보가 아닌 C 프로그램을 작성하는 경우 컴파일러는 최적화를 위해 정말 훌륭한 작업을 수행합니다. 아마도 추적을 걱정할 필요없이 수작업으로 수행 한 최적화의 최소 95 %를 수행 할 수 있습니다. 여기에 90/10 종류의 규칙이 있습니다. 최종 5 %의 최적화가 결국 95 %의 시간을 차지하게됩니다. 왜 귀찮게?
답변
평균 생산 프로그램에서 100k 라인의 코드를 말하고 각 라인이 약 8-12 개의 어셈블러 명령어라면, 이는 백만 개의 어셈블러 명령어입니다.
이 모든 것을 적절한 속도로 직접 작성할 수 있다고해도 (작성해야하는 코드의 8 배 더 많은 코드를 기억하십시오), 일부 기능을 변경하려면 어떻게됩니까? 백만 개의 지침 중 몇 주 전에 작성한 것을 이해하는 것은 악몽입니다! 모듈, 클래스, 객체 지향 디자인, 프레임 워크, 아무것도 없습니다. 그리고 가장 간단한 것조차도 작성해야하는 유사한 코드의 양이 가장 어려울 것입니다.
게다가 코드를 거의 고수준 언어로 최적화 할 수 없습니다. 예를 들어 C가 코드뿐만 아니라 의도 를 설명 하기 때문에 엄청난 수의 최적화를 수행하는 경우 어셈블러에서 코드를 작성하는 경우 어셈블러는 실제로 코드에서 주목할만한 최적화를 수행 할 수 없습니다. 당신이 쓰는 것은 당신이 얻는 것입니다, 그리고 나를 믿으십시오, 당신은 당신이 그것을 작성할 때 패치하고 패치하는 백만 개의 지침을 안정적으로 최적화 할 수 없습니다.
답변
글쎄, 나는 “구시대에”많은 어셈블리를 작성해 왔으며, 고급 언어로 프로그램을 작성할 때 훨씬 더 생산적임을 확신 할 수 있습니다.