어셈블리는 여전히 관련이 있습니까? [닫은]

프로젝트 코딩 및 / 또는 관리와 관련하여 어셈블리 언어와 고급 언어간에 큰 차이가 있습니까? 분명히 다른 언어보다 특정 작업을 수행하기 위해 어셈블리 언어로 더 많은 진술이 필요하지만 어셈블리 언어 타겟팅 (특히 x86 / x64 어셈블리 언어)을 기반으로 프로젝트를 실행하거나 실행 해야하는 방식에 영향을 미치는 차이점이 있습니다 ?

어셈블리 언어와 다른 언어 사이에 차이가있는 경우, 이들 중 적어도 일부가 다른 언어에 유리하다고 추측하는 것이 합리적입니다. 누구나 어셈블리 언어의 특정 단점과 이러한 단점을 완화하는 방법을 지적 할 수 있습니까?

한 가지 구체적인 예는 직원 가용성입니다. 숙련 된 어셈블리 언어 프로그래머를 찾는 데 어려움을 겪은 사람이 있다면 그렇다면이 문제를 완화하기 위해 어떤 단계를 수행해야합니까?

예-그러나 자주는 아닙니다.

어떤 의미에서 어셈블리는 실제로 기계 언어의 프록시 일 뿐이므로, 더 높은 수준의 언어로 할 수있는 모든 작업을 어셈블리에서 수행 할 수 있습니다.

항상 그 반대는 아닙니다. 예를 들어, 몇 년 전에 저는 커널 모드에서만 사용할 수있는 그래픽 상태를 변경하기위한 펑키 한 opcode를 가진 ARM CPU에서 작업했습니다. 그것들은 더 높은 수준의 언어에서 직접적으로 동등한 것이 아니며, 상태를 변경하기위한 Linux 커널 드라이버의 기능에는 일부 어셈블리가 포함되어 있다고 확신합니다.

80 년대와 90 년대 초반의 마이크로 프로세서에서, 정말 빠르게 실행하는 데 필요한 코드가 있다면 숙련 된 사람이 대부분의 C보다 더 최적화 된 어셈블리를 쉽게 작성할 수 있기 때문에 종종 어셈블리로 작성해야합니다 컴파일러가 생성 할 수 있습니다. 초기 맥 프로그램 중 일부는 완전히 조립되어 작성되었으며, 그 시대에 놀랍도록 빠르다. 전체 프로그램을 어셈블리로 작성하지 않더라도 임베디드 어셈블리를 통해 C에서 내부 루프를 최적화하는 일을 확실히했습니다.

그러나 1990 년대 중반에 상황이 변화하기 시작했습니다. CPU는 파이프 라이닝 및 분기 예측과 같은 기능을 포함하기 시작했기 때문에 가장 효율적인 명령 순서가 항상 사람에게 분명하지는 않았습니다. 그보다 더 나쁜 것은 가장 효율적인 순서는 같은 제품군의 CPU마다 다릅니다. 예를 들어 PowerPC 컴파일러는 일반적으로 G3, G4 및 G5 시리즈 용 대상 스위치를 제공했습니다. 동일한 객체 코드가 모든 객체에서 실행되지만 해당 시리즈 중 하나에서 더 효율적으로 실행됩니다.

그 이후로 특히 x86, PowerPC 및 SPARC와 같은 구조적으로 복잡한 CPU에서 명령 순서가 점점 더 복잡해졌습니다. (ARM은 여전히 ​​그렇게 간단하다고 생각합니다.) 더 큰 요인은 코드 크기입니다. 더 많은 CPU주기를 사용하지만 CPU 캐시에 남아있을 수있는 코드는 CPU주기를 적게 사용하지만 느린 메모리 페치를 트리거하는 코드보다 훨씬 빠르게 실행됩니다. . 현대의 주요 컴파일러는 사람이 합리적으로 할 수있는 것보다 CPU에서 코드를 최적화하는 작업을 훨씬 더 잘 수행 할 수 있습니다.

적어도 15 년 만에 집회를해야 할 충분한 이유를 찾지 못했습니다. 2011 년에 어셈블리의 주요 용도는 다음과 같습니다.

• 디버깅 할 때 디스 어셈블리 덤프를 읽으려면 오늘도합니다.
• 펑키 그래픽 모드와 같은 비표준 CPU 기능 다루기
• 컴파일러 작성-고급 언어를 번역하기 위해 사람이 읽을 수있는 중간 형식을 제공합니다.

자동차 알람 리모컨, 전화 배터리 모니터, 키보드 컨트롤러, 팬 속도 조절기 등 "소형 임베디드"용 마이크로 컨트롤러를 조립하지 않고 프로그래밍 해보십시오.

테두리가 움직이는 동안 항상 조립할 공간이 있습니다.

15 년 전 자전거 주행 거리계는 기계식, 전자 레인지는 아날로그 회로, TV 리모컨은 디지털 회로, 위성 TV 튜너는 어셈블리로 작성되었으며 전화 펌웨어는 C로, 컴퓨터 애플릿은 Java로 작성되었습니다.

7 년 전에 전자 레인지가 디지털 회로에 있었고 TV 리모컨이 조립품으로 작성되었고 TV 셋톱 박스가 C로 작성되었으며 휴대 전화가 Java 기반 UI를 실행했습니다.

요즘 자전거 주행 거리계는 디지털 회로에 있으며 전자 레인지는 펌웨어를 조립하고 TV 리모컨에는 C 펌웨어가 있고 TV 셋톱 박스는 Java를 실행하며 휴대 전화에는 Linux가 있습니다.

다음 7 년 동안 내기를 원하십니까? 더 많은 기술이 고급 제어 언어를 사용함에 따라 어셈블리는 새로운 토대를 얻게되며 계속해서 발전 할 것입니다. 오늘날 기계식 또는 아날로그 회로로 수행되는 작업을 살펴보십시오. 몇 년 안에 어셈블리를 내기 할 수 있습니다. 전등 스위치? 수돗물? 주전자? 칫솔?

조립에 프로그래밍 할 새 장치, 기기, 장난감, 일반 품목이 항상 있습니다.

나는 주로 MASM, NASM 및 TASM과 같은 내가 주로 사용했던 어셈블러를 기본으로하고 있습니다. TASM의 최신 버전 중 일부에는 OO를 지원하는 일부 기능이 있었지만 그 기능을 많이 사용하지 않았으며 이에 대해 언급하려고하지 않습니다.

첫째, 대부분의 언어는 적어도 다소 나무와 비슷한 구조로 이동했습니다. 객체 지향이든 객체 기반이든 정확히 무엇이든 시스템의 여러 부분 간의 관계에 대해 약간의 정의가 있습니다. 또한 시스템의 한 부분을 우발적 인 "혼잡"으로부터 "보호"할 수있는 부분도 많이 있습니다 (원하는 경우 보호를 우회 할 수 있음에도 불구하고). 대조적으로, 어셈블리 언어는 상대적으로 "편평하다"-시스템의 다른 부분에서 코드 (와 데이터) 사이의 관계는 주로 문서화와 이름 지정 규칙에 의해 설정된다.

결과적으로 이상적인 것보다 훨씬 더 밀접하게 코드를 결합하는 것이 훨씬 쉽습니다. 승인 된 인터페이스를 우회하여 어셈블리 언어 선택 (고성능, 작은 크기 등)을 선택하도록 요구 한 요구 사항이 종종 보상을 제공하므로 더 작고 빠른 코드를 얻을 수 있습니다 (일반적으로 많지는 않지만) 모든 차원에서 더 좋습니다). 언어와 도구 자체는 사용자가하는 일 (좋은지 나쁜지)을 제한하는 데 훨씬 덜 도움이되므로 문제를 방지하기 위해 관리자에게 훨씬 큰 부담이됩니다. 질적으로는 다르지만 양적으로는 그렇지 않습니다. 즉, 경영진은 어떤 방식 으로든 문제를 방지하기 위해 노력해야하지만, 어셈블리 언어의 경우 일반적으로 무엇이 더 있는지에 대한 더 많은 (그리고 더 엄격한) 지침이 필요합니다. 허용되지 않습니다.

이를 완화하는 것은 주로보다 신중한 지침,보다 숙련 된 직원의 더 많은 지침,보다 구체적이고 신중하게 시행되는 명명 규칙의 문제입니다.

직원 채용은 문제의 일부입니다. 그러나 내가 당면한 문제는 주로 내가 기대하지 않은 문제입니다. 어셈블리 언어 코드로 뛰어 들어 기쁘고 "전투기 선수"성격을 가진 사람을 찾는 것은 매우 쉽습니다. 어셈블리 언어 사용에 대한 사전 경험이 거의 없었음에도 불구하고 대부분은 합리적인 작업을 수행했습니다.

내가 겪은 어려움은 더 많은 고위급 인력을 찾는 것이 었습니다. 프로젝트를 최소한 통제와 비슷하게 유지할 수 있었고 코드를 합리적으로 유지하는 데 필요한 지침을 제공하는 (그리고 대부분 시행하는) 언어에 완전히 익숙하지 않은 사람들 유지 및 이해가 가능합니다.

되돌아 보면, 그 점에서 가장 큰 문제 중 하나가 발생했을 수도 있습니다. 내 부분에서 두 가지 문제의 원인을 볼 수 있습니다. 먼저, 내가 생각하는 프로젝트가 진행될 때까지, 나는 주로 주로 고급 언어 로 코딩 하고 어셈블리 언어 만 사용했습니다.최후의 수단으로. 따라서 내가 그것을 사용할 때 성능을 얻는 거의 모든 트릭은 공정한 게임 일뿐 만 아니라 예상이었습니다. 둘째, 어셈블리 언어로 완전히 (또는 주로) 작성된 일부 시스템에서 작업했을 때 다소 철분 한 프로젝트 관리자가있었습니다. 당시 나는 비교적 젊었을 때, 그들이 일을하는 방식을 솔직히 반박했기 때문에 그 반대의 경향이있었습니다. 돌이켜 보면, 그들이하고있는 일은 정말로 중요했고, 그들이 늙고 융통성이 없어서 만하지 않았습니다.

내 의견으로는 개발 플랫폼으로서의 어셈블리는 일상적인 사용과 관련이 없을 수 있습니다. 이 의견에 대한 주된 이유는 주어진 프로세스에서 제거되는 계산 능력의 양과 동일한 프로세스를 최적화하는 데 필요한 개발 시간의 양이 일반적으로 시간과 에너지의 가치가 없기 때문일 수 있습니다 (이에 대한 특정 용어가 있음) .. 그것은 사람 / 시간 또는 무언가처럼 들립니다. 내가 말한 것을 알고 있다면 편집하십시오.) 위에 언급 된 명백한 예외가 있지만 주류 프로그래밍이 진행되는 한 어셈블리는 자주 사용되지 않습니다.

이것은 소프트웨어 엔지니어링 연구의 맥락에서 프로그래밍을 배울 때 오늘날에도 여전히 관련이 있습니다. 그것은 저수준 프로그래밍 언어가 어떻게 보이고 느끼고 행동 하는지를 가르쳐줍니다. 계속해서 요즘 수업 시간에 우리가 무엇을 사용하는지 예를 들어 보겠습니다. 우리는 Stanley Warford (Pepperdine University USA)가 개발 한 pep / 8 어셈블리와 여기에 제공된 공개 소스 소프트웨어를 사용 합니다 . 주로 CPU를 가상화하고 코드가 실행되는 동안 코드를 단계별로 실행하면서 메모리 내용을 표시하기 때문에 주로 사용됩니다 (학습, 디버깅에 매우 유용).

따라서 사용 어셈블리에 따라 제 의견과 관련이있을 수도 있고 그렇지 않을 수도 있습니다.

"자동차가 있으면 트럭은 여전히 ​​관련이 있습니까?" 즉, 어셈블리는 자동차보다 트럭이 훨씬 적은 것과 같은 방식으로 매우 다양한 응용 분야를 가지고 있지만 높은 수준의 프로그래밍만큼 넓지는 않습니다.

알고리즘 최적화와 같은 필드에서 이미지 / 비디오 처리 알고리즘을 개선하기 위해 직접 프로세서 레지스터를 사용할 수 있습니다.

암호화와 같은 필드에서 동일한 방식으로 사용할 수 있습니다.

새로운 아키텍처의 새로운 프로세서 (Cell 마이크로 프로세서가 출시 된시기를 기억하십시오)에서는 부트 로더 등을 어셈블리로 작성해야합니다 (구형 프로세서의 경우에도 오랜 시간 사용 되었음). 그것).

더 많은 예제가 제공 될 수 있으므로 회사가 웹 / 모바일 개발에 전념하는 경우 회사가 초점을 맞추고있는 분야에 따라 다르지만 필요하지는 않지만 회사가 마이크로 컨트롤러에 초점을 둔 경우, 임베디드 시스템 등은 필요할 것입니다.

그리고 직원의 가용성에 달려 있습니다. 인텔, Qualcomm에 문의하면 큰 어셈블리 프로그래머 목록이 있어야합니다. "직장에서"여기에 트럭 운전자가 몇 명이나 있습니까? " 많이 생각하지는 않지만 다른 곳에는 없다는 의미는 아닙니다. "여기에 몇 명의 자동차 운전자가 있습니까?"라고 물으면 어떻게됩니까?

왜 정말로 학습 어셈블리가 최선의 방법인지 알고 싶다면. 이유는 다음과 같습니다.

1. 비주얼 베이직과 그 MS에 프로그래밍을한다면 어셈블리를 배울 필요가 없습니다.
2. 마이크로 컨트롤러 가제트를 만들 필요가 없다면 조립을 배울 필요가 없습니다.
3. 마이크로 컨트롤러 작업 중에 메모리 공간이 충분한 경우 어셈블리를 배울 필요가 없습니다 (마이크로 컨트롤러와 메모리를 인터페이스하는 동안 신이 도와줍니다)
4. 마이크로 컨트롤러 / 마이크로 프로세서의 전원과 같은 신을 원하지 않으면 어셈블리를 배울 필요가 없습니다.
5. 어셈블리를 모르는 것은 빙산을 아는 것과 같습니다. 귀하와 귀하의 마이크로 기능 중 25 %, 알지 못하거나 이해할 수없는 75 %를 볼 수 있습니다
6. 어셈블리에서 완전히 작성된 Kolibris OS를 실행하십시오! 5 초 이내에 부팅되고 1 초의 마우스 클릭으로 응용 프로그램이 실행되는 OS를 보셨습니까?
7. 최신 컴파일러에는 백엔드에 범용 기능이 있으므로 생성 된 최종 코드는 어셈블리에 비해 무겁습니다.

집회는 보복의 나타샤 로마노프와 같습니다. 매력과 마법입니다. 첫째, 그것은 당신을 물지 만 당신은 결코 맛을 잊지 않을 것이라고 믿습니다.