hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
제퍼 (운영체제) 특징
제퍼는 자원 제약적인 임베디드 또는 마이크로컨트롤러 기반 응용 프로그램을 개발하는 데 필요한 모든 구성 요소를 제공하는 것을 목표로 한다. 다음을 포함한다.
제퍼는 리눅스 커널에서 상속받은 Kconfig와 devicetree를 구성 시스템으로 사용하지만, 비-유닉스 운영 체제에 대한 이식성을 위해 파이썬 프로그래밍 언어로 구현되었다. RTOS 빌드 시스템은 CMake를 기반으로 하여 Zephyr 응용 프로그램이 리눅스, macOS, 마이크로소프트 윈도우에서 빌드될 수 있도록 한다.
제퍼는 저장소 관리, 하드웨어에 프로그램 다운로드 등을 위한 West라는 범용 도구를 가지고 있다.
초기 제퍼 커널은 이중 나노커널과 마이크로커널 설계를 사용했다. 2016년 12월 제퍼 1.6부터 모놀리식 커널로 변경되었다.
커널은 다른 소형 OS와 구별되는 여러 기능을 제공한다.
보안 유지 및 개선에 전념하는 그룹이 있다. 또한 커뮤니티가 소유하고 지원한다는 것은 전 세계 오픈 소스 개발자들이 코드를 검토하여 보안을 크게 강화한다는 것을 의미한다.
ARM Cortex-R
ARM Cortex-R은 Arm 홀딩스가 라이선스하는 32비트 및 64비트 RISC ARM 아키텍처 프로세서 코어 계열이다. 이 코어들은 하드 실시간 및 안전 필수 애플리케이션에 최적화되어 있다. 이 계열의 코어들은 ARM 실시간(R) 프로파일을 구현하는데, 이는 세 가지 아키텍처 프로파일 중 하나이며, 다른 두 가지는 Cortex-A 계열에서 구현되는 애플리케이션(A) 프로파일과 Cortex-M 계열에서 구현되는 마이크로컨트롤러(M) 프로파일이다. ARM Cortex-R 마이크로프로세서 계열은 현재 ARM Cortex-R4(F), ARM Cortex-R5(F), ARM Cortex-R7(F), ARM Cortex-R8(F), ARM Cortex-R52(F), ARM Cortex-R52+(F), 및 ARM Cortex-R82(F)로 구성되어 있다.
ARM Cortex-R 개요
ARM Cortex-R은 ARM 아키텍처의 R 프로파일을 구현하는 ARM 코어 계열이다. 이 프로파일은 고성능 하드 실시간 및 안전 필수 애플리케이션을 위해 설계되었다. 이는 애플리케이션 처리를 위한 A 프로파일과 유사하지만, 오류 허용성을 높이고 하드 실시간 및 안전 필수 애플리케이션에 더 적합하도록 기능을 추가한다.
추가된 실시간 및 안전 필수 기능은 다음과 같다:
Armv8-R 아키텍처는 Armv7-A 아키텍처에서 도입된 것과 유사한 가상화 기능을 포함한다. 하이퍼바이저의 제어 하에 여러 운영 체제를 서로 격리할 수 있도록 두 단계의 MPU 기반 변환이 제공된다.
ARM Cortex-R 개요
2020년 9월 4일에 도입된 R82 이전에는 Cortex-R 계열에는 메모리 관리 장치(MMU)가 없었다. R82 이전 모델은 가상 메모리를 사용할 수 없었으므로, 리눅스와 같은 모든 기능을 갖춘 많은 애플리케이션에는 적합하지 않았다. 그러나 전체 제어에 중점을 둔 많은 실시간 운영체제 (RTOS)는 전통적으로 MMU의 부족을 버그가 아니라 기능으로 간주했다. R82에서는 리눅스와 같은 페이지 기반 OS와 병렬로 전통적인 RTOS를 실행할 수 있다. 여기서 리눅스는 유연성을 위해 MMU를 활용하고, RTOS는 실시간 기능에 대한 완전한 예측 가능성을 유지하기 위해 RTOS에 할당된 페이지에서 MMU를 직접 변환 모드로 고정시킨다.
Arm 홀딩스는 자체 설계에 기반한 CPU 장치를 제조하거나 판매하지 않고, 관심 있는 당사자에게 코어 설계를 라이선스한다. ARM은 비용 및 제공물에 따라 다양한 라이선스 조건을 제공한다. 모든 라이선스 사용자에게 ARM은 ARM 코어의 통합 가능한 하드웨어 설명은 물론 완전한 소프트웨어 개발 도구 세트와 ARM CPU를 포함하는 제조된 규소를 판매할 권리를 제공한다.
통합 장치 제조업체(IDM)는 합성 가능한 RTL(베릴로그로 작성됨) 형태로 ARM 프로세서 IP를 받는다. 이 형태로, 그들은 아키텍처 수준의 최적화 및 확장을 수행할 수 있다. 이를 통해 제조업체는 더 높은 클럭 속도, 매우 낮은 전력 소비, 명령어 세트 확장, 크기 최적화, 디버그 지원 등과 같은 맞춤형 설계 목표를 달성할 수 있다. 특정 ARM CPU 칩에 어떤 구성 요소가 포함되었는지 확인하려면 제조업체 데이터시트 및 관련 문서를 참조해야 한다.
ARM Cortex-R 응용 분야
Cortex-R은 매우 낮은 지연 시간 및 높은 수준의 안전성이 요구되는 컴퓨터 제어 시스템에 사용하기에 적합하다. 하드 실시간, 안전 필수 애플리케이션의 예로는 자동차의 현대적인 전자 제동 시스템이 있다. 이 시스템은 수많은 센서 데이터 입력에 빠르고 반응해야 할 뿐만 아니라, 인명 안전에도 책임이 있다. 이러한 시스템의 고장은 심각한 부상이나 인명 손실로 이어질 수 있다.
하드 실시간 및 안전 필수 애플리케이션의 다른 예시는 다음과 같다:
팔딱이지렁이속
팔딱이지렁이속 (학명: Perionyx 페리오닉스[*])은 지렁이과에 속하는 환형동물의 한 속이다.
이 속은 거의 전 세계에 분포한다.
ARM Cortex-M
ARM Cortex-M은 ARM 리미티드가 라이선스를 부여한 32비트 RISC ARM 아키텍처 프로세서 코어 그룹이다. 이 코어들은 저가형 및 에너지 효율적인 집적 회로에 최적화되어 있으며, 수백억 개의 소비자 기기에 내장되어 있다. 주로 마이크로컨트롤러 칩의 주요 구성 요소로 사용되지만, 다른 유형의 칩 내부에도 내장되기도 한다. Cortex-M 제품군은 Cortex-M0, Cortex-M0+, Cortex-M1, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, Cortex-M33, Cortex-M35P, Cortex-M52, Cortex-M55, Cortex-M85로 구성된다. Cortex-M4 / M7 / M33 / M35P / M52 / M55 / M85 코어에는 부동소수점 장치 (FPU) 옵션이 제공되며, 실리콘에 포함될 경우 이 코어들은 때때로 "Cortex-MxF"로 알려져 있으며, 여기서 'x'는 코어 변형을 나타낸다.
ARM Cortex-M 개요
ARM Cortex-M 제품군은 마이크로컨트롤러, ASIC, ASSP, FPGA, SoC에 사용하도록 설계된 ARM 마이크로프로세서 코어이다. Cortex-M 코어는 일반적으로 전용 마이크로컨트롤러 칩으로 사용되지만, 전원 관리 컨트롤러, I/O 컨트롤러, 시스템 컨트롤러, 터치스크린 컨트롤러, 스마트 배터리 컨트롤러 및 센서 컨트롤러와 같은 SoC 칩 내부에도 "숨겨져" 있다.
Cortex-A 코어와의 주요 차이점은 Cortex-M 코어는 "완전한" 운영체제에 필수적인 것으로 간주되는 가상 메모리용 메모리 관리 장치 (MMU)가 없다는 것이다. Cortex-M 프로그램은 대신 베어 메탈 또는 Cortex-M을 지원하는 다양한 실시간 운영체제 중 하나에서 실행된다.
과거에는 8비트 마이크로컨트롤러가 매우 인기가 있었지만, 저가형 Cortex-M 칩의 가격이 하락하면서 Cortex-M은 점차 8비트 시장을 잠식하고 있다. Cortex-M은 32비트 수학 연산에 이점이 있는 응용 분야에서 8비트 칩을 대체하고 있으며, ARM7 및 ARM9과 같은 오래된 ARM 코어를 대체하고 있다.
ARM Cortex-M 개요
특히, 대부분의 SD 카드 또는 플래시 드라이브 내부에 내장된 마모 평준화 컨트롤러는 (8비트) 8051 마이크로컨트롤러 또는 ARM CPU이다.
ARM 리미티드는 자체 설계에 기반한 CPU 장치를 제조하거나 판매하지 않고, 대신 프로세서 아키텍처를 관심 있는 당사자에게 라이선스한다. Arm은 비용과 결과물에 따라 다양한 라이선스 조건을 제공한다. 모든 라이선스 사용자에게 Arm은 ARM 코어의 통합 가능한 하드웨어 설명뿐만 아니라 완전한 소프트웨어 개발 도구 세트와 ARM CPU를 포함하는 제조된 규소를 판매할 권리를 제공한다.
통합 장치 제조업체(IDM)는 합성 가능한 RTL (베릴로그로 작성됨) 형태로 ARM 프로세서 IP를 받는다. 이 형태로 그들은 아키텍처 수준의 최적화 및 확장을 수행할 수 있다. 이를 통해 제조업체는 더 높은 클록 속도, 매우 낮은 전력 소비, 명령어 세트 확장(부동 소수점 포함), 크기 최적화, 디버그 지원 등과 같은 맞춤형 설계 목표를 달성할 수 있다. 특정 ARM CPU 칩에 어떤 구성 요소가 포함되어 있는지 확인하려면 제조업체의 데이터시트 및 관련 문서를 참조해야 한다.
ARM Cortex-M 개요
Cortex-M 코어의 실리콘 옵션 중 일부는 다음과 같다.
SysTick 타이머: 프로세서와 중첩 벡터 인터럽트 컨트롤러(NVIC)의 기능을 확장하는 24비트 시스템 타이머이다. 존재할 경우 추가로 구성 가능한 우선순위 SysTick 인터럽트도 제공한다. SysTick 타이머는 M0/M0+/M1/M23에는 선택 사항이지만, 이를 포함하지 않는 Cortex-M 마이크로컨트롤러는 매우 드물다. Cortex-M33/M35P/M52/M55/M85 마이크로컨트롤러에 보안 확장 옵션이 있는 경우, 선택적으로 두 개의 SysTick(하나의 보안, 하나의 비보안)을 가질 수 있다.
ARM Cortex-M 개요
비트 밴드: 메모리의 전체 워드를 비트 밴드 영역의 단일 비트에 매핑한다. 예를 들어, 별칭 워드에 쓰면 비트 밴드 영역의 해당 비트를 설정하거나 지운다. 이를 통해 비트 밴드 영역의 모든 개별 비트는 워드 정렬된 주소에서 직접 액세스할 수 있다. 특히, 개별 비트는 읽기-수정-쓰기 명령어 시퀀스를 수행하지 않고 C/C++에서 설정, 지우기 또는 토글할 수 있다. 비트 밴드는 선택 사항이지만, 이를 포함하지 않는 Cortex-M3 및 Cortex-M4 마이크로컨트롤러는 덜 일반적이다. 일부 Cortex-M0 및 Cortex-M0+ 마이크로컨트롤러에는 비트 밴드가 있다.
ARM Cortex-M 개요
밀접하게 결합된 메모리 (TCM): 제로 대기 상태의 낮은 지연 시간 SRAM으로, 콜 스택, RTOS 제어 구조, 인터럽트 데이터 구조, 인터럽트 핸들러 코드 및 속도에 중요한 코드를 저장하는 데 사용될 수 있다. CPU 캐시 외에 TCM은 ARM Cortex-M 마이크로컨트롤러에서 가장 빠른 메모리이다. TCM은 캐시되지 않고 프로세서 및 캐시와 동일한 속도로 액세스할 수 있으므로 개념적으로 "주소 지정 가능한 캐시"로 설명될 수 있다. 하버드 아키텍처 프로세서가 동시에 읽을 수 있도록 ITCM(명령어 TCM)과 DTCM(데이터 TCM)이 있다. DTCM은 명령어를 포함할 수 없지만 ITCM은 데이터를 포함할 수 있다. TCM은 프로세서 코어와 밀접하게 연결되어 있으므로 일부 구현에서는 DMA 엔진이 TCM에 액세스할 수 없을 수도 있다.
추가 실리콘 옵션:
ARM Cortex-M 개요
Cortex-M0 / M0+ / M1은 ARMv6-M 아키텍처를 구현하고, Cortex-M3은 ARMv7-M 아키텍처를 구현하며, Cortex-M4 / Cortex-M7은 ARMv7E-M 아키텍처를 구현하고, Cortex-M23 / M33 / M35P는 ARMv8-M 아키텍처를 구현하며, Cortex-M52 / M55 / M85는 ARMv8.1-M 아키텍처를 구현한다. 이 아키텍처들은 ARMv6-M에서 ARMv7-M, ARMv7E-M으로 바이너리 명령어 상위 호환이 된다. Cortex-M0 / Cortex-M0+ / Cortex-M1에서 사용할 수 있는 바이너리 명령어는 Cortex-M3 / Cortex-M4 / Cortex-M7에서 수정 없이 실행할 수 있다. Cortex-M3에서 사용할 수 있는 바이너리 명령어는 Cortex-M4 / Cortex-M7 / Cortex-M33 / Cortex-M35P에서 수정 없이 실행할 수 있다. Cortex-M 아키텍처에서는 Thumb-1 및 Thumb-2 명령어 세트만 지원되며, 기존의 32비트 ARM 명령어 세트는 지원되지 않는다.
ARM Cortex-M 개요
모든 Cortex-M 코어는 대부분의 Thumb-1, 일부 Thumb-2를 포함하는 공통 명령어 하위 집합을 구현하며, 32비트 결과 곱셈도 포함한다. Cortex-M0 / Cortex-M0+ / Cortex-M1 / Cortex-M23은 가장 작은 실리콘 다이를 만들기 위해 설계되었으므로 Cortex-M 제품군 중 가장 적은 수의 명령어를 가지고 있다.
Cortex-M0 / M0+ / M1은 ARMv7-M 아키텍처에 추가된 새로운 명령어(CBZ, CBNZ, IT)를 제외한 Thumb-1 명령어를 포함한다. Cortex-M0 / M0+ / M1은 Thumb-2 명령어의 작은 하위 집합(BL, DMB, DSB, ISB, MRS, MSR)을 포함한다. Cortex-M3 / M4 / M7 / M33 / M35P는 모든 기본 Thumb-1 및 Thumb-2 명령어를 가지고 있다. Cortex-M3은 3개의 Thumb-1 명령어, 모든 Thumb-2 명령어, 하드웨어 정수 나눗셈 및 포화 연산 명령어를 추가한다. Cortex-M4는 DSP 명령어와 선택적 단정밀도 부동소수점 장치 (VFPv4-SP)를 추가한다. Cortex-M7은 선택적 배정밀도 FPU (VFPv5)를 추가한다. Cortex-M23 / M33 / M35P / M52 / M55 / M85는 TrustZone 명령어를 추가한다.
ARM Cortex-M 시리즈를 위한 ARM 아키텍처는 이전 레거시 코어에서 일부 기능을 제거했다.
32비트 ARM 명령어 세트의 기능은 Thumb-1 및 Thumb-2 명령어 세트에 의해 여러 가지 방식으로 복제되지만, 일부 ARM 기능은 유사한 기능을 가지고 있지 않다.
16비트 Thumb-1 명령어 세트는 ARMv4T 아키텍처를 가진 기존 ARM7T 코어에 처음 출시된 이후 시간이 지남에 따라 진화했다. 각 기존 ARMv5 / ARMv6 / ARMv6T2 아키텍처가 출시됨에 따라 새로운 Thumb-1 명령어가 추가되었다. 일부 16비트 Thumb-1 명령어는 Cortex-M 코어에서 제거되었다.
ARM Cortex-M Cortex-M0
Cortex-M0 코어는 작은 실리콘 다이 크기와 가장 낮은 가격의 칩에 사용하기에 최적화되어 있다.
Cortex-M0 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M0 코어를 기반으로 한다.
다음 칩은 Cortex-M0을 보조 코어로 사용한다.
ARM Cortex-M Cortex-M0+
Cortex-M0+는 Cortex-M0의 최적화된 상위 집합이다. Cortex-M0+는 Cortex-M0와 완벽한 명령어 세트 호환성을 가지므로 동일한 컴파일러 및 디버그 도구를 사용할 수 있다. Cortex-M0+ 파이프라인은 3단계에서 2단계로 줄어들어 전력 사용량을 낮추고 성능을 향상시킨다 (분기가 한 사이클 더 적게 걸리므로 평균 IPC가 더 높다). 기존 Cortex-M0의 디버그 기능 외에도 마이크로 트레이스 버퍼(MTB)라는 실리콘 옵션을 Cortex-M0+에 추가할 수 있으며, 이는 간단한 명령어 트레이스 버퍼를 제공한다. Cortex-M0+는 또한 메모리 보호 장치(MPU) 및 벡터 테이블 재배치와 같은 Cortex-M3 및 Cortex-M4 기능을 실리콘 옵션으로 추가할 수 있다.
Cortex-M0+ 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M0+ 코어를 기반으로 한다.
ARM Cortex-M Cortex-M0+
다음 칩은 Cortex-M0+를 보조 코어로 사용한다.
가장 작은 ARM 마이크로컨트롤러는 Cortex-M0+ 유형이다 (2014년 현재, 칩 스케일 패키지에서 1.6 mm x 2 mm로 가장 작은 것은 Kinetis KL03이다).
2018년 6월 21일, "세계에서 가장 작은 컴퓨터" 또는 컴퓨터 장치가 발표되었다 –  미시간 대학교 연구원들이 2018년 VLSI 기술 및 회로 심포지엄에서 "A 0.04mm3 16nW 무선 및 배터리 없는 센서 시스템, 통합 Cortex-M0+ 프로세서 및 셀룰러 온도 측정을 위한 광통신" 논문과 함께 ARM Cortex-M0+를 기반으로 한 (RAM 및 태양광 발전 기반의 무선 송수신기를 포함한) 장치이다. –  이 장치는 2018년 3월에 IBM이 이전에 주장했던 세계 기록 크기 컴퓨터보다 10분의 1 크기로, 소금 알갱이보다 작다.
ARM Cortex-M Cortex-M1
Cortex-M1은 FPGA 칩에 로드되도록 특별히 설계된 최적화된 코어이다.
Cortex-M1 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
다음 공급업체는 Cortex-M1을 FPGA 칩의 소프트 코어로 지원한다.
ARM Cortex-M Cortex-M3
Cortex-M3 코어의 주요 기능은 다음과 같다.
명령어 집합:
Thumb-1 (전체).
Thumb-2 (전체).
32비트 또는 64비트 결과의 32비트 하드웨어 정수 곱셈, 부호 유무, 곱셈 후 덧셈 또는 뺄셈. 32비트 곱셈은 1 사이클이지만, 64비트 곱셈 및 MAC 명령어는 추가 사이클이 필요하다.
32비트 하드웨어 정수 나눗셈 (2–12 사이클).
포화 연산 지원.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M3 코어를 기반으로 한다.
다음 칩은 Cortex-M3를 보조 코어로 사용한다.
다음 FPGA에는 Cortex-M3 코어가 포함되어 있다.
다음 공급업체는 Cortex-M3를 FPGA 칩의 소프트 코어로 지원한다.
ARM Cortex-M Cortex-M4
개념적으로 Cortex-M4는 Cortex-M3에 DSP 명령어와 선택적 부동소수점 장치 (FPU)를 더한 것이다. FPU가 있는 코어는 Cortex-M4F로 알려져 있다.
Cortex-M4 코어의 주요 기능은 다음과 같다.
명령어 집합:
Thumb-1 (전체).
Thumb-2 (전체).
32비트 또는 64비트 결과의 32비트 하드웨어 정수 곱셈, 부호 유무, 곱셈 후 덧셈 또는 뺄셈. 32비트 곱셈 및 MAC는 1 사이클.
32비트 하드웨어 정수 나눗셈 (2–12 사이클).
포화 연산 지원.
DSP 확장: 단일 사이클 16/32비트 MAC, 단일 사이클 듀얼 16비트 MAC, 8/16비트 SIMD 산술.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M4 코어를 기반으로 한다.
다음 마이크로컨트롤러는 Cortex-M4F (M4 + FPU) 코어를 기반으로 한다.
다음 칩은 Cortex-M4 또는 M4F를 보조 코어로 사용한다.
ARM Cortex-M Cortex-M7
Cortex-M7은 이전 Cortex-M4보다 거의 두 배의 전력 효율을 가진 고성능 코어이다. 분기 예측을 포함한 6단계 슈퍼스칼라 파이프라인과 단정밀도 및 선택적으로 배정밀도 연산이 가능한 선택적 부동소수점 장치를 특징으로 한다. 명령어 및 데이터 버스는 이전 32비트 버스에서 64비트 폭으로 확장되었다. 코어에 FPU가 포함되어 있으면 Cortex-M7F로 알려져 있고, 그렇지 않으면 Cortex-M7이다.
Cortex-M7 코어의 주요 기능은 다음과 같다.
명령어 집합:
Thumb-1 (전체).
Thumb-2 (전체).
32비트 또는 64비트 결과의 32비트 하드웨어 정수 곱셈, 부호 유무, 곱셈 후 덧셈 또는 뺄셈. 32비트 곱셈 및 MAC는 1 사이클.
32비트 하드웨어 정수 나눗셈 (2–12 사이클).
포화 연산 지원.
DSP 확장: 단일 사이클 16/32비트 MAC, 단일 사이클 듀얼 16비트 MAC, 8/16비트 SIMD 산술.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M7 코어를 기반으로 한다.
ARM Cortex-M Cortex-M23
Cortex-M23 코어는 2016년 10월에 발표되었으며, 2015년 11월에 이전에 발표된 ARMv8-M 아키텍처를 기반으로 한다. 개념적으로 Cortex-M23은 Cortex-M0+와 유사하며, 정수 나눗셈 명령어와 TrustZone 보안 기능이 추가되었고, 2단계 명령어 파이프라인도 가지고 있다.
Cortex-M23 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M23 코어를 기반으로 한다.
ARM Cortex-M Cortex-M33
Cortex-M33 코어는 2016년 10월에 발표되었으며, 2015년 11월에 이전에 발표된 ARMv8-M 아키텍처를 기반으로 한다. 개념적으로 Cortex-M33은 Cortex-M4와 Cortex-M23의 교차점과 유사하며, 3단계 명령어 파이프라인도 가지고 있다.
Cortex-M33 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex-M33 코어를 기반으로 한다.
다음 칩은 Cortex-M33 또는 M33F를 보조 코어로 사용한다.
ARM Cortex-M Cortex-M35P
Cortex-M35P 코어는 2018년 5월에 발표되었으며 Armv8-M 아키텍처를 기반으로 한다. 이는 새로운 명령어 캐시와 ARM SecurCore 제품군에서 가져온 새로운 변조 방지 하드웨어 개념, 구성 가능한 패리티 및 ECC 기능을 추가한 Cortex-M33 코어로 볼 수 있다.
현재 Cortex-M35P에 대한 정보는 기술 참조 매뉴얼 및 일반 사용자 가이드가 아직 출시되지 않았기 때문에 제한적이다.
다음 마이크로컨트롤러는 Cortex-M35P 코어를 기반으로 한다.
ARM Cortex-M Cortex-M52
Cortex-M52 코어는 2023년 11월에 발표되었으며 Armv8.1-M 아키텍처를 기반으로 한다. 개념적으로는 Cortex-M33과 Cortex-M55의 교차점으로 볼 수 있다. 주요 차이점은 Helium 코프로세서가 단일 비트(M55는 듀얼 비트)이며, 애플리케이션 전환을 용이하게 하기 위해 M33과 유사한 32비트 메인 버스를 가지고 있다는 것이다. 4단계 명령어 파이프라인을 가지고 있다.
Cortex-M52 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
다음 마이크로컨트롤러는 Cortex M52 코어를 기반으로 한다.
ARM Cortex-M Cortex-M55
Cortex-M55 코어는 2020년 2월에 발표되었으며 Armv8.1-M 아키텍처를 기반으로 한다. 4단계 또는 5단계 명령어 파이프라인을 가지고 있다.
Cortex-M55 코어의 주요 기능은 다음과 같다.
실리콘 옵션:
ARM Cortex-M Cortex-M85
Cortex-M85 코어는 2022년 4월에 발표되었으며 Armv8.1-M 아키텍처를 기반으로 한다. 7단계 명령어 파이프라인을 가지고 있다.
실리콘 옵션:
ARM Cortex-M 문서
ARM 칩에 대한 문서는 광범위하다. 과거에는 8비트 마이크로컨트롤러 문서가 일반적으로 단일 문서에 담겼지만, 마이크로컨트롤러가 진화함에 따라 이를 지원하는 데 필요한 모든 것도 진화했다. ARM 칩의 문서 패키지는 일반적으로 IC 제조업체와 CPU 코어 공급업체(ARM 리미티드)의 문서 모음으로 구성된다.
일반적인 하향식 문서 트리는 다음과 같다.
문서 트리 (위에서 아래로)
IC 제조업체는 평가 보드 사용자 매뉴얼, 애플리케이션 노트, 시작 가이드, 소프트웨어 라이브러리 문서, 오류 정정(errata) 등 추가 문서를 가지고 있다. 공식 Arm 문서 링크는 외부 링크 섹션을 참조한다.
ARC (프로세서)
아르고너트 RISC 코어(Argonaut RISC Core, ARC)는 원래 ARC 인터내셔널이 설계한 32비트 및 64비트 RISC 중앙 처리 장치(CPU) 제품군이다.
ARC 프로세서는 스토리지, 디지털 홈, 모바일, 자동차, 사물인터넷(IoT) 애플리케이션을 포함한 광범위한 시스템 온 칩(SoC) 장치에 사용하기 위해 구성 및 확장이 가능하다. 200개 이상의 조직에서 라이선스를 취득했으며 매년 15억 개 이상의 제품에 탑재된다.
ARC 프로세서는 임베디드 및 호스트 SoC 애플리케이션을 위한 우수한 성능과 코드 밀도를 제공하는 16/32비트 ARCompact 압축 명령어 집합 명령어 집합(ISA)을 사용한다.
ARC (프로세서) 역사
ARC 개념은 원래 슈퍼 패미컴용 슈퍼 FX 칩으로 시작된 일련의 3D 파이프라인 개발 프로젝트를 통해 아르고너트 게임스 내에서 개발되었다.
1995년, 아르고너트는 다양한 기술 프로젝트를 수행하는 아르고너트 테크놀로지스 리미티드(ATL)와 아르고너트 소프트웨어 리미티드(ASL)로 분할되었다.
1996년 초, 아르고너트의 총책임자인 존 에델슨은 BRender 및 모션 캡처와 같은 ATL 프로젝트를 축소하고 ARC 개념 개발에 투자하기 시작했다. 1996년 9월, 릭 클루카스는 ARC 프로세서의 가치가 아르고너트가 이를 사용하는 프로젝트를 수행하는 것보다 다른 사람들이 이를 사용하는 데 있다고 판단하고 밥 테르윌리거에게 CEO로 합류할 것을 요청했다. 릭 클루카스는 이후 CTO 역할을 맡았다.
ARC (프로세서) 역사
1997년, 아팍스 파트너스의 투자에 이어 ATL은 ARC 인터내셔널이 되었고 아르고너트 게임스에서 완전히 독립했다. 골드만삭스와 5개 다른 투자 은행의 인수 보증을 받아 런던 증권거래소에 기업공개를 하기 전에 세 개의 관련 기술 회사(캘리포니아주 샌타크루즈의 MetaWare(개발 및 모델링 소프트웨어), 뉴햄프셔주 내슈아의 VAutomation(주변 반도체 IP), 온타리오주 니핀의 Precise Software(RTOS))를 인수했다.
2009년, ARC 인터내셔널은 비라지 로직에 인수되었다. 2010년, 비라지는 시높시스에 인수되었고 ARC 프로세서는 시높시스 디자인웨어 시리즈의 일부가 되었다.
2020년 4월, 시높시스는 64비트 지원을 포함하는 ARCv3 ISA를 출시했다.
2023년 11월, 시높시스는 ARC 제품군의 확장으로 RISC-V 호환 ARC-V 프로세서 IP를 출시했다.
ARC (프로세서) 설계 구성
설계자는 특허받은 구성 기술을 사용하여 각 ARC 프로세서 인스턴스를 특정 성능, 전력 및 영역 요구 사항에 맞게 조정함으로써 제품을 차별화할 수 있다.
ARC 프로세서의 구성은 ARChitect 프로세서 구성기를 사용하여 설계 시점에 이루어진다. 코어는 확장 가능하도록 설계되어 설계자가 성능을 크게 향상시키거나 전력 소비를 줄일 수 있는 자체 사용자 지정 명령어를 추가할 수 있다.
대부분의 임베디드 마이크로프로세서와 달리 추가 명령어, 레지스터 및 기능을 모듈식으로 추가할 수 있다. 고객은 작업을 분석하고, 작업을 세분화한 다음 적절한 확장을 선택하거나 자체 확장을 개발하여 자체 사용자 지정 마이크로프로세서를 만든다. 속도, 에너지 효율 또는 코드 밀도를 최적화할 수 있다. 확장에는 예를 들어 메모리 관리 장치(MMU), 고속 곱셈-누산기, USB 호스트, 비터비 경로 디코더 또는 사용자의 독점적인 RTL 기능이 포함될 수 있다.
프로세서는 합성 가능하며 모든 파운드리 또는 프로세스에서 구현할 수 있으며 완전한 개발 도구 스위트가 지원된다.
시스리눅스
시스리눅스 프로젝트(The Syslinux Project)는 컴퓨터에서 리눅스 배포판을 시작하기 위한 다섯 가지 부트로더 스위트로, 현재는 개발이 중단되었다. 주로 H. 피터 안빈이 개발했다.
시스리눅스 구성 요소
시스리눅스 프로젝트는 여섯 가지 다른 부트로더로 구성되어 있다:
이 프로젝트에는 두 가지 별도의 메뉴 시스템과 추가 모듈 개발 환경도 포함되어 있다.
SYSLINUX는 원래 복구 플로피 디스크, 라이브 USB 또는 기타 경량 환경을 위한 것이었다. ISOLINUX는 라이브 CD 및 리눅스 설치 CD를 위한 것이다.
SYSLINUX 부트로더는 USB 스틱과 같은 단일 소스에서 여러 배포판을 부팅하는 데 사용될 수 있다.
콤팩트 디스크에서 부팅할 때 약간의 복잡성이 따른다. 엘 토리토 표준은 두 가지 다른 모드에서 부팅을 허용한다:
시스리눅스 구성 요소
이러한 선택권은 때때로 유용하다. 왜냐하면 ISOLINUX는 바이오스 버그에 취약하기 때문이다. 그렇기 때문에 SYSLINUX를 사용하여 부팅할 수 있다는 것은 편리하다. 이는 주로 1999년 이전에 제작된 컴퓨터에 영향을 미치며, 사실 현대 컴퓨터의 경우 "에뮬레이션 없음" 모드가 일반적으로 더 안정적인 방법이다. 버전 3.72부터 ISOLINUX는 소위 "하이브리드 ISO" 이미지 생성을 지원하며, 이는 콤팩트 디스크의 엘 토리토 부팅 레코드와 하드 디스크의 마스터 부트 레코드를 ISO 이미지에 담는다. 이 하이브리드 이미지는 콤팩트 디스크 또는 USB 플래시 드라이브 모두에 쓸 수 있다.
PXELINUX는 네트워크 인터페이스 컨트롤러 (NIC)의 PXE 호환 ROM과 함께 사용되어 근거리 통신망을 통해 부트스트랩 프로그램을 수신할 수 있도록 한다. 이 부트스트랩 프로그램은 운영체제 커널을 로드하고 구성하여 사용자가 컴퓨터를 제어할 수 있게 한다. 일반적으로 PXELINUX는 중앙 네트워크 서버에서 리눅스 설치를 수행하거나 디스크 없는 워크스테이션을 부팅하는 데 사용된다.
EXTLINUX는 LILO 또는 GRUB과 유사한 범용 부트로더이다. 시스리눅스 4부터 EXTLINUX는 Btrfs, FAT, NTFS, UFS/UFS2 및 XFS 파일 시스템을 처리할 수 있다.
EFILINUX는 UEFI에서 부팅하도록 설계된 SYSLINUX 부트로더의 확장 버전이지만, 다른 부트로더로 체인 로딩을 지원하지 않는 등의 몇 가지 제한 사항이 있다.
시스리눅스 COMBOOT
SYSLINUX는 C 또는 어셈블리 언어로 작성된 COMBOOT 모듈을 통해 확장될 수 있다. 32비트 모듈은 일반적으로 .c32 파일 확장자를 사용한다. 버전 5 이상은 16비트 .com 모듈을 지원하지 않는다.
3.74 릴리스부터 Syslinux 프로젝트는 GNU GPL 약관에 따라 라이선스된 하드웨어 감지 도구 (HDT) 프로젝트를 호스팅한다. 이 도구는 모든 IA-32 호환 시스템에 대한 저수준 정보를 표시하는 32비트 모듈이다. 명령줄 인터페이스와 반그래픽 메뉴 모드를 모두 제공하여 탐색할 수 있다. HDT는 부팅 가능한 ISO 및 2.88MB 플로피 디스크 이미지로도 제공된다. HDT의 마지막 업데이트는 2015년이었고, 그 이후로 개발이 중단되었다.
오픈RC
오픈RC(OpenRC)는 유닉스 계열 운영체제를 위한 의존성 기반의 Init 시스템이다. 이는 젠투 리눅스 프로젝트에서도 활동한 NetBSD 개발자 로이 마플스가 만들었다.
오픈RC 채택
오픈RC는 다음의 기본 Init 시스템 또는 프로세스 관리자이다.
오픈RC는 다음의 Init 시스템 또는 프로세스 관리자로 사용할 수 있다.
오픈RC 설계
오픈RC는 여러 모듈식 구성 요소로 이루어져 있으며, 주요 구성 요소는 init(선택 사항), 핵심 의존성 관리 시스템, 데몬 관리자(선택 사항)이다. C와 POSIX 호환 셸로 작성되어 BSD 및 리눅스 시스템에서 사용할 수 있다.
오픈RC의 핵심 부분은 의존성 관리 및 init 스크립트 파싱을 처리한다. 오픈RC는 런레벨을 스캔하고, 의존성 그래프를 구축한 다음, 필요한 서비스 스크립트를 시작하여 작동한다. 스크립트가 시작되면 종료된다. 기본적으로 오픈RC는 데몬 관리를 위해 start-stop-daemon의 수정된 버전을 사용한다.
Init 스크립트는 SysVinit에서 사용되는 스크립트와 유사하지만, 스크립트 생성을 단순화하는 여러 기능을 제공한다. 스크립트는 start(), stop(), status()를 가지고 있다고 가정하며, 시스템은 이미 선언된 변수를 사용하여 기본 함수를 생성한다. depend 함수는 SysVinit에서 LSB 헤더로 수행될 다른 서비스에 대한 의존성을 선언하는 데 사용된다. 구성과 메커니즘은 conf.d 디렉토리의 구성 파일과 init.d 디렉토리의 init 파일로 분리된다.
오픈RC 설계
openrc-init은 버전 0.25에서 /sbin/init의 선택적 대체품으로 처음 등장했다. 이는 젠투 리눅스의 기본 init 시스템인 SysVinit을 대체할 수 있다.
Supervise-daemon은 OpenRC에 감독 기능을 부여하며 버전 0.21에서 처음 등장했다. supervise-daemon이 데몬을 시작하고 모니터링하도록 init 스크립트에서 활성화할 수 있다. Runit 및 s6을 포함한 여러 다른 데몬 감독자가 지원된다.
Ratpoison
ratpoison은 숀 베츠가 주로 개발한 X 윈도 시스템용 타일링 창 관리자이다. 사용자 인터페이스와 대부분의 기능은 GNU Screen 터미널 다중화기에서 영감을 얻었다. ratpoison은 C로 작성되었지만, 베츠의 StumpWM은 유사한 창 관리자를 커먼 리스프로 다시 구현한다.
Ratpoison 개요
"ratpoison"이라는 이름은 마우스를 사용하지 않고 응용 프로그램 창을 관리할 수 있도록 하는 주요 설계 목표를 반영한다. Ion과 같은 다른 타일링 창 관리자와 달리 ratpoison은 마우스("쥐")를 완전히 무시하고, 창 장식을 가능한 한 피한다. 기본 키 바인딩은 이맥스와 충돌하지 않도록 특별히 설계되었다.
Ratpoison 사용법
ratpoison은 창 관리 제어를 위해 이맥스와 유사한 키 코드를 사용하며, 모든 창 상호 작용은 바로 가기를 통해 이루어진다. 각 창은 전체 프레임을 차지하며 겹칠 수 없다. 창은 가로 또는 세로로 분할할 수 있다. 여러 작업 공간과 세션 관리가 지원된다. 응용 프로그램 메뉴를 사용하여 프로그램으로 이동할 수 있다. 구성은 설정 파일을 통해 제어된다.
Ratpoison 평가
마크 필그림은 이를 "미니멀리스트"하고 "설정 가능"하다고 칭찬했다. 제프 코비는 2002년에 "번개처럼 빠르고 완벽하게 안정적"이라고 평가했다. 피터 시백은 "편의성과 성능은 인상적이지만, 학습 곡선은 많은 사용자를 위축시킨다"고 언급했다. 마찬가지로 브라이언 프로핏은 "이 창 관리자의 맨 페이지에 키 명령이 잘 설명되어 있으며, 무엇을 하든 먼저 이것들을 읽어야 한다. 키보드 명령은 어느 정도 사용 후 이해되지만, 초기 학습 곡선은 상당히 가파르다"고 관찰했다. 같은 맥락에서 브루스 바이필드는 (그리고 stumpwm) "문서를 읽기 전까지는 거의 사용할 수 없다"고 평가했다. MakeTechEasier는 2013년에 ratpoison에 대해 긍정적인 평가를 내렸지만, 가파른 학습 곡선을 지적했다. NetworkWorld의 브라이언 룬듀크는 부정적인 평가를 내렸고, 키 바인딩과 김프와 같은 다중 창 프로그램 작업의 어려움을 비판했다.
CrDroid
crDroid는 리니지OS를 기반으로 하는 안드로이드의 맞춤형 포크이다. 안드로이드 10부터 안드로이드 16까지 비공식 맞춤형 ROM을 제공했다.
crDroid 웹사이트는 지원되는 장치 목록과 각 장치의 최신 릴리스 날짜를 제공한다.
CrDroid 역사 및 평가
크리스티아누 마토스는 2012년 후반 삼성 갤럭시 S3용 crDroid 초기 버전을 개발했다.
2014년, 팀 안드로이드의 사드 칸은 자세한 기사에서 crDroid의 기능을 강조했다.
crDroid는 안정적인 릴리스와 사용자 친화적인 경험으로 인정을 받았다. 2015년 니라지 자스트, 2016년 라피아 샤이크, 2017년 매튜 디크하케의 기사 등이 주목할 만하다.
crDroid의 인기는 2019년 여러 장치에 안드로이드 10이 출시되면서 증가했으며, XDA 개발자의 아롤 라이트에 의해 인정받았다.
2022년, crDroid는 버전 8 (안드로이드 12)을 출시했다.
2023년, crDroid는 통합 커널 보조 슈퍼유저를 갖춘 일부 장치 빌드를 출시하기 시작했다.
현재 crDroid 버전 11은 안드로이드 15이다. 이와 함께 2024년 12월 보안 패치가 포함된 crDroid 10.11도 출시하고 있다.
소스 라인 오브 코드
소스 라인 오브 코드(Source lines of code, SLOC), 또는 라인 오브 코드(lines of code, LOC)는 프로그램 소스 코드 텍스트의 줄 수를 세어 컴퓨터 프로그램의 크기를 측정하는 데 사용되는 소프트웨어 메트릭이다. SLOC는 일반적으로 프로그램을 개발하는 데 필요한 노력의 양을 예측하고 소프트웨어가 생산된 후 프로그래밍 생산성 또는 유지보수성을 추정하는 데 사용된다.
소스 라인 오브 코드 측정 방법
여러 유용한 비교는 프로젝트 내 코드 라인의 크기 정도만을 포함한다. 10,000줄 프로젝트와 100,000줄 프로젝트를 비교하는 데 코드 라인을 사용하는 것이 20,000줄 프로젝트와 21,000줄 프로젝트를 비교하는 것보다 훨씬 유용하다. 코드 라인을 정확히 어떻게 측정할 것인지는 논란의 여지가 있지만, 크기 정도의 차이는 소프트웨어 복잡성 또는 공수의 명확한 지표가 될 수 있다.
SLOC 측정에는 물리적 SLOC (LOC)와 논리적 SLOC (LLOC)의 두 가지 주요 유형이 있다. 이 두 가지 측정의 구체적인 정의는 다르지만, 물리적 SLOC의 가장 일반적인 정의는 주석 줄을 제외한 프로그램 소스 코드 텍스트의 줄 수이다.
소스 라인 오브 코드 측정 방법
논리적 SLOC는 실행 가능한 "명령문"의 수를 측정하려고 시도하지만, 그 특정 정의는 특정 컴퓨터 언어에 묶여 있다(예를 들어, C와 유사한 프로그래밍 언어의 간단한 논리적 SLOC 측정은 명령문을 종료하는 세미콜론의 수이다). 물리적 SLOC를 측정하는 도구를 만드는 것이 훨씬 쉽고, 물리적 SLOC 정의는 설명하기 쉽다. 그러나 물리적 SLOC 측정은 논리적 SLOC보다 논리적으로 관련 없는 형식 지정 및 스타일 규칙에 더 민감하다. 그러나 SLOC 측정은 종종 정의를 제공하지 않고 언급되며, 논리적 SLOC는 물리적 SLOC와 크게 다를 수 있다.
SLOC를 결정할 때 발생하는 모호성의 예시로 다음 C 코드 스니펫을 고려해보자.
이 예시에서는 다음과 같다.
프로그래머와 코딩 표준에 따라 위의 "코드 라인"은 여러 개의 개별 라인으로 작성될 수 있다.
이 예시에서는 다음과 같다.
심지어 "논리적" 및 "물리적" SLOC 값도 수많은 다양한 정의를 가질 수 있다. 로버트 E. 파크 (소프트웨어 공학 연구소 소속)와 다른 사람들은 프로젝트에서 사용되는 SLOC 측정을 신중하게 설명하고 정의할 수 있도록 SLOC 값을 정의하기 위한 프레임워크를 개발했다. 예를 들어, 대부분의 소프트웨어 시스템은 코드를 재사용하며, 측정을 보고할 때 어떤 (있다면) 재사용 코드를 포함할지 결정하는 것이 중요하다.
소스 라인 오브 코드 기원
SLOC가 메트릭으로 도입될 당시, 포트란 및 어셈블리어와 같이 가장 일반적으로 사용되던 언어들은 라인 지향 언어였다. 이 언어들은 천공 카드가 프로그래밍을 위한 주요 데이터 입력 형태였던 시절에 개발되었다. 천공 카드 하나는 일반적으로 코드 한 줄을 나타냈다. 그것은 쉽게 셀 수 있는 개별적인 개체였다. 그것은 프로그래머의 가시적인 결과물이었기 때문에, 관리자들은 코드 줄을 프로그래머의 생산성 측정으로 세는 것이 합리적이라고 생각했으며, 심지어 "카드 이미지"라고 부르기도 했다. 오늘날, 가장 일반적으로 사용되는 컴퓨터 언어들은 형식 지정에 훨씬 더 많은 자유를 허용한다. 텍스트 줄은 더 이상 80 또는 96열로 제한되지 않으며, 텍스트 한 줄이 더 이상 반드시 코드 한 줄에 해당하지는 않는다.
소스 라인 오브 코드 SLOC 측정의 사용
SLOC 측정은 다소 논란의 여지가 있으며, 특히 오용되는 방식에서 그렇다. 실험에 따르면 노력은 SLOC와 높은 상관관계가 있으며, 즉 SLOC 값이 큰 프로그램은 개발하는 데 더 많은 시간이 걸린다는 것이 반복적으로 확인되었다. 따라서 SLOC는 노력을 추정하는 데 효과적일 수 있다. 그러나 기능은 SLOC와 상관관계가 적다: 숙련된 개발자는 훨씬 적은 코드로 동일한 기능을 개발할 수 있으므로, SLOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있다. SLOC를 생산성 측정으로 세는 것은 주의할 점이 있는데, 개발자는 몇 줄만 개발하고도 더 많은 줄을 생성하는 개발자보다 기능 측면에서 훨씬 더 생산적일 수 있기 때문이다(그리고 일반적으로 더 많은 노력을 들인다). 우수한 개발자는 여러 코드 모듈을 단일 모듈로 병합하여 시스템을 개선하지만, 코드를 제거했기 때문에 생산성이 음수로 나타날 수 있다. 또한, 미숙한 개발자는 종종 코드 중복에 의존하는데, 이는 버그 발생 가능성이 높고 유지 보수 비용이 많이 들기 때문에 매우 권장되지 않지만, SLOC를 높이는 결과를 초래한다.
소스 라인 오브 코드 SLOC 측정의 사용
SLOC 계산은 언어를 정규화하기 위해 조정 계수를 적용하지 않는 한, 다른 언어로 작성된 프로그램을 비교할 때 추가적인 정확성 문제를 나타낸다. 다양한 컴퓨터 언어는 간결성과 명확성 사이의 균형을 다르게 맞춘다. 극단적인 예로, 대부분의 어셈블리어는 APL에서 몇 글자로 동일한 작업을 수행하기 위해 수백 줄의 코드를 필요로 할 것이다. 다음 예시는 베이직, C, 그리고 (특히 장황한 것으로 알려진 언어인) 코볼로 작성된 "Hello world" 프로그램의 비교를 보여준다.
소스 라인 오브 코드 SLOC 측정의 사용
SLOC 메트릭을 비교하는 데 있어 또 다른 점점 흔해지는 문제는 자동 생성된 코드와 수작업으로 작성된 코드의 차이이다. 최신 소프트웨어 도구는 종종 몇 번의 마우스 클릭으로 엄청난 양의 코드를 자동 생성할 수 있다. 예를 들어, 그래픽 사용자 인터페이스 빌더는 아이콘을 작업 공간으로 드래그하는 것만으로 그래픽 제어 요소의 모든 소스 코드를 자동으로 생성한다. 이 코드를 생성하는 데 필요한 작업은 예를 들어 장치 드라이버를 작성하는 데 필요한 작업과 합리적으로 비교할 수 없다. 같은 맥락에서, 수작업으로 코딩된 사용자 지정 GUI 클래스는 간단한 장치 드라이버보다 훨씬 더 까다로울 수 있다. 따라서 이 메트릭의 단점이 드러난다.
소스 라인 오브 코드 SLOC 측정의 사용
널리 사용되는 배리 보임 등의 COCOMO 모델 시리즈, PRICE Systems True S 및 갈로라쓰의 SEER-SEM을 포함하여 SLOC를 입력 매개변수로 사용하는 여러 비용, 일정 및 노력 추정 모델이 있다. 이 모델들은 우수한 예측력을 보여주었지만, 입력된 추정치(특히 SLOC 추정치)만큼만 좋다. 많은 이들은 기능성 측정으로 SLOC 대신 기능 점수 사용을 주장했지만, 기능 점수가 SLOC와 높은 상관관계가 있고 (자동으로 측정될 수 없기 때문에) 이는 보편적으로 받아들여지는 견해가 아니다.
빈센트 마라이아(Vincent Maraia)에 따르면, 마이크로소프트의 윈도우 NT 제품군의 다양한 운영 체제의 SLOC 값은 다음과 같다.
데이비드 A. 휠러(David A. Wheeler)는 리눅스 운영체제의 레드햇 배포판을 연구했으며, 레드햇 리눅스 버전 7.1 (2001년 4월 출시)이 3천만 줄 이상의 물리적 SLOC를 포함하고 있다고 보고했다. 그는 또한 이 배포판이 기존의 독점적인 방식으로 개발되었다면 약 8천 인년의 개발 노력이 필요했을 것이며 10억 달러 이상(2000년 미국 달러 기준)의 비용이 들었을 것이라고 추정했다.
유사한 연구가 나중에 데비안 GNU/리눅스 버전 2.2("포테이토"라고도 함)에 대해 수행되었다. 이 운영 체제는 2000년 8월에 원래 출시되었다. 이 연구는 데비안 GNU/리눅스 2.2가 5천5백만 줄 이상의 SLOC를 포함하고 있으며, 기존의 독점적인 방식으로 개발되었다면 14,005 인년이 필요하고 개발 비용으로 미화 19억 달러가 들었을 것이라고 밝혔다. 나중에 사용된 도구의 실행 결과에 따르면 데비안의 다음 릴리스는 1억 4백만 SLOC를 가졌고, 2005년 기준, 최신 릴리스는 2억 1천 3백만 SLOC 이상을 포함할 예정이다.
소스 라인 오브 코드 유용성
계산 자동화의 범위: 코드 라인은 물리적 개체이므로, 계산 프로세스를 자동화하여 수동 계산 노력을 쉽게 제거할 수 있다. 프로그램의 LOC를 계산하기 위한 작은 유틸리티가 개발될 수 있다. 그러나 특정 언어를 위해 개발된 논리적 코드 계산 유틸리티는 언어 간의 구문 및 구조적 차이 때문에 다른 언어에는 사용될 수 없다. 그러나 수십 가지 언어를 계산하는 물리적 LOC 카운터가 개발되었다.
직관적인 측정 항목: 코드 라인은 시각적으로 볼 수 있고 그 효과를 시각화할 수 있기 때문에 소프트웨어 크기를 측정하는 직관적인 측정 항목으로 사용된다. 기능 점수는 물리적 개체로 상상할 수 없는 더 객관적인 측정 항목으로 알려져 있으며, 논리적 공간에만 존재한다. 이런 식으로 LOC는 경험이 적은 프로그래머들 사이에서 소프트웨어 크기를 표현하는 데 유용하다.
소스 라인 오브 코드 유용성
기능과의 응집성 부족: 비록 실험을 통해 노력이 LOC와 높은 상관관계가 있지만, 기능은 LOC와 덜 상관관계가 있다는 것이 반복적으로 확인되었다. 즉, 숙련된 개발자는 훨씬 적은 코드로 동일한 기능을 개발할 수 있으므로, LOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있다. 특히 LOC는 개인의 생산성 측정에 좋지 않은데, 몇 줄만 개발하는 개발자도 더 많은 코드 라인을 생성하는 개발자보다 생산성이 더 높을 수 있기 때문이다. 심지어 "메서드 추출"과 같은 좋은 리팩토링은 중복 코드를 제거하고 깨끗하게 유지하여 코드 라인 수를 줄이는 경우가 대부분이다.
소스 라인 오브 코드 유용성
언어의 차이: 동일한 기능(화면, 보고서, 데이터베이스)을 제공하는 두 가지 애플리케이션을 고려해 보자. 한 애플리케이션은 C++로 작성되었고 다른 애플리케이션은 코볼과 같은 언어로 작성되었다. 기능 점수 수는 정확히 동일하겠지만, 애플리케이션의 측면은 다를 것이다. 애플리케이션을 개발하는 데 필요한 코드 라인 수는 분명히 같지 않을 것이다. 결과적으로 애플리케이션을 개발하는 데 필요한 노력의 양도 달라질 것이다(기능 점수당 시간). 코드 라인과 달리 기능 점수 수는 일정하게 유지될 것이다.
소스 라인 오브 코드 유용성
GUI 도구의 등장: 비주얼 베이직과 같은 GUI 기반 프로그래밍 언어 및 도구의 등장으로 프로그래머는 상대적으로 적은 코드를 작성하고 높은 수준의 기능을 달성할 수 있다. 예를 들어, 창을 만들고 버튼을 그리는 프로그램을 작성하는 대신, GUI 도구를 사용하는 사용자는 드래그 앤 드롭 및 기타 마우스 작업을 사용하여 작업 공간에 구성 요소를 배치할 수 있다. GUI 도구에 의해 자동으로 생성되는 코드는 LOC 측정 방법을 사용할 때 일반적으로 고려되지 않는다. 이로 인해 언어 간에 차이가 발생한다. 한 언어에서는 한 줄의 코드(또는 전혀 코드 없이)로 수행할 수 있는 동일한 작업이 다른 언어에서는 여러 줄의 코드를 필요로 할 수 있다.
여러 언어의 문제점: 오늘날의 소프트웨어 환경에서는 소프트웨어가 종종 하나 이상의 언어로 개발된다. 복잡성과 요구 사항에 따라 여러 언어가 사용되는 경우가 많다. 이 경우 생산성 및 결함률 추적 및 보고에 심각한 문제가 발생하는데, 시스템 통합 후 결함을 특정 언어에 귀속시킬 수 없기 때문이다. 이 경우 기능 점수는 크기를 측정하는 가장 좋은 방법으로 두드러진다.
소스 라인 오브 코드 유용성
계산 표준의 부족: 코드 라인이 무엇인지에 대한 표준 정의가 없다. 주석도 세어야 하는가? 데이터 선언은 포함되는가? 명령문이 여러 줄에 걸쳐 확장되면 어떻게 되는가? – 이것들은 종종 발생하는 질문들이다. 비록 SEI 및 IEEE와 같은 조직들이 계산을 표준화하기 위한 일부 지침을 발표했지만, 특히 매년 새로운 언어가 도입되는 상황에서 이를 실제로 적용하기는 어렵다.
심리: 코드 라인으로 생산성을 측정받는 프로그래머는 불필요하게 장황한 코드를 작성하려는 동기를 가질 것이다. 경영진이 코드 라인에 더 집중할수록 프로그래머는 불필요한 복잡성으로 코드를 확장하려는 동기를 더 많이 갖게 된다. 이는 바람직하지 않은데, 복잡성 증가는 유지 보수 비용 증가 및 버그 수정에 필요한 노력 증가로 이어질 수 있기 때문이다.
PBS 다큐멘터리 너드들의 승리에서 마이크로소프트의 임원인 스티브 발머는 코드 라인 수를 세는 관행을 비판했다.
IBM에는 소프트웨어에 대한 종교가 있는데, K-LOC를 세야 한다고 말한다. K-LOC는 천 줄의 코드다. 프로젝트 규모는? 아, 대략 10K-LOC 프로젝트야. 이건 20K-LOC짜리야. 이건 50K-LOC짜리야. IBM은 우리가 어떻게 돈을 벌었는지, 그들이 얼마나 했는지에 대한 종교를 만들고 싶어 했다. 우리가 OS/2로 얼마나 많은 돈을 벌었는지, 그들이 얼마나 했는지. K-LOC를 몇 개 만들었냐고? 우리는 계속해서 그들을 설득하려고 했다. "이봐, 만약 개발자가 좋은 아이디어를 가지고 20K-LOC 대신 4K-LOC로 뭔가를 해낼 수 있다면, 우리가 돈을 덜 벌어야 할까?" 그는 더 작고 빠른 것을 만들었는데, K-LOC는 더 적었다. K-LOC, K-LOC, 그게 방법론이다. 에휴! 어쨌든, 그 생각만 하면 항상 등골이 오싹해진다.
컴퓨터 역사 박물관에 따르면 애플 개발자 빌 앳킨슨은 1982년에 이 관행에 문제점을 발견했다.
1982년 Lisa 팀이 소프트웨어를 완성하기 위해 노력하고 있을 때, 프로젝트 관리자들은 프로그래머들에게 매주 작성한 코드 라인 수를 보고하는 양식을 제출하도록 요구하기 시작했다. 빌 앳킨슨은 그것이 어리석다고 생각했다. QuickDraw의 영역 계산 루틴을 6배 더 빠르게 만들고 2000줄 더 짧게 만든 주에 그는 양식에 "-2000"이라고 기입했다. 몇 주 후에 관리자들은 그에게 양식을 작성하라고 요구하지 않았고, 그는 기꺼이 따랐다.
소스 라인 오브 코드 추가 자료
Li, Luo; Herbsleb, Jim; Shaw, Mary (May 2005). 《Forecasting Field Defect Rates Using a Combined Time-based and Metric–based Approach a Case Study of OpenBSD (CMU-ISRI-05-125)》. Carnegie-Mellon University.