왜 국회에서 프로그램이 더 자주 작성되지 않는가?
조립 프로그래밍은 C와 같은 고급 언어보다 시간이 오래 걸리고 프로그래밍이 더 어렵다는 것이 주류 의견인 것 같습니다.따라서, 이러한 이유와 휴대성이 뛰어난 이유로, 보다 높은 레벨의 언어로 기술하는 것이 추천 또는 상정되고 있는 것 같습니다.
최근 x86 어셈블리에서 글을 쓰고 있는데, 휴대성을 제외하고는 이러한 이유가 사실이 아닐 수 있다는 것을 알게 되었습니다.아마도 그것은 친숙한 것과 조립체를 잘 쓰는 방법에 관한 문제일 것이다.어셈블리의 프로그래밍과 HLL의 프로그래밍이 상당히 다르다는 것도 알게 되었습니다.아마도 훌륭하고 경험이 많은 조립 프로그래머는 C로 쓰는 숙련된 프로그래머처럼 쉽고 빠르게 프로그램을 작성할 수 있을 것이다.
조립 프로그래밍은 HLL과 상당히 달라서 다른 생각, 방법, 방법을 필요로 하기 때문에 익숙하지 않은 사람들을 위해 프로그래밍하는 것이 매우 어색해 보여서 프로그램 작성에 좋지 않은 이름이 붙었기 때문일 것이다.
휴대성이 문제가 되지 않는다면 NASM과 같은 좋은 어셈블러에 대해 C가 가지고 있는 것은 무엇일까요?
편집: 지적합니다.조립해서 쓸 때는 명령어 코드만으로 쓸 필요는 없습니다.매크로, 프로시저, 독자적인 표기법을 사용하면, 프로그램의 모듈러화, 유지보수성, 읽기 쉬운 설정을 실시할 수 있습니다.여기서 조립품을 잘 쓰는 방법을 익히는 것이 중요합니다.
저는 컴파일러입니다.
당신이 이 문장을 읽는 동안 수천 줄의 코드를 스캔했어요수백 가지 최적화 기술을 사용하여 단일 라인을 최적화할 수 있는 수백만 가지 가능성을 살펴보았습니다.여러분이 몇 년 동안 연구한 방대한 양의 학술 연구를 기반으로 합니다.세 줄의 루프를 수천 개의 명령으로 변환하여 속도를 높일 때, 저는 전혀 당황하지 않을 것입니다.나는 최대한의 최적화를 하거나 가장 더러운 재주를 부리는 것을 부끄러워하지 않는다.그리고 당신이 원하지 않는다면, 아마도 하루나 이틀 정도, 당신이 원하는 방식으로 행동할 것입니다.코드의 한 줄도 변경하지 않고 원하는 시간에 사용하는 방법을 변환할 수 있습니다.필요에 따라 어셈블리, 프로세서 아키텍처, 운영체제, 어셈블리 규약에 따라 코드가 어떻게 표시되는지 보여 줄 수도 있습니다.네, 몇 초면 됩니다.난 할 수 있고 넌 할 수 없으니까
추신. 아, 그런데 당신이 작성한 코드의 절반을 사용하지 않았군요.난 네 부탁을 들어줬는데 그걸 버렸어.
ASM은 높은 수준의 언어에 비해 가독성이 떨어지고 유지보수가 어렵습니다.
또한 C와 같은 다른 일반적인 언어에 비해 ASM 개발자가 훨씬 적습니다.
게다가 보다 고도의 언어를 사용해 새로운 ASM 명령(SSE 등)을 이용할 수 있는 경우는, 컴파일러를 갱신하는 것만으로, 낡은 코드가 새로운 명령어를 간단하게 사용할 수 있습니다.
다음 CPU에 2배의 레지스터가 있으면 어떻게 됩니까?
이 질문의 반대는 다음과 같습니다.컴파일러는 어떤 기능을 제공합니까?
ASM을 최적화할 수 있는지, ASM을 최적화할지는 의문입니다.gcc -O3할 수 있다.
6502, Z80, 6809 및 8086 칩에 대한 조립품 대량으로 작성했습니다.C 컴파일러가 어드레싱하고 있던 플랫폼에서 사용할 수 있게 된 직후에 이 작업을 중단했고, 즉시 최소 10배 이상의 생산성이 향상되었습니다.대부분의 훌륭한 프로그래머들은 합리적인 이유로 그들이 사용하는 도구를 사용합니다.
어셈블리 언어로 프로그래밍하는 것을 좋아하지만 고급 언어에서와 같은 작업을 수행하려면 더 많은 코드가 필요하며 코드 행과 버그 사이에는 직접적인 상관관계가 있습니다.(이것은 수십 년 전 신화적 인간의 달에서 설명되었습니다.)
C를 '고급 조립체'라고 생각할 수도 있지만, 그보다 몇 단계만 더 올라가면 당신은 다른 세계에 있게 됩니다.C# 에서는, 이 글을 쓰는 것에 대해 두 번 다시 생각하지 않습니다.
foreach (string s in listOfStrings) { /* do stuff */ }
수십 줄, 어쩌면 수백 줄의 코드가 조립되어 있을 것입니다.그것을 실장하는 프로그래머마다 다른 어프로치가 필요합니다.다음 사람이 알아내야 합니다.따라서 프로그램이 주로 다른 사람이 읽을 수 있도록 작성되어 있다고 믿는다면 어셈블리는 일반적인 HLL보다 읽기 어렵습니다.
편집: 일반적인 작업에 사용되는 코드와 C와 같은 제어 구조를 구현하기 위한 매크로의 개인 라이브러리를 축적했습니다.하지만 저는 GUI가 보편화된 90년대에 벽에 부딪혔습니다.일상적인 일에 너무 많은 시간을 할애하고 있었다.
ASM이 필수였던 마지막 작업은 몇 년 전 악성 프로그램과의 전쟁을 위한 코드를 작성하는 것이었습니다.사용자 인터페이스가 없기 때문에, 부풀어 오른 부분이 없는 것이 즐거웠습니다.
가독성, 유지 보수성, 코드 단축, 버그 감소 등의 다른 사람의 답변과 더불어 다음과 같은 이유를 덧붙입니다.
프로그램 속도
예, 어셈블리에서 코드를 수동으로 조정하여 모든 마지막 사이클을 최대한 빠르게 사용할 수 있습니다.하지만 누가 시간이 있나요?완전하지 않은 C 프로그램을 작성하면 컴파일러는 최적화를 매우 잘 할 수 있습니다.아마 95% 이상의 최적화를 수작업으로 수행했을 것입니다.추적할 필요가 없습니다.여기에는 90/10의 규칙이 있습니다.최적화의 마지막 5%가 시간의 95%를 차지하게 됩니다.그럼 왜 신경써?
평균 생산 프로그램이 10만 줄의 코드를 가지고 있고 각 라인이 약 8-12개의 조립자 명령이라면, 그것은 100만 개의 조립자 명령이 될 것입니다.
이 모든 것을 적당한 속도로 손으로 쓸 수 있다고 해도(작성해야 하는 코드의 8배 이상임을 기억하십시오), 일부 기능을 변경하려면 어떻게 해야 합니까?몇 주 전에 작성한 100만 가지 설명 중 하나를 이해하는 것은 악몽입니다!모듈도 없고 클래스도 없고 오브젝트 지향 설계도 없고 프레임워크도 없고 아무것도 없습니다.그리고 아무리 간단한 일에도 비슷한 코드를 작성해야 하는 것은 아무리 생각해도 벅찬 일입니다.
게다가 코드도 고급 언어만큼 최적화할 수 없습니다.예를 들어 C가 코드뿐만 아니라 어셈블러에서 코드만 작성하기 때문에 엄청난 수의 최적화를 수행하는 경우 어셈블러는 코드에 주목할 만한 최적화를 수행할 수 없습니다.여러분이 쓰는 것은 여러분이 얻는 것입니다. 그리고 제 말을 믿으세요. 여러분이 쓰는 동안 패치하고 패치하는 100만 개의 명령어를 확실하게 최적화할 수는 없습니다.
음, 저는 "옛날"에 많은 조립품을 써왔기 때문에, 높은 수준의 언어로 프로그램을 작성하면 훨씬 더 생산적이라고 장담할 수 있습니다.
적당한 수준의 어셈블러 능력은 특히 시스템 레벨이나 임베디드 프로그래밍에서 작업할 때 유용합니다.어셈블러를 그렇게 많이 써야 하기 때문이 아니라 때로는 박스가 실제로 무엇을 하고 있는지 이해하는 것이 중요하기 때문입니다.어셈블러의 개념과 문제에 대한 낮은 수준의 이해가 없다면 이는 매우 어려울 수 있습니다.
그러나 실제로 어셈블러에 코드를 많이 쓰는 것에 대해서는 몇 가지 이유가 있습니다.
전혀 필요 없다.초기 시스템 초기화나 C 함수나 매크로에 숨겨져 있는 몇 개의 어셈블러 fragment를 제외하고, 어셈블러에서 작성되었을 가능성이 있는 모든 매우 낮은 레벨의 코드는 C 또는 C++로 문제없이 쓸 수 있습니다.
상위 언어(C 및 C++)의 코드는 기능을 훨씬 적은 행으로 압축합니다.또한 버그 수가 소스 코드의 행 수와 관련이 있다는 연구 결과가 상당히 많이 있습니다.즉, 어셈블러와 C에서 해결된 동일한 문제는 단순히 더 길기 때문에 어셈블러에서 더 많은 버그가 발생합니다.같은 인수로 인해 Perl, Python 등의 상위 언어로 이행할 수 있습니다.
어셈블러에 쓸 때는 상세한 메모리 레이아웃, 명령 선택, 알고리즘 선택, 스택 관리 등 문제의 모든 측면에 대처해야 합니다.고급 언어는 이 모든 것을 없애기 때문에 LOC의 밀도가 매우 높아집니다.
기본적으로 위의 모든 것은 어셈블러 대 C 또는 다른 언어에서 사용할 수 있는 추상화 수준과 관련이 있습니다.어셈블러는 C와 같은 중간 레벨의 언어, 특히 상위 레벨의 언어를 통해 새로운 추상화를 비교적 쉽게 만들 수 있는 능력을 제공하는 자기 훈련을 통해 모든 추상화를 만들도록 강요합니다.
임베디드 프로그래밍 세계에서 대부분의 시간을 보내는 개발자로서 어셈블리는 죽은/구식 언어와는 거리가 멀다고 생각합니다.(드라이버 등) 금속에 가까운 수준의 코딩이 있어 때로는 보다 높은 수준의 언어로 정확하거나 효율적으로 표현할 수 없습니다.거의 모든 하드웨어 인터페이스 루틴을 어셈블러에 씁니다.
즉, 이 어셈블리 코드는 C 코드에서 호출할 수 있도록 랩되어 라이브러리처럼 취급됩니다.여러 가지 이유로 프로그램 전체를 조립해서 작성하지는 않습니다.우선은 휴대성입니다.우리의 코드 베이스는 다른 아키텍처를 사용하는 여러 제품에 사용되고 있으며, 이들 제품 간에 공유할 수 있는 코드의 양을 최대화하고 싶습니다.두 번째는 개발자의 친숙함입니다.간단히 말해서, 학교는 예전처럼 조립을 가르치지 않고, 우리의 개발자들은 조립보다 C에서 훨씬 더 생산적입니다.또, 어셈블리 언어 코드에는 없는 C 코드에 대해서, 폭넓은 「추가」(라이브러리, 디버거, 스태틱 해석 툴등)가 준비되어 있습니다.순수 어셈블리 프로그램을 만들고 싶어도 몇 가지 중요한 하드웨어 라이브러리는 Clibs로만 사용할 수 있기 때문에 작성할 수 없습니다.어떤 의미에서는 치킨/계란 문제입니다.이용 가능한 라이브러리와 개발/디버깅 도구가 많지 않기 때문에 사람들은 어셈블리에서 벗어나게 됩니다.그러나 libs/툴을 만드는 데 필요한 사람들이 어셈블리를 사용하지 않기 때문에 libs/툴은 존재하지 않습니다.
결국, 거의 모든 언어를 위한 시간과 장소가 있다.사람들은 가장 친숙하고 생산적인 것을 사용한다.어셈블리에 대한 프로그래머의 레퍼토리에 아마도 항상 그럴 위한 장소이지만, 대부분의 프로그래머는 그들은 거의 훨씬 적은 시간에 보다 효율적인 상위 수준 언어로 코드를 쓸 수 있는 것이다.
조립해서 쓸 때는 명령어 코드만으로 쓸 필요는 없습니다.매크로, 프로시저, 독자적인 표기법을 사용하면, 프로그램의 모듈러화, 유지보수성, 읽기 쉬운 설정을 실시할 수 있습니다.
즉, 기본적으로는 고도의 어셈블러를 능숙하게 사용하면 ASM 코드를 C(또는 자신의 발명품 중 또 다른 저급 언어)에 점점 더 가깝게 만들 수 있다는 것입니다.결국 C 프로그래머와 같은 생산성을 얻을 수 있게 됩니다.
질문에 대한 답변은 되었습니까?;-)
나는 이런 말을 함부로 하지 않는다.나는 정확히 그런 어셈블러와 시스템을 사용해서 프로그램을 짜왔다.게다가 어셈블러는 가상 프로세서를 타겟으로 하고, 다른 변환자는 타겟 플랫폼에 대한 어셈블러의 출력을 컴파일합니다.LLVM의 IF와 비슷하지만 초기 형태에서는 약 10년 전에 날짜가 지정되었습니다.따라서 휴대성과 효율성을 위해 필요한 특정 타깃 어시블러를 위한 루틴을 작성할 수 있는 기능이 있었습니다.
그 어셈블러를 사용하여 쓰는 것은 C와 같은 생산성이었고, GCC-3에 비해(내가 관여했을 무렵), 어셈블러/번역기는 대체로 빠르고 작은 코드를 생성했다.규모는 정말 중요했고, 이 회사는 프로그래머가 거의 없었고, 신입사원들이 유용한 일을 하기 전에 기꺼이 새로운 언어를 가르치려 했습니다.또, 어셈블러를 모르는 사람(고객등)이, 같은 호출 규약등을 사용해 같은 가상 프로세서에 대해서 C를 기입해 컴파일 할 수 있는 백업도 실시했습니다.이것에 의해, C는 깔끔하게 인터페이스 됩니다.그래서 그것은 근소한 승리처럼 느껴졌다.
조립 기술, 라이브러리 등을 개발하는 데 오랜 인력의 노력이 필요했습니다.물론 그 중 많은 부분이 휴대성을 높이는 데 사용되었지만, 만약 하나의 아키텍처만을 대상으로 했다면 노래를 모두 부르는 올 댄싱 어셈블러가 훨씬 더 쉬웠을 것입니다.
요약하면, C를 좋아하지 않을 수도 있지만, C를 사용하는 노력이 더 나은 것을 생각해 내는 노력보다 더 크다는 것을 의미하지는 않습니다.
어셈블리는 다른 마이크로프로세서 간에 이동할 수 없습니다.
우리가 더 이상 밖에 화장실에 가지 않는 이유나 라틴어나 아람어를 사용하지 않는 이유와 같은 이유.
테크놀로지가 등장해, 보다 간단하게 액세스 할 수 있게 됩니다.
편집 - 사람들을 불쾌하게 하는 것을 막기 위해 특정 단어를 삭제했습니다.
왜? 간단해
비교:
for (var i = 1; i <= 100; i++)
{
if (i % 3 == 0)
Console.Write("Fizz");
if (i % 5 == 0)
Console.Write("Buzz");
if (i % 3 != 0 && i % 5 != 0)
Console.Write(i);
Console.WriteLine();
}
와 함께
.locals init (
[0] int32 i)
L_0000: ldc.i4.1
L_0001: stloc.0
L_0002: br.s L_003b
L_0004: ldloc.0
L_0005: ldc.i4.3
L_0006: rem
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0
L_0014: ldc.i4.5
L_0015: rem
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0
L_0023: ldc.i4.3
L_0024: rem
L_0025: brfalse.s L_0032
L_0027: ldloc.0
L_0028: ldc.i4.5
L_0029: rem
L_002a: brfalse.s L_0032
L_002c: ldloc.0
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0
L_0038: ldc.i4.1
L_0039: add
L_003a: stloc.0
L_003b: ldloc.0
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret
기능 면에서는 동일합니다.두 번째는 조립기도 아니고NET IL(Java의 바이트 코드와 유사한 중간 언어).두 번째 컴파일은 IL을 네이티브 코드(즉, 거의 어셈블러)로 변환하여 더욱 암호화합니다.
컴파일러가 최적화하기 어려운 명령어를 사용하여 많은 것을 얻을 수 있는 경우에는 x86(_64)의 ASM도 타당하다고 생각합니다.예를 들어 x264는 부호화에 많은 asm을 사용하고 있어 속도가 크게 향상됩니다.
여러 가지 이유가 있겠지만 제가 생각할 수 있는 두 가지 이유는
- 어셈블리 코드는 확실히 읽기 어렵습니다(작성하는 데 시간이 더 걸릴 수 있습니다).
- 제품을 개발하는 대규모 개발 팀이 있는 경우 코드를 논리 블록으로 나누고 인터페이스에 의해 보호하는 것이 도움이 됩니다.
초기 발견 중 하나는 1960년대 경험에서 나온 브룩스의 신화적 인간월에서 찾을 수 있을 것이다. 사람들은 매일 디버깅된 코드 행에서 다른 언어처럼 어느 정도 생산적이었다는 것이다.이것은 분명히 보편적으로 사실이 아니며, 너무 무리하면 깨질 수 있지만, 브룩스 시대의 고급 언어에는 일반적으로 해당되었다.
따라서 생산성을 얻는 가장 빠른 방법은 코드 한 줄이 더 많은 작업을 수행하는 언어를 사용하는 것이며, 이는 적어도 FORTRAN이나 COBOL과 같은 복잡한 언어의 경우 또는 보다 현대적인 예 C를 제시하는 것입니다.
휴대성이 항상 문제가 되고 있습니다.지금은 아니더라도 적어도 최종적으로는 문제가 됩니다.프로그래밍 업계는 매년 수십억 달러를 들여 오래된 소프트웨어를 이식하고 있습니다. 이 소프트웨어는 작성 당시 "분명히" 휴대성 문제가 전혀 없었습니다.
어셈블리가 일반적이지 않게 되면서 악순환이 있었습니다. 즉, 고급 언어가 성숙함에 따라 어셈블리의 언어 명령 세트가 프로그래머의 편의보다는 컴파일러의 편의성을 위해 더 많이 구축되었습니다.
따라서 현실적으로 어떤 레지스터를 사용해야 하는지, 어떤 명령어가 더 효율적인지 올바른 결정을 내리는 것은 매우 어려울 수 있습니다.컴파일러는 휴리스틱스를 사용하여 어떤 단점이 가장 좋은지를 파악할 수 있습니다.작은 문제를 잘 생각해 보고 현재 매우 정교한 컴파일러를 능가하는 로컬 최적화를 찾을 수 있을 것입니다.그러나 평균적으로는 우수한 컴파일러가 뛰어난 프로그래머보다 첫 번째 시도에서 더 잘할 가능성이 높습니다.결국엔 존 헨리처럼 기계를 이길 수도 있지만, 거기까지 도달하는 데 정말 지칠 수도 있습니다.
우리의 문제 또한 현재 상당히 다르다.1986년에 저는 화면에 수백 개의 픽셀을 넣는 작은 프로그램에서 좀 더 빠른 속도를 낼 수 있는 방법을 찾고 있었습니다. 저는 애니메이션이 덜 덜 덜 흔들렸으면 좋겠다고 생각했습니다.어셈블리 언어에 대한 공정한 사례입니다.저는 계약용어와 서비스 정책에 대한 추상적인 개념을 어떻게 표현해야 할지 고민하고 있습니다.그리고 비즈니스맨들이 사용하는 언어에 가까운 것을 읽고 싶습니다.LISP 매크로와는 달리 어셈블리 매크로는 규칙에 그다지 영향을 주지 않기 때문에 좋은 어셈블러에서는 DSL에 상당히 가까운 것을 얻을 수 있어도 Ruby, Boo, Lisp, C# 또는 F#에 같은 코드를 쓰면 문제가 발생하지 않는 온갖 종류의 기호가 생기기 쉽습니다.
그러나 효율적인 어셈블리 언어로 문제를 쉽게 표현할 수 있다면 더 강력한 힘을 얻을 수 있습니다.
다른 사람들이 말한 것의 대부분도 마찬가지이다.
C가 발명되기 전의 옛날에는 COBOL이나 FORTRAN 같은 고급 언어밖에 없었던 시절에는 어셈블러에 의지하지 않고서는 할 수 없는 일이 많았다.모든 디바이스에 액세스 할 수 있는 등, 폭넓은 유연성을 얻을 수 있는 유일한 방법입니다.하지만 그 후 C가 발명되었고, 조립이 가능한 거의 모든 것이 C에서 가능했습니다.그 이후로 나는 아주 적은 수의 조립품을 썼다.
그렇다고는 해도, 새로운 프로그래머가 어셈블러에서 쓰는 것을 배우는 것은 매우 유용한 연습이라고 생각합니다.실제로 많이 사용하기 때문이 아니라 컴퓨터 내부에서 실제로 무슨 일이 일어나고 있는지 알기 때문입니다.저는 프로그래머들로부터 많은 프로그래밍 오류와 비효율적인 코드를 봐왔습니다. 프로그래머들은 비트, 바이트, 레지스터에서 실제로 무슨 일이 일어나고 있는지 전혀 알지 못합니다.
조립해서 프로그래밍을 한 지 한 달 정도 됐어요.저는 종종 코드를 C로 작성하여 조립에 컴파일하여 도움을 줍니다.C 컴파일러의 최적화 능력을 최대한 활용하지 못하고 있는 것 같습니다만, CASM 소스에 불필요한 조작이 포함되어 있는 것 같습니다.그래서 나는 좋은 C 컴파일러가 좋은 어셈블리 코더를 능가한다는 말이 항상 맞는 것은 아니라는 것을 깨닫기 시작했다.
어쨌든, 제 조립 프로그램은 너무 빨라요.조립을 하면 할수록 코드를 쓰는 데 걸리는 시간이 줄어듭니다.그렇게 어렵지 않기 때문입니다.또한 조립품의 가독성이 떨어진다는 언급은 사실이 아니다.프로그램에 라벨을 올바르게 붙이고 추가 설명이 필요할 때 코멘트를 하면 준비가 완료됩니다.실제로 프로그래머는 프로세서 수준에서 무슨 일이 일어나고 있는지를 파악하고 있기 때문에 어셈블리가 더 명확합니다.나는 다른 프로그래머들에 대해서는 모르지만, 나는 블랙박스 같은 것에 있는 것보다 무슨 일이 일어나고 있는지 아는 것을 좋아한다.
컴파일러의 진정한 장점은 컴파일러가 패턴과 관계를 이해하고 소스의 적절한 위치에 자동으로 코드화할 수 있다는 것입니다.일반적인 예로는 C++의 가상 함수를 들 수 있습니다.이 예에서는 컴파일러가 함수 포인터를 최적으로 매핑해야 합니다.단, 컴파일러는 컴파일러 제조사가 컴파일러를 허용하는 작업에만 한정됩니다.이것은 때때로 프로그래머들이 그들의 코드로 이상한 것들을 하는 것에 의지해야 하는 것으로 이어지는데, 그들이 조립으로 세 번 할 수 있었을 때 코딩 시간을 더한다.
저는 개인적으로 시장이 고급 언어를 많이 지원한다고 생각합니다.어셈블리 언어가 현재 존재하는 유일한 언어라면 프로그래밍 인구가 약 70% 줄어들 것이고, 90년대는 세상이 어떻게 될지 누가 알 수 있을 것입니다.더 높은 수준의 언어는 더 넓은 범위의 사람들에게 어필합니다.이것에 의해, 보다 많은 프로그래머가, 세계에 필요한 인프라스트럭처를 구축할 수 있게 됩니다.중국과 인도와 같은 개발도상국들은 자바와 같은 언어들로부터 큰 혜택을 받는다.이들 국가는 IT인프라스트럭처를 빠르게 발전시켜 사람들의 상호접속이 더욱 강화될 것입니다.즉, 고급 언어가 인기를 끄는 것은 우수한 코드를 생성하기 때문이 아니라 세계 시장의 수요를 충족시키기 위해서입니다.
저는 지금 컴포넌트에서 조립을 배우고 있는데, 재미있긴 하지만 쓰기에도 매우 비효율적입니다.일이 잘 풀리려면 더 많은 세부사항을 머릿속에 새겨야 하고, 같은 것을 쓰는 것도 느리다.예를 들어, C++의 루프용 단순한 6라인은 18라인 이상의 어셈블리와 같을 수 있습니다.
개인적으로 하드웨어 레벨에서의 동작에 대해 배우는 것은 매우 즐겁습니다.컴퓨팅의 동작에 대해 매우 감사하게 생각합니다.
C가 좋은 매크로 어셈블러에 대해 가지고 있는 것은 C 언어입니다.타이프 체크루프 구성자동 스택 관리. (거의) 자동 변수 관리.어셈블러의 동적 기억 기술은 엉덩이에 엄청난 골칫거리입니다.링크된 목록을 올바르게 실행하는 것은 C에 비해 매우 무섭습니다.또한 리스트 foo.insert()도 마찬가지입니다.그리고 디버깅 - 디버깅이 쉬운 것에 대해서는 논쟁의 여지가 없습니다.HLLs가 저 아래에서 손을 잡는다.
조립자 경력 절반 가까이를 코드화했으니까 바보 같은 생각을 하기가 쉽죠이것은 C 컴파일러가 무엇을 하고 있는지 보는 데 도움이 되고, C 컴파일러가 효율적으로 처리할 수 있는 코드를 다시 쓰는 데 도움이 됩니다.C로 작성된 잘 생각한 루틴은 약간의 작업으로 어셈블러에서 원하는 것을 정확하게 출력할 수 있습니다.또, 휴대성도 뛰어납니다!크로스 플랫폼 때문에 오래된 ASM 루틴 몇 개를 C로 다시 써야 했는데 재미없어요.
아니요, 저는 C를 고수하고 HLL로 얻을 수 있는 생산성 시간에 비해 퍼포먼스가 약간 저하되는 문제에 대처합니다.
제가 개인적으로 조립식 프로그램을 더 자주 쓰지 않는 이유를 대답할 수 있을 뿐이고, 주된 이유는 제작하는 것이 더 지루하기 때문입니다.또, 금방 눈치채지 못하고 미묘하게 틀리기 쉽다고 생각합니다.예를 들어, 하나의 루틴에서 레지스터를 사용하는 방법을 변경할 수 있지만, 한 곳에서 레지스터를 변경하는 것을 잊어버릴 수 있습니다.조립이 잘 될 것이고 한참 뒤에나 알아차릴 수 있을 것이다.
그렇다고 해도, 조립에는 아직 유효한 용도가 있다고 생각합니다.예를 들어 대량의 데이터를 처리하고, SIMD를 사용하고, 편집증적인 "모든 비트는 신성하다"[인용 V]를 따르기 위해 최적화된 조립 루틴이 많이 있습니다.Stob] 어프로치. (그러나 단순한 어셈블리의 실장은 컴파일러가 생성하는 것보다 훨씬 나쁜 경우가 많습니다.)
C는 매크로 어셈블러입니다!그리고 최고야!
어셈블리가 할 수 있는 거의 모든 것을 할 수 있고, 휴대할 수 있으며, 대부분의 경우 조립 코드를 사용할 수 있습니다.이렇게 하면 어셈블리에서 작성해야 하는 프로그램은 극히 일부만 남고 어셈블리만 남습니다.
또한 높은 수준의 추상화와 휴대성은 대부분의 사람들이 시스템 소프트웨어를 C로 작성하는 것을 더 가치 있게 만듭니다.휴대성은 현재 필요하지 않을 수 있지만, 프로그램 작성에 많은 시간과 비용을 투자한다면 향후 사용할 수 있는 용도로 제한하고 싶지 않을 수도 있습니다.
사람들은 다른 방향도 있다는 것을 잊은 것 같다.
애초에 왜 어셈블러에 글을 쓰는 거야?그 프로그램을 정말 낮은 수준의 언어로 써보는 건 어때요?
대신
mov eax, 0x123
add eax, 0x456
push eax
call printInt
너는 차라리 글을 쓰는 편이 낫다.
B823010000
0556040000
50
FF15.....
프로그램의 정확한 크기를 알 수 있고 명령의 값을 다른 명령의 입력으로 재사용할 수 있습니다.또한 명령어를 작성하기 위해 어셈블러가 필요 없고 텍스트 에디터도 사용할 수 있습니다.
그리고 당신이 이 문제에 대해 여전히 의원님을 선호하는 이유는 다른 사람들이 C를 선호하는 이유입니다.
항상 그런 식이기 때문에, 시간이 흐르고 좋은 일도 없어집니다.
그러나 asm 코드를 작성할 때는 고급 언어를 코드화할 때와 전혀 다른 느낌이 듭니다.단, 생산성이 훨씬 떨어집니다.마치 화가처럼 자유롭게 원하는 대로 그릴 수 있습니다(CPU 기능만 있으면 가능).그래서 내가 좋아하는 거야.이 언어가 사라지다니 유감입니다.하지만 누군가가 여전히 기억하고 암호화할 때, 그것은 절대 죽지 않을 거예요!
$$$
기업은 코드를 $$$로 변환하는 데 도움이 되는 개발자를 고용하고 있습니다.유용한 코드를 빠르게 생성할수록 기업은 코드를 $$$로 빠르게 전환할 수 있습니다.
일반적으로 더 높은 수준의 언어를 사용하면 더 많은 양의 유용한 코드를 생성할 수 있습니다.그렇다고 해서 집회가 제자리를 찾지 못하는 것은 아니다. 다른 곳에서는 아무 것도 할 수 없는 때와 장소가 있기 때문이다.
The advantage of HLL's is even greater when you compare assembly to a higher level language than C, e.g. Java or Python or Ruby. For instance, these languages have garbage collection: no need to worry about when to free a chunk of memory, and no memory leaks or bugs due to freeing too early.
As others mentioned before, the reason for any tool to exist is how efficiently it can work. As HLLs can accomplish the same jobs as many lines of asm code I guess it's natural for assembly to be superseded by other languages. And for the close-to-hardware fiddling - there's inline assembly in C and other variants as per language. Dr. Paul Carter in says in the PC Assembly Language
"...a better understanding of how computers really work at a lower level than in programming languages like Pascal. By gaining a deeper understanding of how computers work, the reader can often be much more productive developing software in higher level languages such as C and C++. Learning to program in assembly language is an excellent way to achieve this goal."
We've got introduction to assembly in my college courses. It'll help to clear concepts. However I doubt any of us would write 90% of code in assembly. How relevant is in-depth assembly knowledge today?
Flipping through these answers, I'd bet 9/10 of the responders have never worked with assembly.
This is an ages old question that comes up every so often and you get the same, mostly misinformed answers. If it weren't for portability, I'd still do everything in assembly myself. Even then, I code in C almost like I did in assembly.
ReferenceURL : https://stackoverflow.com/questions/2684364/why-arent-programs-written-in-assembly-more-often
'source' 카테고리의 다른 글
| Vue vs 상태에서 글로벌 변수 생성 (0) | 2022.08.31 |
|---|---|
| HTML 내의 Vue 컴포넌트를 다른 Vue 컴포넌트에 추가하려면 어떻게 해야 합니까? (0) | 2022.08.31 |
| Java에서 호스트 이름을 가져오는 권장 방법 (0) | 2022.08.31 |
| Java 8 인터페이스 방식에서 "동기화"가 허용되지 않는 이유는 무엇입니까? (0) | 2022.08.31 |
| Nuxt 모듈을 Storybook으로 가져옵니다. (0) | 2022.08.31 |