RealView Compilation Tools -...

RealView � Compilation Tools버전 4.0

컴파일러 참조 설명서

Copyright © 2007-2009 ARM Limited. All rights reserved.ARM DUI 0348BK (ID090708)

RealView Compilation Tools컴파일러 참조 설명서

Copyright © 2007-2009 ARM Limited. All rights reserved.

릴리스 정보

이 설명서에서 변경된 내용은 다음과 같습니다.

소유권 고지 사항

이 소유권 고지 사항의 아래 부분에서 달리 명시되지 않는 한 또는 표시가 있는 단어와 로고는 EU, 대한민국 및 기타 국가에서 ARM Limited의 등록 상표 또는 상표입니다. 이 설명서에 언급된 기타 브랜드와 이름은 해당 소유자의 상표일 수 있습니다.

이 설명서에 포함된 전체 또는 일부 정보나 설명된 제품은 해당 저작권 소유자의 사전 서면 승인 없이는 어떤 형태로도 개조되거나 복제될 수 없습니다.

이 설명서에 설명된 제품은 지속적으로 개발 및 개선될 수 있습니다. 이 설명서에 포함된 모든 제품 명세와 해당 사용법은 ARM의 신뢰하에 제공됩니다. 그러나 ARM에서는 상품성 또는 특정 목적에의 적합성을 비롯하여 그 밖의 묵시적이거나 명시적인 모든 보증을 부인합니다.

이 설명서는 제품 사용자를 지원하는 용도로만 만들어졌습니다. ARM은 이 설명서 정보의 사용, 정보의 오류나 누락 또는 제품의 잘못된 사용에 따른 어떠한 손실이나 손상도 책임지지 않습니다.

ARM이라는 단어가 사용되는 경우 “ARM이나 해당하는 자회사”를 의미합니다.

기밀 상태

이 설명서는 기밀 문서가 아닙니다. 이 설명서의 사용, 복사 및 공개 권한은 ARM과 설명서 사용 당사자의 동의하에 라이센스 제한을 받습니다.

액세스 제한 없음은 ARM의 내부 분류입니다.

제품 상태

이 설명서의 정보는 개발이 완료된 제품에 대한 최종 정보입니다.

웹 주소

http://www.arm.com

변경 내역

날짜 발행판 기밀 상태 변경된 내용

2007년 3월 A 기밀 문서 아님 RealView Development Suite 버전 3.1용 릴리스 3.1

2008년 9월 B 기밀 문서 아님 RealView Development Suite 버전 4.0용 릴리스 4.0

2009년 1월 23일 B 기밀 문서 아님 RealView Development Suite 버전 4.0용 설명서 업데이트

2009년 3월 2일 B 기밀 문서 아님 RealView Development Suite 버전 4.0용 설명서 업데이트 2

ii Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

목차RealView Compilation Tools컴파일러 참조 설명서

서문설명서 개요 .................................................................................................... vi사용자 의견 .................................................................................................... x

1 장 소개1.1 ARM 컴파일러 개요 .................................................................................... 1-21.2 소스 언어 모드 ............................................................................................ 1-31.3 언어 확장 및 언어 호환 ................................................................................ 1-51.4 C 및 C++ 라이브러리 .................................................................................. 1-8

2 장 컴파일러 명령 행 옵션2.1 명령 행 옵션 ................................................................................................ 2-2

3 장 언어 확장3.1 사전 처리기 확장 ......................................................................................... 3-23.2 C90 에서 사용할 수 있는 C99 언어 기능 ..................................................... 3-53.3 C++ 및 C90 에서 사용할 수 있는 C99 언어 기능 ........................................ 3-73.4 표준 C 언어 확장 ....................................................................................... 3-103.5 표준 C++ 언어 확장 ................................................................................... 3-16

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. iiiID090708 Non-Confidential, Unrestricted Access

3.6 표준 C 및 표준 C++ 언어 확장 .................................................................. 3-203.7 GNU 언어 확장 ......................................................................................... 3-26

4 장 컴파일러 관련 기능4.1 키워드 및 연산자 ........................................................................................ 4-24.2 __declspec 속성 ....................................................................................... 4-264.3 함수 속성 .................................................................................................. 4-334.4 유형 속성 .................................................................................................. 4-444.5 변수 속성 .................................................................................................. 4-484.6 Pragma ..................................................................................................... 4-584.7 명령어 내장 함수 ...................................................................................... 4-764.8 VFP 상태 내장 함수 ................................................................................ 4-1194.9 GNU 기본 제공 함수 ............................................................................... 4-1204.10 컴파일러 사전 정의 ................................................................................. 4-123

5 장 C 및 C++ 구현 정보5.1 C 및 C++ 구현 정보 .................................................................................... 5-25.2 C++ 구현 정보 .......................................................................................... 5-14

Appendix A via 파일 구문A.1 via 파일 개요 ............................................................................................... A-2A.2 구문 ............................................................................................................ A-3

Appendix B 표준 C 구현 정의B.1 구현 정의 .................................................................................................... B-2B.2 ISO C 표준에 정의되지 않은 것으로 간주되는 동작 ................................... B-9

Appendix C 표준 C++ 구현 정의C.1 정수 변환 .................................................................................................... C-3C.2 순수 가상 함수의 호출 ................................................................................ C-4C.3 언어 지원의 주요 기능 ................................................................................ C-5C.4 표준 C++ 라이브러리 구현 정의 ................................................................. C-6

Appendix D C 및 C++ 컴파일러 구현 한계D.1 C++ ISO/IEC 표준 한계 .............................................................................. D-2D.2 정수의 한계 ................................................................................................. D-4D.3 부동 소수점 숫자의 한계 ............................................................................. D-6

Appendix E NEON 지원 사용E.1 소개 ............................................................................................................ E-2E.2 벡터 데이터 유형 ........................................................................................ E-3E.3 내장 함수 .................................................................................................... E-4

iv Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

서문

이 서문에서는 RealView Compilation Tools 컴파일러 참조 설명서에 대해 소개합니다. 여기에는 다음 단원이 포함되어 있습니다.

• vi페이지의 설명서 개요

• x페이지의 사용자 의견

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. vID090708 Non-Confidential, Unrestricted Access

서문

설명서 개요

이 설명서에서는 RVCT(RealView Compilation Tools)에 대한 참조 정보를 제공하고 ARM 컴파일러에 대한 명령 행 옵션에 대해 설명합니다. 또한 컴파일러의 ARM C/C++ 구현에 대한 참조 자료를 제공합니다. ARM 컴파일러 사용 및 제어에 대한 일반적인 정보는 RVCT 컴파일러 사용 설명서를 참조하십시오.

대상 독자

이 설명서는 RVCT를 사용하여 응용 프로그램을 만드는 모든 개발자를 위한 것입니다. 여기에서는 독자가 경험 있는 소프트웨어 개발자라고 가정합니다. RVCT와 함께 제공되는 ARM 개발 도구에 대한 개요는 RealView Compilation Tools 핵심 설명서를 참조하십시오.

설명서 사용

이 설명서는 다음 장과 부록으로 구성되어 있습니다.

1장 소개

이 장에서는 ARM 컴파일러, 규칙 표준, C 및 C++ 라이브러리 개요에 대해 설명합니다.

2장 컴파일러 명령 행 옵션

이 장에서는 ARM 컴파일러에서 허용하는 모든 명령 행 옵션 목록을 제공합니다.

3장 언어 확장

이 장에서는 ARM 컴파일러가 제공하는 언어 확장에 대해 설명하고 표준 규칙 및 구현 세부 정보를 제공합니다.

4장 컴파일러 관련 기능

이 장에서는 ARM 관련 키워드, 연산자, pragma, 내장 함수, 매크로 및 세미호스팅 SVC(관리자 호출)에 대한 세부 정보를 제공합니다.

5장 C 및 C++ 구현 정보

이 장에서는 ARM 컴파일러의 언어 구현 세부 사항에 대해 설명합니다.

vi Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

서문

부록 A via 파일 구문

이 부록에서는 via 파일 구문을 설명합니다. via 파일을 사용하여 여러 ARM 도구에 명령 행 인수를 지정할 수 있습니다.

부록 B 표준 C 구현 정의

이 부록에서는 ISO C 요구조건과 직접 관련된 ARM C 구현에 대한 정보를 제공합니다.

부록 C 표준 C++ 구현 정의

이 부록에서는 ARM C++ 구현에 대한 정보를 제공합니다.

부록 D C 및 C++ 컴파일러 구현 한계

이 부록에서는 ARM 컴파일러의 C/C++ 구현의 한계에 대해 설명합니다.

부록 E NEON 지원 사용

이 부록에서는 이번 릴리스의 RVCT에서 지원되는 NEON™ 내장 함수에 대한 정보를 제공합니다.

이 설명서에서는 ARM 소프트웨어가 기본 위치에 설치되어 있다고 가정합니다. 예를 들어 Windows의 경우 기본 위치는 volume:\Program Files\ARM일 수 있습니다. 예를 들어 install_directory\Documentation\...과 같은 경로 이름을 참조할 때 install_directory는 이 위치를 가리키는 것으로 가정합니다. ARM 소프트웨어를 다른 위치에 설치한 경우에는 이 위치를 변경해야 합니다.

표기 규칙

이 설명서에서는 다음과 같은 표기 규칙을 사용합니다.

monospace 명령, 파일 및 프로그램 이름, 소스 코드와 같이 키보드로 입력할 수 있는 텍스트를 나타냅니다.

monospace 명령 또는 옵션 대신 사용할 수 있는 약어를 나타냅니다. 밑줄이 그어진 텍스트는 전체 명령이나 옵션 이름 대신 입력할 수 있습니다.

monospace italic

명령 및 함수의 인수를 나타냅니다. 인수는 특정 값으로 대체할 수 있습니다.

고정 폭 굵은 글꼴

외부 예제 코드가 사용될 경우 언어 키워드를 나타냅니다.

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. viiID090708 Non-Confidential, Unrestricted Access

서문

기울임 글꼴 중요한 사항을 강조 표시하고, 특수 용어를 소개하며, 내부 상호 참조 및 인용 부분을 나타냅니다.

굵은 글꼴 메뉴 이름과 같은 인터페이스 요소를 강조 표시합니다. 적절한 경우 설명 목록의 내용을 강조할 때와 ARM 프로세서 신호 이름을 표시할 때도 사용됩니다.

추가 정보

이 단원에는 ARM 계열 프로세서용 코드를 개발하는 데 대한 추가 정보를 제공하는 ARM Limited 및 타사 게시물 목록이 나와 있습니다.

ARM Limited는 설명서의 내용을 정기적으로 업데이트하고 수정합니다. http://infocenter.arm.com/help/index.jsp에서 정오표, 추가 목록 및 ARM FAQ(질문과 대답)를 참조하십시오.

ARM 게시물

이 설명서에는 RVCT와 함께 제공되는 각 개발 도구에 대한 참조 정보가 포함되어 있습니다. 이 제품군에 포함된 다른 게시물은 다음과 같습니다.

• RVCT 핵심 설명서(ARM DUI 0202)

• RVCT 컴파일러 사용 설명서(ARM DUI 0205)

• RVCT 라이브러리 및 부동 소수점 지원 설명서(ARM DUI 0349)

• RVCT 링커 사용 설명서(ARM DUI 0206)

• RVCT 링커 참조 설명서(ARM DUI 0381)

• RVCT 유틸리티 설명서(ARM DUI 0382)

• RVCT 어셈블러 설명서(ARM DUI 0204)

• RVCT 개발자 설명서(ARM DUI 0203)

ARM에서 지원하는 기본 표준, 소프트웨어 인터페이스 및 기타 표준에 대한 자세한 내용은 install_directory\Documentation\Specifications\...를 참조하십시오.

또한 ARM 제품과 관련된 구체적인 내용은 다음 설명서를 참조하십시오.

• ARM 아키텍처 참조 문서, ARMv7-A 및 ARMv7-R edition (ARM DDI 0406)

• ARM7-M 아키텍처 참조 문서(ARM DDI 0403)

• ARM6-M 아키텍처 참조 문서(ARM DDI 0419)

• 하드웨어 장치에 대한 ARM 데이터시트 또는 기술 참조 문서

viii Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

서문

기타 게시물

다음 게시물에서는 ETSI 기본 연산에 대한 정보를 제공합니다. 이러한 게시물은 모두 http://www.itu.int의 ITU(국제 전기 통신 연합) 통신국에서 얻을 수 있습니다.

• ETSI Recommendation G.191: Software tools for speech and audio coding standardization

• ITU-T Software Tool Library 2005 User's manual: ETSI Recommendation G.191의 일부로 포함

• ETSI Recommendation G723.1: Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s

• ETSI Recommendation G.729: Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)

TI 컴파일러 내장 함수에 대한 정보를 제공하는 발행물은 http://www.ti.com의 Texas Instruments에서 사용할 수 있습니다.

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. ixID090708 Non-Confidential, Unrestricted Access

서문

사용자 의견

RealView Compilation Tools와 해당 설명서에 대한 의견이 있으시면 ARM Limited에 알려 주시기 바랍니다.

RealView Compilation Tools에 대한 사용자 의견

RVCT와 관련된 문제가 있으시면 해당 공급업체에 문의하십시오. 문의 시 다음 사항을 함께 알려 주시면 보다 신속하고 유용한 답변을 받으실 수 있습니다.

• 사용자 이름 및 회사

• 제품 일련 번호

• 사용 중인 릴리스 정보

• 실행 중인 플랫폼의 세부 사항(예: 하드웨어 플랫폼, 운영 체제 종류 및 버전)

• 문제를 재현하는 작은 독립 실행형 코드 샘플

• 의도한 결과와 실제로 발생한 결과에 대한 명확한 설명

• 사용한 명령(명령 행 옵션 포함)

• 문제를 보여 주는 샘플 출력

• 도구의 버전 문자열(버전 번호 및 빌드 번호 포함)

설명서에 대한 사용자 의견

이 설명서에 오류나 누락이 있으면 다음 사항을 기재하여 [email protected]으로 전자 메일을 보내 주시기 바랍니다.

• 설명서 제목

• 설명서 번호

• 문의 내용에 해당하는 페이지 번호

• 문제에 대한 간략한 설명

추가 및 향상되었으면 하는 기능에 대한 일반적인 제안도 환영합니다.

x Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

1장 소개

이 장에서는 RVCT( RealView Compilation Tools)와 함께 제공되는 ARM 컴파일러에 대해 소개합니다. 또한 표준 규칙에 대해 설명하고 RVCT와 함께 제공되는 런타임 라이브러리에 대해 간략히 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• 1-2페이지의 ARM 컴파일러 개요

• 1-3페이지의 소스 언어 모드

• 1-5페이지의 언어 확장 및 언어 호환

• 1-8페이지의 C 및 C++ 라이브러리

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. 1-1ID090708 Non-Confidential, Unrestricted Access

소개

1.1 ARM 컴파일러 개요

ARM 컴파일러 armcc에서는 C 및 C++ 코드를 컴파일할 수 있습니다.

컴파일러는 다음과 같습니다.

• 최적화 컴파일러입니다. 명령 행 옵션을 사용하여 최적화 수준을 제어할 수 있습니다.

• 컴파일 대상은 다음과 같습니다.

— ISO 표준 C:1990 소스

— ISO 표준 C:1999 소스

— ISO 표준 C++:2003 소스

다음으로 컴파일합니다.

— 32비트 ARM 코드

— 16/32비트 Thumb-2 코드

— 16비트 Thumb 코드

• BSABI(ARM 아키텍처용 기본 표준 응용 프로그램 바이너리 인터페이스)를 사용하여 컴파일합니다. 특히 컴파일러는 다음을 수행합니다.

— ELF 형식으로 출력 개체를 생성합니다.

— DWARF 3(DWARF 디버깅 표준 버전 3) 디버그 정보를 생성합니다. RVCT에는 DWARF 2 디버그 테이블에 대한 지원도 포함되어 있습니다.

자세한 내용은 라이브러리 및 부동 소수점 지원 설명서에서 1-3페이지의 ABI for the ARM Architecture 규격 준수를 참조하십시오.

• 출력 코드의 어셈블리 언어 목록을 생성할 수 있으며 어셈블리 언어 목록을 소스 코드로 인터리브할 수 있습니다.

이전 릴리스에서 RVCT로 업그레이드하는 경우 또는 RVCT를 처음 사용하는 경우 RealView Compilation Tools 핵심 설명서에서 최신 정보를 읽어 보십시오.

1-2 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

소개

1.2 소스 언어 모드

ARM 컴파일러에는 여러 가지 C 및 C++ 소스 코드를 컴파일하는 데 사용할 수 있는 세 가지 고유한 소스 언어 모드가 있으며, 이는 다음과 같습니다.

• ISO C90

• ISO C99

• ISO C++

1.2.1 ISO C90

ARM 컴파일러는 1990 C 표준 및 추가 목록에서 정의된 대로 C를 컴파일합니다.

• ISO/IEC 9899:1990. C에 대한 1990 국제 표준입니다.

• ISO/IEC 9899 AM1. wchar.h 및 wtype.h를 통해 국제 문자 지원을 추가하는 1995 Normative Addendum 1입니다.

ARM 컴파일러는 ISO C90에 대한 여러 가지 확장을 지원합니다. 자세한 내용은 1-5페이지의 언어 확장 및 언어 호환을 참조하십시오.

이 문서 전체에서 사용되는 용어는 다음과 같습니다.

C90 ARM 확장과 함께 ISO C90을 의미합니다.

컴파일러 옵션 --c90을 사용하여 C90 코드를 컴파일합니다. 이것이 기본값입니다.

엄격한 C90 1990 C 표준 및 추가 목록에 정의된 대로 C를 의미합니다.

추가 참고

• 2-23페이지의 --c90


• 부록 B 표준 C 구현 정의

1.2.2 ISO C99

ARM 컴파일러는 1999 C 표준 및 추가 목록에 정의된 대로 C를 컴파일합니다.

• ISO/IEC 9899:1999. C에 대한 1999 국제 표준입니다.

ARM 컴파일러는 ISO C99에 대한 여러 가지 확장을 지원합니다. 자세한 내용은 1-5페이지의 언어 확장 및 언어 호환을 참조하십시오.


소개


C99 ISO C99(ARM 및 GNU 확장 포함)를 의미합니다.

컴파일러 옵션 --c99를 사용하여 C99 코드를 컴파일합니다.

엄격한 C99 1999 C 표준 및 추가 목록에 정의된 C를 의미합니다.

표준 C C90 또는 C99를 적절하게 의미합니다.

C C90, 엄격한 C90, C99 및 표준 C를 의미합니다.

추가 참고

• 2-23페이지의 --c99



1.2.3 ISO C++

ARM 컴파일러는 확장 스트림 및 내보내기 템플릿을 제외하고 2003 표준에 정의된 대로 C++를 컴파일합니다.

• ISO/IEC 14822:2003. C++에 대한 2003 국제 표준입니다.

ARM 컴파일러는 ISO C++에 대한 여러 가지 확장을 지원합니다. 자세한 내용은 1-5페이지의 언어 확장 및 언어 호환을 참조하십시오.


엄격한 C++ 확장 스트림 및 내보내기 템플릿을 제외한 ISO C++를 의미합니다.

표준 C++ 엄격한 C++를 의미합니다.

C++ 확장 스트림 및 내보내기 템플릿을 제외하고 ARM 확장을 사용하거나 사용하지 않는 ISO C++를 의미합니다.

컴파일러 옵션 --cpp를 사용하여 C++ 코드를 컴파일합니다.

추가 참고

• 2-31페이지의 --cpp


• 부록 C 표준 C++ 구현 정의


소개

1.3 언어 확장 및 언어 호환

컴파일러는 다양한 소스 언어에 대한 여러 가지 확장을 지원합니다. 또한 사용 가능한 소스 언어와의 호환성을 제어하는 여러 명령 행 옵션을 제공합니다.

1.3.1 언어 확장

컴파일러가 지원하는 언어 확장은 다음과 같이 분류됩니다.

C99 기능 컴파일러는 C99의 몇 가지 언어 기능을 다음과 같이 사용할 수 있습니다.

• 엄격한 C90에 대한 확장(예: //-스타일 주석)

• 표준 C++와 엄격한 C90에 대한 확장(예: restrict 포인터)

자세한 내용은 다음 항목을 참조하십시오.

• 3-5페이지의 C90에서 사용할 수 있는 C99 언어 기능

• 3-7페이지의 C++ 및 C90에서 사용할 수 있는 C99 언어 기능

표준 C 확장

컴파일러는 엄격한 C99에 대한 여러 가지 확장(예: 이전 스타일 비 프로토타입 정의에 우선하는 함수 프로토타입)을 지원합니다. 자세한 내용은 3-10페이지의 표준 C 언어 확장을 참조하십시오.

표준 C에 대한 이러한 확장은 C90에서도 사용할 수 있습니다.

표준 C++ 확장

컴파일러는 엄격한 C++에 대한 여러 가지 확장(예: 클래스 구성원의 선언에 정규화된 이름)을 지원합니다. 자세한 내용은 3-16페이지의 표준 C++ 언어 확장을 참조하십시오.

이러한 확장은 표준 C 또는 C90에 사용할 수 없습니다.

표준 C 및 표준 C++ 확장

컴파일러는 엄격한 C++ 및 엄격한 C90과 관련된 몇 가지 확장(예: 익명 클래스, 구조체 및 공용체)을 지원합니다. 자세한 내용은 3-20페이지의 표준 C 및 표준 C++ 언어 확장을 참조하십시오.


소개

GNU 확장 컴파일러는 GNU 컴파일러에서 제공하는 몇 가지 확장(예: GNU 스타일의 확장된 lvalue 및 GNU 기본 제공 함수)을 지원합니다. 자세한 내용은 다음 항목을 참조하십시오.

• 언어 호환

• 3-26페이지의 GNU 언어 확장

• 4장 컴파일러 관련 기능

ARM 관련 확장

컴파일러는 ARM 컴파일러와 관련된 다양한 확장(예: 명령어 내장 함수 및 기타 기본 제공 함수)을 지원합니다. 자세한 내용은 4장 컴파일러 관련 기능을 참조하십시오.

1.3.2 언어 호환

컴파일러에는 소스 언어에 대한 호환성의 정도에 따라 여러 가지 모드가 있습니다.

엄격한 모드 엄격한 모드에서는 컴파일러가 소스 언어와 관련된 언어 표준과의 호환성을 엄격하게 적용합니다. 예를 들어 // 스타일 주석을 사용하면 엄격한 C90을 컴파일할 때 오류가 발생합니다.

엄격한 모드에서 컴파일하려면 명령 행 옵션 --strict를 사용하십시오.

GNU 모드 GNU 모드에서는 관련 소스 언어에 대한 모든 GNU 컴파일러 확장을 사용할 수 있습니다. 예를 들어 GNU 모드는 다음과 같습니다.

• 소스 언어가 C90, C99 또는 엄격하지 않은 C++인 경우 switch 문의 케이스 범위를 사용할 수 있습니다.

• 소스 언어가 C90 또는 엄격하지 않은 C++인 경우 C99 스타일이 지정된 이니셜라이저를 사용할 수 있습니다.

GNU 모드에서 컴파일하려면 컴파일러 옵션 --gnu를 사용하십시오.

참고

일부 GNU 확장은 엄격하지 않은 모드에서도 사용할 수 있습니다.


소개

예제

다음 예제에서는 소스 언어 모드와 언어 호환 모드 결합을 보여 줍니다.

• 명령 행 옵션 --strict를 사용하여 .cpp 파일을 컴파일하면 표준 C++가 컴파일됩니다.

• 명령 행 옵션 --gnu를 사용하여 C 소스 파일을 컴파일하면 GNU 모드 C90이 컴파일됩니다.

• 명령 행 옵션 --strict 및 --gnu를 사용하여 .c 파일을 컴파일하면 오류가 발생합니다.

추가 참고

• 2-70페이지의 --gnu

• 2-124페이지의 --strict, --no_strict


• 컴파일러 사용 설명서의 2-13페이지의 파일 명명 규칙


소개

1.4 C 및 C++ 라이브러리

RVCT는 다음 런타임 C 및 C++ 라이브러리를 제공합니다.

ARM C 라이브러리

ARM C 라이브러리는 표준 C 함수와 C 및 C++ 라이브러리에서 사용하는 도우미 함수를 제공합니다. C 라이브러리는 세미호스팅된 환경에서 printf와 같은 표준 C 라이브러리 함수를 구현하는 데 사용되는 타겟 종속 함수도 제공합니다. C 라이브러리는 사용자의 코드에서 타겟 종속 함수를 재정의하여 세미호스팅 종속성을 제거할 수 있도록 구조화됩니다.

ARM 라이브러리는 다음 규칙을 준수합니다.

• CLIBABI(C Library ABI for the ARM Architecture)

• CPPABI(C++ ABI for the ARM Architecture)

자세한 내용은 라이브러리 및 부동 소수점 지원 설명서에서 1-3페이지의 ABI for the ARM Architecture 규격 준수를 참조하십시오.

Rogue Wave Standard C++ Library 버전 2.02.03

Rogue Wave Standard C++ 라이브러리는 Rogue Wave Software, Inc.에서 제공한 대로 cout와 같은 표준 C++ 함수 및 개체를 제공합니다. 이 라이브러리는 STL(Standard Template Library)이라는 데이터 구조체와 알고리즘을 포함합니다. C++ 라이브러리는 C 라이브러리를 사용하여 타겟에 따라 다른 지원을 제공합니다. Rogue Wave Standard C++ Library는 C++ 예외 사용이 가능한 상태로 제공됩니다.

Rogue Wave 라이브러리에 대한 자세한 내용은 Rogue Wave HTML 설명서 및 Rogue Wave 웹 사이트를 참조하십시오. http://www.roguewave.com

지원 라이브러리

ARM C 라이브러리는 C++ 지원을 사용하도록 하고 다른 아키텍처 및 프로세서용으로 코드를 컴파일하기 위한 추가 구성요소를 제공합니다.

C 및 C++ 라이브러리는 이진 형식으로만 제공됩니다. 타겟 시스템의 바이트 순서, 인터워킹 선택 여부 및 부동 소수점 지원 선택 여부와 같은 주요 빌드 옵션의 각 조합에 대한 1990 ISO 표준 C 라이브러리의 변형이 있습니다.

자세한 내용은 라이브러리 및 부동 소수점 지원 설명서에서 2장 C 및 C++ 라이브러리를 참조하십시오.


2장 컴파일러 명령 행 옵션

이 장에서는 ARM 컴파일러 armcc에서 허용하는 명령 행 옵션에 대해 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• 2-2페이지의 명령 행 옵션


컴파일러 명령 행 옵션

2.1 명령 행 옵션

이 단원에서는 컴파일러에서 지원하는 명령 행 옵션을 알파벳 순으로 나열합니다.

2.1.1 -Aopt

이 옵션은 컴파일러에 의해 어셈블러가 호출될 때 어셈블러로 전달할 명령 행 옵션을 지정하여 .s 입력 파일 또는 임베디드 어셈블리 언어 함수를 어셈블합니다.

구문

-Aopt

인수 설명:

opt 어셈블러로 전달할 명령 행 옵션입니다.

참고

일부 컴파일러 명령 행 옵션은 컴파일러에 의해 어셈블러가 호출될 때마다 자동으로 어셈블러로 전달됩니다. 예를 들어 컴파일러 명령 행에 --cpu 옵션을 지정하면 어셈블러가 호출될 때마다 이 옵션이 어셈블러로 전달되어 .s 파일 또는 임베디드 어셈블러가 어셈블됩니다.

컴파일러에 의해 어셈블러로 전달되는 컴파일러 명령 행 옵션을 보려면 컴파일러 명령 행 옵션 -A--show_cmdline을 사용합니다.

예제

armcc -A--predefine="NEWVERSION SETL {TRUE}" main.c

제한

-A를 사용하여 지원되지 않는 옵션을 전달하면 오류가 생성됩니다.

추가 참고

• 2-32페이지의 --cpu=name

• 2-81페이지의 -Lopt

• 2-120페이지의 --show_cmdline



2.1.2 --allow_null_this, --no_allow_this

이 옵션을 사용하면 null 객체 포인터에 대한 멤버 함수 호출 여부를 설정할 수 있습니다.

기본값

기본값은 --no_allow_null_this입니다.

2.1.3 --alternative_tokens, --no_alternative_tokens

이 옵션을 사용하면 C 및 C++에서 대체 토큰이 인식되도록 할 것인지 여부를 설정할 수 있습니다.

사용법

C 및 C++에서 이 옵션을 사용하여 이중음자 인식을 제어할 수 있습니다. C++에서 이 옵션을 사용하여 and 및 bitand 같은 연산자 키워드의 인식을 제어할 수 있습니다.

기본값

기본값은 --alternative_tokens입니다.

2.1.4 --anachronisms, --no_anachronisms

이 옵션을 사용하면 C++에서 구식 표현을 사용할 것인지 여부를 설정할 수 있습니다.

모드

이 옵션은 소스 언어가 C++인 경우에만 적용됩니다.

기본값

기본값은 --no_anachronisms입니다.

예제

typedef enum { red, white, blue } tricolor;inline tricolor operator++(tricolor c, int){



int i = static_cast<int>(c) + 1;return static_cast<tricolor>(i);

}void foo(void){

tricolor c = red;c++; // okay++c; // anachronism

}

--anachronisms 옵션을 사용하여 이 코드를 컴파일하면 경고 메시지가 생성됩니다.

--nachronisms 옵션을 사용하지 않고 이 코드를 컴파일하면 오류 메시지가 생성됩니다.

추가 참고



• 2-126페이지의 --strict_warnings

• 5-15페이지의 구식 표현

2.1.5 --apcs=qualifer...qualifier

이 옵션은 코드 생성 시 인터워킹 및 위치 독립을 제어합니다.

--apcs 명령 행 옵션에 한정자를 지정하여 컴파일러에서 사용되는 AAPCS(ARM 아키텍처용 프로시저 호출 표준)의 변형을 정의할 수 있습니다.

구문

--apcs=qualifer...qualifier

여기서 qualifier...qualifier는 한정자 목록을 나타내며 다음 조건을 만족해야 합니다.

• 적어도 하나의 한정자가 있어야 함

• 목록의 각 한정자를 구분하기 위해 공백을 사용해서는 안 됨



qualifier의 각 인스턴스는 다음 중 하나여야 합니다.

/interwork, /nointerwork

ARM/Thumb™ 인터워킹을 지원하거나 지원하지 않는 코드를 생성합니다. 기본값은 /nointerwork입니다. 단, ARMv6 이상의 경우에는 기본값이 /interwork입니다.

/ropi, /noropi ROPI(읽기 전용 위치 독립적) 코드 생성을 설정 또는 해제합니다. 기본값은 /noropi입니다.

/[no]pic는 /[no]ropi의 별칭입니다.

/rwpi, /norwpi RWPI(읽기/쓰기 위치 독립적) 코드 생성을 설정 또는 해제합니다. 기본값은 /norwpi입니다.

/[no]pid는 /[no]rwpi의 별칭입니다.

/fpic, /nofpic 상대 주소 참조가 프로그램이 로드된 위치와는 독립적인 읽기 전용 위치 독립적 코드의 생성을 설정 또는 해제합니다.

참고

또한 여러 개의 한정자를 지정할 수 있습니다. 예를 들어 --apcs=/nointerwork/noropi/norwpi는 --apcs=/nointerwork --apcs=noropi/norwpi와 동일합니다.

기본값

--apcs 옵션을 지정하지 않으면 컴파일러에서 --apcs=/nointerwork/noropi/norwpi/nofpic로 간주됩니다.

사용법

/interwork, /nointerwork

기본적으로 생성되는 코드는 다음과 같습니다.

• 아키텍처 ARMv5T 이상에 해당하는 --cpu 옵션을 지정하지 않는 한 인터워킹을 지원하지 않는 /nointerwork코드가 생성됩니다.

• ARMv5T 이상의 경우 인터워킹을 지원하는 /interwork 코드가 생성됩니다. ARMv5T 및 최신 ARM 아키텍처에서 인터워킹은 자동으로 이루어집니다.



/ropi, /noropi /ropi 한정자를 선택하여 ROPI 코드를 생성할 경우 컴파일러에서 다음을 수행합니다.

• 읽기 전용 코드 및 데이터 PC 상대 주소 지정

• 읽기 전용 출력 섹션에 PI(위치 독립적) 특성 설정

참고

C++를 컴파일할 때는 --apcs=/ropi가 지원되지 않습니다.

/rwpi, /norwpi /rwpi 한정자를 선택하여 RWPI 코드를 생성할 경우 컴파일러에서 다음을 수행합니다.

• 정적 기본 레지스터 sb의 오프셋을 사용하여 쓰기가 가능한 데이터의 주소 지정. 이것은 다음을 의미합니다.

— 런타임에 RW 데이터 영역의 기본 주소를 고정할 수 있습니다.

— 데이터에 여러 인스턴스가 있을 수 있습니다.

— 데이터는 위치 독립적일 수 있지만 반드시 그래야 하는 것은 아님

• 읽기/쓰기 출력 섹션에 PI 특성 설정

참고

--lower_rwpi 옵션이 기본값이므로 RWPI가 아닌 코드는 자동으로 동등한 RWPI 코드로 변환됩니다. C++ 생성자 메커니즘에 따라 C에 대해서도 런타임에 이 정적 초기화가 수행됩니다.

/fpic, /nofpic 이 옵션을 선택하면 컴파일러에서 다음을 수행합니다.

• PC 상대 주소 지정을 사용하여 모든 정적 데이터에 액세스

• 링커에서 만든 GOT(전역 오프셋 테이블) 엔트리를 사용하여 가져오거나 내보낸 모든 읽기/쓰기 데이터에 액세스

• PC에 대해 상대적인 모든 읽기 전용 데이터에 액세스

코드에서 공유 객체를 사용하는 경우에는 /fpic를 사용하여 코드를 컴파일해야 합니다. 상대 주소 지정이 코드에서 System V 공유 라이브러리를 사용하는 경우에만 구현되기 때문입니다.



정적 이미지 또는 정적 라이브러리를 빌드하는 경우에는 /fpic를 사용하여 컴파일할 필요가 없습니다.

C++를 컴파일할 때에는 /fpic를 사용할 수 있습니다. 이 경우 가상 함수 테이블 및 typeinfo가 읽기/쓰기 영역에 배치되어 PC 위치에 대해 상대적인 위치에서 액세스할 수 있습니다.

참고

System V 또는 ARM Linux 공유 라이브러리를 빌드할 경우 --no_hide_all과 --apcs /fpic를 함께 사용합니다.

제한

/ropi, /rwpi 또는 /fpic로 코드를 컴파일하는 경우 제한이 있습니다.

/ropi /ropi로 컴파일할 때의 주요 제한은 다음과 같습니다.

• C++를 컴파일할 때 --apcs=/ropi의 사용이 지원되지 않습니다.

• 일부 올바른 C 구문은 --apcs=/ropi에 대해 컴파일할 때 작동하지 않습니다. 예를 들면 다음과 같습니다.extern const int ci; // roconst int *p2 = &ci; // this static initialization // does not work with --apcs=/ropi

이러한 정적 초기화를 사용할 수 있도록 하려면 --lower_ropi 옵션을 사용하여 코드를 컴파일합니다. 예를 들면 다음과 같습니다.armcc --apcs=/ropi --lower_ropi

/rwpi /rwpi로 컴파일할 때의 주요 제한은 다음과 같습니다.

• 일부 올바른 C 구문은 --apcs=/rwpi에 대해 컴파일할 때 작동하지 않습니다. 예를 들면 다음과 같습니다.int i; // rwint *p1 = &i; // this static initialization // does not work with --apcs=/rwpi

// --no_lower_rwpi

이러한 정적 초기화를 사용할 수 있도록 하려면 --lower_rwpi 옵션을 사용하여 코드를 컴파일합니다. 예를 들면 다음과 같습니다.armcc --apcs=/rwpi



참고

이것이 기본값이므로 --lower_rwpi를 지정하지 않아도 됩니다.

/fpic /fpic 로 컴파일할 때의 주요 제한은 다음과 같습니다.

• --apcs=/fpic를 사용하면 컴파일러에서 __declspec(dllexport)가 표시된 함수와 데이터만 내보냅니다.

• 동일한 명령 행에서 --apcs=/fpic 및 --no_hide_all을 사용하면 컴파일러에서 __declspec(dll*)을 사용하지 않는 모든 extern 변수와 함수에 대해 기본 ELF 동적 표시를 사용합니다. 컴파일러에서는 기본 ELF 표시를 통해 함수 자동 인라인을 비활성화합니다.

• GNU 모드에서 --apcs=/fpic를 사용하면 --no_hide_all도 사용해야 합니다.

추가 참고

• 2-73페이지의 --hide_all, --no_hide_all

• 2-90페이지의 --lower_ropi, --no_lower_ropi

• 2-91페이지의 --lower_rwpi, --no_lower_rwpi

• 4-26페이지의 __declspec(dllexport)

• 라이브러리 및 부동 소수점 지원 설명서의 2-5페이지의 재진입 및 스레드 안전성 코드 작성

• 링커 사용 설명서의 3-20페이지의 베니어

• 링커 참조 설명서의 4장 BPABI 및 SysV 공유 라이브러리와 실행 가능 파일

• install_directory\Documentation\Specifications\...에서 ARM 아키텍처용 프로시저 호출 표준

2.1.6 --arm

이 옵션은 ARM 명령어 세트를 타겟으로 하도록 하는 컴파일러에 대한 요청입니다. 컴파일러는 ARM 및 Thumb 코드를 모두 생성할 수 있지만 ARM 코드가 기본적으로 사용된다고 인식합니다.



참고

이 옵션은 Cortex-M3과 같은 Thumb 전용 프로세서에는 적용되지 않습니다.

기본값

이것은 ARM 명령어 세트를 지원하는 타겟의 기본 옵션입니다.

추가 참고

• 2-15페이지의 --arm_only

• 2-32페이지의 --cpu=list


• 2-127페이지의 --thumb

• 4-59페이지의 #pragma arm

• 컴파일러 사용 설명서의 2-24페이지의 타겟 프로세서 또는 아키텍처 지정

2.1.7 --arm_linux

이 옵션은 ARM Linux 컴파일에 적합한 기본값으로 기타 옵션 세트를 구성합니다.

사용법

이러한 기본값은 다음 ARM Linux 옵션 중 하나를 사용하면 자동으로 활성화됩니다.

• --arm_linux_paths

• 전체 GCC 에뮬레이션 모드의 --translate_gcc

• 전체 GCC 에뮬레이션 모드의 --translate_g++

• 전체 GCC 에뮬레이션 모드의 --translate_gld

이 옵션은 대개 레거시 코드 마이그레이션에 사용합니다. 이 코드를 사용하면 기존 메이크파일에 사용되는 컴파일러 옵션을 단순화하는 동시에 사용되는 헤더 및 라이브러리 검색 경로에 대한 완전한 명시적 제어를 유지할 수 있습니다.

RVCT 버전 4.0 이전 빌드에서 마이그레이션하는 경우 컴파일러에 제공되는 이와 같은 모든 옵션을 단일 --arm_linux 옵션으로 바꿀 수 있습니다.



기본값

기본적으로 구성되는 옵션 세트는 다음과 같습니다.

• --apcs=/interwork

• --enum_is_int

• --gnu

• --library_interface=aeabi_glibc

• --no_hide_all

• --preinclude=linux_rvct.h

• --wchar32

예제

기본 옵션 세트를 적용하려면 --arm_linux를 사용합니다.

기본 옵션을 재정의하려면 해당 옵션을 별도로 지정하십시오. 예를 들면 --arm_linux --hide_all과 같습니다.

두 번째 예제에서 --hide_all은 --arm_linux에 포함된 --no_hide_all을 재정의합니다.

추가 참고

• 2-11페이지의 --arm_linux_config_file=path

• 2-12페이지의 --arm_linux_configure

• 2-14페이지의 --arm_linux_paths

• 2-25페이지의 --configure_cpp_headers=path

• 2-26페이지의 --configure_extra_includes=paths

• 2-27페이지의 --configure_extra_libraries=paths

• 2-28페이지의 --configure_gcc=path

• 2-29페이지의 --configure_gld=path

• 2-30페이지의 --configure_sysroot=path

• 2-119페이지의 --shared

• 2-128페이지의 --translate_g++

• 2-130페이지의 --translate_gcc

• 2-131페이지의 --translate_gld

• 링커 참조 설명서의 2-3페이지의 --arm_linux

• 링커 참조 설명서의 2-37페이지의 --library=name



• 링커 참조 설명서의 2-57페이지의 --[no_]search_dynamic_libraries

• Application Note 212 - Building Linux applications using RVCT v4.0 and the GNU Tools and Libraries

2.1.8 --arm_linux_config_file=path

이 옵션은 ARM Linux 빌드에 대해 생성되는 구성 파일의 위치를 지정합니다. 이 옵션을 사용하면 코드를 컴파일할 때 표준 Linux 구성 설정을 사용할 수 있습니다.

구문

--arm_linux_config_file=path

여기서 path는 구성 파일의 경로 및 파일 이름입니다.

제한

구성 파일을 생성할 때와 컴파일 및 연결 중에 구성을 사용할 때는 모두 이 옵션을 사용해야 합니다.

명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_gcc, --translate_g++ 또는 --translate_gld를 사용하면 기타 특정 옵션의 기본 설정에 영향을 주게 됩니다. --bss_threshold의 기본값은 0이, --signed_bitfields 및 --unsigned_bitfields의 기본값은 --signed_bitfields가 되고 --enum_is_int 및 --wchar32가 설정됩니다.

추가 참고

• 2-9페이지의 --arm_linux



• 2-21페이지의 --bss_threshold=num









• 2-55페이지의 --enum_is_int


• 2-121페이지의 --signed_bitfields, --unsigned_bitfields




• 2-143페이지의 --wchar32





2.1.9 --arm_linux_configure

이 옵션은 GNU C 라이브러리 glibc의 포함 경로, 라이브러리 경로 및 표준 라이브러리를 설명하는 구성 파일을 만들어 ARM Linux에서 사용할 RVCT를 구성합니다. 이렇게 만든 구성 파일은 코드를 빌드할 때 사용됩니다.

사용법

자동 및 수동 구성 방식이 적용됩니다. 자동 구성의 경우 PATH 환경 변수에 대한 GNU 도구 체인 설치를 자동으로 찾아서 이를 쿼리하여 사용할 구성 설정을 결정합니다. 수동 구성을 사용하면 헤더 파일 및 라이브러리에 대해 직접 위치를 지정할 수 있습니다. 전체 GNU 도구 체인을 설치하지 않은 경우 수동 구성을 사용할 수 있습니다.

자동 구성을 수행하려면 다음을 사용합니다.

• armcc --arm_linux_configure --arm_linux_config_file=config_file_path --configure_gcc=path --configure_gld=path

여기서 config_file_path는 만들어지는 구성 파일의 경로 및 파일 이름입니다. 경우에 따라 GCC(GNU 컴파일러 컬렉션) 드라이버 위치와 GNU 링커 위치를 지정하여 시스템 PATH 환경 변수에서 결정된 위치를 재정의할 수 있습니다.



수동 구성을 수행하려면 다음을 사용합니다.

• armcc --arm_linux_configure --arm_linux_config_file=path --configure_cpp_headers=path --configure_sysroot=path

여기서 GNU libstdc++ STL(Standard Template Library) 헤더 파일의 경로와 라이브러리 및 헤더 파일이 들어 있는 시스템 루트 경로가 지정됩니다.

제한

자동 구성을 사용하려면 GNU 도구 체인이 시스템에 있어야 합니다.

자동 구성 방법을 사용하는 경우 시스템 PATH 환경 변수를 사용하여 ARM Linux GCC를 찾아야 합니다. 시스템 경로에 적절한 GCC가 없는 경우에는 경로에 직접 GCC를 추가하거나 --configure_gcc(및 경우에 따라 --configure_gld)를 사용하여 수동으로 적절한 GCC 위치를 지정할 수 있습니다.

기본값

추가 옵션을 사용하여 GCC 또는 GNU 링커 위치를 지정하지 않으면 자동 구성이 적용됩니다. 즉, 추가 옵션을 통해 별도로 지정하지 않는 한 컴파일러는 시스템 경로 환경 변수를 사용하여 ARM Linux GCC를 찾습니다.

추가 참고




















2.1.10 --arm_linux_paths

이 옵션을 사용하면 ARM Linux용 코드를 빌드할 수 있습니다.

사용법

이 옵션은 ARM Linux에 사용할 RVCT를 구성한 후에 사용할 수 있습니다.

이것은 컴파일러에만 해당하는 옵션으로, 컴파일러 드라이버를 사용하여 표준 시스템 객체 파일 및 라이브러리의 연결과 선택을 지시하는 일반적인 GCC 사용 모델을 따릅니다.

RVCT 버전 4.0 이전의 RVCT 버전으로부터 마이그레이션할 때도 이 옵션을 사용할 수 있습니다. --arm_linux_configure를 사용하여 구성 파일을 만든 후에는 --arm_linux_paths 옵션을 통해 표준 옵션 및 검색 경로 목록을 교체하여 기존 빌드를 수정할 수 있습니다. 즉, --arm_linux_paths를 사용하여 다음을 교체할 수 있습니다.

• --arm_linux에 대해 나열된 모든 기본 옵션

• 헤더 경로

• 라이브러리 경로

• 표준 라이브러리

제한

--arm_linux_config_file=filename을 사용하여 구성 파일 위치를 지정해야 합니다.

예제

응용 프로그램 코드 컴파일 및 연결:

armcc --arm_linux_paths --arm_linux_config_file=my_config_file -o hello -O2 -Otime -g hello.c

공유 라이브러리에 사용할 소스 파일 source.c 컴파일:

armcc --arm_linux_paths --arm_linux_config_file=my_config_file --apcs=/fpic -c source.c



컴파일러를 사용하여 두 객체 파일(obj1 및 obj2)을 공유 라이브러리(my_shared_lib.so)에 연결:

armcc --arm_linux_paths --arm_linux_config_file=my_config_file --shared -o my_shared_lib.so obj1.o obj2.o

추가 참고


















2.1.11 --arm_only

이것은 ARM 전용 코드만 적용합니다. 컴파일러는 타겟 아키텍처에 Thumb이 없는 것처럼 동작합니다.

컴파일러는 --arm_only 옵션을 어셈블러 및 링커에 전달합니다.

예제

armcc --arm_only myprog.c



참고

armcc --arm_only --thumb myprog.c를 지정해도 컴파일러가 Thumb 코드가 없는지 코드를 확인하는 것은 아닙니다. 즉, --thumb은 --arm_only를 무시합니다.

추가 참고

• 2-8페이지의 --arm


• --16 및 --32에 대한 자세한 내용은 어셈블러 설명서에서 3-2페이지의 명령 구문을 참조하십시오

2.1.12 --asm

이 옵션은 컴파일러에 의해 생성된 기계어 코드의 디스어셈블리 파일에 목록을 작성하도록 컴파일러에 지시합니다.

객체 코드는 이 옵션을 선택했을 때 생성됩니다. -c 옵션을 선택하지 않으면 링크 단계도 수행됩니다.

참고

객체 코드를 생성하지 않고 컴파일러에 의해 생성된 기계어 코드의 디스어셈블리를 생성하려면 -asm 대신 -S를 선택합니다.



사용법

-asm의 동작 및 생성된 디스어셈블리 파일의 전체 이름은 다음과 같은 옵션의 조합에 따라 달라집니다.

추가 참고

• 2-22페이지의 -c

• 2-79페이지의 --interleave

• 2-96페이지의 --multifile, --no_multifile

• 2-98페이지의 -o filename

• 2-119페이지의 -S


표 2-1 --asm 옵션을 사용하여 컴파일

컴파일러 옵션 동작

--asm 컴파일된 소스의 디스어셈블리 파일에 목록을 작성합니다.

c 옵션을 사용하지 않으면 링크 단계도 수행됩니다.

디스어셈블리는 파일 확장명이 .s인 입력 파일 이름을 기본값으로 사용하는 텍스트 파일에 작성됩니다.

--asm -c 링크 단계가 수행되지 않는 것을 제외하고 --asm과 같습니다.

--asm --interleave 소스 코드가 디스어셈블리로 인터리브되는 것을 제외하고 --asm과 같습니다.

디스어셈블리는 파일 확장명이 .txt인 입력 파일 이름을 기본값으로 사용하는 텍스트 파일에 작성됩니다.

--asm --multifile 컴파일러가 주 파일로 병합된 파일에 대해 빈 객체 파일을 생성하는 것을 제외하고 --asm과 같습니다.

--asm -o filename 객체 파일 이름이 filename인 것을 제외하고 --asm과 같습니다.

디스어셈블리는 filename.s 파일에 작성됩니다.

객체 파일의 이름에는 파일 확장명 .s를 사용해서는 안 됩니다. 객체 파일의 파일 확장명이 .s이면 디스어셈블리는 객체 파일의 맨 위에 작성됩니다. 이런 경우 예측할 수 없는 결과가 발생할 수 있습니다.



2.1.13 --autoinline, --no_autoinline

이 옵션을 사용하면 함수의 자동 인라인을 사용할 것인지 여부를 설정할 수 있습니다.

높은 최적화 수준에서 컴파일러는 인라인을 설정해야 하는 함수에 자동으로 인라인을 설정합니다. --Ospace 및 --Otime 옵션은 함수 크기와 같은 다른 요소와 함께 컴파일러에서 자동으로 함수를 인라인하는 방법에 영향을 줍니다.

여러 가지 다른 요소와 함께 --Otime을 선택하면 함수가 인라인될 가능성이 높아집니다.

기본값

최적화 수준 -O0 및 -O1의 기본값은 --no_autoinline입니다.

최적화 수준 -O2 및 -O3의 기본값은 --autoinline입니다.

추가 참고

• 2-61페이지의 --forceinline

• 2-77페이지의 --inline, --no_inline

• 2-100페이지의 -Onum

• 2-103페이지의 -Ospace

• 2-103페이지의 -Otime

2.1.14 --bigend

이 옵션은 빅엔디안 메모리를 사용하여 ARM 프로세서에 대한 코드를 생성하도록 컴파일러에 지시합니다.

ARM 아키텍처에서는 다음과 같은 빅엔디안 모드를 정의합니다.

BE8 바이트 불변 주소 지정 모드(ARMv6 이상)

BE32 레거시 빅엔디안 모드

BE8 및 BE32 선택은 링크 타임에 지정됩니다.

기본값

--bigend를 명시적으로 지정하지 않으면 컴파일러에서 --littleend로 간주됩니다.



추가 참고

• 2-89페이지의 --littleend

• 개발자 설명서의 2-14페이지의 엔디안 지원

• 링커 참조 설명서의 2-5페이지의 --be8

• 링커 참조 설명서의 2-5페이지의 --be32

2.1.15 --bitband

이 옵션은 const 전역 구조 객체가 아닌 모든 객체에 대해 비트 밴딩을 수행합니다. 그 결과 메모리의 각 워드가 비트 밴딩 영역의 단일 비트로 매핑됩니다. 그러면 메모리 아키텍처의 SRAM 및 주변 기기 영역에서 단일 비트 값에 효율적으로 원자적 액세스를 수행할 수 있습니다.

메모리 액세스 너비를 구분하는 주변 기기의 경우 별칭 공간에 대한 바이트, 하프워드 및 워드 저장 또는 로드가 char, short 및 int 형식의 bitband 구조체 비트 필드에 대해 각각 생성됩니다.

제한

다음 제한이 적용됩니다.

• 이 옵션은 구조체 형식에만 적용됩니다. 모든 공용체 또는 공용체를 구성원으로 포함하는 집계 형식은 비트 밴딩할 수 없습니다.

• 구조체 구성원은 개별적으로 비트 밴딩할 수 없습니다.

• 단일 비트의 비트 필드에 대해서만 비트 밴딩 액세스가 생성됩니다.

• const 객체, 포인터 및 지역 개체에 대해서는 비트 밴딩 액세스가 생성되지 않습니다.

예제

예제 2-1에서 --bitband 명령 행 옵션으로 컴파일 할 때 i 및 k 비트 필드에 대한 쓰기는 비트 밴딩됩니다.

예제 2-1 비트 밴딩 예제

typedef struct {int i : 1;int j : 2;



int k : 1;} BB;

BB value;

void update_value(void){value.i = 1;value.k = 1;

}

추가 참고

• 4-44페이지의 __attribute__((bitband))

• 컴파일러 사용 설명서의 4-16페이지의 비트 밴딩

• 해당 프로세서의 기술 참조 문서

2.1.16 --brief_diagnostics, --no_brief_diagnostics

이 옵션을 사용하면 컴파일러에서 간단한 진단 메시지를 출력하도록 할 것인지 여부를 설정할 수 있습니다.

이 옵션을 설정할 경우 너무 길어서 한 행에 들어가지 않으면 원래 소스 행이 표시되지 않고 오류 메시지 텍스트가 다음 행으로 줄바꿈되지 않습니다.

기본값

기본값은 --no_brief_diagnostics입니다.

예제

/* main.c */#include <stdio.h>int main(void){

printf("“Hello, world\n");return 0;

}

--brief_diagnostics를 사용하여 이 코드를 컴파일하면 경고 메시지가 생성됩니다.

추가 참고

• 2-46페이지의 --diag_error=tag[,tag,...]



• 2-47페이지의 --diag_remark=tag[,tag,... ]

• 2-48페이지의 --diag_style={arm|ide|gnu}

• 2-49페이지의 --diag_suppress=tag[,tag,...]

• 2-51페이지의 --diag_warning=tag[,tag,...]

• 2-56페이지의 --errors=filename

• 2-116페이지의 --remarks

• 2-141페이지의 -W

• 2-144페이지의 --wrap_diagnostics, --no_wrap_diagnostics

• 컴파일러 사용 설명서의 6장 진단 메시지

2.1.17 --bss_threshold=num

이 옵션은 섹션 내에서 작은 전역 ZI 데이터 항목의 배치를 제어합니다. 작은 전역 ZI 데이터 항목은 초기화되지 않은 데이터 항목이며 8바이트 크기이거나 그보다 작습니다.

구문

--bss_threshold=num

인수 설명:

num 다음 중 하나입니다.

0 작은 전역 ZI 데이터 항목을 ZI 데이터 섹션에 배치합니다.

8 작은 전역 ZI 데이터 항목을 RW 데이터 섹션에 배치합니다.

사용법

RVCT의 현재 버전에서 컴파일러는 최적화 작업의 일환으로 작은 전역 ZI 데이터 항목을 RW 데이터 섹션에 배치할 수 있습니다. 기본적으로 RVCT 2.0.1 및 이전 버전에서는 작은 전역 ZI 데이터 항목을 ZI 데이터 섹션에 배치하였습니다.

작은 전역 ZI 데이터 항목을 ZI 데이터 섹션에 배치하는 것과 관련된 RVCT 2.0.1 이전 버전의 동작을 에뮬레이션하려면 이 옵션을 사용합니다.



참고

--bss_threshold=0 옵션을 선택하면 컴파일러에서 현재 컴파일 모듈에 있는 모든 작은 전역 ZI 데이터 항목을 ZI 데이터 섹션에 배치합니다. 특정 변수 배치와 관련된 옵션은 다음과 같습니다.

• ZI 데이터 섹션에 배치하려면 __attribute__((zero_init)) 사용

• 특정 ZI 데이터 섹션에 배치하려면 __attribute__((section))와 __attribute__((zero_init))의 조합 사용

기본값

--bss_threshold 옵션을 지정하지 않으면 컴파일러에서 --bss_threshold=8로 간주됩니다.

명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_gcc 또는 --translate_g++를 사용하면 컴파일러에서 --bss_threshold=0으로 간주됩니다.

예제

int glob1; /* ZI (.bss) in RVCT 2.0.1 and earlier *//* RW (.data) in RVCT 2.1 and later */

--bss_threshold=0을 사용하여 이 코드를 컴파일하면 glob1가 ZI 데이터 섹션에 배치됩니다.

추가 참고

• 4-59페이지의 #pragma arm section [section_sort_list]



• 4-52페이지의 __attribute__((section("name")))

• 4-57페이지의 __attribute__((zero_init))

2.1.18 -c

이 옵션은 컴파일 단계를 수행하도록 컴파일러에 지시하지만 링크 단계를 수행하도록 하지는 않습니다.



참고

이 옵션은 -C(대문자) 옵션과는 다릅니다.

사용법

두 개 이상의 소스 파일이 포함된 프로젝트에서는 -c 옵션을 사용하는 것이 좋습니다.

추가 참고

• 2-16페이지의 --asm

• 2-85페이지의 --list


• 2-119페이지의 -S

2.1.19 -C

이 옵션은 사전 처리기 출력에 주석을 유지하도록 컴파일러에 지시합니다.

이 옵션을 선택하면 -E 옵션이 암시적으로 선택됩니다.

참고

이 옵션은 -c(소문자) 옵션과는 다릅니다.

추가 참고

• 2-54페이지의 -E

2.1.20 --c90

이 옵션을 사용하면 C90 소스 코드를 컴파일할 수 있습니다.

기본값

이 옵션은 접미사가 .c, .ac 또는 .tc인 파일에 대해 암시적으로 선택됩니다.

참고

.ac 및 .tc 파일 확장명은 제공되지 않습니다.



추가 참고

• --c99





2.1.21 --c99

이 옵션을 사용하면 C99 소스 코드를 컴파일할 수 있습니다.

추가 참고

• 2-23페이지의 --c90




2.1.22 --code_gen, --no_code_gen

이 옵션을 사용하면 객체 코드를 생성할 것인지 여부를 설정할 수 있습니다.

객체 코드 생성을 사용하지 않는 경우 컴파일러에서는 객체 파일을 만들지 않고 구문 검사만 수행합니다.

기본값

기본값은 --code_gen입니다.

2.1.23 --compatible=name

이 옵션을 사용하면 컴파일러에서 생성된 코드가 여러 프로세서 또는 아키텍처와 호환되도록 지정할 수 있습니다.



표 2-2에는 사용 가능한 조합이 나와 있습니다. 그룹 1의 프로세서 또는 아키텍처를 그룹 2의 프로세서 또는 아키텍처에 일치시킬 수 있습니다.

구문

--compatible=name

인수 설명:

name 프로세서 또는 아키텍처의 이름이거나 NONE입니다. 프로세서 및 아키텍처 이름은 대소문자를 구분하지 않습니다.

이 옵션의 여러 인스턴스가 명령 행에 있는 경우 마지막에 지정된 인스턴스가 이전 인스턴스를 재정의합니다.

옵션의 다른 모든 인스턴스를 해제하려면 명령 행 끝에 --compatible=NONE을 지정합니다.

예제

armcc --cpu=arm7tdmi --compatible=cortex-m3 myprog.c

추가 참고


2.1.24 --compile_all_input, --no_compile_all_input

이 옵션을 사용하면 파일 확장명이 처리되지 않도록 할 것인지 여부를 설정할 수 있습니다.

이 옵션을 사용하면 컴파일러에서는 파일 확장명을 처리하지 않고 모든 입력 파일에 접미사 .c가 있는 것으로 간주합니다.

기본값

기본값은 --no_compile_all_input입니다.

표 2-2 호환 프로세서 또는 아키텍처 조합

그룹 1 ARM7TDMI, 4T

그룹 2 Cortex-M1, Cortex-M3, 7-M, 6-M, 6S-M



추가 참고


2.1.25 --configure_cpp_headers=path

이 옵션은 ARM Linux에 사용할 RVCT를 구성할 때 GNU libstdc++ 헤더 파일 경로를 지정합니다.

구문

--configure_cpp_headers=path

인수 설명:

path GNU C++ STL 헤더 파일 경로입니다.

사용법

이 옵션은 자동으로 감지되는 모든 경로를 재정의합니다. ARM Linux에 사용할 RVCT를 구성하는 수동 방식의 일부분으로 이 옵션을 사용할 수 있습니다.

추가 참고




















2.1.26 --configure_extra_includes=paths

이 옵션은 ARM Linux에 사용할 RVCT를 구성할 때 추가 시스템 포함 경로를 지정합니다.

구문

--configure_extra_includes=paths

인수 설명:

paths 추가 시스템 포함 경로 위치를 나타내는 콤마로 구분된 경로 이름 목록입니다.

추가 참고




















2.1.27 --configure_extra_libraries=paths

이 옵션은 ARM Linux에 사용할 RVCT를 구성할 때 추가 시스템 라이브러리 경로를 지정합니다.

구문

--configure_extra_libraries=paths

인수 설명:

paths 추가 시스템 라이브러리 경로 위치를 나타내는 콤마로 구분된 경로 이름 목록입니다.

추가 참고




















2.1.28 --configure_gcc=path

이 옵션은 ARM Linux 에 사용할 RVCT를 구성할 때 GCC 드라이버의 위치를 지정합니다.

구문

--configure_gcc=path

인수 설명:

path GCC 드라이버의 경로 및 파일 이름입니다.

사용법

구성 중에 지정된 CGG 드라이버의 기본 위치를 재정의하거나 자동 구성 방식 --arm_linux_configure에서 드라이버를 찾지 못하는 경우 이 옵션을 사용합니다.

추가 참고




















2.1.29 --configure_gld=path

이 옵션은 GNU 링커 ld의 위치를 지정합니다.

구문

--configure_gld=path

인수 설명:

path GNU 링커의 경로 및 파일 이름입니다.

사용법

구성 중에 컴파일러는 GCC에서 사용하는 GNU 링커 위치를 확인합니다. 컴파일러에서 위치를 확인하지 못하는 경우 또는 GNU 링커에 대한 일반 링커를 재정의하려는 경우에는 --configure_gld=path 옵션을 사용합니다. 이 경로는 GNU ld 바이너리의 전체 경로 및 파일 이름입니다.

추가 참고




















2.1.30 --configure_sysroot=path

이 옵션은 ARM Linux에 사용할 RVCT를 구성할 때 사용할 시스템 루트 경로를 지정합니다.

구문

--configure_sysroot=path

여기서 path는 사용할 시스템 루트 경로입니다.

사용법

이 옵션은 자동으로 감지되는 모든 시스템 루트 경로를 재정의합니다. 일반 시스템 루트 경로와 다른 경로를 사용하려는 경우 ARM Linux에 사용할 RVCT를 구성할 때 수동 방식의 일부로 이 옵션을 사용할 수 있습니다.

시스템 루트 경로는 일반적으로 라이브러리 및 헤더 파일이 들어 있는 기본 경로입니다. 표준 Linux 시스템에서 이 경로는 보통 파일 시스템 루트입니다. 교차 컴파일 GNU 도구 체인에서 이 경로는 보통 GNU C 라이브러리 설치의 상위 디렉토리입니다. 이 디렉토리에는 C 라이브러리 및 헤더 파일이 들어 있는 lib, usr/lib, 및 usr/include 하위 디렉토리가 포함됩니다.

추가 참고




















2.1.31 --cpp

이 옵션을 사용하면 C++ 소스 코드를 컴파일할 수 있습니다.

기본값

이 옵션은 접미사가 .cpp, .cxx, .c++, .cc 또는 .CC인 파일에 대해 암시적으로 선택됩니다.

추가 참고

• 2-3페이지의 --anachronisms, --no_anachronisms

• 2-23페이지의 --c90

• 2-23페이지의 --c99




2.1.32 --cpu=list

이 옵션은 --cpu=name 옵션과 함께 사용할 수 있는 지원되는 아키텍처 및 프로세서 이름을 나열합니다.

추가 참고

• --cpu=name

2.1.33 --cpu=name

이 옵션은 사용하면 선택된 ARM 프로세서 또는 아키텍처에 대한 코드를 생성할 수 있습니다.



구문

--cpu=name

인수 설명:

name 프로세서 또는 아키텍처의 이름입니다.

name이 프로세서의 이름인 경우 ARM7TDMI, ARM1176JZ-S, MPCore 등과 같이 ARM 데이터시트에 표시되는 대로 이름을 입력합니다.

name이 아키텍처의 이름인 경우 해당 아키텍처는 표 2-3에 나와 있는 아키텍처 목록에 있어야 합니다.

프로세서 및 아키텍처 이름은 대소문자를 구분하지 않습니다.

와일드카드 문자는 사용할 수 없습니다.

표 2-3 지원되는 ARM 아키텍처 및 프로세서 예

아키텍처 설명 프로세서의 예

4 Thumb이 없는 ARMv4 SA-1100

4T Thumb이 있는 ARMv4 ARM7TDMI, ARM9TDMI, ARM720T, ARM740T, ARM920T, ARM922T, ARM940T, SC100

5T Thumb 및 인터워킹이 있는 ARMv5

5TE Thumb, 인터워킹, DSP 곱하기 및 더블워드 명령어가 있는 ARMv5 ARM9E, ARM946E-S, ARM966E-S

5TEJ Thumb, 인터워킹, DSP 곱하기, 더블워드 명령어 및 Jazelle � 확장a이 있는 ARMv5

ARM926EJ-S, ARM1026EJ-S, SC200

6 Thumb, 인터워킹, DSP 곱하기, 더블워드 명령어, 정렬되지 않은 혼합엔디안 지원, Jazelle 및 미디어 확장이 있는 ARMv6

ARM1136J-S, ARM1136JF-S

6-M 프로세서 상태 명령어만 포함하며 Thumb이 있는 ARMv6 마이크로컨트롤러 프로파일

OS 확장이 없는 Cortex-M1

6S-M 프로세서 상태 명령어 및 OS 확장을 포함하며 Thumb만 있는 ARMv6 마이크로컨트롤러 프로파일

OS 확장이 있는 Cortex-M1

6K SMP 확장이 있는 ARMv6 MPCore



참고

ARMv7은 실제 ARM 아키텍처가 아닙니다. --cpu=7은 ARMv7-A, ARMv7-R 및 ARMv7-M 아키텍처에 공통적으로 적용되는 기능을 나타냅니다. 즉, --cpu=7과 함께 사용되는 모든 지정된 기능은 ARMv7-A, ARMv7-R 및 ARMv7-M 아키텍처에 모두 존재합니다.

기본값

--cpu 옵션을 지정하지 않으면 컴파일러에서 --cpu=ARM7TDMI로 간주됩니다.

CPU 아키텍처 및 프로세서의 전체 목록을 가져오려면 --cpu=list 옵션을 사용합니다.

사용법

프로세서 및 아키텍처 옵션에는 다음과 같은 일반적인 사항이 적용됩니다.

프로세서

• 프로세서를 선택하면 적절한 아키텍처, FPU(부동 소수점 단위) 및 메모리 구성이 선택됩니다.

6T2 Thumb-2가 있는 ARMv6 ARM1156T2-S, ARM1156T2F-S

6Z 보안 확장이 있는 ARMv6 ARM1176JZF-S, ARM1176JZ-S

7 Thumb-2만 있고 하드웨어 나누기가 없는 ARMv7

7-A ARM 및 Thumb-2와 Thumb-2EE 명령어 세트가 있고 DSP, 32비트 SIMD 및 가상 MMU 기반 메모리 시스템을 지원하는 ARMv7 응용 프로그램 프로파일

Cortex-A8, Cortex-A9

7-R ARM 및 Thumb-2가 있고 DSP 및 32비트 SIMD를 지원하는 ARMv7 실시간 프로파일

Cortex-R4, Cortex-R4F

7-M 하드웨어 나누기와 Thumb-2만 있는 ARMv7 마이크로컨트롤러 프로파일

Cortex-M3, SC300

a. ARM 컴파일러에서는 Java 바이트코드를 생성하지 않습니다.

표 2-3 지원되는 ARM 아키텍처 및 프로세서 예 (계속)

아키텍처 설명 프로세서의 예



• 지원되는 --cpu 값은 모두 현재 ARM 제품 이름이나 아키텍처 버전입니다.

Marvell Feroceon 및 Intel XScale과 같은 기타 ARM 아키텍처 기반 프로세서도 지원됩니다.

• --cpu 옵션에 대해 프로세서를 지정하면 컴파일된 코드가 해당 프로세서에 대해 최적화됩니다. 그러면 컴파일러에서 최적의 성능을 위한 특정 보조 프로세서나 명령어 일정을 사용할 수 있습니다.

아키텍처

• ----cpu 옵션에 아키텍처 이름을 지정하면 해당 아키텍처를 지원하는 모든 프로세서에서 실행할 수 있도록 코드가 컴파일됩니다. 예를 들어 --cpu=5TE는 ARM926EJ-S �에서 사용할 수 있는 코드를 생성합니다.

FPU

• 일부 --cpu 지정에는 --fpu 선택이 포함됩니다. 예를 들어 --arm 옵션을 사용하여 컴파일할 경우 --cpu=ARM1136JF-S에 --fpu=vfpv2가 포함됩니다. 마찬가지로 --cpu=Cortex-R4F에는 --fpu=vfpv3_d16이 포함됩니다.

참고

명령 행에 --fpu를 사용하여 설정하는 명시적 FPU는 암시적 FPU 보다 우선합니다.

• --fpu 옵션 및 --cpu 옵션이 지정되지 않은 경우 --fpu=softvfp가 사용됩니다.

ARM/Thumb

• --cpu=ARM7TDMI처럼 Thumb 명령어를 지원하는 프로세서를 지정하면 컴파일러에서 Thumb 코드를 생성하지 않습니다. long 곱하기처럼 사용할 프로세서의 기능만 활성화합니다. Cortex-M3와 같이 Thumb 전용이 아닌 프로세서의 경우 --thumb 옵션을 사용하여 Thumb 코드를 생성할 수 있습니다. 이때 --thumb은 필요하지 않습니다.

참고

타겟 프로세서 또는 아키텍처를 지정하면 컴파일러에서 생성된 객체 코드가 다른 ARM 프로세서와 호환되지 않을 수 있습니다. 예를 들어 컴파일된 코드에 ARMv6 전용 명령어가 있는



경우 아키텍처 ARMv6에 대해 컴파일된 코드는 ARM920T 프로세서에서 실행되지 않을 수 있습니다. 따라서 목적에 맞는 최소 공통 분모 프로세서를 선택해야 합니다.

• ARMv4T 또는 ARMv5T를 지원하는 프로세서에 대한 ARM/Thumb 혼합 시스템용으로 만들어진 코드를 컴파일하는 경우 인터워킹 옵션 --apcs=/interwork를 지정해야 합니다. ARMv5T 이상을 지원하는 프로세서에서는 이 옵션이 기본적으로 설정되어 있습니다.

• Thumb에 대해 컴파일하는 경우, 즉 명령 행에 --thumb 옵션을 사용하는 경우 컴파일러에서는 Thumb 명령어 세트를 사용하여 코드를 가능한 많이 컴파일합니다. 그러나 컴파일러에서 컴파일 중 일부에 사용되는 ARM 코드를 생성할 수 있습니다. 예를 들어 Thumb-1 프로세서에 대한 코드를 컴파일하고 VFP를 사용하는 경우 부동 소수점 연산이 포함된 모든 함수가 ARM에 대해 컴파일됩니다.

• --cpu=Cortex-M3와 같이 ARMv7-M에 대한 코드를 컴파일하는 경우에는 ARMv7-M은 Thumb-2만 지원하기 때문에 명령 행에 --thumb을 지정할 필요가 없습니다.

제한

같은 명령 행에 프로세서와 아키텍처를 둘 다 지정할 수는 없습니다.

추가 참고

• 2-4페이지의 --apcs=qualifer...qualifier


• 2-65페이지의 --fpu=name


2.1.34 --create_pch=filename

이 옵션은 지정한 파일 이름을 갖는 PCH(사전 컴파일된 헤더) 파일을 만들도록 컴파일러에 지시합니다.

이 옵션은 다른 모든 PCH 옵션에 우선합니다.



구문

--create_pch=filename

인수 설명:

filename 만들 PCH 파일의 이름입니다.

추가 참고

• 2-105페이지의 --pch

• 2-106페이지의 --pch_dir=dir

• 2-106페이지의 --pch_messages, --no_pch_messages

• 2-107페이지의 --pch_verbose, --no_pch_verbose

• 2-136페이지의 --use_pch=filename

• 4-65페이지의 #pragma hdrstop

• 4-67페이지의 #pragma no_pch

• 컴파일러 사용 설명서의 2-18페이지의 사전 컴파일된 헤더 파일

2.1.35 -Dname[(parm-list)][=def]

이 옵션은 name 매크로를 정의합니다.

구문

-Dname[(parm-list)][=def]

인수 설명:

name 정의할 매크로의 이름입니다.

parm-list 콤마로 구분된 매개변수의 선택적 목록입니다. 매크로 매개변수 목록을 매크로 이름에 추가하여 함수 스타일 매크로를 정의할 수 있습니다.

매개변수 목록은 괄호로 묶어야 합니다. 여러 개의 매개변수를 지정하는 경우 목록에서 콤마와 매개변수 이름 사이에 공백을 포함해서는 안 됩니다.

참고

UNIX 시스템 상에서는 괄호를 풀어야 합니다.

=def 선택적 매크로 정의입니다.



=def를 생략하면 컴파일러에서는 name을 값 1로 정의합니다.

명령 행에서 토큰으로 인식되는 문자를 포함하려면 매크로 정의를 큰따옴표로 묶어야 합니다.

사용법

-Dname을 지정하는 것은 #define name 텍스트를 각 소스 파일의 헤드에 배치하는 것과 같은 효과를 제공합니다.

제한

컴파일러에서는 다음 순서에 따라 매크로를 정의하고 정의 해제합니다.

1. 컴파일러에서 사전 정의된 매크로

2. -Dname을 사용하여 명시적으로 정의된 매크로

3. -Uname을 사용하여 명시적으로 정의가 해제된 매크로

예제

명령 행에

-DMAX(X,Y)="((X > Y) ? X : Y)"

위의 옵션을 지정하는 것은 각 소스 파일의 헤드에

#define MAX(X, Y) ((X > Y) ? X : Y)

배치하는 것과 동일한 효과를 갖습니다.

추가 참고

• 2-23페이지의 -C

• 2-54페이지의 -E

• 2-133페이지의 -Uname

• 4-123페이지의 컴파일러 사전 정의

2.1.36 --data_reorder, --no_data_reorder

이 옵션을 사용하면 전역 변수와 같은 최상위 수준 데이터 항목의 자동 순서 변경을 사용할 것인지 여부를 설정할 수 있습니다.



데이터 항목 사이에서 불필요한 공백을 제거하여 가용 메모리 크기를 증가시킬 수 있습니다. 그러나 코드에서 컴파일러의 데이터 순서 지정에 대해 잘못된 가정을 만드는 경우 --data_reorder는 레거시 코드를 중단시킬 수 있습니다.

ISO C 표준에서는 데이터 순서를 보장하지 않으므로 사용되는 순서에 따라 변경되는 코드를 작성하지 않아야 합니다. 데이터 순서를 지정해야 하는 경우 데이터 항목을 구조체에 배치하십시오.

기본값

기본값은 --data_reorder입니다.

2.1.37 --debug, --no_debug

이 옵션을 사용하면 현재 컴파일에 대해 디버그 테이블을 생성할 것인지 여부를 설정할 수 있습니다.

--debug 사용 여부에 상관없이 컴파일러에서 동일한 코드를 생성합니다. 디버그 테이블이 있다는 점만 다릅니다.

기본값

기본값은 --no_debug입니다.

--debug를 사용해도 최적화 설정에 영향을 주지는 않습니다. 기본적으로 --debug 옵션을 단독으로 사용하는 것은 다음을 사용하는 것과 같습니다.

--debug --dwarf3 --debug_macros

추가 참고

• --debug_macros, --no_debug_macros

• 2-54페이지의 --dwarf2



2.1.38 --debug_macros, --no_debug_macros

이 옵션을 사용하면 사전 처리기 매크로 정의에 대해 디버그 테이블을 생성할 것인지 여부를 설정할 수 있습니다.



사용법

--no_debug_macros를 사용하면 디버그 이미지의 크기가 줄어듭니다.

이 옵션은 --debug 옵션과 함께 사용해야 합니다.

기본값

기본값은 --debug_macros입니다.

추가 참고

• 2-39페이지의 --debug, --no_debug

2.1.39 --default_extension=ext

이 옵션을 사용하면 객체 파일의 파일 확장명을 기본 확장명(.o)에서 사용자가 선택한 확장명으로 변경할 수 있습니다.

구문

--default_extension=ext

인수 설명:

ext 사용자가 선택한 파일 확장명입니다.

예제

다음 예제에서는 test.o 대신 test.obj라는 객체 파일을 만듭니다.

armcc --default_extension=obj -c test.c

참고

-o filename 옵션을 사용하면 이 옵션이 무시됩니다. 예를 들어 다음 명령은 test.o라는 객체 파일을 만듭니다.

armcc --default_extension=obj -o test.o -c test.c

2.1.40 --dep_name, --no_dep_name

이 옵션을 사용하면 C++에서 종속적 이름 처리를 사용할 것인지 여부를 설정할 수 있습니다.



C++ 표준에서 템플릿의 이름 조회는 다음과 같은 경우에 발생합니다.

• 이름이 비종속적인 경우 템플릿이 구문 분석될 때

• 이름이 종속적인 경우 템플릿이 구문 분석되거나 인스턴스화될 때

--no_dep_name 옵션이 선택된 경우 템플릿에 있는 종속적 이름 조회는 템플릿이 인스턴스화될 때만 발생할 수 있습니다. 즉, 템플릿이 구분 분석될 때에는 종속적 이름 조회를 할 수 없습니다.

참고

--no_dep_name 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --dep_name입니다.

제한

종속적 이름 처리를 사용할 수 있는 경우 기본적으로 구문 분석이 수행되므로 --dep_name 옵션을 --no_parse_templates 옵션과 함께 사용할 수 없습니다.

오류

--dep_name 옵션과 --no_parse_templates 옵션을 함께 사용하면 컴파일러에서 오류를 생성합니다.

추가 참고

• 2-104페이지의 --parse_templates, --no_parse_templates

• 5-16페이지의 템플릿 인스턴스화

2.1.41 --depend=filename

이 옵션은 컴파일하는 동안 메이크파일 종속 행을 파일에 작성하도록 컴파일러에 지시합니다.



구문

--depend=filename

인수 설명:

filename 출력할 종속 파일의 이름입니다.

제한

명령 행에 여러 개의 소스 파일을 지정하면 모든 --depend 옵션이 무시됩니다. 이런 경우 종속 파일은 생성되지 않습니다.

사용법

출력 파일은 작성 유틸리티에서 사용하기에 적합합니다. 출력 형식을 변경하여 UNIX make 유틸리티와 호환되도록 하려면 --depend_format 옵션을 사용합니다.

추가 참고

• --depend_format=string

• 2-44페이지의 --depend_system_headers, --no_depend_system_headers

• 2-45페이지의 --depend_target=target

• 2-74페이지의 --ignore_missing_headers


• 2-92페이지의 -M

• 2-93페이지의 --md

• 2-108페이지의 --phony_targets

2.1.42 --depend_format=string

이 옵션은 일부 UNIX make 프로그램과 호환될 수 있도록 출력 종속 파일의 형식을 변경합니다.

구문

--depend_format=string



여기서 string은 다음 중 하나입니다.

unix UNIX 스타일 경로 구분 기호를 사용하여 종속 파일 엔트리를 생성합니다.

unix_escaped unix와 같지만 \로 공백을 이스케이프합니다.

unix_quoted unix와 같지만 경로 이름을 큰따옴표로 묶습니다.

사용법

unix Windows 시스템에서 --depend_format=unix는 UNIX 스타일 경로 이름을 사용하도록 합니다. 즉, UNIX 스타일 경로 구분 기호 기호인 /가 \ 대신 사용됩니다.

UNIX 시스템에서 --depend_format=unix는 아무런 영향을 주지 않습니다.

unix_escaped Windows 시스템에서 --depend_format=unix_escaped는 UNIX 스타일 경로 이름을 사용하도록 하고 \로 공백을 이스케이프합니다.

UNIX 시스템에서 --depend_format=unix_escaped는 \로 공백을 이스케이프하도록 합니다.

unix_quoted Windows 시스템에서 --depend_format=unix_quoted는 UNIX 스타일 경로 이름을 사용하도록 하고 해당 이름을 ""로 묶습니다.

UNIX 시스템에서 --depend_format=unix_quoted는 ""로 경로 이름을 묶습니다.

기본값

--depend_format 옵션을 지정하지 않으면 출력 종속 파일의 형식은 사용하는 운영 체제에 따라 달라집니다.

Windows Windows 시스템에서는 기본적으로 지정 방식에 따라 Windows 스타일 경로 또는 UNIX 스타일 경로를 사용할 수 있습니다.

UNIX UNIX 시스템에서의 기본값은 -depend_format=unix입니다.



예제

Windows 시스템에서 --depend=depend.txt --depend_format=unix_escaped 옵션을 사용하여 아래 행을 포함하는 main.c 파일을 컴파일하면

#include "..\include\header files\common.h"

아래 엔트리를 포함하는 종속 파일 depend.txt가 생성됩니다.

main.axf: main.cmain.axf: ../include/header\ files/common.h

추가 참고

• 2-41페이지의 --depend=filename

• --depend_system_headers, --no_depend_system_headers



• 2-92페이지의 -M



2.1.43 --depend_system_headers, --no_depend_system_headers

이 옵션을 사용하면 -M 옵션 또는 --md 옵션을 사용하여 메이크파일 종속 정보를 생성할 때 시스템 include 종속 행을 출력할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --depend_system_headers입니다.

예제

/* hello.c */#include <stdio.h>int main(void){

printf("Hello, world!\n");return 0;

}

-M 옵션을 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

__image.axf: hello.c__image.axf: ...\include\...\stdio.h



-M --no_depend_system_headers 옵션을 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

__image.axf: hello.c

추가 참고


• 2-42페이지의 --depend_format=string

• --depend_target=target


• 2-92페이지의 -M



2.1.44 --depend_target=target

이 옵션은 메이크파일 종속 정보를 생성하는 대상을 지정합니다.

사용법

이 옵션을 사용하면 기본 옵션은 무시합니다.

제한

이 옵션은 GCC의 -MT와 유사하지만 대상을 여러 개 지정할 때 약간 다르게 동작합니다. 예를 들어 gcc -M -MT target1 -MT target2 file.c를 실행하면 target1 target2: file.c header.h의 결과가 반환되는 반면, --depend_target=target1 --depend_target=target2에서는 대상이 target2가 됩니다.

추가 참고





• 2-92페이지의 -M





2.1.45 --device=list

이 옵션은 --device=name 옵션에 사용할 수 있는 지원되는 장치 이름을 나열합니다.

추가 참고

• --device=name.

2.1.46 --device=name

이 옵션을 사용하면 특정 마이크로프로세서 또는 SoC(시스템온칩) 장치용으로 코드를 컴파일할 수 있습니다.

구문

--device=name

인수 설명:

name 타겟 마이크로컨트롤러 또는 SoC 장치의 이름입니다.

사용법

특정 장치 이름을 지정하면 장치는 해당하는 CPU에서 기본 엔디안 및 부동 소수점 아키텍처를 상속받습니다. --bi, --li 및 --fpu 옵션을 사용하여 엔디안 및 타겟 부동 소수점 아키텍처의 기본 설정을 변경할 수 있습니다.

추가 참고

• 2-18페이지의 --bigend

• --device=list


• 2-89페이지의 --littleend

• 링커 참조 설명서의 2-16페이지의 --device=list

• 링커 참조 설명서의 2-16페이지의 --device=name

• 어셈블러 설명서의 3-49페이지의 C 사전 처리기 사용

2.1.47 --diag_error=tag[,tag,...]

이 옵션은 지정된 태그가 있는 분석 메시지를 오류 심각도로 설정합니다.



참고

이 옵션에서는 #pragma diag_error가 #pragma에 해당합니다.

구문

--diag_error=tag[,tag,...]

인수 설명:

tag[,tag,...] 심각도가 변경될 메시지를 지정하는 진단 메시지 번호에 대한 콤마로 구분된 목록입니다.

최소한 하나의 진단 메시지 번호가 지정되어야 합니다.

여러 개의 진단 메시지 번호를 지정하는 경우 목록에서 콤마와 매개변수 이름 사이에 공백을 포함해서는 안 됩니다.

사용법

다음 진단 메시지 유형의 심각도를 변경할 수 있습니다.

• 숫자 형식 #nnnn-D가 있는 메시지

• 숫자 형식 CnnnnW가 있는 경고 메시지

추가 참고

• --diag_remark=tag[,tag,... ]



• 4-62페이지의 #pragma diag_error tag[,tag,...]

• 컴파일러 사용 설명서의 6-5페이지의 진단 메시지 심각도 변경

2.1.48 --diag_remark=tag[,tag,...]

이 옵션은 지정된 태그가 있는 진단 메시지를 설명 수준으로 설정합니다.

--diag_remark 옵션은 컴파일러에서 지정된 태그가 있는 진단 메시지를 오류 심각도가 아닌 설명 수준으로 설정하는 것을 제외하고 --diag_errors와 유사하게 동작합니다.



참고

설명은 기본적으로 표시되지 않습니다. 설명 메시지를 보려면 컴파일러 옵션 --remarks를 사용합니다.

참고

이 옵션에서는 #pragma diag_remark가 #pragma에 해당합니다.

구문

--diag_remark=tag[,tag,...]

인수 설명:


추가 참고





• 4-63페이지의 #pragma diag_remark tag[,tag,...]


2.1.49 --diag_style={arm|ide|gnu}

이 옵션은 진단 메시지를 표시하는 데 사용되는 스타일을 지정합니다.

구문

--diag_style=string

여기서 string은 다음 중 하나입니다.

arm ARM 컴파일러 스타일을 사용하여 메시지를 표시합니다.

ide 오류가 생성된 모든 행의 행 번호 및 문자 수를 포함합니다. 이 값은 괄호 안에 표시됩니다.

gnu gcc에서 사용한 형식으로 메시지를 표시합니다.



기본값

--diag_style 옵션을 지정하지 않으면 컴파일러에서 --diag_style=arm으로 간주됩니다.

사용법

--diag_style=ide 옵션을 선택하면 --brief_diagnostics 옵션이 암시적으로 선택됩니다. 명령 행에서 명시적으로 --no_brief_diagnostics를 선택하면 --diag_style=ide에 의해 암시적으로 선택된 --brief_diagnostics가 무시됩니다.

--diag_style=arm 옵션 또는 --diag_style=gnu 옵션의 선택이 --brief_diagnostics 선택을 의미하지는 않습니다.

추가 참고



• --diag_suppress=tag[,tag,...]



2.1.50 --diag_suppress=tag[,tag,...]

이 옵션은 지정된 태그가 있는 진단 메시지를 비활성화합니다.

--diag_suppress 옵션은 컴파일러에서 지정된 태그가 있는 진단 메시지를 오류 심각도로 설정하는 것이 아닌 해당 메시지를 표시하도록 하는 것을 제외하고 --diag_errors와 유사하게 동작합니다.

참고

이 옵션에서는 #pragma diag_suppress가 #pragma에 해당합니다.

구문

--diag_suppress=tag[,tag,...]

인수 설명:

tag[,tag,...] 표시하지 않을 메시지를 지정하는 진단 메시지 번호에 대한 콤마로 구분된 목록입니다.



추가 참고




• 4-64페이지의 #pragma diag_suppress tag[,tag,...]

• 컴파일러 사용 설명서의 6-6페이지의 진단 메시지 표시 안 함

2.1.51 --diag_suppress=optimizations

이 옵션은 고수준 최적화에 대한 진단 메시지를 표시하지 않습니다.

기본값

기본적으로 최적화 메시지에는 설명 수준이 포함됩니다. --diag_suppress=optimizations를 지정하면 최적화 메시지가 표시되지 않습니다.

참고

설명 수준이 있는 최적화 메시지를 표시하려면 --remarks 옵션을 사용합니다.

사용법

컴파일러에서는 예를 들어 루프 언롤링과 같이 최적화 수준 -O3에서 컴파일하는 경우 특정한 고수준 벡터 및 스칼라 최적화를 수행합니다. 이 옵션을 사용하면 이러한 고수준 최적화에 대한 진단 메시지를 표시하지 않습니다.

예제

int factorial(int n){

int result=1;while (n > 0)

result *= n--;return result;

}

-O3 -Otime --remarks --diag_suppress=optimizations 옵션을 사용하여 이 코드를 컴파일하면 최적화 메시지가 표시되지 않습니다.

추가 참고




• --diag_warning=optimizations




2.1.52 --diag_warning=tag[,tag,...]

이 옵션은 지정된 태그가 있는 진단 메시지를 경고 수준으로 설정합니다.

--diag_warning 옵션은 컴파일러에서 지정된 태그가 있는 진단 메시지를 오류 심각도가 아닌 경고 수준으로 설정하는 것을 제외하고 --diag_errors와 유사하게 동작합니다.

참고

이 옵션에서는 #pragma diag_warning가 #pragma에 해당합니다.

구문

--diag_warning=tag[,tag,...]

인수 설명:


추가 참고




• 4-64페이지의 #pragma diag_warning tag[, tag, ...]


2.1.53 --diag_warning=optimizations

이 옵션은 고수준 최적화 진단 메시지를 경고 수준으로 설정합니다.

기본값

기본적으로 최적화 메시지에는 설명 수준이 포함됩니다.



사용법

컴파일러에서는 예를 들어 루프 언롤링과 같이 최적화 수준 -O3 -Otime에서 컴파일하는 경우 특정한 고수준 벡터 및 스칼라 최적화를 수행합니다. 이 옵션을 사용하면 고수준 최적화에 대한 진단 메시지를 표시합니다.

예제

int factorial(int n){

int result=1;while (n > 0)

result *= n--;return result;

}

--vectorize --cpu=Cortex-A8 -O3 -Otime --diag_warning=optimizations 옵션을 사용하여 이 코드를 컴파일하면 최적화 경고 메시지가 생성됩니다.

추가 참고

• 2-50페이지의 --diag_suppress=optimizations



• 2-103페이지의 -Otime.

2.1.54 --dllexport_all, --no_dllexport_all

이 옵션을 사용하면 DLL을 빌드할 때 기호 표시 유형을 제어할 수 있습니다.

기본값

기본값은 --no_dllexport_all입니다.

사용법

모든 extern 정의를 __declspec(dllexport)로 표시하려면 --dllexport_all 옵션을 사용합니다.

추가 참고





2.1.55 --dllimport_runtime, --no_dllimport_runtime

이 옵션을 사용하면 C++ 런타임 라이브러리를 공유 라이브러리로 사용할 때 기호 표시 형식을 제어할 수 있습니다.

기본값

기본값은 --no_dllimport_runtime입니다.

사용법

--dllimport_runtime 옵션을 사용하여 할 수 있는 표시 종류

• 모든 기본 제공 기호를 __declspec(dllimport)로 표시

• 가져올 런타임 라이브러리에서 생성된 RTTI(런타임 유형 정보)

• 원래 함수가 __declspec(dllimport)로 표시된 경우 가져올 모든 최적화된 printf() 및 __hardfp_ 함수

추가 참고

• 2-72페이지의 --guiding_decls, --no_guiding_decls

• 2-118페이지의 --rtti, --no_rtti

• 4-28페이지의 __declspec(dllimport)

2.1.56 --dollar, --no_dollar

이 옵션은 식별자에 사용되는 달러 부호 $를 허용하거나 거부하도록 컴파일러에 지시합니다.

기본값

--strict 옵션이 지정되지 않은 경우 기본값은 --dollar입니다.

----strict 옵션이 지정된 경우 기본값은 --no_dollar입니다.

추가 참고

• 3-13페이지의 식별자에 사용되는 달러 부호




2.1.57 --dwarf2

이 옵션은 DWARF 2 디버그 테이블 형식을 사용하도록 컴파일러에 지시합니다.

기본값

--dwarf2를 명시적으로 지정하지 않으면 컴파일러에서 --dwarf3로 간주됩니다.

추가 참고

• --dwarf3.

2.1.58 --dwarf3

이 옵션은 DWARF 3 디버그 테이블 형식을 사용하도록 컴파일러에 지시합니다.

기본값

--dwarf2를 명시적으로 지정하지 않으면 컴파일러에서 --dwarf3로 간주됩니다.

추가 참고

• --dwarf2.

2.1.59 -E

이 옵션은 사전 처리기 단계만 실행하도록 컴파일러에 지시합니다.

기본적으로 사전 처리기의 출력이 표준 출력 스트림으로 전송되고 표준 UNIX 및 MS-DOS 표시를 사용하여 파일로 리디렉션할 수 있습니다.

-o 옵션을 사용하여 사전 처리된 출력 파일을 지정할 수도 있습니다. 기본적으로 주석은 출력에서 스트립됩니다. 사전 처리기에서는 .o, .s 및 .txt와 같은 모든 확장명의 소스 파일을 허용합니다.

예제

armcc -E source.c > raw.c

추가 참고

• 2-23페이지의 -C




2.1.60 --emit_frame_directives, --no_emit_frame_directives

이 옵션은 디스어셈블리 출력에 DWARF FRAME 지시어를 추가하도록 컴파일러에 지시합니다.

기본값

기본값은 --no_emit_frame_directives입니다.

예

armcc --asm --emit_frame_directives foo.c

armcc -S emit_frame_directives foo.c

추가 참고


• 2-119페이지의 -S

• 어셈블러 설명서의 2-54페이지의 프레임 지시어 사용

2.1.61 --enum_is_int

이 옵션은 모든 열거 유형의 크기를 최소 4바이트로 설정합니다.

이 옵션은 기본적으로 사용되지 않으며 모든 열거자의 값을 포함할 수 있는 최소 데이터 유형이 사용됩니다.

명령 행에서 ARM Linux 구성 파일을 지정하는 경우 이 옵션은 기본적으로 설정됩니다.

참고

--enum_is_int 옵션은 일반적인 용도로 사용하지 않는 것이 좋습니다.

추가 참고



• 2-78페이지의 --interface_enums_are_32_bit



2.1.62 --errors=filename

이 옵션은 진단 메시지 출력을 stderr에서 지정된 오류 파일로 리디렉션합니다.

구문

--errors=filename

인수 설명:

filename 오류를 리디렉션할 파일의 이름입니다.

이 명령 옵션으로는 문제와 연관된 진단이 리디렉션되지 않으며 옵션 이름을 잘못 입력한 경우를 예로 들 수 있습니다. 그러나 --cpu=999와 같이 옵션에 잘못된 인수를 지정하면 관련된 진단이 지정된 filename으로 리디렉션됩니다.

추가 참고

• 2-20페이지의 --brief_diagnostics, --no_brief_diagnostics







• 2-141페이지의 -W



2.1.63 --exceptions, --no_exceptions

이 옵션을 사용하면 예외 처리를 사용할 것인지 여부를 설정할 수 있습니다.

C++에서 --exceptions 옵션은 throw 및 try/catch를 사용할 수 있게 하고, 함수 예외 지정을 고려하도록 하고, 컴파일러에서 해제 테이블을 내보내서 런타임에 예외 전달을 지원할 수 있도록 합니다.

C++에서 --no_exceptions 옵션이 지정되면 throw 및 try/catch는 소스 코드에서 허용되지 않습니다. 어쨌든 함수 예외 지정 구문은 계속 분석되지만 해당 의미 대부분은 무시됩니다.



C에서 컴파일된 함수를 통해 예외가 throw되면 --no_exceptions를 사용하여 컴파일된 코드 동작은 정의되지 않습니다. C 함수를 통해 예외를 올바르게 전달하려면 --exceptions를 사용해야 합니다.

기본값

기본값은 --no_exceptions입니다. 그러나 명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_g++를 사용하면 기본값이 --exceptions로 변경됩니다.

추가 참고



• --exceptions_unwind, --no_exceptions_unwind

2.1.64 --exceptions_unwind, --no_exceptions_unwind

이 옵션을 사용하면 예외 인식 코드에 대한 함수 해제를 사용할 것인지 여부를 설정할 수 있습니다. 이 옵션은 --exceptions가 설정된 경우에만 동작합니다.

--no_exceptions_unwind 및 --exceptions를 사용하면 컴파일된 함수를 통해 예외가 전달되지 않으며 std::terminate가 대신 호출됩니다.

기본값

기본값은 --exceptions_unwind입니다.

추가 참고

• 2-56페이지의 --exceptions, --no_exceptions

• 5-19페이지의 런타임 시 함수 해제

2.1.65 --export_all_vtbl, --no_export_all_vtbl

이 옵션은 C++에서 동적 기호를 내보내는 방법을 제어합니다.

모드




기본값

기본값은 --no_export_all_vtbl입니다.

사용법

--export_all_vtbl 옵션을 사용하면 키 함수가 있는 클래스의 가상 함수 테이블 및 RTTI를 모두 내보냅니다. 주요 함수는 인라인이 아니면서 순수 가상도 아닌 선언 순서에서 클래스의 첫 번째 가상 함수입니다.

참고

__declspec(notshared)를 사용하여 특정 클래스에 대해 내보내지 않도록 설정할 수 있습니다.

추가 참고

• 4-31페이지의 __declspec(notshared)

2.1.66 --export_defs_implicitly, --no_export_defs_implicitly

이 옵션은 동적 기호를 내보내는 방법을 제어합니다.

기본값

기본값은 --no_export_defs_implicitly입니다.

사용법

--export_defs_implicitly 옵션을 사용하여 프로토타입이 __declspec(dllimport)로 표시된 정의를 내보냅니다.

추가 참고




2.1.67 --extended_initializers, --no_extended_initializers

--strict 또는 --strict_warnings를 사용하여 컴파일하는 경우에도 이 옵션을 사용하여 확장된 상수 이니셜라이저 사용 여부를 설정할 수 있습니다.

정수 유형에 대한 주소 캐스트와 같이 이식 불가능하지만 광범위하게 지원되는 상수 이니셜라이저를 사용할 경우 --extended_initializers는 컴파일러에서 식이 상수 값 또는 산술 유형을 가져야 함을 알리는 특정 오류가 아닌 일반적으로 엄격하지 않은 모드에서 생성되는 상수 이니셜라이저와 관련된 동일한 일반 경고를 생성하도록 합니다.

기본값

--strict 또는 --strict_warnings를 사용하여 컴파일할 경우 기본값은 --no_extended_initializers입니다.

엄격하지 않은 모드에서 컴파일할 경우 기본값은 --extended_initializers입니다.

추가 참고



• 3-10페이지의 상수 식.

2.1.68 --feedback=filename

이 옵션을 사용하면 미사용 함수를 효율적으로 제거할 수 있으며, ARMv4T 아키텍처의 경우에는 인터워킹에 필요한 컴파일을 줄일 수 있습니다.

구문

--feedback=filename

인수 설명:

filename 이전에 ARM 링커를 실행하여 생성한 피드백 파일입니다.

사용법

동일한 피드백 파일을 사용하여 컴파일을 여러 번 수행할 수 있습니다. 컴파일러에서는 피드백 파일에서 확인된 사용되지 않은 각 함수를 해당 객체 파일의 각 ELF 섹션에 배치합니다.



피드백 파일에는 기존 빌드 정보가 포함되어 있습니다. 그 이유는 다음과 같습니다.

• 피드백 파일이 최신이 아닐 수 있습니다. 즉, 이전에 사용하지 않는 것으로 표시된 함수가 현재 소스 코드에 사용되고 있을 수 있습니다. 사용되지 않는 함수의 코드가 현재 소스 코드에서도 사용되지 않는 경우에만 링커가 해당 코드를 제거합니다.

참고

— 이런 이유로 링커 피드백을 사용하여 미사용 함수를 제거하는 것은 안전한 최적화 방법이지만 코드 크기를 많이 줄이지 못합니다.

— 인터워킹에 필요한 컴파일을 줄이기 위한 사용 요구 사항은 미사용 함수 제거 요구 사항보다 더욱 엄격합니다. 인터워킹 컴파일을 줄이려는 경우에는 피드백 파일 생성에 사용한 소스 코드로 피드백 파일을 최신 상태로 유지해야 합니다.

• 링커 피드백을 최대한 이용하려면 전체 컴파일 및 링크를 적어도 두 번 실행해야 합니다. 그러나 일반적으로 이전 빌드의 피드백을 사용하는 단일 컴파일 및 링크로도 충분합니다.

추가 참고

• 2-123페이지의 --split_sections

• 링커 참조 설명서의 2-25페이지의 --feedback_type=type

• 컴파일러 사용 설명서의 2-28페이지의 링커 피드백 사용

2.1.69 --force_new_nothrow, --no_force_new_nothrow

이 옵션은 C++의 new 식의 동작을 제어합니다.

C++ 표준에서는 throw()로 선언된 no throw operator new에서만 실패 시에 NULL을 반환할 수 있습니다. 다른 모든 operator new는 NULL을 반환할 수 없으며 기본 operator new에서는 실패 시 예외를 발생시킵니다.

--force_new_nothrow를 사용하는 경우 컴파일러에서는 전역 ::operator new 또는 ::operator new[]를 사용하는 new T(...args...)와 같은 식을 new (std::nothrow) T(...args...)인 것처럼 처리합니다.

--force_new_nothrow도 클래스 관련 operator new 또는 오버로드된 전역 operator new를 no throw로 처리합니다.



참고

--force_new_nothrow 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_force_new_nothrow입니다.

예제

struct S{ void* operator new(std::size_t); void* operator new[](std::size_t);};void *operator new(std::size_t, int);

--force_new_nothrow 옵션을 사용하면 이 예제가 다음과 같이 처리됩니다.

struct S{ void* operator new(std::size_t) throw(); void* operator new[](std::size_t) throw();};void *operator new(std::size_t, int) throw();

추가 참고

• 5-14페이지의 ::operator new 함수의 사용.

2.1.70 --forceinline

이 옵션은 모든 인라인 함수가 __forceinline으로 한정되는 것처럼 취급합니다.

인라인 함수는 inline 또는 __inline으로 한정되는 함수입니다. C++에서 인라인 함수는 구조체, 클래스 또는 공용체 정의 내에서 정의되는 함수입니다.



--forceinline을 사용하는 경우 컴파일러에서는 가능하면 항상 이들 함수를 인라인하려고 합니다. 그러나 인라인하는 동안 문제가 발생하는 경우 컴파일러에서는 함수를 인라인하지 않습니다. 예를 들어 재귀 함수는 자체로 한 번만 인라인됩니다.

추가 참고

• 2-17페이지의 --autoinline, --no_autoinline


• 4-7페이지의 __forceinline

• 4-10페이지의 __inline

• 컴파일러 사용 설명서의 5-19페이지의 인라인 관리

2.1.71 --fp16_format=format

이 옵션을 사용하면 반정밀도 부동 소수점 숫자를 VFPv3 아키텍처에 대한 선택적 확장으로 사용할 수 있습니다. 형식을 지정하지 않는 경우 __fp16 데이터 형식을 사용하려고 하면 컴파일러에서 오류가 발생합니다.

구문

--fp16_format=format

여기서 format은 다음 중 하나입니다.

alternative 추가 범위를 지정하지만 NaN 또는 무한대 값을 포함하지 않는 ieee 대체 항목입니다.

ieee IEEE 754 표준 개정 버전인 IEEE 754r에서 정의되는 반정밀도 바이너리 부동 소수점 형식입니다.

none 이 설정은 기본 설정입니다. 이 설정은 형식을 지정하지 않는 것과 동일하며, __fp16 데이터 형식을 사용하는 경우 컴파일러에서 오류가 발생함을 의미합니다.

추가 참고

• E-4페이지의 내장 함수

• 컴파일러 사용 설명서의 5-37페이지의 단정밀도 부동 소수점 숫자 지원



2.1.72 --fpmode=model

이 옵션은 부동 소수점 규칙을 지정하고 라이브러리 속성 및 부동 소수점 최적화를 설정합니다.

구문

--fpmode=model

여기서 model은 다음 중 하나입니다.

ieee_full IEEE 표준이 보장하는 모든 기능 작업 및 표현이 단정밀도와 배정밀도로 제공됩니다. 런타임에 연산 모드를 동적으로 선택할 수 있습니다.

다음과 같은 기호를 정의합니다.

__FP_IEEE__FP_FENV_EXCEPTIONS__FP_FENV_ROUNDING__FP_INEXACT_EXCEPTION

ieee_fixed

가장 가까운 수로 반올림되며 부정확한 예외가 생성되지 않는 IEEE 표준입니다.

다음과 같은 기호를 정의합니다.

__FP_IEEE__FP_FENV_EXCEPTIONS

ieee_no_fenv

가장 가까운 수로 반올림되며 예외가 생성되지 않는 IEEE 표준입니다. 이 모드는 상태를 저장하지 않으며 Java 부동 소수점 산술 모델과 호환됩니다.

기호 __FP_IEEE를 정의합니다.

std IEEE 유한 값은 비정규 flush-to-zero, 가장 가까운 수로 반올림 및 예외 없음을 지원합니다. 표준 C 및 C++과 호환되며 기본 옵션입니다.

기본 유한 값은 IEEE 표준에서 예고한 값입니다. 그러나 다음 사항에 유의해야 합니다.

• IEEE 모델에서 정의한 모든 환경에서 NaN 및 무한대가 생성되지 않을 수 있습니다. 생성되었을 경우 동일한 부호를 갖지 않을 수도 있습니다.

• 부호 0은 IEEE 모델에서 예고한 것과 다를 수 있습니다.



fast 정확도가 조금 낮아지는 반면 성능을 크게 향상시킬 수 있는 보다 적극적인 부동 소수점 최적화를 수행합니다. 이 옵션은 __FP_FAST 기호를 정의합니다.

이 옵션을 사용하면 ISO C 및 C++ 표준과 부분적으로만 호환되는 동작이 발생하지만 강력한 수치 제어 부동 소수점 프로그램은 올바르게 작동합니다.

다음과 같은 여러 변환이 수행될 수 있습니다.

• 모든 부동 소수점 인수를 정확히 단정밀도 값으로 나타낼 수 있는 경우 배정밀도 수학 함수가 단정밀도 수학 함수로 변환될 수 있으며 그 결과는 즉시 단정밀도 값으로 변환됩니다.

예를 들어 선택한 라이브러리가 rvct 또는 aeabi_glibc인 경우와 같이 선택한 라이브러리에 함수와 같은 단정밀도가 포함되는 경우에만 이 변환이 수행됩니다.

예를 들면 다음과 같습니다.float f(float a){

return sqrt(a);}

위 옵션이 다음과 같이 변환됩니다.float f(float a){

return sqrtf(a);}.

• 단정밀도로 축소된 배정밀도 부동 소수점 식을 단정밀도로 계산하는 것이 유용한 경우에는 그렇게 계산됩니다. 예를 들어 float y = (float)(x + 1.0)은 float y = (float)x + 1.0f로 평가됩니다.

• 부동 소수점 상수로 나누기는 역수로 곱하기로 바뀝니다. 예를 들어 x / 3.0은 x * (1.0 / 3.0)으로 평가됩니다.

• 수학 함수가 호출된 후에는 errno의 값이 ISO C 또는 C++ 표준과 호환되지 않을 수 있습니다. 이 옵션은 컴파일러에서 sqrt() 또는 sqrtf()를 호출하는 대신 VFP 제곱근 명령어를 인라인하도록 합니다.

참고

VFP를 사용하기 위해 초기화 코드가 필요할 수 있습니다. 자세한 내용은 컴파일러 사용 설명서에서 5-36페이지의 VFP 지원을 참조하십시오.



추가 참고

• install_directory\RVDS\Examples\...\vfpsupport의 ARM Application Note 133 - Using VFP with RVDS

2.1.73 --fpu=list

이 옵션은 --fpu=name 옵션과 함께 사용할 수 있는 지원되는 FPU 아키텍처 이름을 나열합니다.

향후 제공되지 않는 옵션은 표시되지 않습니다.

추가 참고

• --fpu=name

2.1.74 --fpu=name

이 옵션을 사용하면 타겟 FPU 아키텍처를 확인할 수 있습니다.

이 옵션을 지정하면 명령 행에 표시되는 암시적 FPU 옵션(예: --cpu 옵션을 지정하는 경우)보다 우선합니다.

FPU 아키텍처의 전체 목록을 가져오려면 --fpu=list 옵션을 사용합니다.

구문

--fpu=name

여기서 name은 다음 중 하나입니다.

none 부동 소수점 옵션을 선택하지 않습니다. 부동 소수점 코드가 사용되지 않습니다. 코드에 float 유형이 있는 경우 오류가 생성됩니다.

vfpv 이것은 vfpv2의 동의어입니다.

vfpv2 VFPv2 아키텍처를 준수하는 하드웨어 벡터 부동 소수점 단위를 선택합니다.

참고

명령 행에 armcc --thumb --fpu=vfpv2를 입력하면 컴파일러에서 Thumb 명령어 세트를 사용하는 코드를 가능한 많이 컴파일하지만 하드웨어 부동 소수점에 쉽게 영향을 받는 함수는 ARM 코드로 컴파일됩니다. 이 경우 사전 정의된 __thumb 값은 올바르지 않습니다.



ARM C 코드에 대해 --arm 옵션과 함께 vfp 또는 vfpv2를 지정하면 __softfp 키워드를 사용하여 소프트웨어 부동 소수점 연결을 사용할 수 있도록 인터워킹 ARM 코드를 컴파일해야 합니다.

vfpv3 VFPv3 아키텍처를 준수하는 하드웨어 벡터 부동 소수점 단위를 선택합니다. VFPv3은 부동 소수점 예외를 트래핑할 수 없다는 점을 제외하면 VFPv2와 역방향 호환됩니다 vpfv3은 RealView Development Suite 3.0 이상에서만 사용할 수 있습니다.

vfpv3_fp16 반정밀도 확장도 제공하는 VFPv3 아키텍처를 준수하는 하드웨어 벡터 부동 소수점 단위를 선택합니다. vfpv3_fp16은 RealView Development Suite 4.0 이상에서만 사용할 수 있습니다.

vfpv3_d16 VFPv3-D16 아키텍처를 준수하는 하드웨어 벡터 부동 소수점 단위를 선택합니다. vfpv3_d16은 RealView Development Suite 4.0 이상에서만 사용할 수 있습니다.

vfpv3_d16_fp16

반정밀도 확장도 제공하는 VFPv3-D16 아키텍처를 준수하는 하드웨어 벡터 부동 소수점 단위를 선택합니다. vfpv3_d16_fp16은 RealView Development Suite 4.0 이상에서만 사용할 수 있습니다.

softvfp 소프트웨어 부동 소수점 라이브러리 fplib를 선택합니다. --fpu 옵션을 지정하지 않거나 FPU가 없는 CPU를 선택하는 경우 이것이 기본값입니다.

RVCT의 이전 릴리스에서 --fpu=softvfp 및 암시적 VFP 하드웨어가 있는 CPU를 지정한 경우 링커가 VFP 명령어를 사용하여 소프트웨어 부동 소수점 호출을 구현하는 라이브러리를 선택합니다. 더 이상은 적용되지 않습니다. 이 레거시 동작이 필요한 경우 --fpu=softvfp+vfp를 사용합니다.

softvfp+vfpv2

VFPv2 명령어를 사용하는 소프트웨어 부동 소수점 연결로 부동 소수점 라이브러리를 선택합니다. VFP 단위를 구현하는 시스템에서 Thumb 코드와 ARM 코드가 인터워킹하는 경우 이 옵션을 선택합니다.



이 옵션을 선택하면 다음 작업이 수행됩니다.

• --thumb을 사용하여 컴파일하면 VFP 명령어를 사용하는 부동 소수점 라이브러리와 링크되는 것을 제외하고 --fpu=softvfp와 비슷한 방식으로 동작합니다.

• --arm을 사용하여 컴파일하면 모든 함수에 소프트웨어 부동 소수점 연결이 제공되는 것을 제외하고 --fpu=vfpv2와 비슷한 방식으로 동작합니다. 즉, 함수는 부동 소수점 인수를 전달 및 반환하고 --fpu=softvfp와 같은 결과를 발생시키지만 내부적으로는 VFP 명령어를 사용합니다.

참고

C 코드에 대해 --arm 또는 --thumb 옵션과 함께 softvfp+vfpv2를 지정하면 소프트웨어 부동 소수점 연결을 사용할 수 있도록 인터워킹 부동 소수점 코드를 컴파일합니다.

softvfp+vfpv3

VFPv3 아키텍처를 타겟으로 하는 소프트웨어 부동 소수점 연결로 부동 소수점 라이브러리를 선택합니다. VFPv3 단위를 구현하는 시스템에서 ARM 코드가 있는 Thumb 코드를 인터워킹하는 경우 이 옵션을 선택합니다. softvfp+vfpv3은 RealView Development Suite 3.0 이상에서만 사용할 수 있습니다.

softvfp+vfpv3_fp16

반정밀도 부동 소수점 확장을 지원하는 VFPv3 아키텍처를 타겟으로 하는 소프트웨어 부동 소수점 연결로 부동 소수점 라이브러리를 선택합니다. softvfp+vfpv3_fp16은 RealView Development Suite 4.0 이상에서만 사용할 수 있습니다.

softvfp+vfpv3_d16

VFPv3-D16 아키텍처를 타겟으로 하는 소프트웨어 부동 소수점 연결로 부동 소수점 라이브러리를 선택합니다. softvfp+vfpv3_d16은 RealView Development Suite 4.0 이상에서만 사용할 수 있습니다.

softvfp+vfpv3_d16_fp16

반정밀도 부동 소수점 확장을 지원하는 VFPv3-D16 아키텍처를 타겟으로 하는 소프트웨어 부동 소수점 연결로 부동 소수점 라이브러리를 선택합니다. softvfp+vfpv3_d16_fp16은 RealView Development Suite 4.0 이상에서만 사용할 수 있습니다.



제한

--fpu 옵션을 사용하여 명시적으로 선택된 모든 FPU는 --cpu 옵션을 사용하여 암시적으로 선택된 모든 FPU를 항상 재정의합니다. 예를 들어 CPU 선택이 아키텍처 VFPv2 사용을 의미해도 --cpu=ARM1136JF-S --fpu=softvfp 옵션은 소프트웨어 부동 소수점 라이브러리 fplib를 사용하는 코드를 생성합니다.

--fpu를 사용하여 명시적으로 선택된 FPU와 호환되지 않는 --cpu 옵션을 사용하여 FPU를 암시적으로 지정하면 컴파일러는 오류를 생성합니다.

컴파일러는 스칼라 부동 소수점 연산만 생성합니다. VFP 벡터 연산을 사용하려면 어셈블리 코드를 사용하여 수행해야 합니다.

softvfp에 대한 NEON 지원이 비활성화되었습니다.

기본값

VFP 보조 프로세서가 있으면 VFP 명령어가 생성됩니다. VFP 보조 프로세서가 없으면 컴파일러는 부동 소수점 연산을 수행하기 위해 소프트웨어 부동 소수점 라이브러리 fplib에 호출하는 코드를 생성합니다.

참고

기본적으로 프로세서 또는 아키텍처의 선택은 특정한 부동 소수점 단위의 선택을 의미합니다. 예를 들어 --cpu ARM1136JF-S 옵션은 --fpu vfpv2 옵션을 포함합니다.

추가 참고




• 4-17페이지의 __softfp

• 컴파일러 사용 설명서의 5-39페이지의 부동 소수점 계산 및 연결

• 개발자 설명서의 2-5페이지의 부동 소수점 빌드 옵션



2.1.75 --friend_injection, --no_friend_injection

이 옵션은 C++의 friend 선언 표시를 제어합니다.

C++에서 이 옵션은 일반적인 조회 메커니즘을 사용하는 경우 friend 선언에서만 선언되는 클래스 또는 함수의 이름을 표시할지 여부를 제어합니다.

friend 이름이 선언되면 선언된 이름은 해당 조회에 대해 표시됩니다. 표준 요구조건에 따라 friend 이름이 선언되지 않은 경우 인수 종속 조회를 사용할 경우에만 함수 이름이 표시되며 클래스 이름은 표시되지 않습니다.

참고

--friend_injection 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_friend_injection입니다.

추가 참고

• 3-17페이지의 friend

2.1.76 -g

이 옵션을 사용하면 현재 컴파일에 대해 디버그 테이블 생성을 활성화할 수 있습니다.

-g 사용 여부에 상관없이 컴파일러에서 동일한 코드를 생성합니다. 디버그 테이블이 있다는 점만 다릅니다.

-g를 사용해도 최적화 설정에는 영향을 주지 않습니다. 기본적으로 -g 옵션을 단독으로 사용하는 것은 다음을 사용하는 것과 같습니다.

-g --dwarf3 --debug_macros



추가 참고


• 2-39페이지의 --debug_macros, --no_debug_macros




2.1.77 --global_reg=reg_name[,reg_name,...]

이 옵션은 지정한 레지스터 이름을 고정 레지스터로 처리합니다.

구문

--global_reg=reg_name[,reg_name,...]

여기서 reg_name은 레지스터의 APCS 또는 TPCS 이름으로, 1 ~ 8 사이의 정수값으로 표시됩니다.

1 ~ 8의 레지스터 이름은 r4 ~ r11 레지스터에 순서대로 매핑됩니다.

제한

이 옵션은 __global_reg 저장소 클래스 지정자와 동일한 제한이 있습니다.

예제

--global_reg=1,4,5 //는 r4, r7 및 r8의 레지스터 3개를 예약합니다.

추가 참고

• 4-8페이지의 __global_reg

• ARM Software Development Toolkit 참조 설명서

2.1.78 --gnu

이 옵션을 사용하면 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장을 사용할 수 있습니다. 확장과 호환되는 GCC 버전은 사전 정의된 매크로 __GNUC__ 및 __GNUC_MINOR__를 검사하여 확인할 수 있습니다.



추가 참고

• 2-23페이지의 --c90

• 2-23페이지의 --c99





2.1.79 --gnu_instrument, --no_gnu_instrument

이 옵션은 GCC 형식의 사용법을 삽입합니다.

추가 참고

• --gnu_instrument, --no_gnu_instrument.

2.1.80 --gnu_version=version

이 옵션은 컴파일러가 특정 GCC 버전과 호환되도록 지정합니다.

구문

--gnu_version=version

여기서 version은 컴파일러가 호환되도록 지정할 GCC 버전을 나타내는 10진수입니다.

모드

이 옵션은 GNU 호환성 모드를 사용 중일 때 사용합니다.

사용법

이 옵션은 전문가용이며 레거시 코드 처리를 위해 제공됩니다. 일반적인 경우에는 이 옵션을 사용할 필요가 없습니다.

기본값

RVCT 버전 4.0에서 기본값은 40200입니다. 이 값은 GCC 버전 4.2.0에 해당합니다.



예제

--gnu_version=30401은 컴파일러가 GCC 3.4.1과 최대한 호환되도록 지정합니다.

추가 참고

• 2-70페이지의 --gnu.

2.1.81 --guiding_decls, --no_guiding_decls

이 옵션을 사용하면 C++의 템플릿 함수에 대한 안내 선언 인식을 사용할 것인지 여부를 설정할 수 있습니다.

안내 선언은 함수 템플릿의 인스턴스와 일치하지만 해당 정의가 함수 템플릿에서 파생되었기 때문에 명시적 정의가 없는 함수 선언입니다.

--no_guiding_decls와 --old_specializations를 함께 사용하면 비구성원 템플릿 함수의 특수화는 인식되지 않고 독립 함수 정의로 처리됩니다.

참고

--guiding_decls 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_guiding_decls입니다.

예제

template <class T> void f(T){

...}void f(int);

안내 선언으로 간주되는 경우 f(int)는 템플릿의 인스턴스입니다. 안내 선언으로 간주되지 않는 경우 독립 함수이므로 정의를 입력해야 합니다.



추가 참고


• 2-102페이지의 --old_specializations, --no_old_specializations

2.1.82 --help

이 옵션은 기본 명령 행 옵션의 요약을 표시합니다.

옵션이나 소스 파일을 지정하지 않은 경우 이것이 기본값입니다.

추가 참고

• 2-120페이지의 --show_cmdline.

• 2-141페이지의 --vsn

2.1.83 --hide_all, --no_hide_all

이 옵션을 사용하면 SVr4 공유 객체를 빌드할 때 기호 표시 유형을 제어할 수 있습니다.

사용법

--no_hide_all을 사용하면 모든 extern 변수와 함수가 __declspec(dll*)을 사용하지 않는 경우 컴파일러가 이들 변수 및 함수에 대해 STV_DEFAULT 표시를 사용하도록 지정할 수 있습니다. 또한 이렇게 하면 동적 로더가 런타임에 이들 변수와 함수를 사전에 비울 수 있습니다.

System V 또는 ARM Linux 공유 라이브러리를 빌드할 경우 --apcs /fpic과 --no_hide_all을 함께 사용합니다.

기본값

기본값은 --hide_all입니다.



추가 참고




• 링커 참조 설명서의 4-4페이지의 기호 표시 유형

• 링커 참조 설명서의 2-63페이지의 --symver_script=file

2.1.84 -Idir[,dir,...]

이 옵션은 지정된 디렉토리 또는 콤마로 구분된 디렉토리 목록을 포함된 파일을 찾기 위해 검색할 위치 목록에 추가합니다.

디렉토리를 두 개 이상 지정하면 -I 옵션으로 디렉토리를 지정한 순서대로 디렉토리를 검색합니다.

구문

-Idir[,dir,...]

인수 설명:

dir[,dir,...] 포함된 파일을 찾기 위해 검색할 콤마로 구분된 디렉토리 목록입니다.

최소 한 개의 디렉토리가 지정되어야 합니다.

여러 개의 디렉토리를 지정하는 경우 목록에서 콤마와 디렉토리 이름 사이에 공백을 포함해서는 안 됩니다.

추가 참고

• 2-80페이지의 -Jdir[,dir,...]

• 2-81페이지의 --kandr_include

• 2-110페이지의 --preinclude=filename

• 2-127페이지의 --sys_include

• 컴파일러 사용 설명서의 2-15페이지의 헤더 파일



2.1.85 --ignore_missing_headers

이 옵션은 헤더 파일의 존재 유무에 관계 없이 헤더 파일에 대한 종속 행을 인쇄하도록 컴파일러에 지시합니다.

누락된 헤더 파일에 대한 경고 및 오류 메시지는 표시되지 않으며 컴파일도 계속됩니다. 그러나 이 옵션을 사용하지 않으면 헤더 파일이 누락될 경우 오류가 발생하여 컴파일은 중지됩니다.

사용법

이 옵션을 사용하면 메이크파일이 자동 업데이트됩니다. GCC -MG 명령 행 옵션과 유사합니다.

추가 참고





• 2-92페이지의 -M



2.1.86 --implicit_include, --no_implicit_include

이 옵션은 C++에서 인스턴스화할 템플릿 엔터티의 정의를 검색할 방법으로써 소스 파일의 암시적 포함을 제어합니다.

모드


기본값

기본값은 --implicit_include입니다.



추가 참고

• --implicit_include_searches, --no_implicit_include_searches

• 5-16페이지의 암시적 포함

2.1.87 --implicit_include_searches, --no_implicit_include_searches

이 옵션은 컴파일러에서 C++에서 템플릿에 대한 암시적 include 파일을 검색하는 방법을 제어합니다.

--implicit_include_searches 옵션을 선택한 경우 컴파일러에서는 검색 경로를 사용하여 filename.* 형식으로 된 이름의 일부를 가지고 암시적 include 파일을 검색합니다. 검색 경로는 -I, -J 및 RVCT40INC 환경 변수에 의해 결정됩니다.

--no_implicit_include_searches 옵션을 선택한 경우 컴파일러에서는 경로 이름과 파일의 전체 이름을 사용하여 암시적 include 파일을 검색합니다.

모드


기본값

기본값은 --no_implicit_include_searches입니다.

추가 참고

• 2-74페이지의 -Idir[,dir,...]

• 2-75페이지의 --implicit_include, --no_implicit_include


• 5-16페이지의 암시적 포함

• 컴파일러 사용 설명서의 2-16페이지의 검색 경로



2.1.88 --implicit_typename, --no_implicit_typename

이 옵션은 C++에서 이름에 종속적인 템플릿 매개변수가 문맥에서 유형인지 비유형인지를 확인하는 암시적 확인을 제어합니다.

참고

--implicit_typename 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_implicit_typename입니다.

참고

--no_parse_templates를 함께 지정하지 않으면 --implicit_typename 옵션은 효과가 없습니다.

추가 참고

• 2-40페이지의 --dep_name, --no_dep_name

• 2-104페이지의 --parse_templates, --no_parse_templates

• 5-16페이지의 템플릿 인스턴스화

2.1.89 --info=totals

이 옵션은 객체 코드의 총계와 각 객체 파일의 데이터 크기를 제공하도록 컴파일러에 지시합니다.

fromelf -z를 사용하는 경우 컴파일러에서는 fromelf에서 반환하는 값과 동일한 총계를 유사한 형식으로 반환합니다. 소스 코드에 임베디드 어셈블리가 있는 경우에는 총계에 임베디드 어셈블러 크기가 포함됩니다.



예제

Code (inc. data) RO Data RW Data ZI Data Debug File Name3308 1556 0 44 10200 8402 dhry_1.oCode (inc. data) RO Data RW Data ZI Data Debug File Name416 28 0 0 0 7722 dhry_2.o

(inc. data) 열에는 상수 크기, 문자열 리터럴 및 코드의 일부로 사용되는 기타 데이터 항목이 표시됩니다. Code 열에는 예제에서와 같이 이 값이 포함됩니다.

추가 참고


• 링커 참조 설명서의 2-28페이지의 --info=topic[,topic,...]

• 컴파일러 사용 설명서의 5-10페이지의 코드 메트릭스

• 유틸리티 설명서의 2-2페이지의 명령 행 옵션 사용

2.1.90 --inline, --no_inline

이 옵션을 사용하면 함수 인라인을 사용할 것인지 여부를 설정할 수 있습니다. 함수 인라인을 사용하지 않으면 디버그의 일루션을 개선할 수 있습니다.

--inline 옵션을 선택하면 컴파일러에서는 각 함수를 인라인하는 것으로 간주합니다. --inline을 사용하여 코드를 컴파일하더라도 반드시 모든 함수가 인라인되는 것은 아닙니다. 컴파일러에서 함수를 인라인하는 방법에 대한 자세한 내용은 컴파일러 사용 설명서에서 5-19페이지의 컴파일러에서 인라인하기 적당한 경우를 참조하십시오.

--no_inline 옵션을 선택한 경우 컴파일러에서는 __forceinline으로 정규화된 함수를 제외한 다른 함수를 인라인하지 않습니다.

기본값

기본값은 --inline입니다.

추가 참고








• 4-7페이지의 __forceinline

• 4-10페이지의 __inline


• 컴파일러 사용 설명서의 5-18페이지의 함수 인라인

2.1.91 --interface_enums_are_32_bit

이 옵션을 사용하면 열거되는 형식의 크기와 관련하여 외부 코드 인터페이스 간에 호환성을 제공할 수 있습니다.

사용법

--enum_is_int로 컴파일한 객체 파일을 --enum_is_int 없이 컴파일한 객체 파일에 연결할 수는 없습니다. 링커는 열거된 형식이 외부 인터페이스에 영향을 주는 방식으로 사용되는지 여부를 확인할 수 없으므로, 이러한 빌드 차이를 감지하면 경고 또는 오류를 생성합니다. 이러한 현상을 방지하려면 --interface_enums_are_32_bit로 컴파일하면 됩니다. 그 결과로 생성되는 객체 파일은 다른 모든 객체 파일에 링크할 수 있으며, 열거 형식 크기 차이로 인해 발생하는 링커 감지 충돌을 방지할 수 있습니다.

참고

이 옵션을 사용하는 경우 컴파일러에 대해 외부 인터페이스에서 사용되는 모든 열거 형식의 너비가 32비트라는 원칙이 지정됩니다. 예를 들어 사용자가 선언하는 모든 enum에 2의 16제곱보다 큰 값이 최소한 하나 이상 포함되도록 하는 경우 컴파일러는 --enum_is_int 사용 여부에 관계없이 enum의 너비를 32비트로 만들어야 합니다. 컴파일러에 대해 적용하는 이러한 원칙이 참인지는 사용자가 결정합니다. 외부 인터페이스에 enums를 포함하지 않는 방법으로도 이 조건을 충족할 수 있습니다.

추가 참고

• 2-55페이지의 --enum_is_int.



2.1.92 --interleave

이 옵션은 --asm 옵션 또는 -S 옵션을 사용하여 생성된 어셈블리 목록에 C 또는 C++ 소스 코드를 한 행씩 주석으로 인터리브합니다.

사용법

--interleave의 동작은 다음과 같은 옵션의 조합에 따라 다릅니다.

제한

• --asm --interleave 또는 -S --interleave를 사용하여 생성된 어셈블리 목록은 다시 어셈블할 수 없습니다.

• 사전 처리된 소스 파일에는 #line 지시어가 있습니다. --asm --interleave 또는 -S --interleave를 사용하여 사전 처리된 파일을 컴파일하는 경우 컴파일러에서는 모든 #line 지시어가 나타내는 원래 파일을 검색하여 해당 파일에서 올바른 행을 사용합니다. 그러면 사전 처리된 파일을 컴파일할 때 원래 파일이 컴파일된 것처럼 똑같은 출력과 동작을 얻을 수 있습니다.

컴파일러에서 원래 파일을 찾지 못하면 소스를 인터리브할 수 없습니다. 그러므로 #line 지시어를 사용하여 소스 파일을 사전 처리할 경우 사전 처리되지 않은 원래 파일이 없으면 #line 지시어를 모두 제거한 후 --interleave를 사용하여 컴파일해야 합니다.

표 2-4 ---interleave 옵션을 사용한 컴파일

컴파일러 옵션 동작

--asm --interleave 소스 코드를 디스어셈블리에 인터리브하여 컴파일된 소스의 디스어셈블리 파일에 목록을 작성합니다.

-c 옵션을 사용하지 않으면 링크 단계도 수행됩니다.


-S --interleave 소스 코드를 디스어셈블리에 인터리브하여 컴파일된 소스의 디스어셈블리 파일에 목록을 작성합니다.




추가 참고


• 2-119페이지의 -S

2.1.93 -Jdir[,dir,...]

이 옵션은 지정된 디렉토리 또는 콤마로 구분된 디렉토리 목록을 시스템 include 목록에 추가합니다.

--diag_error를 사용하는 경우에도 경고 및 설명은 표시되지 않습니다.

-J를 사용하여 RVCT40INC 환경 변수를 무시하지 않으면 해당 환경 변수에는 기본 시스템 include 경로가 설정됩니다. 시스템 include 목록에서 각괄호로 묶인 include 파일이 첫 번째로 검색되고 그 다음에 -I 옵션으로 지정된 include 목록이 검색됩니다.

참고

Windows 시스템에서 이 환경 변수를 명령 행에 지정하는 경우 변수에서 정의한 기본 경로에 공백이 포함되기 때문에 RVCT40INC를 큰따옴표로 묶어야 합니다. 예를 들면 다음과 같습니다.

armcc -J"%RVCT40INC%" -c main.c

구문

-Jdir[,dir,...]

인수 설명:

dir[,dir,...] 시스템 include 목록에 추가할 콤마로 구분된 디렉토리 목록입니다.

최소 한 개의 디렉토리가 지정되어야 합니다.

여러 개의 디렉토리를 지정하는 경우 목록에서 콤마와 디렉토리 이름 사이에 공백을 포함해서는 안 됩니다.



추가 참고


• --kandr_include




2.1.94 --kandr_include

이 옵션을 사용하면 Kernighan 및 Ritchie 검색 규칙을 사용하여 포함된 파일을 찾을 수 있습니다.

현재 위치는 원래 소스 파일에 의해 정의되고 스택되지는 않습니다. 이 옵션을 지정하지 않으면 Berkeley 스타일 검색이 사용됩니다.

추가 참고






• 컴파일러 사용 설명서의 2-15페이지의 현재 위치

2.1.95 -Lopt

이 옵션은 컴파일 후에 연결 단계가 수행될 때 링커로 전달할 명령 행 옵션을 지정합니다. 옵션은 부분적으로 연결된 객체 또는 실행 가능 이미지를 만들 때 전달할 수 있습니다.

구문

-Lopt

인수 설명:

opt 링커로 전달할 명령 행 옵션입니다.



제한

-L을 사용하여 지원되지 않는 링커 옵션을 링커로 전달하면 오류가 생성됩니다.

예제

armcc main.c -L--map

추가 참고

• 2-2페이지의 -Aopt

• 2-120페이지의 --show_cmdline.

2.1.96 --library_interface=lib

이 옵션을 사용하면 선택한 라이브러리 유형과 호환되는 코드를 생성할 수 있습니다.

구문

--library_interface=lib

여기서 lib 은 다음 중 하나입니다.

rvct 컴파일러 출력을 RVCT 런타임 라이브러리에서 사용하도록 지정합니다.

rvct_c90 --library_interface=rvct와 비슷하게 동작합니다. 그러나 C90에서 보존되지 않는 함수 이름에 대한 입력 소스 코드의 참조를 컴파일러에서 수정하지 않는다는 점이 다릅니다. 그렇지 않은 경우 일부 C99 math.h 함수 이름에는 __hardfp_tgamma와 같이 __hardfp_ 접두사가 붙을 수 있습니다.

aeabi_clib90 컴파일러 출력을 AEABI(ARM 임베디드 응용 프로그램 바이너리 인터페이스)와 호환되는 모든 ISO C90 라이브러리에서 사용하도록 지정합니다.

aeabi_clib99 컴파일러 출력을 AEABI(ARM 임베디드 응용 프로그램 바이너리 인터페이스)와 호환되는 모든 ISO C99 라이브러리에서 사용하도록 지정합니다.



aeabi_clib 컴파일러 출력을 AEABI(ARM 임베디드 응용 프로그램 바이너리 인터페이스)와 호환되는 모든 ISO C 라이브러리에서 사용하도록 지정합니다.

--library_interface=aeabi_clib 옵션을 선택하는 것은 --library_interface=aeabi_clib90 또는 --library_interface=aeabi_clib99를 지정하는 것과 같으며 옵션은 선택하는 소스 언어에 따라 달라집니다.

소스 언어 선택은 선택하는 명령 행 옵션 및 사용하는 파일명 접미사에 종속적입니다.

aeabi_glibc 컴파일러 출력을 GNU C 라이브러리의 AEABI 호환 버전에서 사용하도록 지정합니다.

기본값

--library_interface를 지정하지 않으면 컴파일러에서 --library_interface=rvct로 간주됩니다.

사용법

• --library_interface=rvct 옵션을 사용하여 링크할 때 컴파일러의 전체 범위 및 라이브러리 최적화를 이용합니다.

• ABI 호환 C 라이브러리를 사용하여 링크할 경우 --library_interface=aeabi_*형식의 옵션을 사용합니다. --library_interface=aeabi_* 형식의 옵션은 컴파일러에서 RVCT C 라이브러리에서 제공하는 최적화된 어떠한 함수도 호출하지 않도록 합니다.

예제

RVCT C 라이브러리에서 제공하는 함수를 대체하는 임베디드 운영 체제 제공 함수를 코드에서 호출하는 경우 --library_interface=aeabi_clib를 사용해 코드를 컴파일하여 운영 체제에 의해 대체된 라이브러리 함수의 어떠한 RVCT 전용 변수도 호출하지 않도록 합니다.

추가 참고

• 라이브러리 및 부동 소수점 지원 설명서의 1-3페이지의 ABI for the ARM Architecture 규격 준수



2.1.97 --library_type=lib

이 옵션을 사용하면 링크 타임에 선택한 라이브러리를 사용할 수 있습니다.

참고

다른 --library_type 옵션을 모두 재정의하려면 링커에서 이 옵션을 사용합니다.

구문

--library_type=lib

여기서 lib 는 다음 중 하나입니다.

standardlib 링크 타임에 전체 RVCT 런타임 라이브러리가 선택되도록 지정합니다.

링크할 때 전체 범위의 컴파일러 최적화를 이용하려면 이 옵션을 지정하십시오.

microlib 링크 타임에 C 마이크로 라이브러리(microlib)가 선택되도록 지정합니다.

기본값

--library_type을 지정하지 않으면 컴파일러에서 --library_type=standardlib로 간주됩니다.

추가 참고

• 라이브러리 및 부동 소수점 지원 설명서의 3-4페이지의 microlib로 응용 프로그램 빌드

• 링커 참조 설명서의 2-38페이지의 --library_type=lib



2.1.98 --licretry

floating 라이센스를 사용하는 경우 이 옵션은 사용자가 armcc를 호출할 때 최대 10회까지 라이센스 획득을 시도합니다.

사용법

야간에 수행하는 빌드와 같은 일반적인 빌드 프로세스에는 매우 많은 ARM 컴파일 도구 호출이 포함될 수 있습니다. 그리고 각 도구 호출에는 클라이언트(빌드) 시스템과 라이센스 서버 간의 네트워크 통신이 포함됩니다. 그러나 빌드 시스템이 라이센스 서버에서 라이센스를 가져오려 할 때 일시적으로 네트워크 오류가 발생하면 도구가 라이센스를 가져오지 못할 수 있습니다. 그러므로 --licretry를 사용하면 이러한 문제를 방지할 수 있습니다.

이 옵션은 RVCT40_CCOPT 환경 변수에 배치하는 것이 좋습니다. 이렇게 하면 빌드 파일을 수정할 필요가 없습니다.

참고

이 옵션은 네트워크 또는 라이센스 서버 설정과 관련된 다른 문제를 해결한 후에만 사용하십시오.

추가 참고

• 링커 참조 설명서의 2-39페이지의 --licretry

• 어셈블러 설명서의 3-2페이지의 명령 구문

• 유틸리티 설명서의 2-35페이지의 --licretry

• RealView Compilation Tools 핵심 설명서의 1-7페이지의 RVCT에서 사용되는 환경 변수

• ARM 도구용 FLEXnet 라이센스 관리 설명서.

2.1.99 --list

이 옵션은 소스 파일에 대한 원시 목록 정보를 생성하도록 컴파일러에 지시합니다. 원시 목록 파일의 이름은 기본적으로 파일 확장명이 .lst인 입력 파일의 이름입니다.

명령 행에 여러 개의 소스 파일을 지정하면 지정한 파일 중에 첫 번째 파일에 대해서만 원시 목록 정보가 생성됩니다.



사용법

일반적으로 원시 목록 정보는 형식이 지정된 목록을 생성하는 데 사용됩니다. 원시 목록 파일에는 원시 소스 행, include 파일의 내외부 전이에 대한 정보 및 컴파일러에서 생성된 진단이 포함되어 있습니다. 목록 파일의 각 행은 행 유형을 식별하는 다음 키 문자로 시작합니다.

N 소스의 기본 행입니다. 행의 나머지 부분은 소스 행의 텍스트입니다.

X 소스의 기본 행이 확장된 형식입니다. 행의 나머지 부분은 행의 텍스트입니다. 이 행은 행에 중요한 수정 사항이 있는 경우에만 N 행 다음에 표시됩니다. 주석은 사소한 수정 사항으로 간주되고 매크로 확장, 행 연결 및 3중 음자는 중요한 수정사항으로 간주됩니다. 확장된 형식의 행에서 주석은 하나의 공백으로 바뀝니다.

S #if 등으로 건너뛴 소스 행입니다. 행의 나머지 부분은 텍스트입니다.

참고

건너뛰기를 끝내는 #else, #elseif 또는 #endif는 N으로 표시됩니다.

L 소스 위치 변경을 나타냅니다. 즉, 행에 사전 처리기에 의한 # line-identifying 지시어 출력과 비슷한 다음과 같은 형식이 있습니다.

L line-number "filename" key

여기서 key는 다음 중 하나일 수 있습니다.

1 include 파일로 들어가기

2 include 파일에서 나가기

이외에는 key가 생략됩니다. 원시 목록 파일의 첫 행은 항상 기본 입력 파일을 식별하는 L 행입니다. L 행은 #line 지시어의 출력이기도 하며, 여기서 key는 생략됩니다. L 행은 원시 목록 파일에서 다음 소스 행의 소스 위치를 나타냅니다.

R/W/E 다음과 같이 진단을 나타냅니다.

R 설명을 나타냅니다.

W 경고를 나타냅니다.

E 오류를 나타냅니다.

행에는 다음과 같은 양식이 있습니다.

type "filename" line-number column-number message-text



여기서 type은 R, W 또는 E일 수 있습니다.

파일 끝에 표시된 오류는 기본 소스 파일의 마지막 행 및 0의 열 번호를 나타냅니다.

명령 행 오류는 "<command line>" 의 파일 이름으로 인한 오류입니다. 행 또는 열 번호가 오류 메시지에 표시되지 않습니다.

내부 오류는 일반적으로 위치 정보 및 (Internal fault)로 시작하는 메시지 텍스트로 인한 오류입니다.

진단 메시지가 오버로드된 호출에서의 모호함으로 인한 모든 경쟁 루틴과 같은 목록을 표시하면 첫 진단 행 뒤에는 완전히 동일한 형식의 행이 하나 이상 따라옵니다. 그러나 코드 문자는 첫 번째 행에 있는 코드 문자의 소문자 버전입니다. 이 행의 소스 위치는 해당하는 첫 번째 행에 있는 위치와 같습니다.

예제

/* main.c */#include <stdbool.h>int main(void){

return(true);}

--list 옵션을 사용하여 이 코드를 컴파일하면 다음과 같은 원시 목록 파일이 생성됩니다.

L 1 "main.c"N#include <stdbool.h>L 1 "...\include\...\stdbool.h" 1N/* stdbool.h */N...N #ifndef __cplusplus /* In C++, 'bool', 'true' and 'false' and keywords */N #define bool _BoolN #define true 1N #define false 0N #endif...L 2 "main.c" 2NNint main(void)N{N return(true);X return(1);N}



추가 참고


• 2-22페이지의 -c



• 2-77페이지의 --info=totals



• 2-119페이지의 -S

• 컴파일러 사용 설명서의 6-3페이지의 진단 메시지의 심각도

2.1.100 --list_macros

이 옵션은 지정된 소스 파일을 처리한 후 stdout으로 매크로 정의 목록을 출력합니다. 사용 방법에 따라 출력된 결과에는 명령 행에서 사용된 매크로, 컴파일러에서 사전 정의된 매크로 또는 헤더 파일이나 소스 파일에서 발견된 매크로에 대한 정의가 포함됩니다.

사용법

명령 행에서 정의된 매크로, 컴파일러에서 사전 정의된 매크로 및 헤더 파일이나 소스 파일에서 발견된 매크로의 목록을 출력하려면 비어 있지 않은 소스 파일과 함께 --list_macros를 사용합니다.

컴파일러에서 사전 정의된 매크로 및 명령 행에서 지정한 매크로의 목록만 출력하려면 --list_macros를 빈 소스 파일과 함께 사용합니다.

제한

코드 생성은 표시되지 않습니다.

추가 참고


• 2-37페이지의 -Dname[(parm-list)][=def]

• 2-54페이지의 -E

• 2-120페이지의 --show_cmdline

• 2-139페이지의 --via=filename



2.1.101 --littleend

이 옵션은 리틀엔디안 메모리를 사용하여 ARM 프로세서에 대한 코드를 생성하도록 컴파일러에 지시합니다.

리틀엔디안 메모리를 사용하면 워드의 최하위 바이트가 최하위 주소를 차지합니다.

기본값

--bigend를 명시적으로 지정하지 않으면 컴파일러에서 --littleend로 간주됩니다.

추가 참고

• 2-18페이지의 --bigend

2.1.102 --locale=lang_country

이 옵션은 소스 파일에 대한 기본 로케일을 사용자가 lang_country에 지정한 것으로 변경합니다.

구문

--locale=lang_country

인수 설명:

lang_country 는 새 기본 로케일입니다.

이 옵션은 --multibyte_chars와 함께 사용됩니다.

제한

로케일 이름은 호스트 플랫폼에 따라 대소문자를 구분할 수 있습니다.

허용되는 로케일 설정은 호스트 플랫폼에 의해 결정됩니다.

호스트 플랫폼에 필요한 로케일 지원을 설치했는지 확인하십시오.

예제

영어 기반 Windows 워크스테이션에서 일본어 소스 파일을 컴파일하려면 다음 명령을 실행합니다.

--multibyte_chars --locale=japanese



UNIX 워크스테이션에서는 다음 명령을 실행합니다.

--multibyte_chars --locale=ja_JP

추가 참고

• 2-93페이지의 --message_locale=lang_country[.codepage]

• 2-95페이지의 --multibyte_chars, --no_multibyte_chars.

2.1.103 --loose_implicit_cast

이 옵션은 0이 아닌 정수를 포인터로 캐스트하는 암시적 캐스트와 같이 잘못된 암시적 캐스트를 올바른 캐스트로 만듭니다.

예제

int *p = 0x8000;

--loose_implicit_cast 옵션을 사용하지 않고 이 예제를 컴파일하면 오류가 생성됩니다.

--loose_implicit_cast 옵션을 사용하여 이 예제를 컴파일하면 표시되지 않도록 할 수 있는 경고 메시지가 생성됩니다.

2.1.104 --lower_ropi, --no_lower_ropi

이 옵션을 사용하면 --apcs=/ropi를 사용하여 컴파일할 때 덜 제한적인 C를 사용할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --no_lower_ropi입니다.

참고

--lower_ropi를 사용하여 컴파일하면 런타임에 C++ 생성자 메커니즘에 의해 C와 C++ 코드 모두에 대해 정적 초기화가 수행됩니다. 그러면 ROPI 코드에서도 이런 정적 초기화를 사용할 수 있습니다.



추가 참고


• --lower_rwpi, --no_lower_rwpi

• 컴파일러 사용 설명서의 2-26페이지의 위치 독립 한정자

2.1.105 --lower_rwpi, --no_lower_rwpi

이 옵션을 사용하면 --apcs=/rwpi를 사용하여 컴파일할 때 덜 제한적인 C 및 C++를 사용할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --lower_rwpi입니다.

참고

--lower_rwpi를 사용하여 컴파일하면 런타임에 C++ 생성자 메커니즘에 의해 C에 대해서도 정적 초기화를 수행합니다. 그러면 RWPI 코드에서도 이런 정적 초기화를 사용할 수 있습니다.

추가 참고


• 2-90페이지의 --lower_ropi, --no_lower_ropi

• 컴파일러 사용 설명서의 2-26페이지의 위치 독립 한정자

2.1.106 --ltcg

이 옵션은 링크 타임 코드 생성 최적화를 수행할 수 있도록 중간 형식으로 객체를 만들도록 컴파일러에 지시합니다. 적용되는 최적화로는 성능 개선을 위한 모듈 간 인라인과 코드 크기를 줄이기 위한 기본 주소 공유가 있습니다.

참고

이 옵션을 사용하는 경우 링크 타임 및 메모리 요구 사항이 크게 늘어날 수 있습니다. 대형 응용 프로그램의 경우 객체 하위 세트를 사용하여 부분 연결 단계에서 코드 생성을 수행하는 것이 좋습니다.



예제

다음 예제에서는 --ltcg 옵션을 사용하는 방법을 보여 줍니다.

armcc -c --ltcg file1.carmcc -c --ltcg file2.carmlink --ltcg file1.o file2.o -o prog.axf

추가 참고



• 링커 참조 설명서의 2-41페이지의 --ltcg

2.1.107 -M

이 옵션은 작성 유틸리티에서 사용하기에 적합한 메이크파일 종속 행 목록을 생성하도록 컴파일러에 지시합니다.

컴파일러에서는 컴파일의 사전 처리기 단계만 실행합니다. 기본적으로 출력은 표준 출력 스트림에 있습니다.

여러 소스 파일을 지정하면 한 개의 종속 파일이 생성됩니다.

-o filename 옵션을 지정하면 표준 출력에 생성된 종속 행은 source.o가 아닌 filename.o를 참조합니다. 그러나 객체 파일은 -M -o filename의 조합으로 생성되지 않습니다.

각 소스 파일에 대한 종속 행 및 객체 파일을 생성하려면 --md 옵션을 지정합니다.

예제

다음과 같이 표준 UNIX 및 MS-DOS 표시를 사용하여 출력을 파일로 리디렉션할 수 있습니다.

armcc -M source.c > Makefile



추가 참고

• 2-23페이지의 -C



• 2-54페이지의 -E

• --md


2.1.108 --md

이 옵션은 소스를 컴파일하고 메이크파일 종속 행을 파일에 작성하도록 컴파일러에 지시합니다.

출력 파일은 작성 유틸리티에서 사용하기에 적합합니다.

컴파일러에서는 파일 이름을 filename.d로 지정합니다. 여기서 filename은 소스 파일의 이름입니다. 여러 소스 파일을 지정하면 각 소스 파일에 종속 파일이 생성됩니다.

추가 참고




• 2-92페이지의 -M


2.1.109 --message_locale=lang_country[.codepage]

이 옵션은 오류 및 경고 메시지 표시에 사용할 기본 언어를 lang_country 또는 lang_country.codepage에 지정된 언어로 변경합니다.

구문

--message_locale=lang_country[.codepage]



인수 설명:

lang_country[.codepage]

오류 및 경고 메시지 표시에 사용할 새 기본 언어입니다.

허용되는 언어는 호스트 플랫폼과 관계가 없습니다.

지원되는 설정은 다음과 같습니다.

• en_US

• zh_CN

• ko_KR

• ja_JP

기본값

--message_locale을 지정하지 않으면 컴파일러에서는 --message_locale=en_US로 간주합니다.

제한

호스트 플랫폼에 필요한 로케일 지원을 설치했는지 확인하십시오.

로케일 이름은 호스트 플랫폼에 따라 대소문자를 구분할 수 있습니다.

코드페이지 및 그 의미를 지정하는 기능은 호스트 플랫폼에 따라 다릅니다.

오류

지원되지 않는 설정을 지정하면 컴파일러에서 오류 메시지를 생성합니다.

예제

일본어로 메시지를 표시하려면 다음을 사용합니다.

--message_locale=ja_JP

추가 참고

• 2-89페이지의 --locale=lang_country

• 2-95페이지의 --multibyte_chars, --no_multibyte_chars



2.1.110 --min_array_alignment=opt

이 옵션을 사용하면 배열의 최소 정렬을 지정할 수 있습니다.

구문

--min_array_alignment=opt

인수 설명:

opt 배열의 최소 정렬을 지정합니다. opt의 값은 다음과 같습니다.

1 바이트 정렬 또는 정렬되지 않음

2 2바이트(하프워드) 정렬

4 4바이트(워드) 정렬

8 8바이트(더블워드) 정렬

기본값

--min_array_alignment 옵션을 지정하지 않으면 컴파일러에서 --min_array_alignment=1로 간주됩니다.

예제

--min_array_alignment=8로 다음 코드를 컴파일하면 주석에 설명된 정렬이 제공됩니다.

char arr_c1[1]; // alignment == 8char c1; // alignment == 1

추가 참고

• 4-2페이지의 __align

• 4-5페이지의 __ALIGNOF__



2.1.111 --mm

이 옵션은 -M --no_depend_system_headers를 사용하는 것과 동일한 효과를 제공합니다.

추가 참고


• 2-92페이지의 -M

2.1.112 --multibyte_chars, --no_multibyte_chars

이 옵션을 사용하면 주석, 문자열 리터럴 및 문자 상수에서 다중 바이트 문자 시퀀스의 처리를 사용할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --no_multibyte_chars입니다.

사용법

다중 바이트 인코딩은 일본어 Shift-JIS(Shift-Japanese Industrial Standard)와 같은 문자 세트에서 사용됩니다.

추가 참고

• 2-89페이지의 --locale=lang_country

• 2-93페이지의 --message_locale=lang_country[.codepage]

2.1.113 --multifile, --no_multifile

이 옵션을 사용하면 다중 파일 컴파일을 사용할 것인지 여부를 설정할 수 있습니다.

--multifile을 선택한 경우 컴파일러에서는 각 개별 파일 대신 명령 행에 지정된 모든 파일에 대해 최적화를 수행합니다. 지정한 파일은 단일 객체 파일로 컴파일됩니다.

결합된 객체 파일은 명령 행에 지정한 첫 번째 소스 파일의 이름을 사용합니다. 결합된 객체 파일에 다른 이름을 지정하려면 -o filename 옵션을 사용합니다.



표준 작성 시스템의 요구조건을 충족할 수 있도록 명령 행에 지정한 각 일련 소스 파일에 대해 빈 객체 파일이 만들어집니다.

참고

명령 행에 단일 소스 파일을 지정한 경우에는 --multifile을 사용하여 컴파일해도 아무 효과가 없습니다.

기본값

-O3 옵션을 지정하지 않은 경우 기본값은 --no_multifile입니다.

-O3 옵션을 지정한 경우 기본값은 --multifile입니다.

사용법

--multifile을 선택한 경우 컴파일러에서는 몇 개의 소스 파일을 컴파일하여 추가적인 최적화를 수행할 수도 있습니다.

명령 행에 지정할 수 있는 소스 파일 수에는 제한이 없지만 --multifile은 컴파일 동안에 많은 메모리를 필요로 하기 때문에 최대 10개의 파일이 가장 적합합니다. 최상의 최적화 결과를 얻으려면 동작과 관련된 소스 파일을 소규모로 선택합니다.

예제

armcc -c --multifile test1.c ... testn.c -o test.o

결과 객체 파일의 이름은 test1.c 대신 test.o로 지정되고, testn.o에 대한 빈 객체 파일 test2.o는 명령 행에 지정된 각 소스 파일 test1.c ... testn.c에 대해 만들어집니다.

추가 참고

• 2-22페이지의 -c

• 2-40페이지의 --default_extension=ext

• 2-91페이지의 --ltcg



• 2-143페이지의 --whole_program



2.1.114 --multiply_latency=cycles

이 옵션은 컴파일러에서 하드웨어 방식의 고속 곱셈기에 사용될 주기 수를 지정합니다.

구문

--multiply_latency=cycles

여기서 cycles는 사용 주기 수입니다.

사용법

이 옵션을 사용하여 컴파일러에 승수 블록과 관련 칩 일부를 사용하기 위한 MUL 명령어의 주기 수를 지정할 수 있습니다. MUL 명령어가 완료될 때까지 해당 칩 영역은 다른 명령어에서 사용할 수 없으며, 다른 명령어에서 해당 칩 영역을 사용하게 되면 이후 명령어에서 MUL 결과를 사용할 수 없습니다.

각 프로세서에서는 하드웨어 구현 방식별로 달리 설정된 여러 승수 옵션을 사용할 수 있습니다. 예를 들어 한 번의 주기로 실행되는 구현 방식을 하나 구성한 후, 다른 구현에서는 33번의 주기로 실행되도록 구성할 수 있습니다. 이 옵션은 특정 프로세서에 대해 알맞은 주기 수를 지정하는 데 사용됩니다.

예제

--multiply_latency=33

추가 참고

• Cortex™-M1 기술 참조 문서

2.1.115 --nonstd_qualifier_deduction, --no_nonstd_qualifier_deduction

이 옵션은 C++에서 정규화된 이름의 한정자 부분에서 비표준 템플릿 인수 추론을 수행할지 여부를 제어합니다.

이 기능을 사용하면 A<T>::B 또는 T::B 같은 문맥에서 템플릿 매개변수 T에 대해 템플릿 인수를 추론할 수 있습니다. 표준 추론 메커니즘에서는 이러한 문맥을 명시적으로 지정되었거나 다른 위치에 추론된 템플릿 매개변수 값을 사용하는 비추론 문맥으로 처리합니다.



참고

--nonstd_qualifier_deduction 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_nonstd_qualifier_deduction입니다.

2.1.116 -o filename

이 옵션은 출력 파일의 이름을 지정합니다. 생성되는 출력 파일의 전체 이름은 표 2-5 및 2-99페이지의 표 2-6에 설명된 대로 사용된 옵션 조합에 따라 달라집니다.

구문

-o 옵션을 지정하면 컴파일러에서는 표 2-5의 규칙에 따라 출력 파일 이름을 지정합니다.

표 2-5 -o 옵션을 사용하여 컴파일

컴파일러 옵션 동작 사용 참고 정보

-o- 표준 출력 스트림에 출력을 작성합니다. filename은 -입니다. -E를 지정하지 않으면 -S가 간주됩니다.

-o filename 이름이 filename인 실행 가능한 이미지를 생성합니다.



-o 옵션을 지정하지 않으면 컴파일러에서는 표 2-6의 규칙에 따라 출력 파일의 이름을 지정합니다.

참고

이 옵션은 --default_extension 옵션보다 우선합니다.

-c -o filename 이름이 filename인 객체 파일을 생성합니다.

-S -o filename 이름이 filename인 어셈블리 언어 파일을 생성합니다.

-E -o filename 이름이 filename이고 사전 처리기 출력을 포함하는 파일을 생성합니다.

표 2-6 -o 옵션 없이 컴파일


-c 파일 확장명이 .o인 입력 파일 이름을 기본값으로 사용하는 객체 파일을 생성합니다.

-S 파일 확장명이 .s인 입력 파일 이름을 기본값으로 사용하는 출력 파일을 생성합니다.

-E 사전 처리기의 출력을 표준 출력 스트림에 작성합니다.

(옵션 없음) 기본 이름이 __image.axf인 실행 가능한 이미지를 생성합니다.

명령 행에 -o, -c, -E 또는 -S 중에 어떤 것도 지정하지 않습니다.

표 2-5 -o 옵션을 사용하여 컴파일 (계속)




추가 참고


• 2-22페이지의 -c

• 2-40페이지의 --default_extension=ext



• 2-54페이지의 -E




• 2-119페이지의 -S

2.1.117 -Onum

이 옵션은 소스 파일 컴파일 시 사용할 최적화 수준을 지정합니다.

구문

-Onum

여기서 num은 다음 중 하나입니다.

0 최소 최적화입니다. 대부분의 최적화를 해제합니다. 최상의 디버그 뷰를 제공하는 반면 가장 낮은 수준의 최적화를 제공합니다.

1 제한적 최적화입니다. 사용하지 않는 인라인 함수 및 사용하지 않는 정적 함수를 제거합니다. 디버그 뷰를 심각하게 저하시키는 최적화를 해제합니다. --debug와 함께 사용할 경우 코드가 한결 간결해진 만족스러운 디버그 뷰가 제공됩니다.

2 높은 최적화. --debug와 함께 사용할 경우 소스 코드로의 객체 코드 매핑이 명확하지 않은 경우도 있기 때문에 다소 만족스럽지 않은 디버그 뷰가 제공될 수 있습니다.

이것이 기본 최적화 수준입니다.



3 최대 최적화입니다. -O3은 -O2와 동일한 최적화를 수행하지만 -O2와 비교하여 생성된 코드에서 공간 최적화와 시간 최적화 간에 균형을 이루지 못하고 공간 또는 시간 중 한 쪽에 더 큰 비중을 둡니다. 즉, 다음과 같습니다.

• -O3 -Otime은 이미지 크기가 증가되기는 하지만 -O2 -Otime보다 빠른 코드를 생성하기 위해 사용합니다.

• -O3 -Ospace는 -O2 -Ospace보다 작은 코드를 생성하기 위해 사용하지만 성능이 저하될 수 있습니다.

또한 -O3은 다음과 같은 보다 적극적인 최적화를 추가로 수행합니다.

• -O3 -Otime에 대해 루프 언롤링을 비롯한 고수준의 스칼라 최적화 코드 크기를 작게 작성하기 때문에 상당한 성능상의 장점이 있지만 빌드 시간이 더 길어집니다.

• -O3 -Otime에 대한 보다 적극적인 인라인 및 자동 인라인

• 다중 파일 컴파일 기본 수행

참고

--fpmode 옵션을 사용하여 특정 숫자 모델을 선택하는 경우 부동 소수점 코드의 성능에 영향을 줄 수 있습니다.

참고

이 최적화에 대한 구현 정보는 이후 릴리스에서 변경될 수 있으므로 신뢰하지 마십시오.

기본값

-Onum을 지정하지 않으면 컴파일러에서 -O2로 간주됩니다.

추가 참고




• 2-63페이지의 --fpmode=model


• 2-91페이지의 --ltcg




• -Ospace


• 컴파일러 사용 설명서의 5-2페이지의 코드 최적화

2.1.118 --old_specializations, --no_old_specializations

이 옵션은 C++에서 이전 스타일 템플릿 특수화의 허용 여부를 제어합니다.

이전 스타일 템플릿 특수화는 template<> 구문을 사용하지 않습니다.

참고

--old_specializations 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_old_specializations입니다.

2.1.119 -Ospace

이 옵션은 실행 시간이 늘어나더라도 이미지 크기를 줄이기 위한 최적화를 수행하도록 컴파일러에 지시합니다.

성능보다 코드 크기가 중요하다면 이 옵션을 지정하십시오. 예를 들어 -Ospace 옵션을 선택한 경우 인라인 코드 대신 라인 외부 함수 호출을 통해 대규모 구조체 복사가 수행됩니다.

필요한 경우 -Otime을 사용하여 코드 중에 시간이 중요한 부분을 컴파일할 수 있으며 -Ospace를 사용하여 나머지 부분을 컴파일할 수 있습니다.

기본값

-Ospace 또는 -Otime 옵션을 지정하지 않으면 컴파일러에서 -Ospace로 간주됩니다.



추가 참고

• -Otime


• 4-68페이지의 #pragma Onum

• 4-69페이지의 #pragma Ospace

• 4-69페이지의 #pragma Otime

2.1.120 -Otime

이 옵션은 이미지 크기가 커지더라도 실행 시간을 줄이기 위한 최적화를 수행하도록 컴파일러에 지시합니다.

코드 크기보다 실행 시간이 중요하다면 이 옵션을 지정하십시오. 필요한 경우 -Otime을 사용하여 코드 중에 시간이 중요한 부분을 컴파일할 수 있으며 -Ospace를 사용하여 나머지 부분을 컴파일할 수 있습니다.

기본값

-Otime을 지정하지 않으면 컴파일러에서 -Ospace로 간주됩니다.

예제

-Otime 옵션을 선택한 경우 컴파일러에서는 다음을

while (expression) body;

아래와 같이 컴파일합니다.

if (expression){ do body; while (expression);}

추가 참고




• 4-68페이지의 #pragma Onum

• 4-69페이지의 #pragma Ospace

• 4-69페이지의 #pragma Otime



2.1.121 --parse_templates, --no_parse_templates

이 옵션을 사용하면 C++에서 템플릿을 정의하고 인스턴스화하기 전에 일반 형식의 비클래스 템플릿을 구문 분석할 것인지 여부를 설정할 수 있습니다.

참고

--no_parse_templates 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --parse_templates입니다.

참고

--no_parse_templates 옵션은 종속적 이름 처리를 사용할 수 있는 경우에 구문 분석이 이루어지기 때문에 --dep_name 옵션과 함께 사용할 수 없습니다. 이러한 옵션을 함께 사용하면 오류가 생성됩니다.

추가 참고

• 2-40페이지의 --dep_name, --no_dep_name

• 5-16페이지의 템플릿 인스턴스화.

2.1.122 --pch

이 옵션은 기존 PCH 파일을 사용하도록 하며 PCH 파일이 없는 경우에는 PCH 파일을 작성하여 사용하도록 컴파일러에 지시합니다.

--pch 옵션을 지정한 경우 컴파일러에서는 이름 filename.pch를 사용하여 PCH 파일을 검색하며 여기서 filename.*은 기본 소스 파일의 이름입니다. 컴파일러에서는 PCH 파일 filename.pch가 있으면 그대로 사용하고 없는 경우에는 기본 소스 파일과 같은 이름의 디렉토리에 PCH 파일 filename.pch를 만듭니다.



제한

동일한 명령 행에 --use_pch=filename 옵션 또는 --create_pch=filename 옵션을 포함하면 이 옵션은 아무런 효과가 없습니다.

추가 참고

• 2-36페이지의 --create_pch=filename

• --pch_dir=dir







2.1.123 --pch_dir=dir

이 옵션을 사용하면 PCH 파일이 저장된 디렉토리를 지정할 수 있습니다. 지정된 디렉토리는 PCH 파일을 만들거나 사용할 때마다 액세스됩니다.

이 옵션은 자동 또는 수동 PCH 모드에서 사용할 수 있습니다.

구문

--pch_dir=dir

인수 설명:

dir PCH 파일이 저장된 디렉토리의 이름입니다.

오류

지정한 디렉토리 dir이 없으면 컴파일러에서 오류를 생성합니다.

추가 참고











2.1.124 --pch_messages, --no_pch_messages

이 옵션을 사용하면 현재 컴파일에서 PCH 파일이 사용되고 있음을 나타내는 메시지를 표시할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --pch_messages입니다.

추가 참고




• --pch_verbose, --no_pch_verbose





2.1.125 --pch_verbose, --no_pch_verbose

이 옵션을 사용하면 파일을 사전 컴파일할 수 없는 이유를 나타내는 메시지를 표시할 것인지 여부를 설정할 수 있습니다.

자동 PCH 모드에서 이 옵션을 지정하면 현재 컴파일에 사용할 수 없는 각 PCH 파일에 대해 해당 파일을 사용할 수 없는 이유를 설명하는 메시지가 표시됩니다.

기본값

기본값은 --no_pch_verbose입니다.



추가 참고









2.1.126 --pending_instantiations=n

이 옵션은 C++에서 템플릿의 최대 동시 인스턴스화 수를 지정합니다.

구문

--pending_instantiations=n

인수 설명:

n 허용된 최대 동시 인스턴스화 수입니다.

n이 0이면 제한이 없어집니다.

모드


기본값

--pending_instantations 옵션을 지정하지 않으면 컴파일러에서 --pending_instantiations=64로 간주됩니다.

사용법

이 옵션을 사용하여 재귀 인스턴스화를 검색합니다.



2.1.127 --phony_targets

이 옵션은 더미 메이크파일 규칙을 내보내도록 컴파일러에 지시합니다. 이 규칙은 메이크파일을 적절히 수정하지 않고 헤더 파일을 제거할 경우 발생되는 make 오류를 해결하는 데 사용됩니다.

이 옵션은 GCC 명령 행 옵션의 -MP와 유사합니다.

예제

예제 출력:

source.o: source.csource.o: header.hheader.h:

추가 참고






• 2-92페이지의 -M


2.1.128 --pointer_alignment=num

이 옵션은 응용 프로그램에 필요한 정렬되지 않은 포인터 지원을 지정합니다.

구문

--pointer_alignment=num

여기서 num은 다음 중 하나입니다.

1 포인터를 통한 액세스를 1바이트 정렬 또는 정렬되지 않은 것으로 처리합니다.

2 포인터를 통한 액세스를 2바이트 정렬(하프워드 정렬)로 처리합니다.



4 포인터를 통한 액세스를 4바이트 정렬(워드 정렬)로 처리합니다

8 포인터를 통한 액세스를 기본 정렬(더블워드 정렬)로 처리합니다.

사용법

이 옵션을 사용하면 정렬할 필요가 없는 아키텍처에 대해 작성된 소스 코드를 이식할 수 있습니다. __packed 한정자를 사용하면 생성된 코드의 품질에 영향을 덜 주면서 정렬되지 않은 데이터에 대한 액세스를 보다 정밀하게 제어할 수 있습니다.

제한

비정렬 포인터는 정렬되지 않은 액세스를 지원하는 CPU에서도 코드 크기를 증가시킬 수 있습니다. 이는 로드 및 저장 명령어의 하위 세트만이 정렬되지 않은 액세스 지원을 활용할 수 있기 때문입니다. 컴파일러에서는 하드웨어 부동 소수점 로드 및 저장을 비롯하여 정렬되지 않은 메모리 객체에 다중 워드 전송이나 보조 프로세서 메모리 전송을 직접 사용할 수 없습니다.

참고

• 정렬되지 않은 액세스를 지원하는 pre-v6 아키텍처와 같은 하드웨어가 없는 CPU에 대해 컴파일하는 경우 코드 크기가 상당히 증가될 수 있습니다.

• 이 옵션은 메모리의 객체 배치 또는 구조체의 레이아웃 및 패딩에는 영향을 주지 않습니다.

추가 참고

• 4-12페이지의 __packed

• 4-69페이지의 #pragma pack(n)

• 컴파일러 사용 설명서의 5-26페이지의 데이터 정렬



2.1.129 --preinclude=filename

이 옵션은 컴파일 초기에 지정된 파일의 소스 코드를 포함하도록 컴파일러에 지시합니다.

구문

--preinclude=filename

인수 설명:

filename 포함할 소스 코드가 있는 파일의 이름입니다.

사용법

이 옵션을 사용하여 표준 매크로 정의를 작성할 수 있습니다. filename은 include 검색 목록의 디렉토리에서 검색됩니다.

이 옵션은 명령 행에서 중복 지정할 수 있습니다. 중복 지정하게되면 지정된 순서에 따라 파일이 미리 포함됩니다.

예제

armcc --preinclude file1.h --preinclude file2.h -c source.c

추가 참고








2.1.130 --preprocessed

이 옵션은 사전 처리기에서 확장자가 .i인 파일을 매크로에 의해 변경되는 것처럼 처리하도록 합니다.

사용법

이 옵션을 통해 다양한 사전 처리기를 사용할 수 있습니다. 사전 처리된 코드를 생성한 다음 --preprocessed를 사용하여 filename.i 파일 형식으로 사전 처리된 코드를 컴파일러로 보내 해당 파일은 이미 사전 처리되었음을 알립니다.

제한

이 옵션은 매크로에만 적용됩니다. 3중 음자, 행 연결, 주석을 비롯하여 기타 모든 사전 처리 항목은 사전 처리기에 의해 정상적인 방법으로 처리됩니다.

--compile_all_input을 사용할 경우 .i 파일은 .c 파일로 간주됩니다. 사전 처리기는 이전에 사전 처리 작업을 하지 않은 것으로 간주합니다.

예제

armcc --preprocessed foo.i -c -o foo.o

추가 참고

• 2-25페이지의 --compile_all_input, --no_compile_all_input

• 2-54페이지의 -E

2.1.131 --profile=filename

이 옵션은 ARM Profiler의 피드백을 사용하여 크기는 더 작고 성능은 우수한 코드를 생성하도록 컴파일러에 지시합니다.

구문

--profile=filename

인수 설명:

filename ARM Profiler 분석 파일의 이름입니다.



예제

이 예제에서는hello.c에 대해 코드를 생성할 때 hello_001.apa에 제공되는 ARM Profiler 피드백을 사용합니다.

armcc -c -O3 -Otime --profile=hello_001.apa hello.c

추가 참고

• ARM Profiler 사용 설명서

2.1.132 --project=filename, --no_project=filename

--project=filename 옵션은 컴파일러에서 filename에 의해 지정된 프로젝트 템플릿 파일을 로드하도록 합니다.

참고

기본 프로젝트 파일로 filename을 사용하려면 RVDS_PROJECT 환경 변수를 filename으로 설정합니다.

--no_project 옵션은 RVDS_PROJECT 환경 변수에서 지정한 기본 프로젝트 템플릿 파일이 사용되지 않도록 합니다.

구문

--project=filename

--no_project

인수 설명:

filename 프로젝트 템플릿 파일의 이름입니다.

제한

프로젝트 템플릿 파일의 옵션은 명령 행에 미리 설정된 옵션과 충돌하지 않는 경우에만 설정됩니다. 프로젝트 템플릿 파일의 옵션이 기존 명령 행 옵션과 충돌하지 않는 경우 명령 행 옵션이 우선합니다.


예제

다음은 프로젝트 템플릿 파일의 예제입니다.

<suiteconf name="Platform Baseboard for ARM926EJ-S">

<tool name="armcc"><cmdline>

--cpu=ARM926EJ-S--fpu=vfpv2

</cmdline></tool>

</suiteconf>

RVDS_PROJECT 환경 변수가 이 파일을 가리키도록 설정하면

armcc -c foo.c

명령은 아래의 명령 행과 같은 결과를 생성합니다.

armcc --cpu=ARM926EJ-S --fpu=VFPv2 -c foo.c

추가 참고

• 2-115페이지의 --reinitialize_workdir

• 2-144페이지의 --workdir=directory

2.1.133 --reassociate-saturation

이 옵션은 포화 더하기가 사용되는 벡터화 루프에서 포화 산술의 재연관을 허용함으로써 한층 더 강화된 최적화를 수행합니다.

제한

포화 더하기가 연관되지 않는 루프에서 재연관을 허용하게 되면 결과의 정확도가 떨어질 수 있습니다.

예제

--reassociate-saturation이 지정되지 않으면 다음 코드는 벡터화되지 않습니다.

#include <dspfns.h>int f(short *a, short *b){

int i;int r = 0;for (i = 0; i < 100; i++)


r=L_mac(r,a[i],b[i]);return r;

}

2.1.134 --reduce_paths, --no_reduce_paths

이 옵션을 사용하면 파일 경로에서 중복 경로 이름 정보를 제거할 것인지 여부를 설정할 수 있습니다.

중복 경로 이름 정보 제거를 사용하는 경우 컴파일러에서는 운영 체제에 전달된 디렉토리 경로에서 xyz\.. 형식의 시퀀스를 제거합니다. 여기에는 #include 검색에 대한 것처럼 컴파일러 자체에서 생성한 시스템 경로가 포함됩니다.

참고

xyz가 링크인 경우에는 xyz\.. 형식의 시퀀스 제거가 이루어지지 않을 수 있습니다.

모드

이 옵션은 Windows 시스템에서만 유효합니다.

사용법

Windows 시스템에서는 파일 경로에 대해 260자의 제한이 있습니다. 절대 이름이 260자가 넘는 상대 경로 이름이 있는 경우 --reduce_paths 옵션을 사용하여 디렉토리를 ..의 해당 인스턴스와 일치시키고 directory/.. 시퀀스를 쌍으로 제거하여 절대 경로 이름 길이를 줄일 수 있습니다.

참고

--reduce_paths 옵션을 사용하여 경로 길이를 최소화하는 것보다는 중첩 수준이 높고 긴 파일 경로를 사용하지 않는 것이 좋습니다.

기본값

기본값은 --no_reduce_paths입니다.

예제

컴파일할 파일:

..\..\..\xyzzy\xyzzy\objects\file.c



대상 디렉토리:

\foo\bar\baz\gazonk\quux\bop

위의 파일을 컴파일하면 실제 경로는 다음과 같습니다.

\foo\bar\baz\gazonk\quux\bop\..\..\..\xyzzy\xyzzy\objects\file.o

option --reduce_paths 옵션을 사용하여 동일한 디렉토리에서 동일한 파일을 컴파일하는 경우 실제 경로는 다음과 같습니다.

\foo\bar\baz\xyzzy\xyzzy\objects\file.c

2.1.135 --reinitialize_workdir

이 옵션을 사용하면 --workdir을 사용하여 프로젝트 템플릿 작업 디렉토리 설정을 다시 초기화할 수 있습니다.

--workdir을 사용하여 설정한 디렉토리가 수정된 프로젝트 템플릿 파일이 있는 기존 작업 디렉토리를 가리키는 경우 이 옵션을 지정하면 작업 디렉토리가 삭제되고 원래 프로젝트 템플릿 파일의 새 사본과 함께 다시 만들어집니다.

제한

이 옵션은 --workdir 옵션과 함께 사용해야 합니다.

추가 참고

• 2-112페이지의 --project=filename, --no_project=filename

• 2-144페이지의 --workdir=directory

2.1.136 --relaxed_ref_def, --no_relaxed_ref_def

이 옵션은 여러 객체 파일이 전역 변수의 임시 정의를 사용하도록 허용합니다. 일부 기존 프로그램은 선언 스타일을 사용하여 작성됩니다.

사용법

이 옵션은 기본적으로 GNU C와의 호환성을 위해 제공되며, 새 응용 프로그램 코드에는 사용하지 않는 것이 좋습니다.



기본값

기본값은 엄격한 참조 및 정의입니다. 각 전역 변수는 하나의 객체 파일에만 선언할 수 있습니다. 그러나 명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_gcc를 사용하면 기본값이 --relaxed_ref_def가 됩니다.

제한

이 옵션은 C++에서는 사용할 수 없습니다.

추가 참고




• Rationale for International Standard - Programming Languages - C

2.1.137 --remarks

이 옵션은 구조체 내의 패딩에 대한 경고 같은 설명 메시지를 생성하도록 컴파일러에 지시합니다.

참고

컴파일러에서는 기본적으로 설명 메시지를 생성하지 않습니다.

추가 참고








• 2-141페이지의 -W




2.1.138 --restrict, --no_restrict

이 옵션을 사용하면 C99 키워드 제한을 사용할 것인지 여부를 설정할 수 있습니다.

참고

restrict와 동일한 기능을 가진 대체 키워드 __restrict 및 __restrict__도 지원됩니다. --restrict 옵션의 사용 여부와 관계없이 이 두 키워드는 항상 사용 가능합니다.

기본값

ISO C99 소스 코드를 컴파일하는 경우 기본적으로 C99 키워드 restrict가 설정되어 있습니다.

ISO C90 또는 ISO C++ 소스 코드를 컴파일하는 경우 기본적으로 C99 키워드 restrict가 해제되어 있습니다.

추가 참고

• 3-9페이지의 restrict.

2.1.139 --retain=option

이 옵션을 사용하면 컴파일러가 수행하는 최적화를 제한할 수 있습니다. 이 옵션은 확인, 디버깅 및 적용 테스트를 수행할 때 유용할 수 있습니다.

구문

--retain=option

여기서 option은 다음 중 하나입니다.

fns 사용하지 않는 함수 제거를 방지합니다.

inlinefns 사용하지 않는 인라인 함수 제거를 방지합니다.

noninlinefns 사용하지 않는 인라인이 아닌 함수 제거를 방지합니다.

paths a||b가 a|b로 변환되는 것과 같은 경로 제거 최적화를 방지합니다. 이렇게 하면 MCDC(Modified Condition Decision Coverage) 테스트가 지원됩니다.



calls 인라인 또는 마무리 호출을 통해 호출이 제거되지 않도록 방지합니다.

calls:distinct

교차 분기(일반 마무리 경로 병합)를 통해 호출이 병합되지 않도록 방지합니다.

libcalls 인라인 확장 등을 통해 라이브러리 함수가 제거되지 않도록 방지합니다.

data 데이터가 제거되지 않도록 방지합니다.

rodata 읽기 전용 데이터가 제거되지 않도록 방지합니다.

rwdata 읽기-쓰기 데이터가 제거되지 않도록 방지합니다.

data:order 데이터가 재정렬되지 않도록 방지합니다.

추가 참고

• 4-37페이지의 __attribute__((nomerge))

• 4-39페이지의 __attribute__((notailcall))

2.1.140 --rtti, --no_rtti

이 옵션은 C++에서 RTTI 기능 dynamic_cast 및 typeid에 대한 지원을 제어합니다.

모드


기본값

기본값은 --rtti입니다.

추가 참고

• 2-53페이지의 --dllimport_runtime, --no_dllimport_runtime.



2.1.141 -S

이 옵션은 컴파일러에 의해 생성된 기계어 코드의 디스어셈블리를 파일로 출력하도록 컴파일러에 지시합니다.

그러나 --asm 옵션과 달리 객체 모듈은 생성되지 않습니다. 어셈블리 출력 파일 이름의 기본값은 현재 디렉토리의 filename.s이며 여기서 filename은 앞에 있는 디렉토리 이름을 제거한 소스 파일의 이름입니다. -o 옵션을 사용하여 기본 파일 이름을 재정의할 수 있습니다.

armasm을 사용하여 출력 파일을 어셈블하고 객체 코드를 생성할 수 있습니다. 컴파일러에서는 AAPCS 변형 및 바이트 순서와 같은 명령 행 옵션에 ASSERT 지시어를 추가하여 출력을 다시 어셈블할 때 호환 가능한 컴파일러 및 어셈블러 옵션을 사용할 수 있도록 합니다. 어셈블러와 컴파일러 모두에 동일한 AAPCS 설정을 지정해야 합니다.

추가 참고



• 2-22페이지의 -c

• 2-77페이지의 --info=totals




• 어셈블러 설명서

2.1.142 --shared

이 옵션을 사용하면 --arm_linux_paths 옵션으로 ARM Linux용 빌드를 수행할 때 공유 라이브러리를 생성할 수 있습니다. 또한 ARM Linux 구성을 기반으로 공유 라이브러리에 사용하기에 적합한 라이브러리 및 초기화 코드를 선택할 수 있습니다.

제한

이 옵션은 --arm_linux_paths 및 --apcs=/fpic와 함께 사용해야 합니다.



예제

두 객체 파일(obj1.o 및 obj2.o)을 공유 라이브러리(libexample.o)에 연결합니다.

armcc --arm_linux_paths --arm_linux_config_file=my_config_file --shared -o libexample.so obj1.o obj2.o

추가 참고


















2.1.143 --show_cmdline

이 옵션은 명령 행 옵션이 어떻게 처리되는지를 보여 줍니다.

명령은 기본 형식으로 표시되고 via 파일의 내용은 확장됩니다.

추가 참고

• 2-2페이지의 -Aopt

• 2-81페이지의 -Lopt



• 2-139페이지의 --via=filename

2.1.144 --signed_bitfields, --unsigned_bitfields

이 옵션은 int 유형의 비트 필드를 부호 있는 유형 또는 부호 없는 유형으로 지정합니다.

C 표준에서는 비트 필드 선언에 사용된 유형 지정자가 int 또는 int로 정의된 typedef 이름인 경우 비트 필드에 대한 부호 지정 여부는 구현에 따라 달라집니다.

기본값

기본값은 --unsigned_bitfields입니다. 그러나 명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_gcc 또는 --tranlsate_g++를 사용하면 기본값이 --signed_bitfields가 됩니다.

참고

ARM에서 비트 필드를 기본적으로 부호 없는 유형으로 지정하는 데 필요한 AAPCS 요구조건이 표준 버전 2.03에서는 완화되었습니다.

예제

typedef int integer;struct{

integer x : 1;} bf;

--signed_bitfields를 사용하여 이 코드를 컴파일하면 부호 있는 비트 필드로 처리됩니다.

추가 참고


• 2-12페이지의 --arm_linux_configure.

2.1.145 --signed_chars, --unsigned_chars

이 옵션은 char 유형을 부호 있는 유형 또는 부호 없는 유형으로 설정합니다.

char에 부호가 있으면 컴파일러에서 __FEATURE_SIGNED_CHAR 매크로를 정의합니다.



참고

이 옵션의 사용 여부와 상관없이 컴파일된 변환 단위와 인터페이스 또는 데이터 구조체를 공유하는 변환 단위를 혼합할 때는 주의해야 합니다.

ARM ABI는 char를 부호 없는 바이트로 정의하며 이는 RVCT와 함께 제공되는 C++ 라이브러리에서 사용하는 해석입니다.

기본값

기본값은 --unsigned_chars입니다.

추가 참고

• 4-123페이지의 사전 정의된 매크로.

2.1.146 --split_ldm

이 옵션은 LDM 및 STM 명령어를 두 개 이상의 LDM 또는 STM 명령어로 분할하도록 컴파일러에 지시합니다.

--split_ldm을 선택한 경우 LDM 또는 STM 명령어에 대한 레지스터 전송의 최대 수는 다음과 같이 제한됩니다.

• 모든 STM의 경우 5

• PC를 로드하지 않는 LDM의 경우 5

• PC를 로드하는 LDM의 경우 4

이러한 제한 이상의 레지스터 전송이 필요한 곳에서는 여러 개의 LDM 또는 STM 명령어가 사용됩니다.

사용법

--split_ldm 옵션을 사용하여 다음과 같은 ARM 시스템에서 인터럽트 지연을 줄일 수 있습니다.

• 캐시 또는 작성 버퍼가 없는 시스템(예: 캐시가 없는 ARM7TDMI)

• 대기 상태가 없는 32비트 메모리를 사용하는 시스템

참고

--split_ldm을 사용하면 코드 크기가 커지고 성능이 약간 저하됩니다.



제한

• --split_ldm을 사용할 경우 인라인 어셈블러 LDM 및 STM 명령어는 기본적으로 분할됩니다. 그러나 이후에 컴파일러에서 분할된 명령어를 LDM 또는 STM으로 다시 결합할 수 있습니다.

• --split_ldm을 사용할 경우 LDM 또는 STM 명령어만 분할됩니다.

• --split_ldm을 사용하여 코드를 빌드해도 일부 타겟 하드웨어는 혜택을 받지 못합니다. 예를 들면 다음과 같습니다.

— 캐시된 시스템 또는 작성 버퍼가 있는 프로세서의 경우 별다른 이점이 없습니다.

— 메모리 대기 상태가 0이 아닌 시스템 또는 주변 장치가 느린 시스템의 경우 이점이 없습니다. 이런 시스템의 인터럽트 지연은 가장 느린 메모리 또는 주변 장치 액세스에 필요한 주기 수에 따라 결정됩니다. 일반적으로 이것은 다중 레지스터 전송으로 발생한 지연보다 훨씬 깁니다.

추가 참고

• 컴파일러 사용 설명서의 7-10페이지의 명령어 확장

2.1.147 --split_sections

이 옵션은 소스 파일에 있는 각 함수에 대해 ELF 섹션을 하나씩 생성하도록 컴파일러에 지시합니다.

출력 섹션에는 해당 섹션을 생성하는 함수의 이름에 접두사 i.가 추가된 형태로 이름이 지정됩니다.

참고

별도의 섹션에 특정 데이터 항목 또는 구조체를 배치하려면 __attribute__((section(...)))를 사용하여 따로따로 만듭니다.

사용하지 않는 함수를 제거하려면 이 옵션보다는 링커 피드백 최적화를 사용하는 것이 좋습니다. 링커 피드백은 모든 섹션을 분할하는 오버헤드를 방지하여 더 작은 코드를 생성하기 때문입니다.



제한

이 옵션은 함수 간에 주소, 데이터 및 문자열 리터럴을 공유할 가능성을 줄입니다. 그 결과 일부 함수의 코드 크기가 약간 커질 수 있습니다.

예제

int f(int x){

return x+1;}

--split_sections를 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

AREA ||i.f||, CODE, READONLY, ALIGN=2f PROC

ADD r0,r0,#1BX lrENDP

추가 참고

• 2-38페이지의 --data_reorder, --no_data_reorder

• 2-59페이지의 --feedback=filename





2.1.148 --strict, --no_strict

이 옵션은 사용하는 선택 소스 언어에 따라 엄격한 C 또는 엄격한 C++를 엄격하게 적용하거나 완화합니다.

--strict를 선택하면 다음과 같은 결과가 생성됩니다.

• ISO C 또는 ISO C++와 충돌하는 기능은 사용할 수 없게 됩니다.

• 비표준 기능을 사용할 경우 오류 메시지가 반환됩니다.

기본값

기본값은 --no_strict입니다.



사용법

--strict를 사용하면 다음 사항을 준수해야 합니다.

ISO C90 • C에 대한 ISO/IEC 9899:1990, 1990 국제 표준

• ISO/IEC 9899 AM1, 1995 Normative Addendum 1

ISO C99 C에 대한 ISO/IEC 9899:1999, 1999 국제 표준

ISO C++ C에 대한 ISO/IEC 14822:2003, 2003 국제 표준

오류

--strict 사용 중에 관련 ISO 표준 위반이 발생하면 컴파일러에서 오류 메시지를 생성합니다.

진단 메시지 수준은 일반적인 방식으로 제어할 수 있습니다.

예제

void foo(void){

long long i; /* okay in nonstrict C90 */}

--strict를 사용하여 이 코드를 컴파일하면 오류가 생성됩니다.

추가 참고

• 2-23페이지의 --c90

• 2-23페이지의 --c99





• 컴파일러 사용 설명서의 1-4페이지의 소스 언어 모드



2.1.149 --strict_warnings

--strict 모드에서 오류가 발생한 진단은 가능할 경우 경고로 다운그레이드됩니다. 프로그램 복구가 규칙에 어긋나는 컴파일러와 같이 strict 오류를 다운그레이드할 수 없는 컴파일러도 있습니다.

오류

--strict_warnings 사용 중에 관련 ISO 표준 위반이 발생하면 일반적으로 컴파일러에서 경고 메시지를 생성합니다.

진단 메시지 수준은 일반적인 방식으로 제어할 수 있습니다.

참고

심각한 위반 사항이 발견되는 경우 경우에 따라서 컴파일러는 경고 대신에 오류 메시지를 생성하고 컴파일을 종료합니다. 예를 들면 다음과 같습니다.

#ifdef $Super$extern void $Super$$__aeabi_idiv0(void); /* intercept __aeabi_idiv0 */#endif

--dollar 옵션을 사용하지 않는 경우 --strict_warnings를 사용하여 이 코드를 컴파일하면 오류가 생성됩니다.

예제

void foo(void){

long long i; /* okay in nonstrict C90 */}

--strict_warnings를 사용하여 이 코드를 컴파일하면 경고 메시지가 생성됩니다.

long long 식이 심각한 위반 사항에 해당되더라도 컴파일을 계속 수행합니다.



추가 참고



• 2-23페이지의 --c90

• 2-23페이지의 --c99




2.1.150 --sys_include

이 옵션은 include 검색 경로에서 현재 위치를 제거합니다.

인용부호로 묶은 include 파일은 -I로 지정한 디렉토리에서 항상 첫 번째로 검색되고 각괄호로 묶은 include 파일은 -J 디렉토리에서 첫 번째로 검색되는 것을 제외하고는 인용부호로 묶은 include 파일과 각괄호로 묶은 include 파일은 비슷한 방식으로 처리됩니다.

추가 참고





• 컴파일러 사용 설명서의 2-15페이지의 현재 위치

• 컴파일러 사용 설명서의 2-16페이지의 검색 경로

2.1.151 --thumb

이 옵션은 Thumb 명령어 세트를 타겟으로 하도록 컴파일러를 구성합니다.

기본값

이것은 ARM 명령어 세트를 지원하지 않는 타겟의 기본 옵션입니다.



추가 참고



• 4-75페이지의 #pragma thumb

• 컴파일러 사용 설명서의 2-24페이지의 타겟 프로세서 또는 아키텍처 지정

• 컴파일러 사용 설명서의 5-4페이지의 타겟 CPU 선택

2.1.152 --translate_g++

이 옵션을 사용하면 GNU 도구에서 명령 행을 변환할 수 있도록 하여 C++ 모드에서 GNU 컴파일러를 에뮬레이션할 수 있습니다.

사용법

이 옵션을 사용하여 다음 중 하나를 제공할 수 있습니다.

• ARM Linux를 타겟으로 하는 전체 GCC 에뮬레이션

• 개별 GCC 명령 행 인수를 해당 RVCT 항목으로 변환하는 형식의 전체 GCC 에뮬레이션 하위 세트

전체 ARM Linux GCC 에뮬레이션을 제공하려면 --arm_linux_config_file도 사용해야 합니다. 이 옵션 조합은 구성 파일에 지정된 해당 GNU 헤더 파일 및 라이브러리를 선택하며 일부 기본 동작에 대한 변경 사항을 포함합니다.

전체 GCC 에뮬레이션을 목표로 하지 않고 GCC 명령 행 인수를 해당 RVCT 항목으로 변환하려면 --translate_g++를 사용하여 g++를 에뮬레이션하되, 이 옵션을 --arm_linux_config_file과 함께 사용하지는 마십시오. 이 방식에서는 전체 GCC 에뮬레이션을 목표로 하지 않으므로 RVCT 기본 동작이 유지되며 ARM Linux를 타겟으로 지정하기 위한 기본값이 설정되지 않습니다. RVCT 라이브러리 경로 및 옵션은 기본적으로 변경되지 않고 그대로 유지됩니다.

제한

명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_g++를 사용하면 --exceptions와 --no_exceptions, --bss_threshold, --relaxed_ref_def와 --no_relaxed_ref_def 및 --signed_bitfields와 --unsigned_bitfields의 기본 설정이 변경됩니다.



추가 참고





• 2-21페이지의 --bss_threshold=num








• 2-115페이지의 --relaxed_ref_def, --no_relaxed_ref_def











2.1.153 --translate_gcc

이 옵션을 사용하면 GNU 도구에서 명령 행을 변환할 수 있도록 하여 gcc를 에뮬레이션할 수 있습니다.

사용법


• ARM Linux를 타겟으로 하는 전체 GCC 에뮬레이션

• 개별 GCC 명령 행 인수를 해당 RVCT 항목으로 변환하는 형식의 전체 GCC 에뮬레이션 하위 세트

전체 GCC 에뮬레이션을 제공하려면 arm_linux_config_file도 사용해야 합니다. 이 옵션 조합은 구성 파일에 지정된 해당 GNU 헤더 파일 및 라이브러리를 선택하며 일부 기본 동작에 대한 변경 사항을 포함합니다.

전체 GCC 에뮬레이션을 목표로 하지 않고 개별 GCC 명령 행 인수를 해당 RVCT 항목으로 변환하려면 --translate_gcc를 사용하여 gcc를 에뮬레이션하되, 이 옵션을 --arm_linux_config_file과 함께 사용하지는 마십시오. 이 방식에서는 전체 GCC 에뮬레이션을 목표로 하지 않으므로 RVCT 기본 동작이 유지되며 ARM Linux를 타겟으로 지정하기 위한 기본값이 설정되지 않습니다. RVCT 라이브러리 경로 및 옵션은 기본적으로 변경되지 않고 그대로 유지됩니다.

제한

명령 행에서 ARM Linux 구성 파일을 지정하는 경우 --translate_gcc를 사용하면 --bss_threshold, --relaxed_ref_def와 --no_relaxed_ref_def 및 --signed_bitfields와 --unsigned_bitfields의 기본 설정이 변경됩니다.

추가 참고













• 2-115페이지의 --relaxed_ref_def, --no_relaxed_ref_def




• --translate_gld





2.1.154 --translate_gld

이 옵션을 사용하면 GNU 도구에서 명령 행을 변환할 수 있도록 하여 GNU ld를 에뮬레이션할 수 있습니다.

사용법


• ARM Linux를 타겟으로 하는 전체 GNU ld 에뮬레이션

• 개별 GNU ld 명령 행 인수를 해당 RVCT 항목으로 변환하는 형식의 전체 GNU ld 에뮬레이션 하위 세트

전체 GNU ld 에뮬레이션을 제공하려면 arm_linux_config_file도 사용해야 합니다. 이 옵션 조합은 구성 파일에 지정된 해당 GNU 헤더 파일 및 라이브러리를 선택하며 일부 기본 동작에 대한 변경 사항을 포함합니다.

전체 GNU ld 에뮬레이션을 목표로 하지 않고 개별 GNU ld 명령 행 인수를 해당 RVCT 항목으로 변환하려면 --translate_gld를 사용하여 GNU ld를 에뮬레이션하되, 이 옵션을 --arm_linux_config_file과 함께 사용하지는 마십시오. 이 방식에서는 전체 GNU ld 에뮬레이션을 목표로 하지 않으므로 RVCT 기본 동작이 유지되며 ARM Linux를 타겟으로 지정하기 위한 기본값이 설정되지 않습니다. RVCT 라이브러리 경로 및 옵션은 기본적으로 변경되지 않고 그대로 유지됩니다.



참고

• --translate_gld는 사용 시 GNU 링커인 것처럼 armcc를 호출합니다. 이는 GNU 링커를 직접 포함하는 기존 빌드 스크립트에만 사용됩니다.

• gcc 및 g++ 모드에서 armcc는 --translate_gld를 사용하여 자기 자신을 사용 중인 링커로 보고합니다. 예를 들어 gcc -print-file-name=ld입니다.

추가 참고




















2.1.155 --trigraphs, --no_trigraphs

이 옵션을 사용하면 3중음자 인식을 사용할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --trigraphs입니다. 단, GNU 모드에서는 기본값이 --no_trigraphs입니다.

추가 참고

• ISO/IEC 9899:TC2

2.1.156 -Uname

이 옵션은 name 매크로의 모든 초기 정의를 제거합니다.

name 매크로는 다음 중 하나일 수 있습니다.

• 사전 정의된 매크로

• -D 옵션을 사용하여 지정한 매크로

참고

컴파일러에서 사전 정의된 모든 매크로의 정의를 해제할 수는 없습니다.

구문

-Uname

인수 설명:

name 정의 해제할 매크로의 이름입니다.

사용법

-Uname을 지정하는 것은 #undef name 텍스트를 각 소스 파일의 헤드에 배치하는 것과 같은 효과를 제공합니다.



제한

컴파일러에서는 다음 순서에 따라 매크로를 정의하고 정의 해제합니다.

1. 컴파일러에서 사전 정의된 매크로

2. -Dname을 사용하여 명시적으로 정의된 매크로

3. -Uname을 사용하여 명시적으로 정의 해제된 매크로

추가 참고

• 2-23페이지의 -C

• 2-37페이지의 -Dname[(parm-list)][=def]

• 2-54페이지의 -E

• 2-92페이지의 -M


2.1.157 --unaligned_access, --no_unaligned_access

이 옵션을 사용하면 ARM 아키텍쳐 기반 프로세서에서 데이터에 대해 정렬되지 않은 액세스를 사용할 것인지 여부를 설정할 수 있습니다.

기본값

데이터에 대해 정렬되지 않은 액세스를 지원하는 ARM 아키텍쳐 기반 프로세서의 경우 기본값은 --unaligned_access입니다. 해당되는 프로세서는 다음과 같습니다.

• ARMv6 아키텍처 기반의 모든 프로세서

• ARMv7-A 및 ARMv7-R 아키텍쳐 기반의 프로세서

데이터에 대해 정렬되지 않은 액세스를 지원하지 않는 ARM 아키텍쳐 기반 프로세서의 경우 기본값은 --no_unaligned_access입니다. 해당되는 프로세서는 다음과 같습니다.

• ARMv6 이전 아키텍처 기반의 모든 프로세서

• ARMv7-M 아키텍처 기반의 프로세서



사용법

--unaligned_access

--cpu=ARM1136J-S와 같이 데이터에 대해 정렬되지 않은 액세스를 지원하는 프로세서에 --unaligned_access를 사용하여 패킹된 구조체에 대한 액세스 속도를 증가시킵니다.

정렬되지 않은 지원을 사용하려면 다음과 같은 작업을 수행해야 합니다.

• 초기화 코드에서 CP15 레지스터 1의 A 비트 및 비트 1을 지워야 합니다.

• 초기화 코드에서 CP15 레지스터 1의 U 비트 및 비트 22를 설정해야 합니다.

U 비트의 초기값은 코어에 대한 UBITINIT 입력에 의해 결정됩니다.

RVCT 라이브러리에는 정렬되지 않은 액세스를 검색하도록 설계된 특정 라이브러리 함수의 특수 버전이 포함되어 있습니다. 정렬되지 않은 액세스 지원이 설정된 경우 RVCT 도구는 이러한 라이브러리 함수를 사용하여 정렬되지 않은 액세스를 이용합니다.

--no_unaligned_access

--no_unaligned_access를 사용하여 ARMv6 프로세서에서 정렬되지 않은 워드 및 하프워드 액세스의 생성을 해제합니다.

정렬되지 않은 액세스를 사용하지 않고 ARMv6 타겟에 대한 모듈로 4바이트 정렬 검사를 사용하려면 다음과 같은 작업을 수행해야 합니다.

• 초기화 코드에서 CP15 레지스터 1의 A 비트 및 비트 1을 설정해야 합니다.

• 초기화 코드에서 CP15 레지스터 1의 U 비트 및 비트 22를 설정해야 합니다.

U 비트의 초기값은 코어에 대한 UBITINIT 입력에 의해 결정됩니다.

참고

long long 정수에 대한 정렬되지 않은 액세스와 같이 정렬되지 않은 더블워드 액세스는 ARM 프로세서 코어에서 지원하지 않습니다. 더블워드 액세스는 8바이트 또는 4바이트로 정렬되어야 합니다.



컴파일러에서는 모듈로 8바이트 정렬 검사를 지원하지 않습니다. 즉, CP15 레지스터 1의 구성 U = 0 및 A = 1은 컴파일러에서 지원하지 않으며 RVCT 도구 세트에서는 더욱 더 일반적입니다.

RVCT 라이브러리에는 정렬되지 않은 액세스를 검색하도록 설계된 특정 라이브러리 함수의 특수 버전이 포함되어 있습니다. 정렬되지 않은 액세스 지원이 해제된 경우 이러한 향상된 라이브러리 함수가 사용되지 않도록 하려면 C 및 C++ 소스 파일의 조합과 어셈블리 언어 소스 파일을 컴파일할 때 컴파일러 명령 행과 어셈블러 명령 행 모두에 --no_unaligned_access를 지정해야 합니다.

제한

데이터에 대해 정렬되지 않은 액세스를 지원하는 프로세서를 위해 컴파일된 코드는 소프트웨어에서 선택한 정렬 지원과 프로세서 코어에서 선택한 정렬 지원이 일치하는 경우에만 올바르게 실행됩니다.

추가 참고


• 어셈블러 설명서의 3-2페이지의 명령 구문

• 개발자 설명서의 2-13페이지의 정렬 지원

2.1.158 --use_pch=filename

이 옵션은 지정된 이름을 갖는 PCH 파일을 현재 컴파일의 일부로 사용하도록 컴파일러에 지시합니다.

동일한 명령 행에 --pch를 포함하는 경우 이 옵션이 우선합니다.

구문

--use_pch=filename

인수 설명:

filename 현재 컴파일의 일부로 사용할 PCH 파일입니다.

제한

동일한 명령 행에 --create_pch=filename을 포함하면 이 옵션을 지정해도 영향을 주지 않습니다.



오류

지정한 파일이 없거나 잘못된 PCH 파일인 경우 컴파일러에서 오류를 생성합니다.

추가 참고







2.1.159 --using_std, --no_using_std

이 옵션을 사용하면 C++에 표준 헤더 파일이 포함된 경우 std 네임스페이스를 암시적으로 사용할 것인지 여부를 설정할 수 있습니다.

참고

이 옵션은 C++ 표준을 준수하지 않는 레거시 소스 코드에 대한 마이그레이션 지원용으로만 제공됩니다. 이 옵션은 사용하지 않는 것이 좋습니다.

모드


기본값

기본값은 --no_using_std입니다.

추가 참고

• 5-17페이지의 네임스페이스.



2.1.160 --vectorize, --no_vectorize

이 옵션을 사용하면 C 또는 C++ 코드에서 직접 NEON 벡터 명령 생성 여부를 설정할 수 있습니다.

기본값

기본값은 --no_vectorize입니다.

제한

다음 옵션은 벡터화할 루프에 지정되어야 합니다

--cpu=name 타겟 프로세스에 NEON 기능이 포함되어야 합니다.

-Otime 실행 시간을 줄이기 위한 최적화 유형입니다.

-Onum 최적화 수준으로 다음 중 하나를 사용해야 합니다.

• -O2 높은 최적화. 기본값입니다.

• -O3 최대 최적화

참고

NEON은 ARM Advanced SIMD(Single Instruction, Multiple Data) Extension을 구현한 것입니다.

벡터화를 사용하려면 별도의 FLEXnet 라이센스가 필요합니다. 이 라이센스는 RVDS 4.0 Professional과 함께 제공됩니다.

예제

armcc --vectorize --cpu=Cortex-A8 -O3 -Otime -c file.c

추가 참고






2.1.161 --vfe, --no_vfe

이 옵션을 사용하면 C++에서 VFE(가상 함수 제거)를 사용할 것인지 여부를 설정할 수 있습니다.

VFE는 코드에서 사용되지 않은 가상 함수를 제거합니다. VFE를 사용하면 컴파일러에서는 접두사가 .arm_vfe_인 특수 섹션에 정보를 배치합니다. 이러한 섹션은 나머지 코드에서 참조되지 않기 때문에 VFE를 인식하지 않는 링커에 의해 무시됩니다. 그러므로 실행 파일 크기가 증가되지 않습니다. 그러나 객체 파일의 크기는 증가됩니다.

모드


기본값

RVCT 버전 2.1 이전의 컴파일러로 컴파일된 레거시 객체 파일에 VFE 정보가 없는 경우를 제외하고 --vfe가 기본값입니다.

추가 참고

• C-4페이지의 순수 가상 함수의 호출

• 링커 사용 설명서의 3-12페이지의 사용하지 않는 가상 함수 제거

2.1.162 --via=filename

이 옵션은 지정된 파일에서 추가 명령 행 옵션을 읽도록 컴파일러에 지시합니다. 이 옵션은 현재 명령에 추가된 파일에서 읽습니다.

Via 명령은 via 파일에 중첩될 수 있습니다.

구문

--via=filename

인수 설명:

filename 명령 행에 포함될 옵션을 포함하고 있는 via 파일의 이름입니다.



예제

소스 파일 main.c, 다음 행을 포함하는 via 파일 apcs.txt,

--apcs=/rwpi --no_lower_rwpi --via=L_apcs.txt

다음 행을 포함하는 두 번째 via 파일 L_apcs.txt가 있다고 했을 때

-L--rwpi -L--callgraph

다음 명령 행을 사용하여 main.c를 컴파일합니다.

armcc main.c -L-o” main.axf" --via=apcs.txt

다음 명령 행을 사용하여 main.c를 컴파일합니다.

armcc --no_lower_rwpi --apcs=/rwpi -L--rwpi -L--callgraph -L-o"main.axf" main.c

추가 참고

• 부록 A via 파일 구문

• 컴파일러 사용 설명서의 2-12페이지의 파일에서 컴파일러 옵션 읽기

2.1.163 --vla, --no_vla

이 옵션을 사용하면 변수 길이 배열에 대한 지원을 사용할 것인지 여부를 설정할 수 있습니다.

기본값

C90 및 표준 C++에서는 기본적으로 변수 길이 배열을 지원하지 않습니다. C90 또는 표준 C++에서 변수 길이 배열을 지원하려면 --vla 옵션을 선택합니다.

변수 길이 배열은 표준 C와 GNU 컴파일러 확장 모두에서 지원됩니다. 소스 언어가 C99이거나 --gnu 옵션이 지정된 경우 --vla 옵션이 암시적으로 선택됩니다.

예제

size_t arr_size(int n){

char array[n]; // variable length array, dynamically allocatedreturn sizeof array; // evaluated at runtime

}



추가 참고

• 2-23페이지의 --c90

• 2-23페이지의 --c99



2.1.164 --vsn

이 옵션은 버전 정보 및 라이센스 세부 사항을 표시합니다.

추가 참고

• 2-73페이지의 --help.

2.1.165 -W

이 옵션은 모든 경고 메시지를 표시하지 않도록 컴파일러에 지시합니다.

추가 참고










2.1.166 --wchar, --no_wchar

이 옵션을 사용하여 wchar_t의 사용을 허용 또는 금지할 수 있습니다. 단, 사용되지 않아도 오류로 선언하지 않습니다.

사용법

이 옵션을 사용하여 wchar_t 크기와 독립적인 객체 파일을 만들 수 있습니다.



제한

--no_wchar가 지정된 경우 다음과 같은 제한이 있습니다.

• 구조체 선언에 wchar_t 필드가 있으면 해당 구조체의 사용 여부와 관계 없이 컴파일러에 의해 오류로 처리됩니다.

• typedef에 wchar_t가 있으면 해당 typedef의 사용 여부에 관계 없이 컴파일러에 의해 오류로 처리됩니다.

기본값

기본값은 --wchar입니다.

추가 참고

• --wchar16

• 2-143페이지의 --wchar32.

2.1.167 --wchar16

이 옵션은 wchar_t의 유형을 부호 없는 short로 변경합니다.

이 옵션을 선택하면 C에서 정의된 wchar_t 유형과 C++의 네이티브 유형 wchar_t의 유형이 모두 수정됩니다. 또한 WCHAR_MIN 및 WCHAR_MAX의 값에도 영향을 미칩니다.

기본값

--wchar32를 명시적으로 지정하지 않으면 컴파일러에서 --wchar16으로 간주됩니다.

추가 참고

• 2-141페이지의 --wchar, --no_wchar


• 4-123페이지의 사전 정의된 매크로



2.1.168 --wchar32

이 옵션은 wchar_t의 유형을 부호 없는 int로 변경합니다.

이 옵션을 선택하면 C에서 정의된 wchar_t 유형과 C++의 네이티브 유형 wchar_t의 유형이 모두 수정됩니다. 또한 WCHAR_MIN 및 WCHAR_MAX의 값에도 영향을 미칩니다.

기본값

--wchar32를 명시적으로 지정하거나 명령 행에서 ARM Linux 구성 파일을 지정하는 경우가 아니면 컴파일러는 --wchar16을 간주합니다. 명령 행에서 ARM Linux 구성 파일을 지정하면 --wchar32가 설정됩니다.

추가 참고



• 2-141페이지의 --wchar, --no_wchar


• 4-123페이지의 사전 정의된 매크로.

2.1.169 --whole_program

이 옵션은 명령 행에 명시된 소스 파일이 전체 프로그램을 형성한다는 원칙을 컴파일러에 지정합니다. 컴파일러는 이 원칙에 근거하여 보이는 소스 코드가 컴파일할 전체 프로그램이라고 판단하여 최적화를 적용할 수 있습니다. 전체 프로그램을 구성하는 소스 코드를 모를 경우 컴파일러에서 코드에 최적화를 적용하는 데 제한이 있습니다.

사용법

이 옵션을 사용하면 작은 프로그램에 대해 성능을 극대화할 수 있습니다.

제한

컴파일러에 전체 소스 코드를 알려줄 수 없는 경우에는 이 옵션을 사용하지 마십시오.

추가 참고

• 2-96페이지의 --multifile, --no_multifile.



2.1.170 --workdir=directory

이 옵션을 사용하면 프로젝트 템플릿의 작업 디렉토리를 제공할 수 있습니다.

참고

프로젝트 템플릿은 RVD 구성 파일과 같은 파일을 포함하는 경우에만 작업 디렉토리를 필요로 합니다.

구문

--workdir=directory

인수 설명:

directory 프로젝트 디렉토리의 이름입니다.

제한

--workdir을 사용하여 프로젝트 작업 디렉토리를 지정할 경우 --project를 사용하여 프로젝트 파일을 지정해야 합니다.

오류

--workdir 없이 --project를 사용할 경우 오류 메시지가 생성되며 --workdir이 있어야 합니다.

추가 참고

• 2-112페이지의 --project=filename, --no_project=filename

• 2-115페이지의 --reinitialize_workdir.

2.1.171 --wrap_diagnostics, --no_wrap_diagnostics

이 옵션을 사용하면 오류 메시지 텍스트가 너무 길어 한 행에 맞지 않는 경우 다음 행으로 이어지는 기능을 사용할 것인지 여부를 설정할 수 있습니다.

기본값

기본값은 --no_wrap_diagnostics입니다.



추가 참고









• 2-141페이지의 -W



3장 언어 확장

이 장에서는 ARM 컴파일러가 지원하는 다음과 같은 언어 확장에 대해 설명합니다.

• 3-2페이지의 사전 처리기 확장

• 3-5페이지의 C90에서 사용할 수 있는 C99 언어 기능


• 3-10페이지의 표준 C 언어 확장

• 3-16페이지의 표준 C++ 언어 확장

• 3-20페이지의 표준 C 및 표준 C++ 언어 확장


ARM 컴파일러에 대한 참조 자료를 더 보려면 추가로 다음을 참조하십시오.



• 부록 D C 및 C++ 컴파일러 구현 한계


언어 확장

3.1 사전 처리기 확장

ARM 컴파일러는 System V 릴리스 4의 #assert 사전 처리 확장을 비롯하여 사전 처리기에 대한 여러 가지 확장을 지원합니다.

3.1.1 #assert

System V 릴리스 4의 #assert 사전 처리 확장이 허용됩니다. 이 확장을 통해 조건자 이름을 정의 및 테스트할 수 있습니다.

조건자 이름은 매크로 이름을 비롯한 다른 모든 이름과 구별되는 네임스페이스에 있습니다.

구문

#assert name

#assert name[(token-sequence)]

인수 설명:

name 조건자 이름입니다.

token-sequence 선택적 토큰 시퀀스입니다.

토큰 시퀀스를 생략하면 name에 값이 주어지지 않습니다.

토큰 시퀀스를 포함하면 name에 값 token-sequence가 주어집니다.

예제

#assert를 사용하여 정의된 조건자 이름은 #if 식에서 테스트할 수 있습니다. 예를 들면 다음과 같습니다.

#if #name(token-sequence)

여기서 이름이 name인 #assert에 토큰 시퀀스 token-sequence가 포함된 경우 값은 1이고, 그렇지 않으면 0입니다. 주어진 조건자에는 지정된 시점에 둘 이상의 값이 주어질 수 있습니다.

추가 참고

• 3-3페이지의 #unassert.


언어 확장

3.1.2 #include_next

이 사전 처리기 지시어는 #include 지시어의 변형입니다. 이 지시어는 현재 소스 파일이 있는 디렉토리 다음에 오는 검색 경로의 디렉토리에서 명명된 파일, 즉 #include_next 지시어를 포함하는 파일만 검색합니다.

참고

이 사전 처리기 지시어는 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

3.1.3 #unassert

조건자 이름은 #unassert 사전 처리 지시어를 사용하여 삭제할 수 있습니다.

구문

#unassert name

#unassert name[(token-sequence)]

인수 설명:

name 조건자 이름입니다.

token-sequence 선택적 토큰 시퀀스입니다.

토큰 시퀀스를 생략하면 name의 모든 정의가 제거됩니다.

토큰 시퀀스를 포함하면 지정된 정의만 제거됩니다. 다른 모든 정의는 그대로 유지됩니다.

추가 참고

• 3-2페이지의 #assert.


언어 확장

3.1.4 #warning

사전 처리 지시어 #warning이 지원됩니다. #error 지시어처럼 이 지시어는 컴파일 시 사용자 정의 경고를 생성합니다. 하지만 컴파일을 중단시키지는 않습니다.

제한

--strict 옵션을 지정하면 #warning 지시어를 사용할 수 없습니다. 이 지시어를 사용하면 오류가 발생합니다.

추가 참고



언어 확장

3.2 C90에서 사용할 수 있는 C99 언어 기능

컴파일러는 ISO C90 표준에 대한 여러 가지 확장(예: C99 스타일의 // 주석)을 지원합니다.

이러한 확장은 소스 언어가 C90이고 엄격하지 않은 모드에서 컴파일하는 경우에 사용할 수 있습니다.

소스 언어가 C90이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 C90을 컴파일하도록 제한되어 있는 경우에는 이 확장을 사용할 수 없습니다.

참고

표준 C 및 표준 C++의 언어 기능(예: C++ 스타일의 // 주석)은 이 단원에서 설명하는 C90 언어 확장과 유사할 수 있습니다. --strict 컴파일러 옵션을 사용하여 엄격한 표준 C 또는 엄격한 표준 C++를 컴파일하는 경우에는 이러한 기능을 계속 사용할 수 있습니다.

3.2.1 // 주석

// 문자 시퀀스는 C99 또는 C++에서처럼 1라인 주석을 시작합니다.

C90에서 사용되는 // 주석의 의미는 C99에서 사용되는 // 주석의 의미와 동일합니다.

예제

// this is a comment

추가 참고

• 컴파일러 사용 설명서의 5-47페이지의 C99의 새로운 기능


언어 확장

3.2.2 struct 첨자화

C90에서 lvalues가 아닌 배열은 포인터로 변하여 첨자화될 수 있습니다. 그러나 다음 시퀀스 지점 이후에는 배열을 수정하거나 사용하면 안 됩니다. 단항 & 연산자를 배열에 사용하지 마십시오. 이런 종류의 배열은 C90에서 첨자화될 수 있지만 C99 모드가 아닐 경우 포인터로 변하지 않습니다.

예제

struct Subscripting_Struct{

int a[4];};extern struct Subscripting_Struct Subscripting_0(void);int Subscripting_1 (int index){ return Subscripting_0().a[index];}

3.2.3 유연한 배열 구성원

struct의 마지막 구성원에게는 불완전한 배열 유형이 지정될 수 있습니다. 마지막 구성원이 struct의 유일한 구성원이 되어서는 안 됩니다. 그렇게 되면 struct의 크기가 0이 됩니다.

예제

typedef struct{ int len; char p[]; // incomplete array type, for use in a malloced data structure} str;

추가 참고



언어 확장

3.3 C++ 및 C90에서 사용할 수 있는 C99 언어 기능

ARM 컴파일러는 ISO C++ 표준 및 C90 언어에 대한 여러 가지 확장(예: 구식 비 프로토타입 정의를 재정의하는 함수 프로토타입)을 지원합니다.

이러한 확장은 다음과 같은 경우에 사용할 수 있습니다.

• 소스 언어가 C++이고 엄격하지 않은 모드에서 컴파일하는 경우

• 소스 언어가 C90이고 엄격하지 않은 모드에서 컴파일하는 경우

이러한 확장은 다음과 같은 경우에 사용할 수 없습니다.

• 소스 언어가 C++이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 C90을 컴파일하도록 제한되어 있는 경우

• 소스 언어가 C90이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 표준 C를 컴파일하도록 제한되어 있는 경우

참고

표준 C의 언어 기능(예: long long 정수)은 이 단원에서 설명하는 언어 확장과 유사할 수 있습니다. --strict 컴파일러 옵션을 사용하여 엄격한 표준 C++ 또는 엄격한 C90을 컴파일하는 경우에는 이러한 기능을 계속 사용할 수 있습니다.

3.3.1 가변성 매크로

C90 및 C++에서는 매크로를 선언하여 가변적인 개수의 인수를 취할 수 있습니다.

C90 및 C++에서 가변성 매크로를 선언하는 구문은 --gnu 옵션을 선택하지 않을 경우 C99의 가변성 매크로 선언 구문을 따릅니다. --gnu 옵션을 지정할 경우에는 GNU의 가변성 매크로 구문을 따릅니다.

예제

#define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)void variadic_macros(void){ debug ("a test string is printed out along with %x %x %x\n", 12, 14, 20);}


언어 확장

추가 참고



3.3.2 long long

ARM 컴파일러는 유형 지정자 long long 및 unsigned long long을 통해 64비트 정수 유형을 지원합니다. 이 유형은 일반 산술 변환에 대해 long 및 unsigned long과 유사하게 동작합니다. __int64는 long long의 동의어입니다.

정수 상수에는 다음이 포함될 수 있습니다.

• 적합한 경우 long long, 적합하지 않은 경우 unsigned long long으로 상수 유형을 강제 지정하는 ll 접미사

• unsigned long long으로 상수 유형을 강제 지정하는 ull 또는 llu 접미사

printf() 및 scanf()의 형식 지정자에는 %lld 또는 %llu에서와 같이 다음 변환이 long long 인수에 적용되도록 지정하기 위해 ll을 포함할 수 있습니다.

또한 값이 너무 클 경우에는 일반 정수 상수의 유형이 long long 또는 unsigned long long입니다. 변경을 알려 주는 경고 메시지가 컴파일러에서 발생합니다. 예를 들어 2147483648의 유형은 엄격한 1990 ISO 표준 C에서는 unsigned long이고 ARM C 및 C++에서는 long long입니다. 이 결과 중 하나는 다음과 같은 식의 값입니다.

2147483648 > –1

이 식은 엄격한 C 및 C++에서는 0으로 평가되고 ARM C 및 C++에서는 1로 평가됩니다.

long long 유형은 일반 산술 변환에서 사용됩니다.

추가 참고

• 4-10페이지의 __int64


언어 확장

3.3.3 restrict

restrict 키워드는 다양한 객체 포인터 유형과 함수 매개변수 배열이 메모리의 중복 영역을 가리키지 않도록 해 주는 C99 기능입니다. 따라서 컴파일러의 최적화 작업이 별칭 지정 가능성 때문에 방지되지 않고 자유롭게 수행됩니다.

제한

C90 또는 C++에서 restrict 키워드를 사용하려면 --restrict 옵션을 지정해야 합니다.

키워드 __restrict 및 __restrict__는 restrict의 동의어로 지원되며 --restrict 지정 여부에 상관없이 항상 사용할 수 있습니다.

예제

void copy_array(int n, int *restrict a, int *restrict b){ while (n-- > 0) *a++ = *b++;}

추가 참고

• 2-119페이지의 --restrict, --no_restrict


3.3.4 16진수 부동 소수점 숫자

C90 및 C++는 16진수 형식으로 작성할 수 있는 부동 소수점 숫자를 지원합니다.

예제

float hex_floats(void){

return 0x1.fp3; // 1.55e1}

추가 참고



언어 확장

3.4 표준 C 언어 확장

ARM 컴파일러는 ISO C99 표준에 대한 여러 가지 확장(예: 구식 비 프로토타입 정의를 재정의하는 함수 프로토타입)을 지원합니다.




이 확장의 어떤 것도 다음과 같은 경우에 사용할 수 없습니다.

• 소스 언어가 C90이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 C90을 컴파일하도록 제한되어 있는 경우

• 소스 언어가 C99이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 표준 C를 컴파일하도록 제한되어 있는 경우

• 소스 언어가 C++인 경우

3.4.1 상수 식

확장된 상수 식이 이니셜라이저에서 지원됩니다. 다음 예제는 기본값인 --strict_warnings 및 --strict 컴파일러 모드에 대한 컴파일러의 동작을 보여 줍니다.

예제 1, 변수 주소 할당

코드에는 파일 범위에서 변수의 주소를 할당하는 상수 식을 포함할 수 있습니다. 예를 들면 다음과 같습니다.

int i;int j = (int)&i; /* but not allowed by ISO */

C에 대해 컴파일할 경우 다음과 같은 동작이 발생합니다.

• 기본 모드에서는 경고가 발생합니다.

• --strict_warnings 모드에서는 경고가 발생합니다.

• --strict 모드에서는 오류가 발생합니다.


언어 확장

예제 2, 상수 값 이니셜라이저

다음 예제에는 C 코드에 상수 값이 포함된 식을 사용할 경우의 컴파일러 동작이 요약되어 있습니다.

/* Std RVCT v3.1 */extern int const c = 10; /* ok ok */extern int const x = c + 10; /* error ext */static int y = c + 10; /* error ext */static int const z = c + 10; /* error ext */extern int *const cp = (int*)0x100; /* ok ok */extern int *const xp = cp + 0x100; /* error ext */static int * yp = cp + 0x100; /* error ext */static int *const zp = cp + 0x100; /* error ext */

ISO C 표준(Std)에 정의된 동작과 RVCT의 동작으로 구분되어 있습니다.

• ok는 문이 모든 C 모드에서 허용된다는 것을 의미합니다.

• ext는 ISO C 표준의 확장입니다. 이 동작은 C를 컴파일할 때 사용되는 엄격한 모드에 따라 다릅니다.

엄격하지 않음

허용됨, 경고 없음

--strict_warnings

허용됨, 경고 있음

--strict

ISO C 표준 준수, 오류 발생

추가 참고

• 2-59페이지의 --extended_initializers, --no_extended_initializers




언어 확장

3.4.2 배열 및 포인터 확장

다음 배열 및 포인터 확장이 지원됩니다.

• 할당 및 포인터 차이는 상호 교환되지만 동일하지 않은 유형, 예를 들어 unsigned char * 및 char * 같은 유형에 대한 포인터 사이에서 허용됩니다. 여기에는 int *와 long * 같은 동일한 크기의 정수 유형에 대한 포인터도 포함됩니다. 경고가 발생합니다.

모든 종류의 문자에 대한 포인터에 문자열 상수를 할당할 수 있으며 이 경우 경고가 발생하지 않습니다.

• 대상 유형이 최상위 수준이 아닌 유형 한정자를 추가한 경우에는 포인터 유형을 할당할 수 있습니다. 예를 들어 int **를 const int **에 할당할 수 있습니다. 이러한 포인터 유형 쌍의 비교 및 포인터 차이도 허용됩니다. 경고가 발생합니다.

• 포인터에 대한 연산에서 void에 대한 포인터는 필요할 경우 항상 다른 유형으로 암시적으로 변환됩니다. 또한 null 포인터 상수는 필요할 경우 언제나 정확한 유형의 null 포인터로 암시적으로 변환됩니다. ISO C에서 일부 연산자는 이를 허용하고 일부 연산자는 허용하지 않습니다.

• 서로 다른 함수 유형에 대한 포인터를 명시적 유형 캐스트 없이 할당하고 동등성(==) 또는 비동등성(!=)을 비교할 수 있습니다. 경고 또는 오류가 발생합니다.

이 확장은 C++ 모드에서 금지됩니다.

• void에 대한 포인터를 포인터와 함수 유형 간에 암시적으로 변환할 수 있습니다.

• 이니셜라이저에서 포인터 상수 값은 정수 값이 포인터 상수 값을 포함할 정도로 클 경우 정수 유형으로 캐스트될 수 있습니다.

• 비 lvalue 배열 식은 첨자화되거나 이와 유사하게 사용될 경우 배열의 첫 번째 요소에 대한 포인터로 변환됩니다.


언어 확장

3.4.3 블록 범위 함수 선언

다음과 같이 블록 범위 함수 선언에 대한 두 가지 확장이 지원됩니다.

• 블록 범위 함수 선언도 파일 유효 범위에서 함수 이름을 선언할 수 있습니다.

• 블록 범위 함수 선언에는 정적 스토리지 클래스가 포함될 수 있으므로 기본적으로 결과 선언에 내부 연결이 포함됩니다.

예제

void f1(void){

static void g(void); /* static function declared in local scope *//* use of static keyword is illegal in strict ISO C */

}void f2(void){

g(); /* uses previous local declaration */}static void g(int i){ } /* error - conflicts with previous declaration of g */

3.4.4 식별자에 사용되는 달러 부호

식별자에 달러 부호($)를 사용할 수 있습니다.

참고

--strict 옵션으로 컴파일할 때 --dollar 명령 행 옵션을 사용하면 식별자에 달러 부호를 사용할 수 있습니다.

예제

#define DOLLAR$

추가 참고

• 2-53페이지의 --dollar, --no_dollar



언어 확장

3.4.5 최상위 수준의 선언

C 입력 파일에는 최상위 수준의 선언이 포함될 수 없습니다.

오류

C 입력 파일에 최상위 수준의 선언이 포함되지 않는 경우 설명이 표시됩니다.

참고

설명은 기본적으로 표시되지 않습니다. 설명 메시지를 표시하려면 컴파일러 옵션 --remarks를 사용합니다.

추가 참고


3.4.6 재선언

typedef 이름의 재선언이 허용됩니다. 즉, typedef 이름은 동일한 유형으로 동일한 유효 범위에서 재선언될 수 있습니다.

예제

typedef int INT;typedef int INT; /* redeclaration */


언어 확장

3.4.7 외부 엔터티

다른 유효 범위에서 선언된 외부 엔터티가 표시됩니다.

오류

다른 유효 범위에서 선언된 외부 엔터티가 표시되면 컴파일러에서 경고를 생성합니다.

예제

void f1(void){

extern void f();}void f2(void){

f(); /* Out of scope declaration */}

3.4.8 함수 프로토타입

컴파일러는 다음과 같이 코드의 후반부에 나타나는 구식 비 프로토타입 정의를 재정의하는 함수 프로토타입을 인식합니다.

오류

구식 함수 프로토타입을 사용하면 컴파일러에서 경고 메시지를 생성합니다.

예제

int function_prototypes(char);// Old-style function definition.int function_prototypes(x) char x;{ return x == 0;}


언어 확장

3.5 표준 C++ 언어 확장

ARM 컴파일러는 ISO C++ 표준에 대한 여러 가지 확장(예: 클래스 구성원 선언의 정규화된 이름)을 지원합니다.

이러한 확장은 소스 언어가 C++이고 엄격하지 않은 모드에서 컴파일하는 경우에 사용할 수 있습니다.

소스 언어가 C++이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 표준 C++를 컴파일하도록 제한되어 있는 경우에는 이 확장을 사용할 수 없습니다.

3.5.1 ? 연산자

두 번째 및 세 번째 피연산자가 문자열 리터럴이거나 넓은 문자열 리터럴인 ? 연산자는 char * 또는 wchar_t *로 암시적으로 변환될 수 있습니다. C++에서 문자열 리터럴은 const입니다. 문자열 리터럴을 char * 또는 wchar_t *로 변환하게 하여 const를 삭제하는 암시적 변환이 있습니다. 그러나 이 변환은 단순한 문자열 리터럴에만 적용됩니다. ? 연산의 결과에 이러한 변환을 허용하는 것이 확장입니다.

예제

char *p = x ? "abc" : "def";

3.5.2 클래스 구성원의 선언

클래스 구성원 선언 시 정규화된 이름을 사용할 수 있습니다.

오류

클래스 구성원 선언 시 정규화된 이름이 사용되면 경고가 발생합니다.

예제

struct A{ int A::f(); // is the same as int f();};


언어 확장

3.5.3 friend

class에 대한 friend 선언에서는 클래스 키워드를 생략할 수 있습니다.

액세스 확인은 기본적으로 friend 선언에 대해 실행되지 않습니다. --strict 명령 행 옵션을 사용하여 강제로 액세스 확인을 수행하십시오.

예제

class B;class A{ friend B; // is the same as "friend class B"};

추가 참고


3.5.4 상수 읽기/쓰기

외부 상수에 대한 연결 지정은 상수가 동적으로 초기화되거나 가변 구성원을 포함할 수 있음을 나타냅니다.

참고

"C++:read/write" 연결은 --apcs /rwpi로 컴파일한 코드에서만 사용해야 합니다. 이 옵션을 사용하여 기존 코드를 다시 컴파일할 경우 동적으로 초기화되거나 가변 구성원을 포함할 수 있는 외부 상수에 대해 연결 지정을 변경해야 합니다.

--apcs /rwpi 옵션을 사용하여 C++를 컴파일하는 것은 ISO C++ 표준에서 벗어납니다. 예제 3-1의 선언은 x가 읽기 전용 세그먼트에 있다고 가정합니다.

예제 3-1 외부 액세스

extern const T x;extern "C++" const T x;extern "C" const T x;


언어 확장

x(사용자 정의 생성자 포함)의 동적 초기화는 상수에서 불가능하며 T는 가변 구성원을 포함할 수 없습니다. 예제 3-2의 새 연결 지정에서는 x가 상수를 사용하여 초기화되었더라도 읽기/쓰기 세그먼트에 있음을 선언합니다. x의 동적 초기화가 허용되며 T는 가변 구성원을 포함할 수 있습니다. x, y 및 z 정의에 대한 연결 지정은 다른 파일에서도 서로 동일해야 합니다.

예제 3-2 연결 지정

extern const int z; /* in read-only segment, cannot *//* be dynamically initialized */

extern "C++:read/write" const int y; /* in read/write segment *//* can be dynamically initialized */

extern "C++:read/write"{ const int i=5; /* placed in read-only segment, */

/* not extern because implicitly static */ extern const T x=6; /* placed in read/write segment */ struct S

{ static const T T x; /* placed in read/write segment */ };}

상수 객체는 다른 연결과 함께 다시 선언하지 마십시오. 예제 3-3의 코드에 컴파일 오류가 발생합니다.

예제 3-3 컴파일러 오류

extern "C++" const T x;extern "C++:read/write" const T x; /* error */

참고

C에는 연결 지정이 없으므로 C++에서 선언된 const 객체를 C의 extern "C++:read/write"로 사용할 수 없습니다.

추가 참고



언어 확장

3.5.5 스칼라 유형 상수

스칼라 유형의 상수는 클래스 내에서 정의될 수 있지만 이는 이전 형식입니다. 현재 형식은 초기화된 정적 데이터 구성원을 사용합니다.

오류

클래스 내에서 상수 정수 유형의 구성원을 정의하면 경고가 발생합니다.

예제

class A{ const int size = 10; // must be static const int size = 10; int a[size];};

3.5.6 비구성원 함수 템플릿의 특수화

비구성원 함수 템플릿의 특수화 과정에서 하나의 확장으로 스토리지 클래스를 지정할 수 있습니다.

3.5.7 유형 변환

extern "C" 함수에 대한 포인터와 extern "C++" 함수에 대한 포인터 사이의 유형 변환이 허용됩니다.

예제

extern "C" void f(); // f’ s type has extern "C" linkagevoid (*pf)() = &f; // pf points to an extern "C++" function

// error unless implicit conversion is allowed


언어 확장

3.6 표준 C 및 표준 C++ 언어 확장

ARM 컴파일러는 ISO C99 표준과 ISO C++ 표준 모두에 대한 여러 가지 확장(예: 다양한 정수 유형 확장, 다양한 부동 소수점 확장, 16진수의 부동 소수점 상수와 익명 클래스, 구조체 및 공용체)을 지원합니다.


• 소스 언어가 C++이고 엄격하지 않은 모드에서 컴파일하는 경우



이러한 확장은 다음과 같은 경우에 사용할 수 없습니다.

• 소스 언어가 C++이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 C++를 컴파일하도록 제한되어 있는 경우

• 소스 언어가 C99이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 표준 C를 컴파일하도록 제한되어 있는 경우

• 소스 언어가 C90이고 컴파일러가 --strict 컴파일러 옵션을 사용하여 엄격한 C90을 컴파일하도록 제한되어 있는 경우

3.6.1 레지스터 변수의 주소

register 스토리지 클래스의 변수 주소를 가져올 수 있습니다.

오류

register 스토리지 클래스를 사용하여 변수 주소를 가져오면 컴파일러에서 경고를 생성합니다.

예제

void foo(void){

register int i;int *j = &i;

}


언어 확장

3.6.2 인수 대 함수

최상위 수준의 함수 선언 이외에서 함수 매개 변수에 대한 기본 인수를 지정할 수 있습니다. 예를 들어 typedef 선언과 함수에 대한 포인터 및 구성원 함수에 대한 포인터 선언에서 기본 인수를 지정할 수 있습니다.

3.6.3 익명 클래스, 구조체 및 공용체

익명 클래스, 구조체 및 공용체는 확장으로 지원됩니다. 익명 구조체 및 공용체는 C와 C++에서 지원됩니다.

익명 공용체는 기본적으로 C++에서 사용할 수 있습니다. 하지만 다음을 사용하려면 anon_unions pragma를 지정해야 합니다.

• C에서 익명 공용체 및 구조체

• C++에서 익명 클래스 및 구조체

익명 공용체는 포함 클래스에 typedef 이름으로 추가될 수 있습니다. 진정한 익명 공용체와 달리 직접 선언할 필요가 없습니다. 예를 들면 다음과 같습니다.

typedef union{ int i, j;} U; // U identifies a reusable anonymous union.#pragma anon_unionsclass A{ U; // Okay -- references to A::i and A::j are allowed.};

또한 확장에 따라 C++ 기능이 없는 익명 클래스 및 익명 구조체를 사용할 수 있습니다. 예를 들어 익명 클래스 및 익명 구조체에 정적 데이터 구성원이나 구성원 함수, 비공개 구성원, 중첩된 유형(익명 클래스, 구조체 또는 공용체 제외)은 사용할 수 없습니다. 예를 들면 다음과 같습니다.

#pragma anon_unionsstruct A{ struct

{ int i, j; }; // Okay -- references to A::i and A::j are allowed.};


언어 확장

추가 참고

• 3-34페이지의 명명되지 않은 필드

• 4-59페이지의 #pragma anon_unions, #pragma no_anon_unions.

3.6.4 어셈블러 레이블

어셈블러 레이블은 C 기호에 사용할 어셈블러 이름을 지정합니다. 예를 들어 어셈블러 코드와 C 코드에 counter 같은 동일한 기호 이름을 사용할 수 있습니다. 이 경우 어셈블러에 다른 이름을 사용하여 내보낼 수 있습니다.

int counter __asm__("counter_v1") = 0;

기호 counter가 아닌 기호 counter_v1이 내보내집니다.

추가 참고

• 4-6페이지의 __asm.

3.6.5 빈 선언

앞에 세미콜론밖에 없는 빈 선언이 허용됩니다.

예제

; // do nothing

3.6.6 16진수 부동 소수점 상수

ARM 컴파일러는 C의 숫자 상수 구문에 대한 확장을 구현하여 부동 소수점 상수를 IEEE 비트 패턴으로 명시적으로 지정할 수 있습니다.

구문

부동 소수점 상수를 IEEE 비트 패턴으로 지정하는 구문은 다음과 같습니다.

0f_n 8자리 16진수 n을 float 상수로 해석합니다. 정확히 8자리여야 합니다.

0d_nn 16자리 16진수 nn을 double 상수로 해석합니다. 정확히 16자리여야 합니다.


언어 확장

3.6.7 불완전한 열거형

enum의 정방향 선언이 지원됩니다.

예제

enum Incomplete_Enums_0;int Incomplete_Enums_2 (enum Incomplete_Enums_0 * passon){ return 0;}int Incomplete_Enums_1 (enum Incomplete_Enums_0 * passon){ return Incomplete_Enums_2(passon);}enum Incomplete_Enums_0 { ALPHA, BETA, GAMMA };

3.6.8 정수 유형 확장

정수 계열 상수 식에서 정수 계열 상수를 포인터 유형으로 캐스트한 다음 다시 정수 유형으로 캐스트할 수 있습니다.

3.6.9 레이블 정의

표준 C 및 표준 C++에서 문은 레이블 정의 다음에 와야 합니다. C 및 C++에서는 레이블 정의 바로 뒤에 오른쪽 괄호가 올 수 있습니다.

오류

레이블 정의 바로 뒤에 오른쪽 괄호가 오면 컴파일러에서 경고를 생성합니다.

예제

void foo(char *p){

if (p){

/* ... */label:

}}


언어 확장

3.6.10 Long float

long float는 double의 동의어로 허용됩니다.

3.6.11 비 정적 지역 변수

바깥쪽 함수의 비 정적 지역 변수는 지역 클래스 내의 비평가 식(예: sizeof 식)에서 참조될 수 있습니다. 경고가 발생합니다.

3.6.12 구조체, 공용체, enum 및 비트 필드 확장

다음과 같은 구조체, 공용체, enum 및 비트 필드 확장이 지원됩니다.

• C에서 파일 유효 범위 배열의 요소 유형은 불완전한 struct 또는 union 유형이 될 수 있습니다. 요소 유형은 배열이 첨자화되는 경우와 같이 요소 유형의 크기가 필요하기 전에 완료되어야 합니다. 배열이 extern이 아닌 경우 요소 유형은 컴파일이 끝날 때까지 완료되어야 합니다.

• struct 또는 union 지정자의 닫는 괄호 } 앞에 있는 마지막 세미콜론은 생략될 수 있습니다. 경고가 발생합니다.

• 단일 값이며 전체 정적 배열(struct 또는 union)을 초기화하는 데 사용되는 이니셜라이저 식은 괄호로 묶을 필요가 없습니다. ISO C에서는 괄호가 필요합니다.

• 확장은 다음과 같은 C++ 익명 공용체와 유사한 구성체를 활성화할 수 있도록 지원됩니다.

— 익명 공용체뿐만 아니라 익명 구조체도 사용할 수 있습니다. 익명 구조체의 구성원은 포함 struct의 유효 범위로 승격되어 일반 구성원처럼 조회됩니다.

— 이러한 구성원은 포함 struct에 typedef 이름으로 추가될 수 있습니다. 즉, 진정한 익명 공용체와 달리 직접 선언할 필요가 없습니다.

— 태그가 C 모드에서만 선언될 수 있습니다.

익명 구조체 및 공용체에 대한 지원을 활성화하려면 anon_unions pragma를 사용해야 합니다.

• enum 목록 끝에 추가 쉼표가 허용되지만 설명이 표시됩니다.

• enum 태그는 불완전할 수 있습니다. 괄호로 묶은 목록을 지정하여 태그 이름을 정의하고 차후에 확인할 수 있습니다.


언어 확장

• 열거 상수의 값은 평가 결과가 int 범위가 아니라 unsigned int 범위에 맞는 unsigned 수량으로 평가되는 식에서 제공될 수 있습니다. 예를 들면 다음과 같습니다.

/* When ints are 32 bits: */enum a { w = -2147483648 }; /* No error */enum b { x = 0x80000000 }; /* No error */enum c { y = 0x80000001 }; /* No error */enum d { z = 2147483649 }; /* Error */

• 비트 필드는 int 및 unsigned int. 외에도 enum 유형 또는 정수 유형인 기본 유형을 포함할 수 있습니다.

추가 참고

• 4-58페이지의 Pragma

• 3-24페이지의 구조체, 공용체, enum 및 비트 필드 확장



언어 확장

3.7 GNU 언어 확장

이 단원에서는 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장에 대해 설명합니다. 이러한 확장은 --gnu 옵션을 사용하여 소스 코드를 컴파일하는 경우인 GNU 모드에서만 지원됩니다. 자세한 내용은 1-6페이지의 언어 호환 및 2-70페이지의 --gnu를 참조하십시오.

참고

언어에 따라 일부 GNU 컴파일러 확장이 지원되지 않는 경우도 있습니다. 예를 들어 C++의 경우에는 확장된 포인터 산술이 지원되지 않습니다.

GNU 확장 사용에 대한 자세한 내용은 http://gcc.gnu.org에서 온라인으로 제공되는 GNU 컴파일러 설명서를 참조하십시오.

ARM 컴파일러에 대한 참조 자료를 더 보려면 추가로 다음을 참조하십시오.



• 부록 D C 및 C++ 컴파일러 구현 한계.

3.7.1 대체 키워드

컴파일러는 __keyword__ 형식의 대체 키워드를 인식합니다. 이 대체 키워드는 원본 키워드와 동일하게 동작합니다.

예제

__const__ int pi = 3.14; // same as const int pi = 3.14

3.7.2 asm 키워드

이 키워드는 __asm 키워드의 동의어입니다.

모드

C90 및 C99용 GNU 모드에서만 지원됩니다.

추가 참고

• 4-6페이지의 __asm.


언어 확장

3.7.3 케이스 범위

switch 문에서 값 범위를 지정할 수 있습니다.

예제

int Case_Ranges_0(int arg){ int aLocal; int bLocal =arg; switch (bLocal) { case 0 ... 10: aLocal= 1; break; case 11 ... 100: aLocal =2; break; default: aLocal=-1; } return aLocal;}

3.7.4 공용체의 캐스트

union 유형에 대한 캐스트는 지정된 유형이 union 유형인 점만 제외하고 다른 캐스트와 유사합니다. union 태그 또는 typedef 이름이 있는 유형을 지정할 수 있습니다.

모드


예제

typedef union{

double d;int i;

} foo_t;int Cast_to_Union_0(int a, double b){ foo_t u; if (a>100)


언어 확장

u = (foo_t) a ; // automatically equivalent to u.i=a; else u = (foo_t) b ; // automatically equivalent to u.d=b; return u.i; }

3.7.5 문자 확장 시퀀스

문자열에서 확장 시퀀스 ‘\e’는 확장 시퀀스 <ESC>(ASCII 27)로 사용될 수 있습니다.

예제

void foo(void){

printf("Escape sequence is: \e\n");}

3.7.6 복합 리터럴

C99에서와 같이 복합 리터럴이 지원됩니다. 모든 복합 리터럴은 lvalues입니다.

예제

int y[] = (int []) {1, 2, 3}; // error in strict C99, okay in C99 --gnuint z[] = (int [3]) {1};

모드


참고

또한 복합 리터럴은 C99에서 이니셜라이저로 사용될 수 있습니다. 그러나 C99 소스 코드를 컴파일할 때보다 GNU 모드에서 컴파일할 때 이니셜라이저로 취하는 복합 리터럴에 대해 보다 완화된 규칙이 적용됩니다.


언어 확장

3.7.7 조건부

결과가 테스트와 동일할 경우 조건문의 가운데 피연산자는 생략할 수 있습니다.

예를 들면 다음과 같습니다.

예제

다음은 동동한 조건문입니다.

c = i ? : j; // middle operand omittedc = i ? i : j;if (i) c = i; else c = j; // expanded in full

이것은 테스트가 특정 방식으로 값을 수정할 경우 대단히 유용합니다. 예를 들면 다음과 같습니다.

i++ ? : j;

여기서 i++는 매크로에서 옵니다. 이런 방식으로 코드를 작성할 경우 i++는 한 번만 평가됩니다.

i의 원래 값이 0이 아닌 값인 경우 결과는 i의 원래 값입니다. 이에 상관없이 i는 한 번만 증가합니다.

모드

GNU 모드에서만 지원됩니다. 지원되는 언어는 C90, C99 및 C++입니다.

3.7.8 지정된 이니셜라이저

C99에서와 같이 지정된 이니셜라이저가 지원됩니다.

예제

int a[6] = { [4] = 29, [2] = 15 };int b[6] = { 0,0,15,0,29,0 }; // a[] is equivalent to b[]

모드

C90 및 C++용 GNU 모드에서만 지원됩니다.

추가 참고



언어 확장

3.7.9 확장된 lvalues

GNU 모드에서는 쉼표 식과 ?: 구성체의 lvalue 구성 요소를 정의할 때 좀 더 완화된 규칙이 적용됩니다. 복합 식, 조건 식 및 캐스트를 다음과 같이 사용할 수 있습니다.

• 복합 식을 할당할 수 있습니다.

(a++, b) += x;

이는 다음과 동일합니다.

temp = (a++,b);b = temp + x

• 복합 식 &(a, b)의 주소를 구할 수 있습니다. 이는 (a, &b)와 동일합니다.

• 조건 식을 사용할 수도 있습니다. 예를 들면 다음과 같습니다.

(a ? b : c) = a;

이는 a에 따라 b 또는 c를 대상으로 선택합니다.

모드


3.7.10 이니셜라이저

표준 C++ 및 ISO C99에서와 같이 자동 변수의 집계 이니셜라이저의 요소는 상수 식일 필요가 없습니다.

모드

C90용 GNU 모드에서만 지원됩니다.

예제

float Initializers_0 (float f, float g){ float beat_freqs[2] = { f-g, f+g }; float aLocal; int i=0; for (; i<2; i++) aLocal += beat_freqs[i]; return aLocal;}


언어 확장

3.7.11 인라인

inline 함수 한정자는 함수가 인라인된다는 것을 컴파일러에 알려줍니다.

static inline foo (){...}

foo는 파일에 대해 내부적으로 사용되며 기호는 내보내지 않습니다.

inline foo(){...}

foo는 파일에 대해 내부적으로 사용되면 라인 외부 버전을 사용할 수 있게 되며 이름 foo는 내보냅니다.

extern inline foo (){...}

GNU 모드에서 foo는 인라인될 경우 내부적으로 사용됩니다. 인라인되지 않을 경우에는 내부 버전에 대한 호출을 사용하지 않고 외부 버전이 참조됩니다. 또한 foo 기호는 내보내지 않습니다.

비GNU 모드에서 extern은 무시되며 C++의 inline foo()와 동일하게 작동합니다. C에서는 __inline을 사용해야 합니다. 자세한 내용은 5-20페이지의 Extern 인라인 함수를 참조하십시오.

모드

C90용 GNU 모드에서만 지원됩니다.

3.7.12 레이블을 값으로 지원

컴파일러는 && 연산자를 사용하여 GCC 레이블을 값으로 지원합니다.

모드

C 및 C++용 GNU 모드에서 지원됩니다.

예

다음은 레이블 테이블입니다.

int f(int n){

void *const table[] = { &&a1, &&a2};goto *table[n];

a1: return 1;a2: return 2;}


언어 확장

다음은 연결로 사용되는 레이블입니다.

void *toggle(void *lab, int *x){

if (lab) goto *lab;a1: *x = 1; return &&a2;a2: *x = 0; return &&a1;}

3.7.13 포인터 산술

void 포인터 및 함수 포인터에서 산술을 수행할 수 있습니다.

void 유형 또는 함수 유형의 크기가 1로 정의됩니다.

모드


오류

컴파일러는 void 포인터 또는 함수 포인터에서의 산술을 감지하면 경고를 생성합니다.

예제

int ptr_arith_0(void){ void * pointer;

return sizeof *pointer;}int ptr_arith_1(void){ static int diff; diff = ptr_arith_0 - ptr_arith_1; return sizeof ptr_arith_0;}


언어 확장

3.7.14 문 식

문 식을 사용하면 괄호({ }) 안에 선언을 비롯한 전체 코드 섹션을 포함할 수 있습니다.

문 식의 결과는 문 목록의 최종 항목입니다.

제한

문 식으로의 분기는 허용되지 않습니다.

C++ 모드에서는 시작 분기도 허용되지 않습니다. 변수 길이 배열, 소멸할 수 있는 엔터티, try, catch, POD가 아닌 지역 클래스 정의 및 동적으로 초기화된 지역 정적 변수는 문 식 내에 사용할 수 있습니다.

예제

int bar(int b, int foo){

if (({int y = foo;int z;if (y > 0) z = y;else z = -y;z>b;

}))b++;return b;

}


언어 확장

3.7.15 명명되지 않은 필드

구조체나 공용체를 다른 구조체나 공용체에 임베드할 경우 내부 구조체를 명명할 필요가 없습니다. .name을 사용하여 참조하지 않고도 명명되지 않은 구조체의 내용에 액세스할 수 있습니다.

명명되지 않은 필드는 익명 공용체 및 구조체와 동일합니다.

모드


예제

struct{

int a;union{

int b;float c;

}; int d;} Unnamed_Fields_0;int Unnamed_Fields_1(){ return Unnamed_Fields_0.b; }

추가 참고

• 3-21페이지의 익명 클래스, 구조체 및 공용체


4장 컴파일러 관련 기능

이 장에서는 다음과 같은 ARM 컴파일러 관련 기능에 대해 설명합니다.

• 4-2페이지의 키워드 및 연산자

• 4-26페이지의 __declspec 속성

• 4-33페이지의 함수 속성

• 4-44페이지의 유형 속성

• 4-48페이지의 변수 속성

• 4-58페이지의 Pragma

• 4-76페이지의 명령어 내장 함수

• 4-119페이지의 VFP 상태 내장 함수

• 4-120페이지의 GNU 기본 제공 함수



컴파일러 관련 기능

4.1 키워드 및 연산자

이 단원에서는 ARM 컴파일러 armcc에서 지원하는 함수 키워드 및 연산자에 대해 설명합니다.

표 4-1에는 C 및 C++ 표준에 대한 ARM 확장인 키워드가 나와 있습니다. ARM 컴파일러와 관련된 동작이나 제한이 없는 표준 C 및 표준 C++ 키워드는 이 표에서 설명하지 않습니다.

4.1.1 __align

__align 키워드는 n-바이트 단위로 변수를 정렬하도록 컴파일러에 지시합니다.

__align은 저장소 클래스 한정자이며 함수의 유형에 영향을 주지 않습니다.

구문

__align(n)

인수 설명:

n 정렬 단위입니다.

지역 변수에 대해 n에 사용할 수 있는 값은 1, 2, 4 또는 8입니다.

전역 변수의 경우 n에는 최대 0x80000000까지 2의 제곱인 값을 사용할 수 있습니다.

__align 키워드는 변수 이름 바로 앞에 옵니다.

표 4-1 ARM 컴파일러에서 지원하는 키워드 확장

키워드

__align __int64 __svc

__ALIGNOF__ __INTADDR__ __svc_indirect

__asm __irq __svc_indirect_r7

__declspec __packed __value_in_regs

__forceinline __pure __weak

__global_reg __softfp __writeonly

__inline __smc



사용법

__align(n)은 선언되고 있는 변수의 기본 정렬이 n보다 적을 경우 유용합니다. 8바이트 정렬은 VFP 명령어로 대폭적인 성능 향상을 꾀할 수 있습니다.

__align은 extern 및 static과 함께 사용할 수 있습니다.

제한

__align은 저장소 클래스 한정자이므로 다음에서 사용할 수 없습니다.

• typedefs 및 구조체 정의를 포함하는 유형

• 함수 매개변수

과정렬(overalign)만 가능합니다. 즉, 2바이트 객체를 4바이트로 정렬할 수 있지만 4바이트 객체를 2바이트로 정렬할 수는 없습니다.

예

__align(8) char buffer[128]; // buffer starts on eight-byte boundary

void foo(void){

...__align(16) int i; // this alignment value is not permitted for // a local variable...

}

__align(16) int i; // permitted as a global variable.

추가 참고

• 컴파일러 사용 설명서의 2-96페이지의 --min_array_alignment=opt



4.1.2 __alignof__

__alignof__ 키워드를 사용하면 유형 또는 변수의 정렬에 대해 질문할 수 있습니다.

참고

. 이 키워드는 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

구문

__alignof__(type)

__alignof__(expr)

인수 설명:

type 유형입니다.

expr lvalue입니다.

반환 값

__alignof__(type)은 type 형식에 대한 정렬 요구 사항을 반환하거나, 정렬 요구 사항이 없으면 1을 반환합니다.

__alignof__(expr)은 lvalue expr 형식에 대한 정렬 요구 사항을 반환하거나, 정렬 요구 사항이 없으면 1을 반환합니다.

예제

int Alignment_0(void){

return __alignof__(int);}

추가 참고

• 4-5페이지의 __ALIGNOF__.



4.1.3 __ALIGNOF__

__ALIGNOF__ 키워드는 지정된 유형 또는 지정된 객체에 대한 정렬 요구조건을 반환합니다.

구문

__ALIGNOF__(type)

__ALIGNOF__(expr)

인수 설명:

type 유형입니다.

expr lvalue입니다.

반환 값

__ALIGNOF__(type)은 type 형식에 대한 정렬 요구 사항을 반환하거나, 정렬 요구 사항이 없으면 1을 반환합니다.

__ALIGNOF__(expr)은 lvalue expr 형식에 대한 정렬 요구 사항을 반환하거나, 정렬 요구 사항이 없으면 1을 반환합니다. lvalue 자체는 평가되지 않습니다.

예제

typedef struct s_foo { int i; short j; } foo;typedef __packed struct s_bar { int i; short j; } bar;return __ALIGNOF(struct s_foo); // returns 4return __ALIGNOF(foo); // returns 4return __ALIGNOF(bar); // returns 1

추가 참고

• 4-4페이지의 __alignof__.



4.1.4 __asm

이 키워드는 컴파일러에서 ARM 어셈블러 armasm으로 정보를 전달하는 데 사용됩니다.

이 키워드의 정확한 작업은 사용법에 따라 다릅니다.

사용법

임베디드 어셈블러

__asm 키워드는 임베디드 어셈블리 함수를 선언하거나 정의하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

__asm void my_strcpy(const char *src, char *dst);

자세한 내용은 컴파일러 사용 설명서에서 7-19페이지의 임베디드 어셈블러를 참조하십시오.

인라인 어셈블러

__asm 키워드는 인라인 어셈블리를 함수로 통합하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

int qadd(int i, int j){

int res;__asm{

QADD res, i, j}return res;

}

자세한 내용은 컴파일러 사용 설명서에서 7-2페이지의 인라인 어셈블러를 참조하십시오.

어셈블러 레이블

__asm 키워드는 C 기호에 어셈블러 레이블을 지정하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

int count __asm__("count_v1"); // export count_v1, not count

자세한 내용은 3-22페이지의 어셈블러 레이블을 참조하십시오.



명명된 레지스터 변수

__asm 키워드는 명명된 레지스터 변수를 선언하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

register int foo __asm("r0");

자세한 내용은 4-116페이지의 명명된 레지스터 변수를 참조하십시오.

추가 참고

• 3-26페이지의 asm 키워드

4.1.5 __forceinline

__forceinline 키워드는 컴파일러가 C 또는 C++ 함수를 인라인으로 컴파일하도록 만듭니다.

__forceinline 의 의미는 C++ inline 키워드의 의미와 정확히 동일합니다. 컴파일러에서는 함수의 특성에 상관없이 __forceinline으로 한정된 함수를 인라인하려고 합니다. 그러나 인라인하는 것이 문제를 일으키는 경우 컴파일러는 함수를 인라인하지 않습니다. 예를 들어 재귀 함수는 자체로 한 번만 인라인됩니다.

__forceinline은 저장소 클래스 한정자이며 함수의 유형에 영향을 주지 않습니다.

참고

함수 속성에서는 __attribute__((always_inline))가 이 키워드에 해당합니다.

예제

__forceinline static int max(int x, in y){

return x > y ? x : y; // always inline if possible}

추가 참고


• 4-35페이지의 __attribute__((always_inline))



4.1.6 __global_reg

__global_reg 저장소 클래스 지정자는 선언된 변수를 전역 변수 레지스터로 할당합니다.

구문

__global_reg(n) type varName

인수 설명:

n 1과 8 사이의 정수입니다.

type 다음 유형 중 하나입니다.

• long long을 제외한 모든 정수 유형

• 모든 문자 유형

• 모든 포인터 유형

varName 변수 이름

제한

이 저장소 클래스를 사용할 경우 extern, static 또는 typedef와 같은 추가 저장소 클래스를 사용할 수 없습니다.

C에서 전역 레지스터 변수는 선언 시 정규화되거나 초기화될 수 없습니다. C++에서 모든 초기화는 동적 초기화로 처리됩니다.

사용하는 AAPCS의 변형에 따라 사용할 수 있는 레지스터의 수는 다르며 5 ~ 7개의 레지스터를 전역 변수 레지스터로 사용할 수 있습니다.

실제로는 다음 이상을 사용하지 않는 것이 좋습니다.

• ARM 또는 Thumb-2에서 세 개의 전역 레지스터 변수

• Thumb-1에서 한 개의 전역 레지스터 변수

• 전역 부동 소수점 레지스터 변수로 사용 가능한 부동 소수점 레지스터 개수의 절반

너무 많은 전역 변수를 선언할 경우 코드 크기가 크게 증가합니다. 프로그램이 컴파일되지 못할 경우도 있습니다.



주의

전역 레지스터 변수를 사용할 경우 다음과 같은 이유 때문에 주의해야 합니다.

• 서로 다른 컴파일 단위 간의 직접적 호출이 의미가 있는지 확인하는 링크 타임 시 확인이 없습니다. 가능한 한 프로그램에서 사용되는 전역 레지스터 변수를 프로그램의 각 컴파일 단위에 정의하십시오. 일반적으로 정의는 전역 헤더 파일에 배치하는 것이 가장 좋습니다. 전역 레지스터의 값을 레지스터가 사용되기 전에 코드에서 초기에 설정해야 합니다.

• 전역 레지스터 변수는 호출 수신자가 저장하는 레지스터에 매핑됩니다. 따라서 그 값은 라이브러리 함수와 같은 전역 레지스터 변수로 해당 값을 사용하지 않는 컴파일 단위에서 함수에 대한 호출에 걸쳐 저장 및 복원됩니다.

• 전역 레지스터 변수를 사용하는 컴파일 단위로 다시 호출하는 것은 위험합니다. 예를 들어 전역 레지스터를 사용하는 함수가 전역 레지스터 변수를 선언하지 않는 컴파일 단위로부터 호출될 경우, 이 함수는 자신의 예정된 전역 레지스터 변수로부터 잘못된 값을 읽습니다.

• 이 저장소 클래스는 파일 범위에서만 사용할 수 있습니다.

예제

예제 4-1에서는 r5로 할당된 전역 변수 레지스터를 선언합니다.

예제 4-1 전역 정수 레지스터 변수 선언

__global_reg(2) int x; v2 is the synonym for r5

전역 레지스터는 동일한 변수의 모든 선언에 지정되어야 하므로 예제 4-2에서 오류가 발생합니다.

예제 4-2 전역 레지스터 – 선언 오류

int x;__global_reg(1) int x; // error

C에서 __global_reg 변수는 정의 시 초기화될 수 없습니다. 4-10페이지의 예제 4-3으로 인해 C에서 오류가 발생하지만 C++에서는 오류가 발생하지 않습니다.



예제 4-3 전역 레지스터 – 초기화 오류

__global_reg(1) int x=1; // error in C, OK in C++

추가 참고

• 2-70페이지의 --global_reg=reg_name[,reg_name,...]

4.1.7 __inline

__inline 키워드는 컴파일러가 C 또는 C++ 함수를 인라인으로 컴파일하도록 제안합니다(그렇게 하는 것이 현명할 경우).

__inline 의 의미는 inline 키워드의 의미와 정확히 동일합니다. 그러나 C90에서는 inline 키워드를 사용할 수 없습니다.

__inline은 저장소 클래스 한정자이며 함수의 유형에 영향을 주지 않습니다.

예제

__inline int f(int x){

return x*5+1;}int g(int x, int y){

return f(x) + f(y);}

추가 참고

• 컴파일러 사용 설명서의 5-18페이지의 함수 인라인

4.1.8 __int64

__int64 키워드는 키워드 시퀀스 long long의 동의어입니다.

__int64는 --strict를 사용하는 경우에도 허용됩니다.

추가 참고


• 3-8페이지의 long long



4.1.9 __INTADDR__

__INTADDR__ 연산은 괄호로 묶인 식을 상수 식으로 처리하고 이것을 정수 상수로 변환합니다.

참고

이것은 offsetof 매크로에서 사용됩니다.

구문

__INTADDR(expr)

인수 설명:

expr 정수 계열 상수 식입니다.

반환 값

__INTADDR__(expr)은 expr의 해당 항목 정수 상수를 반환합니다.

추가 참고

• 컴파일러 사용 설명서의 7-21페이지의 임베디드 어셈블리 연산의 제한

4.1.10 __irq

__irq 키워드를 사용하면 C 또는 C++ 함수를 인터럽트 루틴으로 사용할 수 있습니다.

__irq는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.

제한

AAPCS에 따라 정상적으로 보존되는 레지스터뿐 아니라 부동 소수점 레지스터를 제외한 모든 손상된 레지스터가 보존됩니다. 기본 AAPCS 모드를 사용해야 합니다.

프로그램 카운터를 lr-4로 설정하고 CPSR을 SPSR의 값으로 설정하여 함수를 종료합니다. 인수 또는 반환 값은 __irq 함수와 함께 사용할 수 없습니다.



참고

Thumb 전용 프로세서에 대해 컴파일할 때 인터럽트 처리기가 Thumb 상태가 되기 때문에 코드가 Thumb 코드로 컴파일됩니다. 그렇지 않으면 --thumb 옵션 또는 #pragma thumb을 사용하여 Thumb용으로 컴파일할 때에도 __irq로 지정된 함수는 ARM용으로 컴파일됩니다.

추가 참고



• 개발자 설명서의 6장 프로세서 예외 처리

4.1.11 __packed

__packed 한정자는 유효한 정렬을 1로 설정합니다. 이것은 다음을 의미합니다.

• 패킹된 객체를 정렬하기 위해 삽입된 패킹이 없습니다.

• 패킹된 유형의 객체는 정렬되지 않은 액세스를 사용하여 읽히고 쓰여집니다.

__packed 한정자는 __packed를 사용하여 선언될 경우 구조체 또는 공용체의 모든 구성원에게 적용됩니다. 구성원 사이에 또는 구조체 끝에 패딩이 없습니다. 패킹된 구조체의 모든 하위 구조체는 __packed를 사용하여 선언해야 합니다. 패킹되지 않은 구조체의 필수 하위 필드는 개별적으로 패킹될 수 있습니다.

사용법

__packed 한정자는 구조체를 외부 데이터 구조체에 매핑하거나 정렬되지 않은 데이터에 액세스할 경우 유용하지만, 일반적으로 액세스 비용이 비교적 높기 때문에 데이터 크기를 줄이는 데는 유용하지 않습니다. 패킹이 필요한 구조체에서 필드를 패킹하는 것만이 정렬되지 않은 액세스의 수를 줄일 수 있습니다.

참고

하드웨어의 미정렬 액세스를 지원하지 않는 ARM 프로세서(예: ARMv6 이전)에서 미정렬 데이터에 대한 액세스는 코드 크기와 실행 속도 면에서 비용이 많이 들 수 있습니다. 패킹된 구조체를 통한 데이터 액세스는 코드 크기 증가와 성능 손실을 막기 위해 최소화되어야 합니다.



제한

__packed 사용 시 다음 제한이 적용됩니다.

• __packed 한정자는 __packed 없이 이전에 선언된 구조체에서는 사용할 수 없습니다.

• 다른 유형의 한정자와 달리, 동일한 구조체 유형의 __packed와 비 __packed 버전을 동시에 가질 수는 없습니다.

• __packed 한정자는 정수 유형의 지역 변수에 영향을 주지 않습니다.

• 패킹된 구조체나 공용체는 패킹되지 않은 해당 구조체와 할당 호환성이 없습니다. 구조체는 다른 메모리 레이아웃을 갖고 있으므로 패킹된 구조체를 패킹되지 않은 구조체로 할당하는 유일한 방법은 한 필드씩 복사하는 것입니다.

• __packed를 캐스트하는 효과는 정의되지 않습니다. 패킹되지 않은 구조체를 패킹된 구조체로 캐스트하는 효과는 정의되지 않습니다. 정수 유형에 대한 포인터는 패킹된 정수 유형에 대한 포인터로 암시적으로 또는 명시적으로 올바르게 캐스트될 수 있습니다. char 유형에서도 __packed를 캐스트할 수 있습니다.

• 패킹된 배열 유형은 없습니다. 패킹된 배열은 패킹된 유형을 가진 객체의 배열입니다. 배열에 패딩이 없습니다.

예제

예제 4-4에서는 포인터가 패킹된 유형을 가리킬 수 있음을 보여 줍니다.

예제 4-4 패킹된 유형에 대한 포인터

typedef __packed int* PpI; /* pointer to a __packed int */__packed int *p; /* pointer to a __packed int */PpI p2; /* 'p2' has the same type as 'p' */ /* __packed is a qualifier */ /* like 'const' or 'volatile' */typedef int *PI; /* pointer to int */__packed PI p3; /* a __packed pointer to a normal int */ /* -- not the same type as 'p' and 'p2' */int *__packed p4; /* 'p4' has the same type as 'p3' */



예제 4-5에서는 패킹된 객체가 포인터를 사용하여 액세스될 경우 컴파일러에서 포인터 정렬과 독립적으로 작동하는 코드를 생성하는 것을 보여 줍니다.

예제 4-5 패킹된 구조체

typedef __packed struct{ char x; // all fields inherit the __packed qualifier int y;} X; // 5 byte structure, natural alignment = 1int f(X *p){ return p->y; // does an unaligned read}typedef struct{ short x; char y; __packed int z; // only pack this field char a;} Y; // 8 byte structure, natural alignment = 2int g(Y *p){ return p->z + p->x; // only unaligned read for z}

추가 참고

• 4-52페이지의 __attribute__((packed))


• 5-10페이지의 패킹된 구조체

• 컴파일러 사용 설명서의 5-28페이지의 __packed 한정자 및 정렬되지 않은 액세스

• 컴파일러 사용 설명서의 5-30페이지의 __packed 구조체 및 개별 __packed 필드



4.1.12 __pure

__pure 키워드는 함수 선언이 순수하도록 지정합니다.

함수는 다음과 같은 경우에만 순수합니다.

• 결과는 인수의 값에 따라 배타적으로 달라집니다.

• 함수에 부작용이 없습니다.

__pure는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.

참고

함수 속성에서는 __attribute__((const))가 이 키워드에 해당합니다.

기본값

기본적으로 함수는 순수하지 않은 것으로 간주됩니다.

사용법

순수한 함수는 공통 하위식 제거가 필요할 수 있습니다.

제한

순수한 것으로 선언된 함수에는 부작용이 없습니다. 예를 들어 순수한 함수는 다음과 같습니다.

• 순수하지 않은 함수를 호출할 수 없습니다.

• 전역 변수나 참조 해제 포인터를 사용할 수 없습니다. 컴파일러는 해당 함수가 메모리(스택 메모리는 제외)에 액세스하지 않는다고 간주하기 때문입니다.

• 동일한 매개변수를 사용하여 두 번 호출되는 경우 매번 같은 값을 반환해야 합니다.

예제

int factr(int n) __pure{

int f = 1;while (n > 0)

f *= n--;return f;}



추가 참고

• 4-35페이지의 __attribute__((const))

• 컴파일러 사용 설명서의 5-14페이지의 __pure

• 컴파일러 사용 설명서의 5-16페이지의 ARM 함수 한정자 배치

4.1.13 __smc

__smc 키워드는 SMC(보안 모니터 호출) 함수를 선언합니다. SMC 함수를 호출하면 함수 호출 시 컴파일러에서 생성한 명령어 스트림에 SMC 명령어가 삽입됩니다.

참고

SMC 명령어는 이전 버전의 ARM 어셈블리 언어에 사용된 SMI 명령어를 대체합니다.

__smc 는 함수 한정자이며 함수 유형에 영향을 줍니다.

구문

__smc(int smc_num) return-type function-name([argument-list]);

인수 설명:

smc_num SMC 명령어에 사용되는 4비트 즉치값입니다.

ARM 프로세서에서는 smc_num의 값을 무시하지만 SMC 예외 처리기에서는 요청 중인 서비스를 확인하기 위해 이 값을 사용할 수 있습니다.

제한

SMC 명령어는 보안 확장이 있는 선택된 ARM 아키텍처 기반 프로세서에서 사용할 수 있습니다. 자세한 내용은 어셈블러 설명서에서 4-140페이지의 SMC를 참조하십시오.

SMC 명령어를 지원하지 않는 아키텍처에 대해 __smc 키워드를 포함한 소스 코드를 컴파일 하는 경우 컴파일러에서 오류를 생성합니다.

예제

__smc(5) void mycall(void); /* declare a name by which SMC #5 can be called */...mycall(); /* invoke the function */



추가 참고

• 어셈블러 설명서의 4-140페이지의 SMC

4.1.14 __softfp

__softfp 키워드는 함수가 소프트웨어 부동 소수점 연결을 사용하도록 지정합니다.

__softfp는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.

참고

#pragma에서는 #pragma __softfp_linkage가 이 키워드에 해당합니다.

사용법

함수를 호출하면 정수 레지스터에서 부동 소수점 인수가 전달됩니다. 결과가 부동 소수점 값일 경우 그 값은 정수 레지스터에서 반환됩니다. 그러면 소프트웨어 부동 소수점을 타겟으로 하는 컴파일의 동작이 복제됩니다.

이 키워드를 사용하면 하드웨어 및 소프트웨어 부동 소수점을 사용하도록 컴파일된 소스가 동일한 라이브러리를 사용할 수 있습니다.

참고

C++에서 __softfp 키워드로 정규화된 가상 함수가 무시될 경우 우선하는 함수는 __softfp로도 선언되어야 합니다. 함수가 일치하지 않으면 컴파일러에서 오류를 생성합니다.

추가 참고


• 4-71페이지의 #pragma softfp_linkage, #pragma no_softfp_linkage




4.1.15 __svc

__svc 키워드는 최대 4개의 정수 유사 인수를 받아서 value_in_regs 구조체로 최대 4개의 결과를 반환하는 SVC(관리자 호출) 함수를 선언합니다.

__svc 는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.

구문

__svc(int svc_num) return-type function-name([argument-list]);

인수 설명:

svc_num SVC 명령어에 사용되는 즉치값입니다.

다음 범위에 있는 정수로 평가되는 식입니다.

• ARM 명령어의 경우 0 ~ 224–1(24비트 값)

• 16비트 Thumb 명령어의 경우 0 ~ 255(8비트 값)

사용법

이로 인해 함수 호출은 일반 함수 호출과 유사하게 동작하는 AAPCS 호환 연산으로 인라인으로 컴파일됩니다.

__value_in_regs 한정자는 AAPCS에 정의된 일반 구조체 전달 메커니즘이 아니라 최대 16바이트의 작은 구조체가 레지스터에서 반환되도록 지정하는 데 사용할 수 있습니다.

예제

__svc(42) void terminate_1(int procnum); // terminate_1 returns no results__svc(42) int terminate_2(int procnum); // terminate_2 returns one resulttypedef struct res_type{

int res_1;int res_2;int res_3;int res_4;

} res_type;__svc(42) __value_in_regs res_type terminate_3(int procnum);

// terminate_3 returns more than// one result



오류

SVC 명령어를 지원하지 않는 ARM 아키텍처 변형 또는 ARM 아키텍처 기반 프로세서가 --cpu 옵션을 사용하여 명령 행에 지정되면 컴파일러에서 오류를 생성합니다.

추가 참고


• 4-21페이지의 __value_in_regs

• 어셈블러 설명서의 4-133페이지의 SVC

4.1.16 __svc_indirect

__svc_indirect 키워드는 연산 코드를 r12의 SVC 처리기로 전달합니다.

__svc_indirect는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.

구문

__svc_indirect(int svc_num)return-type function-name(int real_num[, argument-list]);

인수 설명:



• ARM 명령어의 경우 0 ~ 224–1(24비트 값)


real_num 수행할 함수를 결정하기 위해 r12에서 처리기로 전달되는 값

간접 메커니즘을 이용하려면 시스템 처리기가 r12 값을 사용하여 필요한 연산을 선택해야 합니다.

사용법

이 기능을 이용하여 간접 SVC를 구현할 수 있습니다.



예제

int __svc_indirect(0) ioctl(int svcino, int fn, void *argp);

호출:

ioctl(IOCTL+4, RESET, NULL);

r12에서 IOCTL+4과 함께 SVC #0으로 컴파일됩니다.

오류


추가 참고


• 4-21페이지의 __value_in_regs


4.1.17 __svc_indirect_r7

__svc_indirect_r7 키워드는 __svc_indirect_r7처럼 동작하지만 r12 대신 r7을 사용합니다.

__svc_indirect_r7는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.

구문

__svc_indirect_r7(int svc_num)return-type function-name(int real_num[, argument-list]);

인수 설명:



• ARM 명령어의 경우 0 ~ 224–1(24비트 값)


real_num 수행할 함수를 결정하기 위해 r7에서 처리기로 전달되는 값



사용법

ARM Linux에서 실행되는 Thumb 응용 프로그램은 __svc_indirect_r7을 사용하여 커널 시스템 호출을 수행합니다.

또한 이 기능을 이용하여 간접 SVC를 구현할 수 있습니다.

예제

long __svc_indirect_r7(0) \SVC_write(unsigned, int fd, const char * buf, size_t count);

#define write(fd, buf, count) SVC_write(4, (fd), (buf), (count))

호출:

write(fd, buf, count);

r0 = fd, r1 = buf, r2 = count 및 r7 = 4와 함께 SVC #0으로 컴파일됩니다.

오류


추가 참고

• __value_in_regs



4.1.18 __value_in_regs

__value_in_regs 한정자는 메모리를 사용하는 대신 정수 레지스터에서 최대 4개의 정수 워드 또는 부동 소수점 레지스터에서 최대 4개의 float 또는 double로 구성된 구조체를 반환하도록 컴파일러에 지시합니다.

__value_in_regs는 함수 한정자이며 함수 유형에 영향을 주지 않습니다.



구문

__value_in_regs return-type function-name([argument-list]);

인수 설명:

return-type 크기가 최대 4워드인 구조체의 유형입니다.

사용법

__value_in_regs 함수를 선언하면 두 개 이상의 결과를 반환하는 함수를 호출할 경우 유용할 수 있습니다.

제한

C++ 함수는 구조체에서 복사 생성이 필요할 경우 __value_in_regs 구조체를 반환할 수 없습니다.

__value_in_regs로 선언된 가상 함수가 무시될 경우 우선하는 함수는 __value_in_regs로도 선언되어야 합니다. 함수가 일치하지 않으면 컴파일러에서 오류를 생성합니다.

오류

__value_in_regs로 정규화된 함수에서 반환된 구조체가 너무 클 경우 경고가 발생하며 __value_in_regs 구조체는 무시됩니다.

예제

typedef struct int64_struct{ unsigned int lo; unsigned int hi;} int64_struct;__value_in_regs extern int64_struct mul64(unsigned a, unsigned b);

추가 참고

• 컴파일러 사용 설명서의 5-13페이지의 __value_in_regs



4.1.19 __weak

이 키워드는 컴파일러가 기호를 weak로 내보내도록 지시합니다.

__weak 키워드는 함수 및 변수 선언과 함수 정의에 적용할 수 있습니다.

사용법

함수 및 변수 선언

선언의 경우, 이 저장소 클래스는 extern 객체 선언을 지정합니다. 이 객체 선언은 부재 시에도 링커가 미확인 참조에 잘못 연결하지 않도록 합니다.


__weak void f(void);...f(); // call f weakly

존재하지 않는 weak 함수가 분기 또는 분기 링크 명령어로 컴파일되는 코드에서 참조될 경우 다음과 같은 두 가지 결과가 나타납니다.

• 참조는 다음 명령어로 분기하는 것으로 확인됩니다. 이로 인해 분기는 NOP가 됩니다.

• 분기는 NOP 명령어에 의해 교체됩니다.

함수 정의

__weak로 정의된 함수는 기호를 weak로 내보냅니다. weak로 정의된 함수는 비 weak로 정의된 같은 이름의 함수가 동일한 이미지로 링크되어 있지 않는 한 정상적으로 정의된 함수처럼 동작합니다. 비 weak로 정의된 함수와 weak로 정의된 함수가 동일한 이미지에 있을 경우 모든 함수 호출은 비 weak 함수 호출로 처리됩니다. 여러 개의 weak 정의를 사용할 수 있는 경우 링커에서는 모든 호출에 사용될 하나의 정의를 선택합니다.

__weak로 선언된 함수가 __weak 없이 정의될 경우 비 weak 함수처럼 동작합니다.



제한

함수 및 변수 선언과 함수 정의를 __weak로 정규화하는 경우 제한이 있습니다.

함수 및 변수 선언

함수 또는 변수는 동일한 컴파일에서 weak 또는 비 weak 중 하나로만 사용할 수 있습니다. 예를 들어 다음 코드는 g() 및 h()에서 f()를 weak로 사용합니다.

void f(void);void g(){

f();}__weak void f(void);void h(){

f();}

함수나 변수를 정의하는 동일 컴파일에서 함수나 변수를 weak로 사용할 수는 없습니다. 다음 코드는 h()에서 f()를 비 weak로 사용합니다.

__weak void f(void);void h(){

f();}void f() {}

다른 컴파일에서 함수나 변수를 비 weak로 사용하지 않는 한, 링커는 라이브러리에서 함수나 변수를 로드하지 않습니다. 참조가 미확인으로 남아 있으면 해당 값은 NULL로 간주됩니다. 하지만 코드에서 위치 독립적 섹션이나 없는 __weak 함수로 참조될 경우, 미확인 참조는 NULL이 아닙니다.

함수 정의

weak로 정의된 함수는 인라인될 수 없습니다.



예제

__weak const int c; // assume 'c' is not present in final link const int *f1() { return &c; } // '&c' returns non-NULL if // compiled and linked /ropi __weak int i; // assume 'i' is not present in final link int *f2() { return &i; } // '&i' returns non-NULL if // compiled and linked /rwpi __weak void f(void); // assume 'f' is not present in final link typedef void (*FP)(void); FP g() { return f; } // 'g' returns non-NULL if // compiled and linked /ropi

추가 참고

• 라이브러리 검색에 대한 자세한 내용은 유틸리티 설명서에서 3장 armar 사용을 참조하십시오.

4.1.20 __writeonly

__writeonly 유형 한정자는 데이터 객체에서 읽기 작업을 수행할 수 없음을 나타냅니다.

C 및 C++ 유형 시스템에서 이 한정자는 const 또는 volatile과 같은 cv-한정자처럼 동작합니다. 이를 사용하면 __writeonly 유형의 lvalue를 rvalue로 변환할 수 없습니다.

__writeonly 비트 필드에 대한 할당이 읽기- 수정- 쓰기로 구현되는 경우 해당 할당은 허용되지 않습니다. 이는 구현 방식에 따라 다릅니다.

예제

void foo(__writeonly int *ptr){

*ptr = 0; // allowedprintf("ptr value = %d\n", *ptr); // error

}



4.2 __declspec 속성

__declspec 키워드를 사용하면 객체 및 함수의 특별한 속성을 지정할 수 있습니다. 예를 들어 __declspec 키워드를 사용하여 가져오거나 내보낸 함수 및 변수를 선언하거나 TLS(Thread Local Storage) 객체를 선언할 수 있습니다.

__declspec 키워드는 선언 사양의 접두사로 추가되어야 합니다. 예를 들면 다음과 같습니다.

__declspec(noreturn) void overflow(void);__declspec(thread) int i;

표 4-2에는 사용 가능한 __declspec 속성이 요약되어 있습니다. __declspec 속성은 저장소 클래스 한정자입니다. 함수 또는 변수의 유형에 영향을 주지 않습니다.

4.2.1 __declspec(dllexport)

__declspec(dllexport) 속성은 DLL 라이브러리 빌드 시 동적 기호 테이블을 통해 기호의 정의를 내보냅니다. 클래스에서 이 속성은 vtable, 구성 vtable, RTTI와 같은 클래스 장애 요소의 표시를 제어하고 구성원 함수와 정적 데이터 구성원의 기본 표시를 설정합니다.

사용법

함수, 클래스 또는 클래스의 개별 구성원 수준에서 __declspec(dllexport)를 사용할 수 있습니다.

표 4-2 컴파일러에서 지원하는 __declspec 속성 및 해당 항목

__declspec 속성 __declspec가 아닌 해당 항목

__declspec(dllexport) -

__declspec(dllimport) -

__declspec(noinline) __attribute__((noinline))

__declspec(noreturn) __attribute__((noreturn))

__declspec(nothrow) -

__declspec(notshared) -

__declspec(thread) -



인라인 함수가 __declspec(dllexport)로 표시되는 경우 함수 정의가 인라인될 수도 있지만 함수의 라인 외부 인스턴스는 항상 비 인라인 함수와 동일한 방식으로 생성되어 내보내집니다.

클래스가 __declspec(dllexport)로 표시되면(예: class __declspec(dllexport) S { ... };) 해당 클래스의 정적 데이터 구성원과 구성원 함수는 모두 내보내집니다. 개별 정적 데이터 구성원과 구성원 함수가 __declspec(dllexport)로 표시되면 해당 구성원만 내보내지고, 이때 vtable, 구성 vtable 및 RTTI도 같이 내보내집니다.

참고

다음은 올바른 선언의 예입니다.

class __declspec(dllexport) S { ... };

다음은 잘못된 선언의 예입니다.

__declspec(dllexport) class S { ... };

--export_all_vtbl과 함께 __declspec(notshared)를 사용하여 클래스 또는 구조체에서 vtable, 구성 vtable 및 RTTI를 내보내지 않도록 설정할 수 있습니다. --export_all_vtbl 및 __declspec(dllexport)는 일반적으로 함께 사용되지 않습니다.

제한

클래스를 __declspec(dllexport)로 표시하면 해당 클래스의 개별 구성원을 __declspec(dllexport)로 표시할 수 없습니다.

클래스를 __declspec(dllexport)로 표시할 경우 해당 클래스의 기본 클래스도 모두 __declspec(dllexport)로 표시되어야 합니다.

클래스 내 가상 함수를 내보낼 경우 해당 클래스의 모든 가상 함수를 내보내거나, 가상 함수가 클라이언트에 표시되도록 인라인으로 정의해야 합니다.

예제

정의가 동일한 공유 라이브러리에 존재하는지 여부에 따라 선언에 __declspec()가 필요할 수 있습니다.

/* This is the declaration for use in the same shared library as the *//* definition */__declspec(dllexport) extern int mymod_get_version(void);

/* Translation unit containing the definition */



__declspec(dllexport) extern int mymod_get_version(void){

return 42;}

/* This is the declaration for use in a shared library that does not contain *//* the definition */__declspec(dllimport) extern int mymod_get_version(void);

다음 매크로의 결과로 정의 연결 단위에 있는 비정의 변환 단위는 __declspec(dllexport)를 확인합니다.

/* mymod.h - interface to my module */#ifdef BUILDING_MYMOD#define MYMOD_API __declspec(dllexport)#else /* not BUILDING_MYMOD */#define MYMOD_API __declspec(dllimport)#endif

MYMOD_API int mymod_get_version(void);

추가 참고

• __declspec(dllimport)

• 4-31페이지의 __declspec(notshared)

• 2-57페이지의 --export_all_vtbl, --no_export_all_vtbl

4.2.2 __declspec(dllimport)

__declspec(dllimport) 속성은 DLL 라이브러리 빌드 시 동적 기호 테이블을 통해 기호를 가져옵니다.

사용법

인라인 함수가 __declspec(dllimport)으로 표시되는 경우 이 컴파일 단위의 함수 정의는 인라인될 수 있지만 외부적으로는 생성되지 않습니다. 라인 외부 호출이나 주소 참조는 가져온 기호를 사용합니다.

extern 함수와 변수 및 클래스에서는 __declspec(dllimport)만 사용할 수 있습니다.

클래스가 __declspec(dllimport)로 표시된 경우 해당 클래스의 정적 데이터 구성원과 구성원 함수를 모두 가져옵니다. 개별 정적 데이터 구성원 및 구성원 함수가 __declspec(dllimport)로 표시된 경우 해당 구성원만 가져옵니다.



제한

클래스를 __declspec(dllimport)로 표시하면 해당 클래스의 개별 구성원을 __declspec(dllimport)로 표시할 수 없습니다.

예

__declspec(dllimport) int i;

class __declspec(dllimport) X{

void f();};

추가 참고


4.2.3 __declspec(noinline)

__declspec(noinline) 속성은 함수의 호출 지점에서 그 함수의 인라인을 억제합니다.

참고

함수 속성에서는 __attribute__((noinline))가 이 __declspec 속성에 해당합니다.

추가 참고

• 4-67페이지의 #pragma inline, #pragma no_inline

• 4-37페이지의 __attribute__((noinline))

4.2.4 __declspec(noreturn)

__declspec(noreturn) 속성은 함수가 반환하지 않도록 지정합니다.

참고

함수 속성에서는 __attribute((noreturn))가 이 속성에 해당합니다. 그러나 __attribute((noreturn)) 및 __declspec(noreturn)은 함수 정의를 컴파일할 때 함수가 명시적 또는 암시적 반환에 도달하면 __attribute((noreturn))는 무시되고 컴파일러가 경고를 생성하지만 __declspec(noreturn)은 그렇지 않다는 점에서 서로 다릅니다.



사용법

이 속성을 사용하여 exit() 같은 반환하지 않는 함수를 호출하는 비용을 줄일 수 있습니다. noreturn 함수가 호출자로 돌아갈 경우, 동작은 정의되지 않습니다.

제한

noreturn 함수를 호출하는 경우 반환 주소가 보존되지 않습니다. 이는 콜 스택을 표시하는 디버거의 기능을 제한합니다.

예제

__declspec(noreturn) void overflow(void); // never return on overflowint negate(int x) { if (x == 0x80000000) overflow(); return -x;}

추가 참고

• 4-38페이지의 __attribute__((noreturn))

4.2.5 __declspec(nothrow)

__declspec(nothrow) 속성은 함수 호출이 호출에서 호출자로 전파되는 C++ 예외를 발생시키지 않도록 지정합니다.

ARM 라이브러리 헤더는 ISO C 표준에 따라 결코 throw할 수 없는 C 함수의 선언에 이 한정자를 자동으로 추가합니다.

사용법

함수가 throw할 수 없다는 사실을 컴파일러가 알고 있을 경우, 함수의 호출자를 위한 더 작은 예외 처리 테이블을 생성할 수도 있습니다.

제한

함수 호출이 호출에서 호출자로 전파되는 C++ 예외를 발생시키는 경우 동작이 정의되지 않습니다.

예외를 활성화하고 컴파일하지 않으면 이 한정자는 무시됩니다.



예제

struct S{

~S();};__declspec(nothrow) extern void f(void);void g(void){

S s;f();

}

추가 참고

• 2-60페이지의 --force_new_nothrow, --no_force_new_nothrow

• 5-14페이지의 ::operator new 함수의 사용

4.2.6 __declspec(notshared)

__declspec(notshared) 속성은 특정 클래스에서 가상 함수 테이블과 RTTI를 내보낼 수 없도록 방지합니다. 이 속성은 다른 옵션의 사용 여부에 관계 없이 적용됩니다. 예를 들어 --export_all_vtbl을 사용해도 __declspec(notshared)는 그대로 적용됩니다.

예제

struct __declspec(notshared) X{

virtual int f();}; // do not export thisint X::f(){

return 1;}struct Y : X{

virtual int g();}; // do export thisint Y::g(){

return 1;}



4.2.7 __declspec(thread)

__declspec(thread) 속성은 변수가 해당 스레드 저장 기간 동안 해당 스레드에서만 적용되도록 지정하여 스레드가 생성될 때까지 저장소가 자동으로 할당되도록 링커가 준비할 수 있게 합니다.

참고

__thread 키워드는 __declspec(thread)의 동의어로 지원됩니다.

제한

파일 범위 스레드 지역 변수는 동적으로 초기화될 수 없습니다.

예제

__declspec(thread) int i;__thread int j; // same as __decspec(thread) int j;



4.3 함수 속성

__attribute__ 키워드를 사용하면 변수 또는 구조체 필드, 함수 및 유형의 특별한 속성을 지정할 수 있습니다. 키워드의 형식은 다음 중 하나입니다.

__attribute__ ((attribute1, attribute2, ...))__attribute__ ((__attribute1__, __attribute2__, ...))


void * Function_Attributes_malloc_0(int b) __attribute__ ((malloc));static int b __attribute__ ((__unused__));

표 4-3에는 사용할 수 있는 함수 속성이 요약되어 있습니다.

표 4-3 컴파일러에서 지원하는 함수 속성 및 해당 항목

함수 속성 속성이 아닌 해당 항목

__attribute__((alias)) -

__attribute__((always_inline)) __forceinline

__attribute__((const)) __pure

__attribute__((deprecated)) -

__attribute__((malloc)) -

__attribute__((noinline)) __declspec(noinline)

__attribute__((no_instrument_function))

__attribute__((nomerge)) -

__attribute__((nonnull))

__attribute__((noreturn)) __declspec(noreturn))

__attribute__((notailcall)) -

__attribute__((pure)) -

__attribute__((unused)) -

__attribute__((used)) -

__attribute__((visibility("visibility_type")))

__attribute__((weak)) __weak



4.3.1 __attribute__((alias))

이 함수 속성을 사용하면 함수에 여러 개의 별칭을 지정할 수 있습니다.

현재 변환 단위에서 함수가 정의되면 별칭 호출은 함수에 대한 호출로 대체되고 별칭은 원래 이름과 함께 내보내집니다. 현재 변환 단위에서 함수가 정의되지 않으면 별칭 호출은 실제 함수에 대한 호출로 대체됩니다. 함수가 static으로 정의되면 함수 이름은 별칭 이름으로 대체되고, 별칭이 외부에서 선언된 경우 함수가 외부에서 선언됩니다.

참고

이 함수 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

참고

해당 변수 속성 __attribute__((alias))를 사용하여 변수 이름에 별칭을 지정할 수도 있습니다.

구문

return-type newname([argument-list]) __attribute__((alias("oldname")));

인수 설명:

oldname 별칭을 지정할 함수의 이름입니다.

newname 별칭을 지정할 함수의 새 이름입니다.

예제

#include <stdio.h>void foo(void){

printf("%s\n", __FUNCTION__);}void bar(void) __attribute__((alias("foo")));void gazonk(void){

bar(); // calls foo}

추가 참고

• 4-49페이지의 __attribute__((alias))



4.3.2 __attribute__((always_inline))

이 함수 속성은 함수가 인라인되어야 함을 나타냅니다.

컴파일러에서는 함수의 특성에 상관없이 함수를 인라인하려 합니다. 그러나 인라인하는 것이 문제를 일으키는 경우 컴파일러는 함수를 인라인하지 않습니다. 예를 들어 재귀 함수는 자체로 한 번만 인라인됩니다.

참고

이 함수 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다. 키워드에서는 __forceinline가 이 함수 속성에 해당합니다.

예제

static int max(int x, int y) __attribute__((always_inline)){

return x > y ? x : y; // always inline if possible}

추가 참고


• 4-7페이지의 __forceinline.

4.3.3 __attribute__((const))

많은 함수는 전달되는 인수만 검사하므로 반환 값을 제외하고는 영향을 주지 않습니다. 이것은 함수가 전역 메모리를 읽는 것이 허용되지 않기 때문에 __attribute__((pure))보다 훨씬 더 엄격한 클래스입니다. 함수가 인수에만 작동하는 것으로 알려져 있다면, 공통 하위식 제거와 루프 최적화가 필요할 수 있습니다.

참고

이 함수 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다. 키워드에서는 __pure가 이 함수 속성에 해당합니다.

예제

int Function_Attributes_const_0(int b) __attribute__ ((const));int Function_Attributes_const_2(int b){



int aLocal=0; aLocal += Function_Attributes_const_0(b); aLocal += Function_Attributes_const_0(b); return aLocal;}

이 코드에서 Function_Attributes_const_0은 한 번만 호출될 수 있으며 그 결과는 정확한 반환 값을 얻기 위해 2배가 됩니다.

추가 참고

• 4-39페이지의 __attribute__((pure))

• 컴파일러 사용 설명서의 5-14페이지의 __pure

4.3.4 __attribute__((deprecated))

이 함수 속성은 함수가 존재하지만 deprecated 함수가 사용될 경우 컴파일러에서 경고를 생성해야 함을 나타냅니다.

참고


예제

int Function_Attributes_deprecated_0(int b) __attribute__ ((deprecated));

4.3.5 __attribute__((malloc))

이 함수 속성은 함수가 malloc처럼 취급될 수 있고 연관된 최적화가 수행될 수 있음을 나타냅니다.

참고


예제

void * Function_Attributes_malloc_0(int b) __attribute__ ((malloc));



4.3.6 __attribute__((noinline))

이 함수 속성은 함수의 호출 지점에서 그 함수의 인라인을 억제합니다.

참고

이 함수 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다. 여기에는 __declspec(noinline)와 같은 __declspec가 있습니다.

예제

int fn(void) __attribute__((noinline));

int fn(void){

return 42;}

추가 참고

• 4-67페이지의 #pragma inline, #pragma no_inline

• 4-29페이지의 __declspec(noinline)

4.3.7 __attribute__((no_instrument_function))

이 함수 속성은 --gnu_instrument로 얻은 도구에서 함수를 제외시킵니다.

추가 참고

• 2-71페이지의 --gnu_instrument, --no_gnu_instrument

4.3.8 __attribute__((nomerge))

이 함수 속성은 소스에서 고유한 함수 호출이 객체 코드에서 결합되지 않도록 합니다.

추가 참고

• 4-39페이지의 __attribute__((notailcall))

• 2-119페이지의 --retain=option



4.3.9 __attribute__((nonnull))

이 함수 속성은 null 포인터가 될 수 없는 함수 매개 변수를 지정합니다. 이 속성을 사용하면 컴파일러에서 그러한 매개 변수가 발견될 경우 경고를 생성합니다.

참고


구문

__attribute__((nonnull(arg-index, ...)))

여기서 arg-index, ...는 인수 인덱스 목록입니다.

인수 인덱스 목록이 지정되지 않으면 모든 포인터 인수가 nonnull로 표시됩니다.

예제

다음은 이 속성을 사용한 선언의 예입니다.

void * my_memcpy (void *dest, const void *src, size_t len) __attribute__((nonnull (1, 2)));

void * my_memcpy (void *dest, const void *src, size_t len) __attribute__((nonnull));

4.3.10 __attribute__((noreturn))

이 함수 속성은 함수의 반환 값이 없음을 컴파일러에 알립니다. 그러면 컴파일러는 도달되지 않은 코드를 제거하여 최적화를 수행할 수 있습니다.

참고

이 함수 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다. 여기에는 __declspec(noreturn)과 같은 __declspec가 있습니다. 그러나 __attribute((noreturn)) 및 __declspec(noreturn)은 함수 정의를 컴파일할 때 함수가 명시적 또는 암시적 반환에 도달하면 __attribute((noreturn))는 무시되고 컴파일러가 경고를 생성하지만 __declspec(noreturn)은 그렇지 않다는 점에서 서로 다릅니다.

예제

int Function_Attributes_NoReturn_0(void) __attribute__ ((noreturn));



추가 참고

• 4-29페이지의 __declspec(noreturn)

4.3.11 __attribute__((notailcall))

이 함수 속성은 함수 마무리 호출을 수행할 수 없도록 합니다. 즉, 호출이 함수 끝에 수행되므로 이 함수는 분기를 통해 전송될 수 있는 경우에도 항상 분기 및 링크로 호출됩니다.

추가 참고

• 4-37페이지의 __attribute__((nomerge))

• 2-119페이지의 --retain=option

4.3.12 __attribute__((pure))

많은 함수들은 값을 반환하는 것을 제외하고 영향을 주지 않으며 반환 값은 매개변수와 전역 변수에 따라서만 달라집니다. 이런 종류의 함수는 데이터 흐름 분석이 필요할 수 있으며 제거될 수도 있습니다.

참고


이 함수 속성은 __pure 키워드와 관련이 있지만 이 키워드에 해당하지는 않습니다. __pure의 해당 항목 함수 속성은 __attribute__((const))입니다.

예제

int Function_Attributes_pure_0(int b) __attribute__ ((pure));int Function_Attributes_pure_0(int b){ static int aStatic; aStatic++; return b++;} int Function_Attributes_pure_2(int b){ int aLocal=0; aLocal += Function_Attributes_pure_0(b); return 0;}



이 예제에서 Function_Attributes_pure_0에 대한 호출은 결과가 사용되지 않기 때문에 제거될 수도 있습니다.

4.3.13 __attribute__((section("name")))

section 함수 속성을 사용하면 이미지의 여러 섹션에 코드를 배치할 수 있습니다.

참고


예제

다음 예제에서 Function_Attributes_section_0은 .text가 아니라 RO 섹션 new_section으로 배치됩니다.

void Function_Attributes_section_0 (void) __attribute__ ((section ("new_section")));

void Function_Attributes_section_0 (void){ static int aStatic =0; aStatic++;}

다음 예제에서 section 함수 속성은 #pragma arm section 설정을 재정의합니다.

#pragma arm section code="foo"int f2(){

return 1;} // into the 'foo' area__attribute__ ((section ("bar"))) int f3(){

return 1;} // into the 'bar' areaint f4(){

return 1;} // into the 'foo' area

#pragma arm section

추가 참고




4.3.14 __attribute__((unused))

unused 함수 속성은 함수가 참조되지 않을 경우 컴파일러가 경고를 생성하는 것을 방지합니다. 이것은 unused 함수 제거 프로세스의 동작을 변경하지 않습니다.

참고


예제

static int Function_Attributes_unused_0(int b) __attribute__ ((unused));

4.3.15 __attribute__((used))

이 함수 속성은 자신이 참조되지 않더라도 정적 함수가 객체 파일에 유지됨을 컴파일러에 알립니다.

사용됨으로 표시된 정적 함수는 선언된 순서대로 단일 섹션으로 내보내집니다. __attribute__((section))를 사용하여 함수가 배치되는 섹션을 지정할 수 있습니다.

참고


참고

__attribute__((used))를 사용하여 정적 변수를 사용됨으로 표시할 수도 있습니다.

예제

static int lose_this(int);static int keep_this(int) __attribute__((used)); // retained in object filestatic int keep_this_too(int) __attribute__((used)); // retained in object file

추가 참고


• 4-55페이지의 __attribute__((used))



4.3.16 __attribute__((visibility("visibility_type")))

이 함수 속성은 ELF 기호의 표시에 영향을 줍니다.

참고

이 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

구문


여기서 visibility_type은 다음 중 하나입니다.

default 기호 표시 설정은 다른 옵션에 따라 변경될 수 있습니다. 기본 표시는 이러한 변경에 우선 적용됩니다. 기본 표시는 외부 연결에 해당합니다.

hidden 이 기호는 동적 기호 테이블에 배치되지 않으므로 다른 실행 또는 공유 라이브러리에서 직접 참조할 수 없습니다. 함수 포인터를 사용하여 간접적으로 참조할 수도 있습니다.

internal psABI(프로세서 특정 응용 프로그램 바이너리 인터페이스)에 의해 별도로 지정되지 않는 한 내부 표시는 함수가 다른 모듈에서 호출되지 않는다는 것을 의미합니다.

protected 이 기호는 동적 기호 테이블에 배치되지만 정의 모듈 내에서의 참조는 지역 기호에 바인드됩니다. 즉, 다른 모듈에서 이 기호를 재정의할 수 없습니다.

사용법

default 표시를 지정하는 경우를 제외하고 이 속성은 외부 연결을 갖는 선언에 사용됩니다.

이 속성을 C 및 C++에서 사용할 수 있습니다. C++에서 이 속성은 형식, 구성원 함수 및 네임스페이스 선언에도 적용됩니다.



예제

void __attribute__((visibility(“internal” ))) foo(){

...}

추가 참고


• 4-56페이지의 __attribute__((visibility("visibility_type")))

4.3.17 __attribute__((weak))

__attribute__((weak))로 정의된 함수는 기호를 weak로 내보냅니다.

__attribute__((weak))로 선언된 함수가 __attribute__((weak)) 없이 정의될 경우 weak 함수처럼 동작합니다. 이것은 __weak 키워드와 동일한 동작이 아닙니다.

참고


예제

extern int Function_Attributes_weak_0 (int b) __attribute__ ((weak));

추가 참고

• 4-23페이지의 __weak



4.4 유형 속성





표 4-4에는 사용할 수 있는 유형 속성이 요약되어 있습니다.

4.4.1 __attribute__((bitband))

__attribute__((bitband)) 형식 속성은 메모리 아키텍처의 SRAM 및 주변 기기 영역에서 단일 비트 값에 대한 원자적 액세스를 효율적으로 수행할 수 있도록 합니다. 기존의 읽기, 수정 및 쓰기 방식을 사용하는 대신 단일 메모리 액세스로 특정 메모리 영역에 바로 단일 비트를 설정 또는 해제할 수 있습니다. 또한 기존의 읽기 다음에 시프트 및 마스크 작업을 수행하지 않고 직접 단일 비트를 읽을 수도 있습니다. 예제 4-6에 __attribute__((bitband))의 사용법이 나와 있습니다.

예제 4-6 __attribute__((bitband)) 사용

typedef struct {int i: 1;int j: 2;int k: 3;

} BB __attribute__((bitband));

표 4-4 컴파일러에서 지원하는 유형 속성 및 해당 항목

유형 속성 속성이 아닌 해당 항목

__attribute__((bitband)) -

__attribute__((aligned)) __align

__attribute__((packed)) __packeda

a. __packed 한정자는 GNU 모드의 유형에 영향을 주지 않습니다.

__attribute__((transparent_union)) -



BB bb __attribute__((at(0x20000004)));

void foo(void){

bb.i = 1;}

너비를 구분하는 주변 기기의 경우 별칭 공간에 대한 바이트, 하프워드 및 워드 저장 또는 로드가 char, short 및 int 형식의 비트 밴딩 구조체 비트 필드에 대해 각각 생성됩니다.

예제 4-7에서 bb.i에 대해 비트 밴딩 액세스가 생성됩니다.

예제 4-7 비트 필드 비트 밴딩 액세스

typedef struct {char i: 1;int j: 2;int k: 3;

} BB __attribute__((bitband));

BB bb __attribute__((at(0x20000004)));

void foo(){

bb.i = 1;}

비트 밴딩 영역에 비트 밴딩 변수를 배치할 때 __attribute__((at()))를 사용하지 않으려면 다른 방법을 사용하여 재배치해야 합니다. 그러려면 해당 분산 로드 설명 파일이나 --rw_base 링커 명령 행 옵션을 사용해야 합니다. 자세한 내용은 링커 참조 설명서를 참조하십시오.

제한

다음 제한이 적용됩니다.

• 이 형식 속성은 struct에만 사용할 수 있습니다. 모든 공용체 또는 공용체를 구성원으로 포함하는 집계 형식은 비트 밴딩할 수 없습니다.

• 구조체 구성원은 개별적으로 비트 밴딩할 수 없습니다.



• 단일 비트의 비트 필드에 대해서만 비트 밴딩 액세스가 생성됩니다.

• const 객체, 포인터 및 지역 개체에 대해서는 비트 밴딩 액세스가 생성되지 않습니다.

추가 참고

• 4-50페이지의 __attribute__((at(address)))

• 컴파일러 사용 설명서의 4-16페이지의 비트 밴딩

• 해당 프로세서의 기술 참조 문서

4.4.2 __attribute__((aligned))

aligned 유형 속성은 유형의 최소 정렬을 지정합니다.

참고

이 유형 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

4.4.3 __attribute((packed))

packed 유형 속성은 유형에 가능한 최소 정렬이 있어야 한다고 지정합니다.

참고


오류

typedef에서 이 속성을 사용하는 경우 컴파일러는 경고 메시지를 생성합니다.

추가 참고








4.4.4 __attribute__((transparent_union))

transparent_union 유형 속성을 사용하면 __attribute__((transparent_union))__로 정규화된 공용체 데이터 유형인 transparent_union 유형을 지정할 수 있습니다.

함수가 투명한 공용체 유형의 매개변수로 정의되는 경우 공용체에 포함된 임의 유형의 인수를 사용하는 함수를 호출하면 전달된 인수의 유형이 있고 해당 값이 전달된 인수의 값으로 설정된 구성원이 포함된 공용체 객체가 초기화됩니다.

__attribute__((transparent_union))로 정규화된 공용체 데이터 유형의 경우 해당 유형의 모든 함수 매개변수에 투명한 공용체가 적용됩니다.

참고


참고

각 함수 매개변수는 해당 __attribute__((transparent_union)) 변수 속성으로 정규화될 수도 있습니다.

예제

typedef union { int i; float f; } U __attribute__((transparent_union));void foo(U u){

static int s;s += u.i; /* Use the 'int' field */

}void caller(void){

foo(1); /* u.i is set to 1 */foo(1.0f); /* u.f is set to 1.0f */

}

모드

GNU 모드에서만 지원됩니다.

추가 참고

• 4-53페이지의 __attribute__((transparent_union))



4.5 변수 속성





4-33페이지의 표 4-3에는 사용 가능한 변수 속성이 요약되어 있습니다.

표 4-5 컴파일러에서 지원하는 변수 속성 및 해당 항목

변수 속성 속성이 아닌 해당 항목

__attribute__((alias)) -

__attribute__((at(address))) -

__attribute__((aligned)) -

__attribute__((deprecated)) -

__attribute__((packed)) -

__attribute__((section(“name”))) -

__attribute__((transparent_union)) -

__attribute__((unused)) -

__attribute__((used)) -

__attribute__((weak)) __weak


__attribute__((zeroinit)) -



4.5.1 __attribute__((alias))

이 변수 속성을 사용하면 변수에 여러 개의 별칭을 지정할 수 있습니다.

현재 변환 단위에서 변수가 정의되면 별칭 참조는 변수에 대한 참조로 대체되고 별칭은 원래 이름과 함께 내보내집니다. 현재 변환 단위에서 변수가 정의되지 않으면 별칭 참조는 실제 변수에 대한 참조로 대체됩니다. 변수가 static으로 정의되면 변수 이름은 별칭 이름으로 대체되고 별칭이 외부에서 선언되면 변수는 외부에서 선언됩니다.

참고

해당 함수 속성 __attribute__((alias))를 사용하여 함수 이름에 별칭을 지정할 수도 있습니다.

구문

type newname __attribute__((alias("oldname")));

인수 설명:

oldname 별칭을 지정할 변수의 이름입니다.

newname 별칭이 지정된 변수의 새 이름입니다.

예제

#include <stdio.h>int oldname = 1;extern int newname __attribute__((alias("oldname"))); // declarationvoid foo(void){

printf("newname = %d\n", newname); // prints 1}

추가 참고

• 4-34페이지의 __attribute__((alias))



4.5.2 __attribute__((at(address)))

이 변수 속성을 사용하면 변수의 절대 주소를 지정할 수 있습니다.

변수는 자체 섹션에 배치되며 변수를 포함하는 섹션에는 컴파일러에 의해 적절한 유형이 지정됩니다.

• 읽기 전용 변수는 RO 유형의 섹션에 배치됩니다.

• 초기화된 읽기쓰기 변수는 RW 유형의 섹션에 배치됩니다.

특히 명시적으로 0으로 초기화된 변수는 ZI가 아니라 RW에 배치됩니다. 이러한 변수는 컴파일러에 의해 ZI에서 RW로 최적화되지 않습니다.

• 초기화되지 않은 변수는 ZI 유형의 섹션에 배치됩니다.

참고

이 변수 속성은 GNU 컴파일러에서 지원하지 않습니다.

구문

__attribute__((at(address)))

인수 설명:

address 원하는 변수 주소입니다.

제한

링커는 at 변수 속성에 의해 생성되는 섹션을 배치하지 못할 수도 있습니다.

오류

지정된 주소에 섹션을 배치할 수 없는 경우 링커는 오류 메시지를 생성합니다.

예제

const int x1 __attribute__((at(0x10000))) = 10; /* RO */int x2 __attribute__((at(0x12000))) = 10; /* RW */int x3 __attribute__((at(0x14000))) = 0; /* RW, not ZI */int x4 __attribute__((at(0x16000))); /* ZI */



추가 참고

• 링커 사용 설명서의 5-17페이지의 __at 섹션을 사용하여 특정 주소에 섹션 배치

4.5.3 __attribute__((aligned))

aligned 변수 속성은 변수 또는 구조체 필드의 최소 정렬(바이트)을 지정합니다.

참고

이 변수 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

예제

int Variable_Attributes_aligned_0 __attribute__ ((aligned (16)));/* aligned on 16 byte boundary */short Variable_Attributes_aligned_1[3] __attribute__ ((aligned));/* aligns on 4 byte boundary for ARM */

추가 참고

• 4-2페이지의 __align.

4.5.4 __attribute__((deprecated))

deprecated 변수 속성은 컴파일러가 경고나 오류를 발생시키지 않고 제공되지 않을 변수를 선언하게 해줍니다. 그러나 deprecated 변수에 액세스할 경우 경고는 발생하지만 컴파일은 계속 진행됩니다. 경고에서는 변수가 사용된 위치와 변수가 정의된 위치를 제공합니다. 이로써 특정 정의가 제공되지 않는 이유를 알 수 있습니다.

참고


예제

extern int Variable_Attributes_deprecated_0 __attribute__ ((deprecated));extern int Variable_Attributes_deprecated_1 __attribute__ ((deprecated));void Variable_Attributes_deprecated_2(){



Variable_Attributes_deprecated_0=1; Variable_Attributes_deprecated_1=2;}

이 예제를 컴파일하면 두 개의 경고 메시지가 생성됩니다.

4.5.5 __attribute__((packed))

packed 변수 속성은 변수나 구조체 필드가 가능한 최소 정렬을 갖도록 지정합니다. 즉, aligned 속성을 사용하여 더 큰 값을 지정하지 않는 한 변수의 경우 1바이트가 되고 필드의 경우 1비트가 됩니다.

참고


예제

struct{ char a; int b __attribute__ ((packed));} Variable_Attributes_packed_0;

추가 참고





4.5.6 __attribute__((section("name")))

일반적으로 ARM 컴파일러는 생성한 객체를 data 및 bss와 같은 섹션에 배치합니다. 그러나 추가 데이터 섹션이 필요할 수도 있고 또는 변수를 특별 섹션에 배치하여 특별 하드웨어에 매핑하기를 원할 수도 있습니다. section 속성은 변수가 특정 데이터 섹션에 배치되도록 지정합니다. section 속성을 사용할 경우, zero_init



속성을 사용하지 않는 한, 읽기 전용 변수는 RO 데이터 섹션에 배치되고 읽기-쓰기 변수는 RW 데이터 섹션에 배치됩니다. 다음과 같은 경우 변수는 ZI 섹션에 배치됩니다.

참고


예제

/* in RO section */const int descriptor[3] __attribute__ ((section ("descr"))) = { 1,2,3 };/* in RW section */long long rw[10] __attribute__ ((section ("RW")));/* in ZI section *long long altstack[10] __attribute__ ((section ("STACK"), zero_init));/

4.5.7 __attribute__((transparent_union))

공용체인 함수 매개변수에 첨부되는 transparent_union 변수 속성은 해당 인수가 모든 공용체 구성원의 유형을 가질 수 있다는 것을 의미하지만, 이 인수는 그 유형이 첫 번째 공용체 구성원의 유형인 것처럼 전달됩니다.

참고

C 사양에서는 공용체가 하나의 유형으로 작성될 때 값이 반환되고 다른 유형을 사용하여 다시 읽혀진 값은 정의되지 않는다고 지정합니다. 따라서 transparent_union이 어떤 유형으로 작성되는지 구분하는 방법도 인수로 전달되어야 합니다.

참고


참고

공용체 데이터 유형에 대해 typedef에서 이 속성을 사용할 수도 있습니다. 이 경우 이 속성은 해당 유형을 가진 모든 함수 매개변수에 적용됩니다.

모드

GNU 모드에서만 지원됩니다.



예제

typedef union{ int myint; float myfloat;} transparent_union_t;void Variable_Attributes_transparent_union_0(transparent_union_t aUnion __attribute__ ((transparent_union))){ static int aStatic; aStatic +=aUnion.myint;}void Variable_Attributes_transparent_union_1(){ int aLocal =0; float bLocal =0; Variable_Attributes_transparent_union_0(aLocal); Variable_Attributes_transparent_union_0(bLocal);}

추가 참고


4.5.8 __attribute__((unused))

일반적으로 컴파일러는 변수가 선언되지만 참조되지 않을 경우 경고합니다. 이 속성은 변수가 사용되지 않을 것을 기대하고 있음을 통보하고 사용되지 않더라도 경고를 발생하지 말라고 컴파일러에 알립니다.

참고


예제

void Variable_Attributes_unused_0(){ static int aStatic =0; int aUnused __attribute__ ((unused)); int bUnused; aStatic++;}



이 예제에서 컴파일러는 bUnused가 선언되었지만 참조되지 않는다고 경고하지만 aUnused에 대해서는 경고하지 않습니다.

참고

GNU 컴파일러는 경고를 발생시키지 않습니다.

4.5.9 __attribute__((used))

이 변수 속성은 자신이 참조되지 않더라도 정적 변수가 객체 파일에 유지됨을 컴파일러에 알립니다.

사용됨으로 표시된 정적 변수는 선언된 순서대로 단일 섹션으로 내보내집니다. __attribute__((section))를 사용하여 변수가 배치되는 섹션을 지정할 수 있습니다.

참고


참고

__attribute__((used))를 사용하여 정적 함수를 사용됨으로 표시할 수도 있습니다.

사용법

__attribute__((used))를 사용하여 객체에 테이블을 빌드할 수 있습니다.

예제

static int lose_this = 1;static int keep_this __attribute__((used)) = 2; // retained in object filestatic int keep_this_too __attribute__((used)) = 3; // retained in object file

추가 참고


• 4-41페이지의 __attribute__((used))



4.5.10 __attribute__((visibility("visibility_type")))

이 변수 속성은 ELF 기호의 표시에 영향을 줍니다.

참고

이 속성은 ARM 컴파일러에서 지원하는 GNU 컴파일러 확장입니다.

visibility_type은 동일한 이름의 함수 속성으로 지정된 값과 같은 값을 사용할 수 있습니다.

예제

int i __attribute__((visibility(“hidden” )));

추가 참고


• 4-42페이지의 __attribute__((visibility("visibility_type")))

4.5.11 __attribute__((weak))

weak 변수의 선언이 허용되며 __weak와 유사하게 동작합니다.

• GNU 모드에서는 다음과 같이 사용합니다.

extern int Variable_Attributes_weak_1 __attribute__((weak));

• 비 GNU 모드의 해당 항목에서는 다음과 같이 사용합니다.

__weak int Variable_Attributes_weak_compare;

참고

GNU 모드에서는 extern 한정자가 필요합니다. 비 GNU 모드에서 컴파일러는 변수가 extern이 아닐 경우 비 weak 변수처럼 처리된다고 간주됩니다.

참고


추가 참고

• 4-23페이지의 __weak



4.5.12 __attribute__((zero_init))

section 속성은 변수가 특정 데이터 섹션에 배치되도록 지정합니다. zero_init 속성은 이니셜라이저가 없는 변수가 ZI 데이터 섹션에 배치되도록 지정합니다. 이니셜라이저 가 지정될 경우 오류가 보고됩니다.

예제

__attribute__((zero_init)) int x; /* in section ".bss" */__attribute__((section("mybss"), zero_init)) int y; /* in section "mybss" */

추가 참고




4.6 Pragma

ARM 컴파일러는 여러 가지 ARM 관련 pragma를 인식합니다. 표 4-6에는 사용 가능한 pragma가 요약되어 있습니다.

참고

Pragma는 관련 명령 행 옵션을 재정의합니다. 예를 들어 #pragma arm은 명령 행 옵션 --thumb을 재정의합니다.

표 4-6 컴파일러에서 지원하는 Pragma

Pragma

#pragma anon_unions, #pragma no_anon_unions

#pragma hdrstop #pragma Otime

#pragma arm #pragma import symbol_name #pragma pack(n)

#pragma arm section

[section_sort_list]#pragma import(__use_full_stdio)

#pragma pop

#pragma diag_default tag[,tag,...]

#pragma inline, #pragma no_inline

#pragma push

#pragma diag_error tag[,tag,...]

#pragma no_pch #pragma softfp_linkage, no_softfp_linkage

#pragma diag_remark tag[,tag,...]

#pragma Onum #pragma unroll [(n)]

#pragma diag_suppress tag[,tag,...]

#pragma once #pragma unroll_completely

#pragma diag_warning tag[,tag,...]

#pragma hdrstop #pragma thumb

#pragma [no_]exceptions_unwind

#pragma Ospace



4.6.1 #pragma anon_unions, #pragma no_anon_unions

이 pragma를 사용하면 익명 구조체와 공용체에 대한 지원을 설정하거나 해제할 수 있습니다.

기본값

기본값은 #pragma no_anon_unions입니다.

추가 참고

• 3-21페이지의 익명 클래스, 구조체 및 공용체


4.6.2 #pragma arm

이 pragma는 코드 생성을 ARM 명령어 세트로 전환하며 --thumb 컴파일러 옵션을 재정의합니다.

추가 참고




4.6.3 #pragma arm section [section_sort_list]

이 pragma는 후속 함수나 객체에 섹션 이름을 사용하도록 지정합니다. 여기에는 컴파일러가 초기화를 위해 생성하는 익명 객체의 정의가 포함됩니다.

참고

#pragma arm section의 대체 방법으로 함수나 변수에 대해 __attribute__((section(..)))를 사용할 수 있습니다.



구문

#pragma arm section [section_sort_list]

인수 설명:

section_sort_list. 후속 함수나 객체에 사용할 선택적 섹션 이름 목록을 지정합니다. section_sort_list의 구문은 다음과 같습니다.

section_type[[=]"name"] [,section_type="name"]*

사용할 수 있는 섹션 형식은 다음과 같습니다.

• code

• rodata

• rwdata

• zidata

사용법

ARM 링커와 함께 스캐터 로딩 설명 파일을 사용하여 명명된 섹션을 메모리의 특정 주소에 배치하는 방식을 제어할 수 있습니다.

제한

이 옵션은 다음 사항에 영향을 주지 않습니다.

• 인라인 함수 및 해당 지역 정적 변수

• 템플릿 인스턴스 생성 및 해당 지역 정적 변수

• 사용하지 않는 변수 및 함수 제거. 그러나 #pragma arm section을 사용하면 사용하는 함수나 변수와 동일한 섹션에 있기 때문에 유지되는 함수나 변수를 링커가 제거할 수 있습니다.

• 객체 파일에 정의가 기록되는 순서

예제

int x1 = 5; // in .data (default)int y1[100]; // in .bss (default)int const z1[3] = {1,2,3}; // in .constdata (default)#pragma arm section rwdata = "foo", rodata = "bar"int x2 = 5; // in foo (data part of region)int y2[100]; // in .bssint const z2[3] = {1,2,3}; // in bar



char *s2 = "abc"; // s2 in foo, "abc" in .conststring#pragma arm section rodataint x3 = 5; // in fooint y3[100]; // in .bssint const z3[3] = {1,2,3}; // in .constdatachar *s3 = "abc"; // s3 in foo, "abc" in .conststring#pragma arm section code = "foo"int add1(int x) // in foo (code part of region){

return x+1;} #pragma arm section code

추가 참고


• 링커 사용 설명서의 5장 스캐터 로딩 설명 파일 사용

4.6.4 #pragma diag_default tag[,tag,...]

이 pragma는 지정된 태그가 있는 진단 메시지의 심각도를 pragma가 표시되기 전에 유효하던 심각도로 되돌립니다.

구문

#pragma diag_default tag[,tag,...]

인수 설명:


최소한 한 개의 진단 메시지 번호가 지정되어야 합니다.

예제

// <stdio.h> not #included deliberately#pragma diag_error 223void hello(void){

printf("Hello ");}#pragma diag_default 223void world(void){

printf("world!\n");}



--diag_warning=223 옵션을 사용하여 이 코드를 컴파일하면 printf() 함수가 암시적으로 선언됨을 보고하는 진단 메시지가 생성됩니다.

#pragma diag_default 223은 --diag_warning 명령 행 옵션에서 지정한 대로 진단 메시지 223의 심각도를 경고 수준으로 되돌리기 위한 것입니다.

추가 참고


• #pragma diag_error tag[,tag,...]




• 컴파일러 사용 설명서의 6-4페이지의 진단 메시지의 출력 제어

4.6.5 #pragma diag_error tag[,tag,...]

이 pragma는 지정한 태그가 있는 진단 메시지를 오류 심각도로 설정합니다.

구문

#pragma diag_error tag[,tag,...]

인수 설명:


최소한 한 개의 진단 메시지 번호가 지정되어야 합니다.

추가 참고


• 4-61페이지의 #pragma diag_default tag[,tag,...]







4.6.6 #pragma diag_remark tag[,tag,...]

이 pragma는 지정된 태그가 있는 진단 메시지를 설명 수준으로 설정합니다.

#pragma diag_remark는 컴파일러에서 지정된 태그가 있는 진단 메시지를 오류 심각도 대신 설명 수준으로 설정한다는 점을 제외하고 #pragma diag_errors와 유사하게 동작합니다.

참고

설명은 기본적으로 표시되지 않습니다. 설명 메시지를 보려면 --remarks 컴파일러 옵션을 사용하십시오.

구문

#pragma diag_remark tag[,tag,...]

인수 설명:


추가 참고










4.6.7 #pragma diag_suppress tag[,tag,...]

이 pragma는 지정된 태그가 있는 모든 진단 메시지를 표시하지 않습니다.

#pragma diag_suppress는 컴파일러에서 지정된 태그가 있는 진단 메시지를 오류 심각도로 설정하는 대신 해당 메시지가 표시되지 않도록 한다는 점을 제외하고 #pragma diag_errors와 유사하게 동작합니다.

구문

#pragma diag_suppress tag[,tag,...]

인수 설명:

tag[,tag,...] 표시하지 않을 메시지를 지정하는 진단 메시지 번호에 대한 콤마로 구분된 목록입니다.

추가 참고





• #pragma diag_warning tag[, tag, ...]

• 컴파일러 사용 설명서의 6-6페이지의 진단 메시지 표시 안 함

4.6.8 #pragma diag_warning tag[, tag, ...]

이 pragma는 지정된 태그가 있는 진단 메시지를 경고 수준으로 설정합니다.

#pragma diag_remark는 컴파일러에서 지정된 태그가 있는 진단 메시지를 오류 심각도가 아닌 설명 수준으로 설정하는 것을 제외하고 #pragma diag_errors와 유사하게 동작합니다.

구문

#pragma diag_warning tag[,tag,...]

인수 설명:




추가 참고







4.6.9 #pragma exceptions_unwind, #pragma no_exceptions_unwind

이 pragma는 런타임 시 함수 해제를 활성화 및 비활성화할 수 있습니다.

기본값

기본값은 #pragma exceptions_unwind입니다.

추가 참고


• 2-57페이지의 --exceptions_unwind, --no_exceptions_unwind

• 5-19페이지의 런타임 시 함수 해제

4.6.10 #pragma hdrstop

이 pragma를 사용하면 사전 컴파일 헤더 파일의 세트가 끝나는 위치를 지정할 수 있습니다.

이 pragma는 사전 처리 지시어에 속하지 않은 첫 번째 토큰 앞에 있어야 합니다.

추가 참고




4.6.11 #pragma import symbol_name

이 pragma는 symbol_name에 대한 가져오기 참조를 생성합니다. 이는 다음 어셈블러 지시어와 같습니다.

IMPORT symbol_name

구문

#pragma import symbol_name

인수 설명:

symbol_name 가져올 기호입니다.

사용법

이 pragma를 사용하여 힙 구현 또는 실시간 나누기와 같은 C 라이브러리의 특정 기능을 선택할 수 있습니다. 이 설명서에 설명하는 기능을 사용하기 위해 기호 참조를 가져와야 할 경우에는 필요한 기호가 지정됩니다.

추가 참고

• 라이브러리 및 부동 소수점 지원 설명서의 2-21페이지의 C 라이브러리로 응용 프로그램 빌드

4.6.12 #pragma import(__use_full_stdio)

이 pragma는 전체 표준 ANSI C 입력 및 출력 기능을 사용하는 microlib의 확장 버전을 선택합니다.

다음 예외가 적용됩니다.

• feof() 및 ferror()는 항상 0을 반환합니다

• setvbuf() 및 setbuf()는 항상 실패합니다

feof() 및 ferror()는 항상 0을 반환합니다. 오류 및 파일 끝 표시기가 지원되지 않기 때문입니다.

setvbuf() 및 setbuf()는 항상 실패합니다. 모든 스트림이 버퍼링되지 않기 때문입니다.

이 microlib stdio 버전은 standardlib stdio 함수와 같은 방식으로 다시 타겟으로 지정할 수 있습니다.



추가 참고

• 2-85페이지의 --library_type=lib

• 라이브러리 및 부동 소수점 지원 설명서의 3장 C 마이크로 라이브러리

• 라이브러리 및 부동 소수점 지원 설명서의 2-87페이지의 입력/출력 함수 조정

4.6.13 #pragma inline, #pragma no_inline

이 pragma는 --inline 및--no_inline 명령 행 옵션과 유사하게 인라인을 제어합니다. #pragma no_inline에서 정의된 함수는 다른 함수로 인라인되지 않고 자신의 호출로도 인라인되지 않습니다.

다른 함수로의 인라인을 수행하지 않아 발생하는 결과는 함수를 __declspec(noinline) 또는 __attribute__((noinline))로 표시하여 얻을 수도 있습니다.

기본값

기본값은 #pragma inline입니다.

추가 참고


• 4-29페이지의 __declspec(noinline)

• 4-37페이지의 __attribute__((noinline))

4.6.14 #pragma no_pch

이 pragma는 해당 소스 파일에 대해 PCH 처리를 하지 않습니다.

추가 참고





4.6.15 #pragma Onum

이 pragma는 최적화 수준을 변경합니다.

구문

#pragma Onum

인수 설명:

num 새로운 최적화 수준입니다.

num의 값은 0, 1, 2 또는 3입니다.

추가 참고


4.6.16 #pragma once

이 pragma를 사용하면 컴파일러가 해당 헤더 파일을 더 이상 포함하지 않습니다.

#pragma once는 다른 컴파일러와의 호환성을 위해 허용되며 다른 형식의 헤더 가드 코딩을 사용할 수 있도록 합니다. 그렇지만 이식성이 우수하기 때문에 #ifndef 및 #define 코딩을 사용하는 것이 더 좋습니다.

예제

다음 예제에서는 #ifndef 뒤에 가드 변수의 #define을 배치하여 #ifndef 가드를 파일 본문 주위에 배치하는 것을 보여 줍니다.

#ifndef FILE_H#define FILE_H#pragma once // optional ... body of the header file ...#endif

이 예제에서 #pragma once는 선택 사항으로 표시됩니다. 이는 컴파일러가 #ifndef 헤더 가드 코딩을 인식하고 #pragma once가 없더라도 이후에는 포함시키지 않기 때문입니다.



4.6.17 #pragma Ospace

이 pragma는 실행 시간이 늘어나더라도 이미지 크기를 줄이기 위해 최적화를 수행하도록 컴파일러에 지시합니다.

추가 참고

• #pragma Otime


4.6.18 #pragma Otime

이 pragma는 이미지 크기가 증가할 가능성이 있는 대신 실행 시간을 줄이기 위해 최적화를 수행하도록 컴파일러에 지시합니다.

추가 참고

• #pragma Ospace


4.6.19 #pragma pack(n)

이 pragma는 구조체 구성원을 최소값인 n 및 해당 기본 정렬로 정렬합니다. 패킹된 객체는 정렬되지 않은 액세스를 사용하여 읽히고 쓰여집니다.

구문

#pragma pack(n)

인수 설명:

n 바이트 단위의 정렬입니다. 사용 가능한 정렬 값은 1, 2, 4 및 8입니다.

기본값

기본값은 #pragma pack(8)입니다.

예제

이 예제에서는 pack(2)가 정수 변수 b를 2바이트 단위로 정렬하는 방법을 보여 줍니다.



typedef struct{

char a;int b;

} S;

#pragma pack(2)

typedef struct{

char a;int b;

} SP;

S var = { 0x11, 0x44444444 };SP pvar = { 0x11, 0x44444444 };

S의 레이아웃은 그림 4-1에 나와 있고, SP의 레이아웃은 그림 4-2에 나와 있습니다. 그림 4-2에서 x는 1바이트의 패딩을 나타냅니다.

그림 4-1 패킹되지 않은 구조체 S

그림 4-2 패킹된 구조체 SP

참고

SP는 6바이트 구조체로, b 뒤에는 패딩이 없습니다.

추가 참고


• 4-52페이지의 __attribute__((packed))


a

b

0 1 2 3

bb b4

padding5 6 7

a

b

0 1 2 3

b4 5

x b b





4.6.20 #pragma pop

이 pragma는 이전에 저장된 pragma 상태를 복원합니다.

추가 참고

• #pragma push

4.6.21 #pragma push

이 pragma는 현재 pragma 상태를 저장합니다.

추가 참고

• #pragma pop

4.6.22 #pragma softfp_linkage, #pragma no_softfp_linkage

이 pragma는 소프트웨어 부동 소수점 연결을 제어합니다.

#pragma softfp_linkage는 다음 #pragma no_softfp_linkage까지 모든 함수 선언이 소프트웨어 부동 소수점 연결을 사용하는 함수를 설명하도록 지정합니다.

참고

키워드에서는 __softfp가 이 pragma에 해당합니다.

사용법

이 pragma는 해당 파일을 변경하지 않은 채 헤더 파일에 있는 전체 인터페이스 사양에 적용될 경우 유용할 수 있습니다.

기본값

기본값은 #pragma no_softfp_linkage입니다.



추가 참고

• 4-17페이지의 __softfp


4.6.23 #pragma unroll [(n)]

이 pragma는 n번의 이터레이션으로 루프를 언롤링하도록 컴파일러에 지시합니다.

참고

벡터화된 루프와 벡터화되지 않은 루프 모두 #pragma unroll [(n)]을 사용하여 언롤링할 수 있습니다. 즉, #pragma unroll [(n)]은 --vectorize 및 --no_vectorize에 모두 적용됩니다.

구문

#pragma unroll

#pragma unroll (n)

인수 설명:

n 언롤링할 이터레이션 수를 나타내는 선택적인 값입니다.

기본값

n에 값을 지정하지 않으면 컴파일러는 #pragma unroll (4)로 간주합니다.

사용법

-O3 -Otime에서 컴파일하는 경우 컴파일러는 이러한 수행에 적합한 위치에 있는 루프를 자동으로 언롤링합니다. 이 pragma를 사용하면 자동으로 언롤링되지 않은 루프를 언롤링하도록 컴파일러에 요청할 수 있습니다.

참고

이 #pragma는 확실한 경우에만 사용해야 합니다. 예를 들어 컴파일러가 자체적으로 루프를 언롤링하지 않는 --diag_warning=optimizations에서 사용할 수 있습니다.



제한

#pragma unroll [(n)]은 for 루프, while 루프 또는 do ... while 루프 바로 앞에만 사용할 수 있습니다.

예제

void matrix_multiply(float ** __restrict dest, float ** __restrict src1,float ** __restrict src2, unsigned int n)

{unsigned int i, j, k;for (i = 0; i < n; i++){

for (k = 0; k < n; k++){

float sum = 0.0f;/* #pragma unroll */for(j = 0; j < n; j++)

sum += src1[i][j] * src2[j][k];dest[i][k] = sum;

}}

}

이 예제에서 src2가 src2[j][k]로 인덱싱되어 있는 데 루프는 반대 순서(즉, k 내부에 j가 위치)로 중첩되어 있으므로 대개 컴파일러는 해당 루프를 완료하지 못합니다. #pragma unroll 주석을 이 예제에서 제거하면 컴파일러는 루프 언롤링을 4번 수행합니다.

크기가 4의 배수가 아닌 매트릭스를 증가시키려는 경우(예: n * n 매트릭스) #pragma unroll (m)을 대신 사용할 수 있습니다. 여기서 m은 n이 m의 정수 배수가 되도록 하는 값입니다.

추가 참고

• 2-51페이지의 --diag_warning=optimizations



• 2-140페이지의 --vectorize, --no_vectorize

• 4-74페이지의 #pragma unroll_completely

• 컴파일러 사용 설명서의 5-4페이지의 루프 최적화



4.6.24 #pragma unroll_completely

이 pragma는 루프를 완전히 언롤링하도록 컴파일러에 지시합니다. 이는 루프에 있는 이터레이션 수를 컴파일러가 결정할 수 있는 경우에만 적용됩니다.

참고

벡터화된 루트와 벡터화되지 않은 루프 모두 #pragma unroll_completely를 사용하여 언롤링할 수 있습니다. 즉, #pragma unroll_completely는 --no_vectorize 및 --vectorize에 모두 적용됩니다.

사용법

-O3 -Otime에서 컴파일하면 컴파일러는 이러한 수행에 적합한 위치에 있는 루프를 자동으로 언롤링합니다. 이 pragma를 사용하여 자동으로 완전히 언롤링되지 않은 루프를 완전히 언롤링하도록 컴파일러에 요청할 수 있습니다.

참고

이 #pragma는 확실한 경우에만 사용해야 합니다. 예를 들어 컴파일러가 자체적으로 루프를 언롤링하지 않는 --diag_warning=optimizations에서 사용할 수 있습니다.

제한

#pragma unroll_completely는 for 루프, while 루프 또는 do ... while 루프 바로 앞에만 사용할 수 있습니다.

외부 루프에 #pragma unroll_completely를 사용하면 벡터화를 방지할 수 있습니다. 즉 내부 루프에 #pragma unroll_completely를 사용하면 어떤 경우에는 도움이 될 수도 있습니다.

추가 참고

• 2-51페이지의 --diag_warning=optimizations



• 2-140페이지의 --vectorize, --no_vectorize

• 4-72페이지의 #pragma unroll [(n)]

• 컴파일러 사용 설명서의 5-4페이지의 루프 최적화



4.6.25 #pragma thumb

이 pragma는 코드 생성을 Thumb 명령어 세트로 전환하며 --arm 컴파일러 옵션을 재정의합니다.

Thumb-2 이전 프로세서에 대한 코드를 컴파일하고 VFP를 사용하는 경우 부동 소수점 연산이 포함된 모든 함수가 ARM에 대해 컴파일됩니다.

추가 참고






4.7 명령어 내장 함수

이 단원에서는 C 또는 C++ 코드에서 ARM 기계 언어 명령어를 인식하는 데 필요한 명령어 내장 함수에 대해 설명합니다. 표 4-7에는 사용 가능한 내장 함수가 요약되어 있습니다.

4-120페이지의 GNU 기본 제공 함수도 참조하십시오.

표 4-7 ARM 컴파일러에서 지원하는 명령어 내장 함수

명령어 내장 함수

__breakpoint __ldrt __schedule_barrier

__cdp __memory_changed __semihost

__clrex __nop __sev

__clz __pld __sqrt

__current_pc __pldw __sqrtf

__current_sp __pli __ssat

__disable_fiq __promise __strex

__disable_irq __qadd __strexd

__enable_fiq __qdbl __strt

__enable_irq __qsub __swp

__fabs __rbit __usat

__fabsf __rev __wfe

__force_stores __return_address __wfi

__ldrex __ror __yield

__ldrexd



4.7.1 __breakpoint

이 내장 함수는 BKPT 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에 breakpoint 명령어를 포함할 수 있습니다.

구문

void __breakpoint(int val)

인수 설명:

val 컴파일- 시간 상수 정수로 범위는 다음과 같습니다.

0 ... 65535 소스를 ARM 코드로 컴파일하는 경우

0 ... 255 Thumb 코드를 소스로 컴파일하는 경우

오류

BKPT 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __breakpoint 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

BKPT 명령어가 해당 명령어를 지원하지 않는 아키텍처에서 실행될 경우 정의되지 않은 명령어 트랩이 수행됩니다.

예제

void func(void){ ... __breakpoint(0xF02C); ...}

추가 참고

• 어셈블러 설명서의 4-132페이지의 BKPT



4.7.2 __cdp

이 내장 함수는 CDP 또는 CDP2 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에 보조 프로세서 데이터 연산을 포함할 수 있습니다.

구문

__cdp(unsigned int coproc, unsigned int opcode1, unsigned int opcode2)

인수 설명:

coproc 명령어의 대상인 보조 프로세서를 식별합니다.

coproc는 0 ~ 15 범위의 정수여야 합니다.

opcode1 보조 프로세서 관련 op 코드입니다.

CDP2 명령어를 생성하려면 op 코드에 0x100을 추가합니다.

opcode2 보조 프로세서 관련 op 코드입니다.

사용법

이러한 명령어의 사용 방법은 보조 프로세서에 따라 다릅니다. 자세한 내용은 보조 프로세서 설명서를 참조하십시오.

추가 참고

• 어셈블러 설명서의 4-124페이지의 CDP 및 CDP2

4.7.3 __clrex

이 내장 함수는 CLREX 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에 CLREX 명령어를 포함할 수 있습니다.

구문

void __clrex(void)



오류

CLREX 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __clrex 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고

• 어셈블러 설명서의 4-39페이지의 CLREX

4.7.4 __clz

이 내장 함수는 CLZ 명령어 또는 해당 항목 코드 시퀀스를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에 있는 데이터 값의 선행 0 개수를 계산할 수 있습니다.

구문

unsigned char __clz(unsigned int val)

인수 설명:

val unsigned int입니다.

반환 값

__clz 내장 함수는 val에 있는 앞에 오는 0의 수를 반환합니다.

추가 참고

• 4-122페이지의 기타 기본 제공 함수

• 어셈블러 설명서의 4-54페이지의 CLZ

4.7.5 __current_pc

이 내장 함수를 사용하면 프로그램 내의 내장 함수가 사용되는 지점에서 프로그램 카운터의 현재 값을 확인할 수 있습니다.

구문

unsigned int __current_pc(void)



반환 값

__current_pc 내장 함수는 프로그램 내의 이 함수가 사용되는 지점에서 프로그램 카운터의 현재 값을 반환합니다.

추가 참고

• __current_sp

• 4-97페이지의 __return_address

• 컴파일러 사용 설명서의 7-29페이지의 sp, lr 또는 pc에 액세스하는 레거시 인라인 어셈블러

4.7.6 __current_sp

이 내장 함수는 프로그램 내의 현재 지점에서 스택 포인터의 값을 반환합니다.

구문

unsigned int __current_sp(void)

반환 값

__current_sp 내장 함수는 프로그램 내의 이 함수가 사용되는 지점에서 스택 포인터의 현재 값을 반환합니다.

추가 참고


• 4-79페이지의 __current_pc

• 4-97페이지의 __return_address




4.7.7 __disable_fiq

이 내장 함수는 FIQ 인터럽트를 비활성화합니다.

참고

일반적으로 이 내장 함수는 CPSR에서 F비트를 설정하여 FIQ 인터럽트를 비활성화합니다. 그러나 v7-M의 경우에는 오류 마스크 레지스터(FAULTMASK)를 설정합니다. v6-M에서는 FIQ 인터럽트가 지원되지 않습니다.

구문

int __disable_fiq(void)

참고

M 프로필에서 __disable_fiq 내장 함수에 있는 프로토타입은 다음과 같습니다.

void __disable_fiq(void)

반환 값

__disable_fiq는 FIQ 인터럽트의 비활성화 이전에 PSR에 있는 FIQ 인터럽트 마스크의 값을 반환합니다.

제한

__disable_fiq 내장 함수는 권한 모드, 즉 비 사용자 모드에서만 실행할 수 있습니다. 사용자 모드에서 이 내장 함수는 CPSR의 인터럽트 플래그를 변경하지 않습니다.

예제

void foo(void){

int was_masked = __disable_fiq();/* ... */if (!was_masked)

__enable_fiq();}

추가 참고

• 4-83페이지의 __enable_fiq



4.7.8 __disable_irq

이 내장 함수는 IRQ 인터럽트를 비활성화합니다.

참고

일반적으로 이 내장 함수는 CPSR에서 I비트를 설정하여 IRQ 인터럽트를 비활성화합니다. 그러나 M 프로필의 경우에는 예외 마스크 레지스터(PRIMASK)를 설정합니다.

구문

int __disable_irq(void)

참고

M 프로필에서 __disable_irq 내장 함수에 있는 프로토타입은 다음과 같습니다.

void __disable_irq(void)

반환 값

__disable_irq()는 IRQ 인터럽트의 비활성화 이전에 PSR에 있는 IRQ 인터럽트 마스크의 값을 반환합니다.

예제

void foo(void){

int was_masked = __disable_irq();/* ... */if (!was_masked)

__enable_irq();}

제한

__disable_irq 내장 함수는 권한 모드, 즉 비 사용자 모드에서만 실행할 수 있습니다. 사용자 모드에서 이 내장 함수는 CPSR의 인터럽트 플래그를 변경하지 않습니다.

추가 참고

• 4-83페이지의 __enable_irq



4.7.9 __enable_fiq

이 내장 함수는 FIQ 인터럽트를 활성화합니다.

참고

일반적으로 이 내장 함수는 CPSR에서 F비트를 지워 FIQ 인터럽트를 활성화합니다. 그러나 v7-M의 경우에는 오류 마스크 레지스터(FAULTMASK)를 지웁니다. v6-M에서는 FIQ 인터럽트가 지원되지 않습니다.

구문

void __enable_fiq(void)

제한

__enable_fiq 내장 함수는 권한 모드, 즉 비 사용자 모드에서만 실행할 수 있습니다. 사용자 모드에서 이 내장 함수는 CPSR의 인터럽트 플래그를 변경하지 않습니다.

추가 참고

• 4-81페이지의 __disable_fiq

4.7.10 __enable_irq

이 내장 함수는 IRQ 인터럽트를 활성화합니다.

참고

일반적으로 이 내장 함수는 CPSR에서 I비트를 지워 IRQ 인터럽트를 활성화합니다. 그러나 Cortex M 프로필 프로세서의 경우에는 예외 마스크 레지스터(PRIMASK)를 지웁니다.

구문

void __enable_irq(void)

제한

__enable_irq 내장 함수는 권한 모드, 즉 비 사용자 모드에서만 실행할 수 있습니다. 사용자 모드에서 이 내장 함수는 CPSR의 인터럽트 플래그를 변경하지 않습니다.



추가 참고

• 4-82페이지의 __disable_irq

4.7.11 __fabs

이 내장 함수는 VABS 명령어 또는 해당 항목 코드 시퀀스를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 배정밀도 부동 소수점 값의 절대값을 얻을 수 있습니다.

참고

__fabs 내장 함수는 표준 C 라이브러리 함수 fabs와 비슷합니다. 그러나 __fabs로의 호출이 VFP 보조 프로세서가 장착된 ARM 아키텍처 기반 프로세서에서 단일, 인라인, 기계 명령으로 컴파일되는 표준 라이브러리 함수와는 다릅니다.

구문

double __fabs(double val)

인수 설명:

val 배정밀도 부동 소수점 값입니다.

반환 값

__fabs 내장 함수는 val의 절대값을 double로 반환합니다.

추가 참고

• __fabsf

• 어셈블러 설명서의 5-101페이지의 VABS, VNEG 및 VSQRT

4.7.12 __fabsf

이 내장 함수는 __fabs 내장 함수의 단정밀도 버전입니다. 이 함수의 기능은 __fabs와 같으며 예외는 다음과 같습니다.

• 이 함수는 double 유형의 인수 대신 float 유형의 인수를 사용합니다.

• 이 함수는 double 값 대신 float 값을 반환합니다.



추가 참고

• 4-84페이지의 __fabs

• 어셈블러 설명서의 5-62페이지의 V{Q}ABS 및 V{Q}NEG

4.7.13 __force_stores

이 내장 함수는 현재 함수의 범위 밖에서 보이는 모든 변수, 즉 자신을 가리키는 포인터가 함수 안으로 또는 밖으로 전달되는 변수가 변경되었을 경우 다시 메모리에 기록되도록 합니다.

이 내장 함수는 일정 장벽의 역할도 합니다.

구문

void __force_stores(void)

추가 참고

• 4-90페이지의 __memory_changed

• 4-98페이지의 __schedule_barrier

4.7.14 __ldrex

이 내장 함수는 LDREX[size] 형식의 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 LDREX 명령어를 사용하여 C 또는 C++ 코드 메모리에서 데이터를 로드할 수 있습니다. LDREX[size]의 size는 바이트 저장의 경우 B, 하프워드 저장의 경우 H입니다. 크기를 지정하지 않으면 워드 저장이 수행됩니다.

구문

unsigned int __ldrex(volatile void *ptr)



인수 설명:

ptr 메모리에서 로드할 데이터의 주소를 가리킵니다. 로드할 데이터의 형식을 지정하려면 매개변수를 적절한 포인터 형식으로 캐스트합니다.

반환 값

__ldrex 내장 함수는 ptr가 가리키는 메모리 주소에서 로드된 데이터를 반환합니다.

오류

LDREX 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __ldrex 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

__ldrex 내장 함수는 더블워드 데이터에 대한 액세스를 지원하지 않습니다. 지원되지 않는 액세스 너비를 지정하면 컴파일러에서 오류를 생성합니다.

예제

int foo(void){

int loc = 0xff;return __ldrex((volatile char *)loc);

}

--cpu=6k 명령 행 옵션을 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

표 4-8 __ldrex 내장 함수가 지원하는 액세스 너비

명령어 로드된 데이터 크기 C 캐스트

LDREXB 부호 없는 바이트 (unsigned char *)

LDREXB 부호 있는 바이트 (signed char *)

LDREXH 부호 없는 하프워드 (unsigned short *)

LDREXH 부호 있는 하프워드 (짧은 비니어 *)

LDREX 워드 (int *)



||foo|| PROCMOV r0,#0xffLDREXB r0,[r0]BX lrENDP

추가 참고

• __ldrexd

• 4-103페이지의 __strex

• 4-105페이지의 __strexd

• 어셈블러 설명서의 4-36페이지의 LDREX 및 STREX

4.7.15 __ldrexd

이 내장 함수는 LDREXD 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 LDREXD 명령어를 사용하여 C 또는 C++ 코드의 메모리에서 데이터를 로드할 수 있습니다. 그러면 더블워드 데이터에 액세스할 수 있습니다.

구문

unsigned long long __ldrexd(volatile void *ptr)

인수 설명:

ptr 메모리에서 로드할 데이터의 주소를 가리킵니다. 로드할 데이터의 형식을 지정하려면 매개변수를 적절한 포인터 형식으로 캐스트합니다.

반환 값

__ldrexd 내장 함수는 ptr이 가리키는 메모리 주소에서 로드된 데이터를 반환합니다.

표 4-9 __ldrex 내장 함수가 지원하는 액세스 너비


LDREXD unsigned long long (unsigned long long *)

LDREXD signed long long (signed long long *)



오류

LDREXD 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __ldrexd 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

__ldrexd 내장 함수는 더블워드 데이터에 대한 액세스만 지원합니다. 지원되지 않는 액세스 너비를 지정하면 컴파일러에서 오류를 생성합니다.

추가 참고

• 4-85페이지의 __ldrex




4.7.16 __ldrt

이 내장 함수는 LDR{size}T 형식의 어셈블리 언어 명령어를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 LDRT 명령어를 사용하여 C 또는 C++ 코드의 메모리에서 데이터를 로드할 수 있습니다.

구문

unsigned int __ldrt(const volatile void *ptr)

인수 설명:

ptr 메모리에서 로드할 데이터의 주소를 가리킵니다. 로드할 데이터의 크기를 지정하려면 매개변수를 적절한 정수 유형으로 캐스트합니다.

표 4-10 __ldrt 내장 함수가 지원하는 액세스 너비

명령어a 로드된 데이터 크기 C 캐스트

LDRSBT 부호 있는 바이트 (signed char *)

LDRBT 부호 없는 바이트 (char *)



반환 값

__ldrt 내장 함수는 ptr이 가리키는 메모리 주소에서 로드된 데이터를 반환합니다.

오류

LDRT 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __ldrt 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

__ldrt 내장 함수는 더블워드 데이터에 대한 액세스를 지원하지 않습니다. 지원되지 않는 액세스 너비를 지정하면 컴파일러에서 오류를 생성합니다.

예제

int foo(void){

int loc = 0xff;return __ldrt((const volatile int *)loc);

}

기본 옵션을 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

||foo|| PROCMOV r0,#0xffLDRBT r1,[r0],#0MOV r2,#0x100LDRBT r0,[r2],#0ORR r0,r1,r0,LSL #8BX lrENDP

LDRSHT 부호 있는 하프워드 (signed short int *)

LDRHT 부호 없는 하프워드 (short int *)

LDRT 워드 (int *)

a. 또는 이와 동등함

표 4-10 __ldrt 내장 함수가 지원하는 액세스 너비 (계속)

명령어a 로드된 데이터 크기 C 캐스트



추가 참고


• 어셈블러 설명서의 4-18페이지의 LDR 및 STR (사용자 모드)

4.7.17 __memory_changed

이 내장 함수는 현재 함수의 범위 밖에서 보이는 모든 변수, 즉 자신을 가리키는 포인터가 함수 안으로 또는 밖으로 전달되는 변수가 변경되었을 경우 다시 메모리에 기록된 다음 메모리에서 다시 읽히도록 합니다.

이 내장 함수는 일정 장벽의 역할도 합니다.

구문

void __memory_changed(void)

추가 참고

• 4-85페이지의 __force_stores


4.7.18 __nop

이 내장 함수는 NOP 명령어 또는 해당 항목 코드 시퀀스를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 소스의 각 __nop 내장 함수에 대해 한 개의 NOP 명령어가 생성됩니다.

컴파일러는 접근할 수 없는 코드의 정상적인 제거를 제외하고 NOP 명령어를 최적화하지 않습니다. __nop 내장 함수는 컴파일러에서 명령어 일정의 장벽 역할도 합니다. 즉, 명령어는 최적화 결과 NOP의 한쪽에서 다른 쪽으로 이동하지 않습니다.

참고

__schedule_barrier 내장 함수를 사용하여 NOP 명령어를 생성하지 않고 일정 장벽을 삽입할 수 있습니다.

구문

void __nop(void)



추가 참고

• 4-101페이지의 __sev


• 4-109페이지의 __wfe

• 4-110페이지의 __wfi

• 4-111페이지의 __yield

• 어셈블러 설명서의 4-142페이지의 NOP, SEV, WFE, WFI 및 YIELD

• 컴파일러 사용 설명서의 4-4페이지의 일반 내장 함수

4.7.19 __pld

이 내장 함수는 데이터 프리페치(예: PLD)를 컴파일러에서 생성한 명령어 스트림에 삽입합니다. 이를 통해 주소에서 데이터를 곧 로드할 것이라는 신호를 C 또는 C++ 프로그램에서 메모리 시스템으로 보낼 수 있습니다.

구문

void __pld(...)

인수 설명:

... 미리 가져올 메모리의 주소를 지정하는 포인터 또는 정수 인수의 임의 개수를 나타냅니다.

제한

타겟 아키텍처가 데이터 프리페치를 지원하지 않는 경우 이 내장 함수는 아무런 영향을 미치지 않습니다.

예제

extern int data1;extern int data2;volatile int* interrupt = (volatile int *)0x8000;volatile int* uart = (volatile int *)0x9000;void get(void){

__pld(data1, data2);while (!*interrupt);*uart = data1; // trigger uart as soon as interrupt occurs*(uart+1) = data2;

}



추가 참고

• __pldw

• 4-93페이지의 __pli

• 어셈블러 설명서의 4-25페이지의 PLD, PLDW 및 PLI

4.7.20 __pldw

이 내장 함수는 PLDW 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 주소에서 쓰기를 위한 데이터를 곧 로드할 것이라는 신호를 C 또는 C++ 프로그램에서 메모리 시스템으로 보낼 수 있습니다.

구문

void __pldw(...)

인수 설명:

... 미리 가져올 메모리의 주소를 지정하는 포인터 또는 정수 인수의 임의 개수를 나타냅니다.

제한

타겟 아키텍처가 데이터 프리페치를 지원하지 않는 경우 이 내장 함수는 아무런 영향을 미치지 않습니다.

이 내장 함수는 다중 처리 확장을 제공하는 ARMv7 이상의 아키텍처에서만 적용됩니다. 즉, __TARGET_FEATURE_MULTIPROCESSING 사전 정의 매크로가 정의되어 있어야 합니다.

예제

void foo(int *bar){

__pldw(bar);}

추가 참고


• 4-91페이지의 __pld

• 4-93페이지의 __pli




4.7.21 __pli

이 내장 함수는 명령어 프리페치(예: PLI)를 컴파일러에서 생성한 명령어 스트림에 삽입합니다. 이를 통해 주소에서 명령어를 곧 로드할 것이라는 신호를 C 또는 C++ 프로그램에서 메모리 시스템으로 보낼 수 있습니다.

구문

void __pli(...)

인수 설명:

... 미리 가져올 명령어의 주소를 지정하는 포인터 또는 정수 인수의 임의 개수를 나타냅니다.

제한

타겟 아키텍처가 명령어 프리페치를 지원하지 않는 경우 이 내장 함수는 아무런 영향을 미치지 않습니다.

추가 참고

• 4-91페이지의 __pld

• 4-92페이지의 __pldw


4.7.22 __promise

이 내장 함수는 지정된 식이 0이 아님을 컴파일러에 알립니다. 이를 통해 컴파일러는 코드를 벡터화할 때 최적화 수준을 더욱 높일 수 있습니다.

구문

void __promise(expr)

여기서 expr은 0이 아닌 것으로 평가되는 식입니다.

추가 참고

• 컴파일러 사용 설명서의 3-18페이지의 __promise를 사용하여 벡터화 향상



4.7.23 __qadd

이 내장 함수는 QADD 명령어 또는 해당 항목 코드 시퀀스를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 두 개의 정수에 대한 포화 더하기를 얻을 수 있습니다.

구문

int __qadd(int val1, int val2)

인수 설명:

val1 포화 더하기 연산의 첫째 피가수입니다.

val2 포화 더하기 연산의 둘째 피가수입니다.

반환 값

__qadd 내장 함수는 val1 및 val2의 포화 더하기를 반환합니다.

추가 참고

• __qdbl

• 4-95페이지의 __qsub

• 어셈블러 설명서의 4-93페이지의 QADD, QSUB, QDADD 및 QDSUB

4.7.24 __qdbl

이 내장 함수는 정수 자체의 포화 더하기의 해당 항목 명령어를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 정수 포화값의 2배를 얻을 수 있습니다.

구문

int __qdbl(int val)

인수 설명:

val 2배가 될 데이터 값입니다.

반환 값

__qdbl 내장 함수는 val 자체 또는 해당 항목 __qadd(val, val)의 포화 더하기를 반환합니다.



추가 참고

• 4-94페이지의 __qadd

4.7.25 __qsub

이 내장 함수는 QSUB 명령어 또는 해당 항목 코드 시퀀스를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 두 개의 정수에 대한 포화 빼기를 얻을 수 있습니다.

구문

int __qsub(int val1, int val2)

인수 설명:

val1 포화 빼기 연산의 첫째 피감수입니다.

val2 포화 빼기 연산의 둘째 피감수입니다.

반환 값

__qsub 내장 함수는 val1 및 val2의 포화 빼기를 반환합니다.

추가 참고

• 4-94페이지의 __qadd

• 어셈블러 설명서의 4-93페이지의 QADD, QSUB, QDADD 및 QDSUB

4.7.26 __rbit

이 내장 함수는 RBIT 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 32비트 워드의 비트 순서를 반전시킬 수 있습니다.

구문

unsigned int __rbit(unsigned int val)

인수 설명:

val 비트 순서가 반전될 데이터 값입니다.



반환 값

__rbit 내장 함수는 val에서 얻은 값을 이 값의 비트 순서를 반전하여 반환합니다.

추가 참고

• 어셈블러 설명서의 4-65페이지의 REV, REV16, REVSH 및 RBIT

4.7.27 __rev

이 내장 함수는 REV 명령어 또는 해당 항목 코드 시퀀스를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 32비트 빅엔디안 데이터 값을 리틀엔디안 데이터 값으로 변환하거나 32비트 리틀엔디안 데이터 값을 빅엔디안 데이터 값으로 변환할 수 있습니다.

참고

컴파일러는 특정 식을 인식할 경우 자동으로 REV를 사용합니다.

구문

unsigned int __rev(unsigned int val)

인수 설명:

val unsigned int입니다.

반환 값

__rev 내장 함수는 val에서 얻은 값을 이 값의 바이트 순서를 반전하여 반환합니다.

추가 참고

• 어셈블러 설명서의 4-65페이지의 REV, REV16, REVSH 및 RBIT



4.7.28 __return_address

이 내장 함수는 현재 함수의 반환 주소를 반환합니다.

구문

unsigned int __return_address(void)

반환 값

__return_address 내장 함수는 현재 함수에서 반환하는 데에 사용된 링크 레지스터의 값을 반환합니다.

제한

__return_address 내장 함수는 컴파일러가 인라인, 마무리 호출 및 코드 공유와 같은 최적화 작업을 수행하는 능력에 영향을 주지 않습니다. 최적화가 수행되면 __return_address에 의해 반환된 값은 다음과 같이 수행된 최적화 작업을 반영합니다.

최적화 안 함

최적화가 수행되지 않으면 foo 함수 내에서 __return_address에 의해 반환된 값은 foo의 반환 주소입니다.

인라인 최적화

foo 함수가 bar 함수로 인라인되면 foo 내에서 __return_address에 의해 반환되는 값은 bar의 반환 주소입니다.

마무리 호출 최적화

foo 함수가 bar 함수에서 마무리 호출되면 foo 내에서 __return_address에 의해 반환되는 값은 bar의 반환 주소입니다.

추가 참고


• 4-79페이지의 __current_pc

• 4-80페이지의 __current_sp




4.7.29 __ror

이 내장 함수는 ROR 명령어 또는 피연산자 회전을 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 해당 위치에 지정된 숫자만큼 값을 오른쪽으로 회전할 수 있습니다.

참고

컴파일러는 특정 식을 인식할 경우 자동으로 ROR을 사용합니다.

구문

unsigned int __ror(unsigned int val, unsigned int shift)

인수 설명:

val 오른쪽으로 시프트할 값입니다.

shift 1-31 범위에서의 상수 시프트입니다.

반환 값

__ror 내장 함수는 shift 해당 위치에 숫자만큼 오른쪽으로 회전된 val의 값을 반환합니다.

추가 참고

• 어셈블러 설명서의 4-67페이지의 ASR, LSL, LSR, ROR 및 RRX

4.7.30 __schedule_barrier

이 내장 함수는 지점 전후의 연산이 컴파일러에 의해 병합되지 않는 시퀀스 지점을 생성합니다. 일정 장벽은 메모리가 업데이트되지 않도록 합니다. 레지스터에 변수가 있을 경우, 이 변수는 적절하게 업데이트되며 강제로 제외되지 않습니다.

이 내장 함수는 NOP 명령어가 생성되지 않는다는 점을 제외하고 __nop 내장 함수와 유사합니다.



구문

void schedule_barrier(void)

추가 참고

• 4-90페이지의 __nop

4.7.31 __semihost

이 내장 함수는 SVC 또는 BKPT 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 타겟 아키텍처와 독립적인 C 또는 C++에서의 세미호스팅 호출을 수행할 수 있습니다.

구문

int __semihost(int val, const void *ptr)

인수 설명:

val 세미호스팅 요청의 요청 코드입니다.

자세한 내용은 개발자 설명서에서 8장 세미호스팅을 참조하십시오.

ptr 인수/결과 블록에 대한 포인터입니다.

자세한 내용은 개발자 설명서의 8장 세미호스팅을 참조하십시오.

반환 값

세미호스팅 호출의 결과에 대한 자세한 내용은 개발자 설명서에서 8장 세미호스팅을 참조하십시오.

사용법

C 또는 C++에서 이 내장 함수를 사용하여 타겟 및 명령어 세트에 대한 적절한 세미호스팅 호출을 다음과 같이 생성하십시오.

SVC 0x123456 모든 아키텍처에 대해 ARM 상태인 경우

SVC 0xAB ARMv7-M을 제외한 Thumb 상태인 경우. 이 동작은 ARM 또는 타사의 모든 디버그 타겟에서 보장되지는 않습니다.

BKPT 0xAB Thumb-2만 해당하는 ARMv7-M의 경우



제한

ARMv7 이전의 ARM 프로세서는 SVC 명령어를 사용하여 세미호스팅 호출을 수행합니다. 그러나 Cortex M 프로필 프로세서용으로 컴파일할 경우 세미호스팅은 BKPT 명령어를 사용하여 구현됩니다.

예제

char buffer[100];...void foo(void){

__semihost(0x01, (const void *)buf); // equivalent in thumb state to // int __svc(0xAB) my_svc(int, int *);// result = my_svc(0x1, &buffer);

}

--thumb 옵션을 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

||foo|| PROC...LDR r1,|L1.12|MOVS r0,#1SVC #0xab...

|L1.12|...

buffer% 400

추가 참고



• 4-18페이지의 __svc

• 어셈블러 설명서의 4-132페이지의 BKPT


• 개발자 설명서의 8장 세미호스팅



4.7.32 __sev

이 내장 함수는 SEV 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다.

구문

void __sev(void)

오류

SEV 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __sev 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고






4.7.33 __sqrt

이 내장 함수는 VFP VSQRT 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 배정밀도 부동 소수점 값의 제곱근을 얻을 수 있습니다.

참고

__sqrt 내장 함수는 표준 C 라이브러리 함수 sqrt와 비슷합니다. 그러나 __sqrt로의 호출이 VFP 보조 프로세서가 장착된 ARM 아키텍처 기반 프로세서에서 단일, 인라인, 기계 명령으로 컴파일되는 표준 라이브러리 함수와는 다릅니다.

구문

double __sqrt(double val)

인수 설명:

val 배정밀도 부동 소수점 값입니다.



반환 값

__sqrt 내장 함수는 val의 제곱근을 double로 반환합니다.

오류

VFP 보조 프로세서가 장착되지 않은 타겟에 대해 컴파일하는 경우 컴파일러는 __sqrt 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고

• __sqrtf


4.7.34 __sqrtf

이 내장 함수는 __sqrtf 내장 함수의 단정밀도 버전입니다. 이 함수의 기능은 __sqrt와 같으며 예외는 다음과 같습니다.

• 이 함수는 double 유형의 인수 대신 float 유형의 인수를 사용합니다.

• 이 함수는 double 값 대신 float 값을 반환합니다.

추가 참고

• 4-101페이지의 __sqrt


4.7.35 __ssat

이 내장 함수는 SSAT 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 부호 있는 값에 대해 포화시킬 수 있습니다.

구문

int __ssat(int val, unsigned int sat)

인수 설명:

val 포화시킬 값입니다.

sat 포화시킬 비트 위치입니다.

sat의 값은 1 ~ 32 사이여야 합니다.



반환 값

__ssat 내장 함수는 부호 있는 범위 –2sat–1 ≤ x ≤ 2sat–1 –1로 포화된 val을 반환합니다.

오류

SSAT 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __ssat 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고

• 4-108페이지의 __usat

• 어셈블러 설명서의 4-95페이지의 SSAT 및 USAT

4.7.36 __strex

이 내장 함수는 STREX[size] 형식의 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에서 STREX 명령어를 사용하여 메모리에 데이터를 저장할 수 있습니다.

구문

int __strex(unsigned int val, volatile void *ptr)

인수 설명:

val 메모리에 작성할 값입니다.

ptr 메모리에 작성할 데이터의 주소를 가리킵니다. 작성할 데이터의 크기를 지정하려면 매개변수를 적절한 정수 유형으로 캐스트합니다.

표 4-11 __strex 내장 함수가 지원하는 액세스 너비

명령어 저장된 데이터 크기 C 캐스트

STREXB 부호 없는 바이트 (char *)

STREXH 부호 없는 하프워드 (짧은 비니어 *)

STREX 워드 (int *)



반환 값

__strex 내장 함수는 다음을 반환합니다.

0 STREX 명령어가 성공할 경우

1 STREX 명령어가 잠길 경우

오류

STREX 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __strex 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

__strex 내장 함수는 더블워드 데이터에 대한 액세스를 지원하지 않습니다. 지원되지 않는 액세스 너비를 지정하면 컴파일러에서 오류를 생성합니다.

예제

int foo(void){

int loc=0xff;return(!__strex(0x20, (volatile char *)loc));

}

--cpu=6k 명령 행 옵션을 사용하여 이 코드를 컴파일하면 다음이 생성됩니다.

||foo|| PROCMOV r0,#0xffMOV r2,#0x20STREXB r1,r2,[r0]RSBS r0,r1,#1MOVCC r0,#0BX lr

ENDP

추가 참고


• 4-87페이지의 __ldrexd





4.7.37 __strexd

이 내장 함수는 STREXD 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에서 STREXD 명령어를 사용하여 메모리에 데이터를 저장할 수 있습니다. 그러면 메모리에 더블워드 데이터를 배타적으로 저장할 수 있습니다.

구문

int __strexd(unsigned long long val, volatile void *ptr)

인수 설명:



반환 값

__strexd 내장 함수는 다음을 반환합니다.

0 STREXD 명령어가 성공할 경우

1 STREXD 명령어가 잠길 경우

오류

STREXD 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __strexd 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

__strexd 내장 함수는 더블워드 데이터에 대한 액세스만 지원합니다. 지원되지 않는 액세스 너비를 지정하면 컴파일러에서 오류를 생성합니다.

표 4-12 __strexd 내장 함수가 지원하는 액세스 너비

명령어 저장된 데이터 크기 C 캐스트

STREXD unsigned long long (unsigned long long *)

STREXD signed long long (signed long long *)



추가 참고


• 4-87페이지의 __ldrexd



4.7.38 __strt

이 내장 함수는 STR{size}T 형식의 어셈블리 언어 명령어를 컴파일러에서 생성하는 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드에서 STRT 명령어를 사용하여 메모리에 데이터를 저장할 수 있습니다.

구문

void __strt(unsigned int val, volatile void *ptr)

인수 설명:



오류

STRT 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __strt 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

__strt 내장 함수는 부호 있는 데이터 또는 더블워드 데이터에 대한 액세스를 지원하지 않습니다. 지원되지 않는 액세스 너비를 지정하면 컴파일러에서 오류를 생성합니다.

표 4-13 __strt 내장 함수가 지원하는 액세스 너비


STRBT 부호 없는 바이트 (char *)

STRHT 부호 없는 하프워드 (short int *)

STRT 워드 (int *)



예제

void foo(void){

int loc=0xff;__strt(0x20, (volatile char *)loc);

}

이 코드를 컴파일하면 다음이 생성됩니다.

||foo|| PROCMOV r0,#0xffMOV r1,#0x20STRBT r1,[r0],#0BX lrENDP

추가 참고


• 어셈블러 설명서의 4-18페이지의 LDR 및 STR (사용자 모드)

4.7.39 __swp

이 내장 함수는 SWP{size} 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 메모리 위치 간 데이터를 스왑할 수 있습니다.

참고

ARMv6 이상에서는 SWP 및 SWPB의 사용이 제공되지 않습니다.

구문

unsigned int __swp(unsigned int val, volatile void *ptr)

인수 설명:

val 메모리에 작성할 데이터 값입니다.




반환 값

__swp 내장 함수는 ptr이 가리키는 메모리 주소에 있는 데이터 값을 이 값이 val로 덮어쓰여지기 전에 미리 반환합니다.

예제

int foo(void){

int loc=0xff;return(__swp(0x20, (volatile int *)loc));

}

이 코드를 컴파일하면 다음이 생성됩니다.

||foo|| PROCMOV r1, #0xffMOV r0, #0x20SWP r0, r0, [r1]BX lrENDP

추가 참고

• 어셈블러 설명서의 4-40페이지의 SWP 및 SWPB

4.7.40 __usat

이 내장 함수는 USAT 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다. 이를 통해 C 또는 C++ 코드 내에서 부호 없는 값에 대해 포화시킬 수 있습니다.

구문

int __usat(unsigned int val, unsigned int sat)

표 4-14 __swp 내장 함수가 지원하는 액세스 너비


SWPB 부호 없는 바이트 (char *)

SWP 워드 (int *)



인수 설명:

val . 포화시킬 값입니다.

sat . 포화시킬 비트 위치입니다.

usat의 값은 0 ~ 31 사이여야 합니다.

반환 값

__usat 내장 함수는 부호 없는 범위 0 ≤ x ≤ 2sat–1 –1로 포화된 val을 반환합니다.

오류

USAT 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __usat 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고

• 4-102페이지의 __ssat

• 어셈블러 설명서의 4-95페이지의 SSAT 및 USAT

4.7.41 __wfe

이 내장 함수는 WFE 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다.

v6T2 아키텍처에서 WFE 명령어는 NOP 명령어로 실행됩니다.

구문

void __wfe(void)

오류

WFE 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __wfe 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.



추가 참고

• __wfi





4.7.42 __wfi

이 내장 함수는 WFI 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다.

v6T2 아키텍처에서 WFI 명령어는 NOP 명령어로 실행됩니다.

구문

void __wfi(void)

오류

WFI 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __wfi 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고








4.7.43 __yield

이 내장 함수는 YIELD 명령어를 컴파일러가 생성한 명령어 스트림에 삽입합니다.

구문

void __yield(void)

오류

YIELD 명령어를 지원하지 않는 타겟에 대해 컴파일하는 경우 컴파일러는 __yield 내장 함수를 인식하지 않습니다. 이 경우 컴파일러에서 경고 또는 오류를 생성합니다.

추가 참고






4.7.44 ARMv6 SIMD 내장 함수

ARM 아키텍처 v6 명령어 세트 아키텍처는 고성능 미디어 응용 프로그램의 효율적인 소프트웨어 구현을 위해 60개가 넘는 SIMD 명령어를 ARMv6에 추가합니다.

ARM 컴파일러는 ARMv6 SIMD 명령어에 매핑하는 내장 함수를 지원합니다. 이러한 내장 함수는 ARMv6 아키텍처 또는 프로세서에 대한 코드를 컴파일하는 경우 사용할 수 있습니다. 다음 목록에서는 이러한 내장 함수의 함수 프로토타입을 보여 줍니다. 이 목록에 나열된 함수 프로토타입은 내장 함수가 인식하는 ARMv6 명령어의 기본 형식을 나타냅니다. 내장 함수가 인식하는 기본 명령어의 이름을 사용하려면 내장 함수의 이름에 선행 밑줄(__)을 놓습니다. 예를 들어 __qadd16 내장 함수가 ARMv6 QADD16 명령어에 해당합니다.

참고

각 ARMv6 SIMD 내장 함수는 ARM v6 아키텍처 또는 프로세서에 대해 단일, 인라인, 기계 명령으로 컴파일됩니다. 그러나 컴파일러는 기본 명령어의 최적화된 형식을 사용할 기회를 감지할 경우 이를 수행할 수도 있습니다.



ARMv6 SIMD 명령어는 APSR(Application Program Status Register)에 GE[3:0]비트를 설정할 수 있습니다. SIMD 명령어는 이러한 플래그를 업데이트하여 SIMD 연산의 8/16비트 부분마다 “크거나 같음”을 나타낼 수도 있습니다.

ARM 컴파일러는 GE[3:0]비트를 전역 변수로 처리합니다. C 또는 C++ 프로그램 내에서 이러한 비트에 액세스하려면 다음 중 하나에 해당해야 합니다.

• 명명된 레지스터 변수를 통해 APSR의 16-19비트에 액세스하는 경우

• __sel 내장 함수를 사용하여 SEL 명령어를 제어하는 경우

unsigned int __qadd16(unsigned int, unsigned int)unsigned int __qadd8(unsigned int, unsigned int)unsigned int __qasx(unsigned int, unsigned int)unsigned int __qsax(unsigned int, unsigned int)unsigned int __qsub16(unsigned int, unsigned int)unsigned int __qsub8(unsigned int, unsigned int)unsigned int __sadd16(unsigned int, unsigned int)unsigned int __sadd8(unsigned int, unsigned int)unsigned int __sasx(unsigned int, unsigned int)unsigned int __sel(unsigned int, unsigned int)unsigned int __shadd16(unsigned int, unsigned int)unsigned int __shadd8(unsigned int, unsigned int)unsigned int __shasx(unsigned int, unsigned int)unsigned int __shsax(unsigned int, unsigned int)unsigned int __shsub16(unsigned int, unsigned int)unsigned int __shsub8(unsigned int, unsigned int)unsigned int __smlad(unsigned int, unsigned int, unsigned int)unsigned long long __smlald(unsigned int, unsigned int, unsigned long long)unsigned int __smlsd(unsigned int, unsigned int, unsigned int)unsigned long long __smlsld(unsigned int, unsigned int, unsigned long long)unsigned int __smuad(unsigned int, unsigned int)unsigned int __smusd(unsigned int, unsigned int)unsigned int __ssat16(unsigned int, unsigned int)unsigned int __ssax(unsigned int, unsigned int)unsigned int __ssub16(unsigned int, unsigned int)unsigned int __ssub8(unsigned int, unsigned int)unsigned int __sxtab16(unsigned int, unsigned int)unsigned int __sxtb16(unsigned int, unsigned int)unsigned int __uadd16(unsigned int, unsigned int)unsigned int __uadd8(unsigned int, unsigned int)unsigned int __uasx(unsigned int, unsigned int)unsigned int __uhadd16(unsigned int, unsigned int)unsigned int __uhadd8(unsigned int, unsigned int)unsigned int __uhasx(unsigned int, unsigned int)unsigned int __uhsax(unsigned int, unsigned int)unsigned int __uhsub16(unsigned int, unsigned int)unsigned int __uhsub8(unsigned int, unsigned int)unsigned int __uqadd16(unsigned int, unsigned int)unsigned int __uqadd8(unsigned int, unsigned int)



unsigned int __uqasx(unsigned int, unsigned int)unsigned int __uqsax(unsigned int, unsigned int)unsigned int __uqsub16(unsigned int, unsigned int)unsigned int __uqsub8(unsigned int, unsigned int)unsigned int __usad8(unsigned int, unsigned int)unsigned int __usada8(unsigned int, unsigned int, unsigned int)unsigned int __usax(unsigned int, unsigned int)unsigned int __usat16(unsigned int, unsigned int)unsigned int __usub16(unsigned int, unsigned int)unsigned int __usub8(unsigned int, unsigned int)unsigned int __uxtab16(unsigned int, unsigned int)unsigned int __uxtb16(unsigned int, unsigned int)

추가 참고

• 4-116페이지의 명명된 레지스터 변수

• 어셈블러 설명서의 2-7페이지의 레지스터

• 어셈블러 설명서의 4-63페이지의 SEL

• 어셈블러 설명서의 5장 NEON 및 VFP 프로그래밍

4.7.45 ETSI 기본 작업

RVCT는 ETSI G.729 Recommendation Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)에 설명되어 있는 원래 ETSI 계열의 기본 작업을 지원합니다.

ETSI 기본 연산을 사용자 코드에 사용하려면 dspfns.h 표준 헤더 파일을 포함해야 합니다. dspfns.h에서 제공되는 내장 함수는 표 4-15에 나열되어 있습니다.

표 4-15 RVCT에서 지원하는 ETSI 기본 연산

내장 함수

abs_s L_add_c L_mult L_sub_c norm_l

add L_deposit_h L_negate mac_r round

div_s L_deposit_l L_sat msu_r saturate

extract_h L_mac L_shl mult shl

extract_l L_macNs L_shr mult_r shr

L_abs L_msu L_shr_r negate shr_r

L_add L_msuNs L_sub norm_s sub



dspfns.h 헤더 파일은 특정 상태 플래그를 C 또는 C++ 프로그램에서 사용할 전역 변수처럼 나타낼 수도 있습니다. dspfns.h에 의해 나타나는 상태 플래그는 표 4-16에 나열되어 있습니다.

예제

#include <limits.h>#include <stdint.h>#include <dspfns.h> // include ETSI basic operationsint32_t C_L_add(int32_t a, int32_t b){

int32_t c = a + b;if (((a ^ b) & INT_MIN) == 0){

if ((c ^ a) & INT_MIN){

c = (a < 0) ? INT_MIN : INT_MAX;}

}return c;

}__asm int32_t asm_L_add(int32_t a, int32_t b){

qadd r0, r0, r1bx lr

}int32_t foo(int32_t a, int32_t b){

int32_t c, d, e, f;Overflow = 0; // set global overflow flagc = C_L_add(a, b); // C saturating addd = asm_L_add(a, b); // assembly language saturating adde = __qadd(a, b); // ARM intrinsic saturating addf = L_add(a, b); // ETSI saturating addreturn Overflow ? -1 : c == d == e == f; // returns 1, unless overflow

}

표 4-16 RVCT에 나타나는 ETSI 상태 플래그

상태 플래그 설명

Overflow Overflow 상태 플래그입니다.

일반적으로 포화 함수에서 오버플로에 대한 까다로운 결과입니다.

Carry Carry 상태 플래그입니다.



추가 참고

• C 코드 및 내장 함수의 조합을 통한 ETSI 기본 작업의 정의에 대해서는 dspfns.h 헤더 파일을 참조하십시오.

• 컴파일러 사용 설명서의 4-7페이지의 ETSI 기본 연산

• ETSI Recommendation G.191: Software tools for speech and audio coding standardization

• ITU-T Software Tool Library 2005 User's manual: ETSI Recommendation G.191의 일부로 포함

• ETSI Recommendation G723.1: Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s

• ETSI Recommendation G.729: Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)

4.7.46 C55x 내장 함수

ARM 컴파일러는 선택된 TI C55x 컴파일러 내장 함수의 에뮬레이션을 지원합니다.

TI C55x 내장 함수를 사용자 코드에서 사용하려면 c55x.h 표준 헤더 파일을 포함해야 합니다. c55x.h에서 제공되는 내장 함수는 표 4-17에 나열되어 있습니다.

표 4-17 RVCT에서 지원하는 TI C55x 내장 함수

내장 함수

_abss _lshrs _rnd _smas

_count _lsadd _norm _smpy

_divs _lsmpy _round _sneg

_labss _lsneg _roundn _sround

_lmax _lsshl _sadd _sroundn

_lmin _lssub _shl _sshl

_lnorm _max _shrs _ssub

_lshl _min _smac



예제

#include <limits.h>#include <stdint.h>#include <c55x.h> // include TI C55x intrinsics__asm int32_t asm_lsadd(int32_t a, int32_t b){

qadd r0, r0, r1bx lr}

int32_t foo(int32_t a, int32_t b){

int32_t c, d, e;c = asm_lsadd(a, b); // assembly language saturating addd = __qadd(a, b); // ARM intrinsic saturating adde = _lsadd(a, b); // TI C55x saturating addreturn c == d == e; // returns 1

}

추가 참고

• C55x 내장 함수의 ARM 구현에 대한 자세한 내용은 c55x.h 헤더 파일을 참조하십시오.

• TI 컴파일러 내장 함수에 대한 정보를 제공하는 발행물은 http://www.ti.com의 Texas Instruments에서 사용할 수 있습니다.

4.7.47 명명된 레지스터 변수

컴파일러를 사용하면 명명된 레지스터 변수를 사용하는 ARM 아키텍처 기반 프로세서의 레지스터에 액세스할 수 있습니다. 명명된 레지스터 변수가 다음 범위에서 지원됩니다.

• 파일 범위

• 함수 매개변수를 제외한 지역 범위

구문

register type var-name __asm(reg);

인수 설명:

type 명명된 레지스터 변수의 유형입니다.

명명되는 레지스터와 크기가 같은 모든 형식이 명명된 레지스터 변수의 선언에 사용될 수 있습니다. 유형은 구조체가 될 수 있지만 비트 필드 레이아웃은 엔디안에 쉽게 영향을 받습니다.



var-name 명명된 레지스터 변수의 이름입니다.

reg ARM 아키텍처 기반 프로세서에서 레지스터의 이름을 나타내는 문자 문자열입니다.

표 4-18에서는 ARM 아키텍처 기반 프로세서의 명명된 레지스터 변수에 사용할 수 있는 레지스터를 보여 줍니다.

표 4-18 ARM 아키텍처 기반 프로세서에 사용할 수 있는 명명된 레지스터

레지스터 __asm용 문자열 프로세서

CPSR "cpsr" 또는 "apsr" 모든 프로세서

BASEPRI "basepri" Cortex-M3

BASEPRI_MAX "basepri_max" Cortex-M3

CONTROL "control" Cortex-M1, Cortex-M3

EAPSR "eapsr" Cortex-M1, Cortex-M3

EPSR "epsr" Cortex-M1, Cortex-M3

FAULTMASK "faultmask" Cortex-M3

IAPSR "iapsr" Cortex-M1, Cortex-M3

IEPSR "iepsr" Cortex-M1, Cortex-M3

IPSR "ipsr" Cortex-M1, Cortex-M3

MSP "msp" Cortex-M1, Cortex-M3

PRIMASK "primask" Cortex-M1, Cortex-M3

PSP "psp" Cortex-M1, Cortex-M3

r0 ~ r12 "r0" ~ "r12" 모든 프로세서

r13 또는 sp "r13" 또는 "sp" 모든 프로세서

r14 또는 lr "r14" or "lr" 모든 프로세서

r15 또는 pc "r15" or "pc" 모든 프로세서

SPSR "spsr" 모든 프로세서

XPSR "xpsr" Cortex-M1, Cortex-M3



VFP를 사용하는 타겟에서도 표 4-19의 레지스터를 명명된 레지스터 변수로 사용할 수 있습니다.

예제

void foo(void){

register int foo __asm("r0");}

이 예제에서 foo는 r0 레지스터에 대한 명명된 레지스터 변수로 선언됩니다.

추가 참고

• 컴파일러 사용 설명서의 4-10페이지의 명명된 레지스터 변수

표 4-19 VFP를 사용하는 타겟에서 사용할 수 있는 명명된 레지스터

레지스터 __asm용 문자 문자열

FPSID "fpsid"

FPSCR "fpscr"

FPEXC "fpexc"



4.8 VFP 상태 내장 함수

컴파일러는 Floating Point and Status Control Register (FPSCR)읽기를 위한 내장 함수를 제공합니다.

참고

이 레지스터를 읽는 대체 방법으로 명명된 레지스터 변수를 사용하는 것이 좋습니다. 그러면 보다 효율적인 방법으로 액세스할 수 있습니다. 자세한 내용은 4-116페이지의 명명된 레지스터 변수을 참조하십시오.

4.8.1 __vfp_status

이 내장 함수는 FPSCR을 참조합니다.

구문

unsigned int __vfp_status(unsigned int mask, unsigned int flags);

오류

VFP가 없는 타겟에 대해 컴파일할 때 이 내장 함수를 사용하려고 하면 컴파일러에서 오류를 생성합니다.

추가 참고

• FPSCR 레지스터에 대한 자세한 내용은 ARM 아키텍처 참조 문서를 참조하십시오.



4.9 GNU 기본 제공 함수

이 함수는 GNU 라이브러리 헤더 파일과의 호환성을 제공합니다.

4.9.1 비표준 함수

__builtin_alloca(), __builtin_bcmp(), __builtin_exit(), __builtin_gamma(),__builtin_gammaf(), __builtin_gammal(), __builtin_index(), __builtin_rindex(),__builtin_strcasecmp(), __builtin_strncasecmp().

4.9.2 C99 함수

__builtin_Exit(), __builtin_acoshf(), __builtin_acoshl(), __builtin_acosh(),__builtin_asinhf(), __builtin_asinhl(), __builtin_asinh(), __builtin_atanhf(),__builtin_atanhl(), __builtin_atanh(), __builtin_cabsf(), __builtin_cabsl(),__builtin_cabs(), __builtin_cacosf(), __builtin_cacoshf(), __builtin_cacoshl(),__builtin_cacosh(), __builtin_cacosl(), __builtin_cacos(), __builtin_cargf(),__builtin_cargl(), __builtin_carg(), __builtin_casinf(), __builtin_casinhf(),__builtin_casinhl(), __builtin_casinh(), __builtin_casinl(), __builtin_casin(),__builtin_catanf(), __builtin_catanhf(), __builtin_catanhl(),__builtin_catanh(), __builtin_catanl(), __builtin_catan(), __builtin_cbrtf(),__builtin_cbrtl(), __builtin_cbrt(), __builtin_ccosf(), __builtin_ccoshf(),__builtin_ccoshl(), __builtin_ccosh(), __builtin_ccosl(), __builtin_ccos(),__builtin_cexpf(), __builtin_cexpl(), __builtin_cexp(), __builtin_cimagf(),__builtin_cimagl(), __builtin_cimag(), __builtin_clogf(), __builtin_clogl(),__builtin_clog(), __builtin_conjf(), __builtin_conjl(), __builtin_conj(),__builtin_copysignf(), __builtin_copysignl(), __builtin_copysign(),__builtin_cpowf(), __builtin_cpowl(), __builtin_cpow(), __builtin_cprojf(),__builtin_cprojl(), __builtin_cproj(), __builtin_crealf(), __builtin_creall(),__builtin_creal(), __builtin_csinf(), __builtin_csinhf(), __builtin_csinhl(),__builtin_csinh(), __builtin_csinl(), __builtin_csin(), __builtin_csqrtf(),__builtin_csqrtl(), __builtin_csqrt(), __builtin_ctanf(), __builtin_ctanhf(),__builtin_ctanhl(), __builtin_ctanh(), __builtin_ctanl(), __builtin_ctan(),__builtin_erfcf(), __builtin_erfcl(), __builtin_erfc(), __builtin_erff(),__builtin_erfl(), __builtin_erf(), __builtin_exp2f(), __builtin_exp2l(),__builtin_exp2(), __builtin_expm1f(), __builtin_expm1l(), __builtin_expm1(),__builtin_fdimf(), __builtin_fdiml(), __builtin_fdim(), __builtin_fmaf(),__builtin_fmal(), __builtin_fmaxf(), __builtin_fmaxl(), __builtin_fmax(),__builtin_fma(), __builtin_fminf(), __builtin_fminl(), __builtin_fmin(),__builtin_hypotf(), __builtin_hypotl(), __builtin_hypot(), __builtin_ilogbf(),__builtin_ilogbl(), __builtin_ilogb(), __builtin_imaxabs(), __builtin_isblank(),__builtin_isfinite(), __builtin_isinf(), __builtin_isnan(), __builtin_isnanf(),__builtin_isnanl(), __builtin_isnormal(), __builtin_iswblank(),__builtin_lgammaf(), __builtin_lgammal(), __builtin_lgamma(), __builtin_llabs(),__builtin_llrintf(), __builtin_llrintl(), __builtin_llrint(),__builtin_llroundf(), __builtin_llroundl(), __builtin_llround(),__builtin_log1pf(), __builtin_log1pl(), __builtin_log1p(), __builtin_log2f(),__builtin_log2l(), __builtin_log2(), __builtin_logbf(), __builtin_logbl(),



__builtin_logb(), __builtin_lrintf(), __builtin_lrintl(), __builtin_lrint(),__builtin_lroundf(), __builtin_lroundl(), __builtin_lround(),__builtin_nearbyintf(), __builtin_nearbyintl(), __builtin_nearbyint(),__builtin_nextafterf(), __builtin_nextafterl(), __builtin_nextafter(),__builtin_nexttowardf(), __builtin_nexttowardl(), __builtin_nexttoward(),__builtin_remainderf(), __builtin_remainderl(), __builtin_remainder(),__builtin_remquof(), __builtin_remquol(), __builtin_remquo(), __builtin_rintf(),__builtin_rintl(), __builtin_rint(), __builtin_roundf(), __builtin_roundl(),__builtin_round(), __builtin_scalblnf(), __builtin_scalblnl(),__builtin_scalbln(), __builtin_scalbnf(), __builtin_calbnl(),__builtin_scalbn(), __builtin_signbit(), __builtin_signbitf(),__builtin_signbitl(), __builtin_snprintf(), __builtin_tgammaf(),__builtin_tgammal(), __builtin_tgamma(), __builtin_truncf(), __builtin_truncl(),__builtin_trunc(), __builtin_vfscanf(), __builtin_vscanf(),__builtin_vsnprintf(), __builtin_vsscanf().

4.9.3 C90 예약 네임스페이스의 C99 함수

__builtin_acosf(), __builtin_acosl(), __builtin_asinf(), __builtin_asinl(),__builtin_atan2f(), __builtin_atan2l(), __builtin_atanf(), __builtin_atanl(),__builtin_ceilf(), __builtin_ceill(), __builtin_cosf(), __builtin_coshf(),__builtin_coshl(), __builtin_cosl(), __builtin_expf(), __builtin_expl(),__builtin_fabsf(), __builtin_fabsl(), __builtin_floorf(), __builtin_floorl(),__builtin_fmodf(), __builtin_fmodl(), __builtin_frexpf(), __builtin_frexpl(),__builtin_ldexpf(), __builtin_ldexpl(), __builtin_log10f(), __builtin_log10l(),__builtin_logf(), __builtin_logl(), __builtin_modfl(), __builtin_modf(),__builtin_powf(), __builtin_powl(), __builtin_sinf(), __builtin_sinhf(),__builtin_sinhl(), __builtin_sinl(), __builtin_sqrtf(), sqrtl, __builtin_tanf(),__builtin_tanhf(), __builtin_tanhl(), __builtin_tanl().

4.9.4 C94 함수

__builtin_swalnum(), __builtin_iswalpha(), __builtin_iswcntrl(),__builtin_iswdigit(), __builtin_iswgraph(), __builtin_iswlower(),__builtin_iswprint(), __builtin_iswpunct(), __builtin_iswspace(),__builtin_iswupper(), __builtin_iswxdigit(), __builtin_towlower(),__builtin_towupper().



4.9.5 C90 함수

__builtin_abort(), __builtin_abs(), __builtin_acos(), __builtin_asin(),__builtin_atan2(), __builtin_atan(), __builtin_calloc(), __builtin_ceil(),__builtin_cosh(), __builtin_cos(), __builtin_exit(), __builtin_exp(),__builtin_fabs(), __builtin_floor(), __builtin_fmod(), __builtin_fprintf(),__builtin_fputc(), __builtin_fputs(), __builtin_frexp(), __builtin_fscanf(),__builtin_isalnum(), __builtin_isalpha(), __builtin_iscntrl(),__builtin_isdigit(), __builtin_isgraph(), __builtin_islower(),__builtin_isprint(), __builtin_ispunct(), __builtin_isspace(),__builtin_isupper(), __builtin_isxdigit(), __builtin_tolower(),__builtin_toupper(), __builtin_labs(), __builtin_ldexp(), __builtin_log10(),__builtin_log(), __builtin_malloc(), __builtin_memchr(), __builtin_memcmp(),__builtin_memcpy(), __builtin_memset(), __builtin_modf(), __builtin_pow(),__builtin_printf(), __builtin_putchar(), __builtin_puts(), __builtin_scanf(),__builtin_sinh(), __builtin_sin(), __builtin_snprintf(), __builtin_sprintf(),__builtin_sqrt(), __builtin_sscanf(), __builtin_strcat(), __builtin_strchr(),__builtin_strcmp(), __builtin_strcpy(), __builtin_strcspn(), __builtin_strlen(), __builtin_strncat(), __builtin_strncmp(),__builtin_strncpy(), __builtin_strpbrk(), __builtin_strrchr(),__builtin_strspn(), __builtin_strstr(), __builtin_tanh(), __builtin_tan(),__builtin_vfprintf(), __builtin_vprintf(), __builtin_vsprintf().

4.9.6 C99 부동 소수점 함수

__builtin_huge_val(), __builtin_huge_valf(), __builtin_huge_vall(),__builtin_inf(), __builtin_nan(), __builtin_nanf(), __builtin_nanl(),__builtin_nans(), __builtin_nansf(), __builtin_nansl().

4.9.7 기타 기본 제공 함수

__builtin_clz(), __builtin_constant_p(), __builtin_ctz(), builtin_ctzl(),__builtin_ctzll(), __builtin_expect(), __builtin_ffs(), __builtin_ffsl(),__builtin_ffsll(), __builtin_frame_address(), __builtin_return_address(),__builtin_popcount(), __builtin_signbit().



4.10 컴파일러 사전 정의

이 단원에서는 ARM 컴파일러의 사전 정의된 매크로에 대해 설명합니다.

4.10.1 사전 정의된 매크로

표 4-20은 C 및 C++에서 ARM 컴파일러가 사전 정의하는 매크로 이름을 나열합니다. 값 필드가 빈 곳에서는 기호만 정의됩니다.

표 4-20 사전 정의된 매크로

이름 값 정의되는 경우

__arm__ – --thumb 옵션을 지정하는 경우에도 ARM 컴파일러에 대해 항상 정의됩니다.

__ARMCC_VERSION도 참조하십시오.

__ARMCC_VERSION ver 항상 정의됩니다. 10진수이며 릴리스가 바뀔 때마다 증가합니다. 형식은 PVbbbb이며 여기서,

• P는 주 버전입니다.

• V는 부 버전입니다.

• bbbb는 빌드 번호입니다.

참고

이것을 사용하여 RVCT와 __arm__을 정의하는 다른 도구를 구분하십시오.

__APCS_INTERWORK – --apcs /interwork 옵션을 지정하거나 CPU 아키텍처를 ARMv5T 이후 버전으로 설정할 경우 정의됩니다.

__APCS_ROPI – --apcs /ropi 옵션을 지정할 경우 정의됩니다.

__APCS_RWPI – --apcs /rwpi 옵션을 지정할 경우 정의됩니다.

__APCS_FPIC – --apcs /fpic 옵션을 지정할 경우 정의됩니다.

__ARRAY_OPERATORS – C++ 컴파일러 모드에서 배열 새로 만들기 및 삭제를 사용 가능하도록 지정합니다.

__BASE_FILE__ name 항상 정의됩니다. __FILE__과 유사하지만 현재 파일이 아니라 기본 소스 파일을 나타냅니다(즉, 현재 파일이 포함된 파일일 경우).

__BIG_ENDIAN – 빅엔디안 타겟에 대해 컴파일할 경우 정의됩니다.



_BOOL – C++ 컴파일러 모드에서 bool이 키워드임을 지정하기 위해 정의됩니다.

__cplusplus – C++ 컴파일러 모드의 경우 정의됩니다.

__CC_ARM 1 --thumb 옵션을 지정할 경우에도 항상 ARM 컴파일러에 대해 1로 설정됩니다.

__CHAR_UNSIGNED__ – GNU 모드에서 char이 unsigned 유형인 경우에만 정의됩니다.

__DATE__ date 항상 정의됩니다.

__EDG__ – 항상 정의됩니다.

__EDG_IMPLICIT_USING_STD – C++ 모드에서 --implicit_using_std 옵션을 지정할 경우 정의됩니다.

__EDG_VERSION__ – EDG(Edison Design Group) 프런트 엔드의 버전 번호를 나타내는 정수 값으로 항상 설정됩니다. 예를 들어 버전 3.8은 308로 표시됩니다.

EDG 프런트 엔드의 버전 번호는 RVCT나 RealView Development Suite 버전 번호와 반드시 일치할 필요는 없습니다.

__EXCEPTIONS 1 C++ 모드에서 --exceptions 옵션을 지정할 경우 정의됩니다.

__FEATURE_SIGNED_CHAR – CHAR_MIN 및 CHAR_MAX에서 사용하는 --signed_chars 옵션을 지정할 경우 정의됩니다.

__FILE__ name 항상 문자열 리터럴로 정의됩니다.

__FP_FAST – --fpmode=fast 옵션을 지정할 경우 정의됩니다.

__FP_FENV_EXCEPTIONS – --fpmode=ieee_full 또는 --fpmode=ieee_fixed 옵션을 지정할 경우 정의됩니다.

__FP_FENV_ROUNDING – --fpmode=ieee_full 옵션을 지정할 경우 정의됩니다.

__FP_IEEE – --fpmode=ieee_full, --fpmode=ieee_fixed 또는 --fpmode=ieee_no_fenv 옵션을 지정할 경우 정의됩니다.

__FP_INEXACT_EXCEPTION – --fpmode=ieee_full 옵션을 지정할 경우 정의됩니다.

__GNUC__ ver --gnu 옵션을 지정할 경우 정의됩니다. 사용 중인 GNU 모드의 현재 주 버전을 보여 주는 정수입니다.

표 4-20 사전 정의된 매크로 (계속)




__GNUC_MINOR__ ver --gnu 옵션을 지정할 경우 정의됩니다. 사용 중인 GNU 모드의 현재 부 버전을 보여 주는 정수입니다.

__GNUG__ ver GNU 모드에서 --cpp 옵션을 지정할 경우 정의됩니다. __GNUC__ 값과 동일합니다.

__IMPLICIT_INCLUDE – --implicit_include 옵션을 지정할 경우 정의됩니다.

__INTMAX_TYPE__ – GNU 모드에서 정의됩니다. intmax_t typedef의 올바른 원본 유형을 지정합니다.

__LINE__ num 항상 설정됩니다. 이 매크로를 포함하는 코드 라인의 소스 행 번호입니다.

__MODULE__ mod __FILE__ 값의 파일 이름 부분을 포함합니다.

__NO_INLINE__ – GNU 모드에서 --no_inline 옵션을 지정할 경우 정의됩니다.

__OPTIMISE_LEVEL num -Onum 옵션을 사용하여 최적화 수준을 변경하지 않는 한 항상 기본적으로 2로 설정됩니다.

__OPTIMISE_SPACE – -Ospace 옵션을 지정할 경우 정의됩니다.

__OPTIMISE_TIME – -Otime 옵션을 지정할 경우 정의됩니다.

__OPTIMIZE__ – GNU 모드에서 -O1, -O2 또는 -O3가 지정될 경우 정의됩니다.

__OPTIMIZE_SIZE__ – GNU 모드에서 -Ospace가 지정될 경우 정의됩니다.

__PLACEMENT_DELETE – C++ 모드에서 배치 삭제(즉, 생성자가 예외를 throw할 경우 호출되는 배치 연산자 new에 해당하는 연산자 delete)가 지정하기 위해 정의됩니다. 이것은 예외를 사용할 경우에만 관련됩니다.

__PTRDIFF_TYPE__ – GNU 모드에서 ptrdiff_t typedef의 올바른 원본 유형을 지정합니다.

__RTTI – C++ 모드에서 RTTI가 사용 가능할 경우 정의됩니다.

__sizeof_int 4 sizeof(int)를 위한 것이지만 사전 처리기 식에서 사용 가능합니다.

__sizeof_long 4 sizeof(long)을 위한 것이지만 사전 처리기 식에서 사용 가능합니다.





__sizeof_ptr 4 sizeof(void *)를 위한 것이지만 사전 처리기 식에서 사용 가능합니다.

__SIZE_TYPE__ – GNU 모드에서 size_t typedef의 올바른 원본 유형을 지정합니다.

__SOFTFP__ – 소프트웨어 부동 소수점 호출 표준과 라이브러리를 사용하도록 컴파일할 경우 정의됩니다. ARM 또는 Thumb에서 --fpu=softvfp 옵션을 지정할 경우이거나 Thumb에서 --fpu=softvfp+vfpv2를 지정할 경우 정의됩니다.

__STDC__ – 모든 컴파일러 모드에서 정의됩니다.

__STDC_VERSION__ – 표준 버전 정보입니다.

__STRICT_ANSI__ – --strict 옵션을 지정할 경우 정의됩니다.

__SUPPORT_SNAN__ – --fpmode=ieee_fixed 또는 --fpmode=ieee_full 지정 시 NaN 신호 발생을 지원합니다.

__TARGET_ARCH_ARM num 타겟 CPU의 ARM 기본 아키텍처의 수(컴파일러가 ARM에 대해 컴파일하거나 Thumb에 대해 컴파일하거나 관계 없음). ARM 아키텍처 버전과 관련하여 __TARGET_ARCH_ARM에 사용할 수 있는 값은 4-129페이지의 표 4-21을 참조하십시오.

__TARGET_ARCH_THUMB num 타겟 CPU의 Thumb 기본 아키텍처의 수(컴파일러가 ARM에 대해 컴파일하거나 Thumb에 대해 컴파일하거나 관계 없음). 타겟이 Thumb을 지원하지 않을 경우 이 값은 0으로 정의됩니다. ARM 아키텍처 버전과 관련하여 __TARGET_ARCH_THUMB에 사용할 수 있는 값은 4-129페이지의 표 4-21을 참조하십시오.

__TARGET_ARCH_XX – XX는 타겟 아키텍처를 나타내며 그 값은 타겟 아키텍처에 따라 다릅니다. 예를 들어 컴파일러 옵션 --cpu=4T 또는 --cpu=ARM7TDMI를 지정할 경우 __TARGET_ARCH_4T가 정의됩니다.

__TARGET_CPU_XX – XX는 타겟 CPU를 나타냅니다. XX 의 값은 --cpu 컴파일러 옵션에서 파생되거나 지정된 것이 없을 경우 기본값이 됩니다. 예를 들어 컴파일러 옵션 --cpu=ARM7TM을 설정할 경우 __TARGET_CPU_ARM7TM이 정의되며 __TARGET_CPU_ 로 시작되는 다른 기호는 정의되지 않습니다.

타겟 아키텍처를 지정할 경우 __TARGET_CPU_generic 이 정의됩니다.

프로세서 이름에 하이픈(-) 문자가 포함되어 있을 경우, 이 문자는 밑줄(_)로 매핑됩니다. 예를 들어 --cpu=ARM1136JF-S는 __TARGET_CPU_ARM1136JF_S로 매핑됩니다.





__TARGET_FEATURE_DOUBLEWORD – ARMv5T 이상에서 정의됩니다.

__TARGET_FEATURE_DSPMUL – ARMv5TE에서와 같이 DSP 승수를 사용할 수 있는 경우 정의됩니다.

__TARGET_FEATURE_MULTIPLY – 타겟 아키텍처가 long 곱하기 명령어 MULL 및 MULAL을 지원할 경우 정의됩니다.

__TARGET_FEATURE_DIVIDE – 타겟 아키텍처가 하드웨어 나누기 명령어(즉, ARMv7-M 또는 ARMv7-R)를 지원할 경우 정의됩니다.

__TARGET_FEATURE_MULTIPROCESSING – 다음 옵션을 지정할 경우 정의됩니다.

• --cpu=Cortex-A9

• --cpu=Cortex-A9.no_neon

• --cpu=Cortex-A9.no_neon.no_vfp

__TARGET_FEATURE_THUMB – 타겟 아키텍처가 Thumb(ARMv4T 이상)을 지원할 경우 정의됩니다.

__TARGET_FPU_xx – 다음 중 하나가 FPU 사용을 나타내도록 설정됩니다.

• __TARGET_FPU_NONE

• __TARGET_FPU_VFP

• __TARGET_FPU_SOFTVFP

또한 다음의 --fpu 옵션 중 하나를 사용하여 컴파일하는 경우에는 해당하는 타겟 이름이 설정됩니다.

• --fpu=softvfp+vfpv2, __TARGET_FPU_SOFTVFP_VFPV2

• --fpu=softvfp+vfpv3, __TARGET_FPU_SOFTVFP_VFPV3

• --fpu=softvfp+vfpv3_fp16, __TARGET_FPU_SOFTVFP_VFPV3_FP16

• --fpu=softvfp+vfpv3_d16, __TARGET_FPU_SOFTVFP_VFPV3_D16

• --fpu=softvfp+vfpv3_d16_fp16, __TARGET_FPU_SOFTVFP_VFPV3_D16_FP16

• --fpu=vfpv2, __TARGET_FPU_VFPV2

• --fpu=vfpv3, __TARGET_FPU_VFPV3

• --fpu=vfpv3_fp16, __TARGET_FPU_VFPV3_FP16

• --fpu=vfpv3_d16, __TARGET_FPU_VFPV3_D16

• --fpu=vfpv3_d16_fp16, __TARGET_FPU_VFPV3_D16_FP16

자세한 내용은 2-65페이지의 --fpu=name를 참조하십시오.





__TARGET_PROFILE_A --cpu=7-A 옵션을 지정할 경우 정의됩니다.

__TARGET_PROFILE_R --cpu=7-R 옵션을 지정할 경우 정의됩니다.

__TARGET_PROFILE_M 다음 옵션을 지정할 경우 정의됩니다.

• --cpu=6-M

• --cpu=6S-M

• --cpu=7-M

__thumb__ – 컴파일러가 Thumb 모드일 경우. 즉, 명령 행에서 --thumb 옵션을 지정했거나 소스 코드에서 #pragma thumb을 지정했을 경우입니다.

참고

• 컴파일러는 Thumb에 대해 컴파일할 경우에도 ARM 코드를 생성할 수 있습니다.

• __thumb 및 __thumb__은 #pragma thumb 또는 #pragma arm을 사용할 경우 정의되거나 정의되지 않게 됩니다. 하지만 Thumb 함수가 다른 이유로 인해 ARM 코드로 생성될 경우에는 변경되지 않습니다(예: __irq로 지정된 함수).

__TIME__ time 항상 정의됩니다.

__UINTMAX_TYPE__ – GNU 모드에서 정의됩니다. uintmax_t typedef의 올바른 원본 유형을 지정합니다.

__USER_LABEL_PREFIX__ GNU 모드에서 빈 문자열을 정의합니다. 이 매크로는 일부 Linux 헤더 파일에 사용됩니다.

__VERSION__ ver --gnu 옵션을 지정할 경우 정의됩니다. 사용 중인 GNU 모드의 현재 버전을 보여 주는 문자열입니다.

_WCHAR_T – C++ 모드에서 wchar_t가 키워드임을 지정할 경우 정의됩니다.

__WCHAR_TYPE__ – GNU 모드에서 정의됩니다. wchar_t typedef의 올바른 원본 유형을 지정합니다.

__WCHAR_UNSIGNED__ – GNU 모드에서 --cpp 옵션을 지정할 경우 정의됩니다. wchar_t가 unsigned 유형인 경우에만 정의됩니다.

__WINT_TYPE__ – GNU 모드에서 wint_t typedef의 올바른 원본 유형을 지정합니다.





표 4-21에는 __TARGET_ARCH_THUMB에 사용할 수 있는 값(4-123페이지의 표 4-20 참조)과 이러한 값과 ARM 아키텍처 버전과의 관계를 보여 줍니다.

4.10.2 함수 이름

표 4-22에서는 C 및 C++에 대해 ARM 컴파일러에서 지원되는 기본 제공 변수를 보여 줍니다.

표 4-21 ARM 아키텍처 버전과 관련한 Thumb 아키텍처 버전

ARM 아키텍처 __TARGET_ARCH_ARM __TARGET_ARCH_THUMB

v4 4 0

v4T 4 1

v5T, v5TE, v5TEJ 5 2

v6, v6K, v6Z 6 3

v6T2 6 4

v6-M, v6S-M 0 3

v7-A, v7-R 7 4

v7-M 0 4

표 4-22 기본 제공 변수

이름 값

__FUNCTION__ 함수 이름을 소스에 나타나는 대로 유지합니다.

__FUNCTION__은 상수 문자열 리터럴입니다. 사전 처리기를 사용하여 내용을 다른 텍스트에 결합하여 새 토큰을 만들 수 없습니다.

__PRETTY_FUNCTION__ 언어별 방식으로 인쇄되어 나타나는 대로 함수 이름을 유지합니다.

__PRETTY_FUNCTION__은 상수 문자열 리터럴입니다. 사전 처리기를 사용하여 내용을 다른 텍스트에 결합하여 새 토큰을 만들 수 없습니다.


5장 C 및 C++ 구현 정보

이 장에서는 ARM 컴파일러에 대한 언어 구현 정보에 대해 설명합니다. 다음 내용이 포함됩니다.

• 5-2페이지의 C 및 C++ 구현 정보

• 5-14페이지의 C++ 구현 정보


C 및 C++ 구현 정보

5.1 C 및 C++ 구현 정보

이 단원에서는 C와 C++에 공통된 언어 구현 정보에 대해 설명합니다.

5.1.1 문자 세트와 식별자

다음 사항은 컴파일러가 예상하는 문자 세트와 식별자에 적용됩니다.

• 대문자와 소문자는 모든 내부 및 외부 식별자에서 구별됩니다. 또한 --strict 컴파일러 옵션이 지정되지 않는 한 식별자에 달러 문자($)도 포함될 수 있습니다. --strict 옵션이 지정된 식별자에 달러 부호를 허용하려면 --dollar 명령 행 옵션도 사용하십시오.

• setlocale(LC_CTYPE, "ISO8859-1")을 호출하면 isupper()와 islower() 함수가 7비트 ASCII 하위 세트가 아니라 완전 8비트 Latin-1 알파벳에서와 같이 동작합니다. 링크 타임에 로케일을 선택해야 합니다.

• 소스 파일은 현재 선택된 로케일에 따라 컴파일됩니다. 소스 파일에 비 ASCII 문자가 포함되어 있을 경우 --locale 명령 행 옵션을 사용하여 다른 로케일을 선택해야 할 수도 있습니다. 자세한 내용은 컴파일러 사용 설명서에서 2-2페이지의 ARM 컴파일러 호출을 참조하십시오.

• ARM 컴파일러는 유니코드 같은 다중 바이트 문자 세트를 지원합니다.

• 소스 문자 세트의 다른 속성은 호스트에 따라 다릅니다.

실행 문자 세트의 속성은 타겟에 따라 다릅니다. ARM C 및 C++ 라이브러리는 다음과 같은 결과로 ISO 8859-1(Latin-1 알파벳) 문자 세트를 지원합니다.

• 실행 문자 세트는 소스 문자 세트와 동일합니다.

• 실행 문자 세트의 한 문자에는 8비트가 있습니다.

• 하나의 int에는 4문자(바이트)가 있습니다. 다음과 같은 메모리 시스템이 지원됩니다.

리틀엔디안 바이트는 최하위 주소의 최하위 바이트로부터 최상위 주소의 최상위 바이트의 순서로 배열됩니다.

빅엔디안 바이트는 최상위 주소의 최하위 바이트부터 최하위 주소의 최상위 바이트의 순서로 배열됩니다.

• C에서는 모든 문자 상수에 int 형식이 있습니다. C++에서 한 문자를 포함하는 문자 상수에는 char 형식이 있으며, 여러 문자를 포함하는 문자 상수에는 int 형식이 있습니다. 상수의 최대 4문자는 정수 값으로 표시됩니다. 상수의



마지막 문자는 정수 값의 최하위 바이트를 차지합니다. 최대 세 개의 선행 문자가 상위 순위의 바이트에 배치될 수 있습니다. 사용되지 않는 바이트는 NULL 문자(\0)로 채워집니다.

• 표 5-1에서는 단일 문자 또는 문자 확장 시퀀스를 포함하는 모든 정수 문자 상수를 소스 문자 세트 및 실행 문자 세트로 모두 표시하여 나열합니다.

• 문자열 리터럴과 문자 상수의 소스 문자 세트의 문자는 실행 문자 세트로 동일하게 매핑됩니다.

• char 유형의 데이터 항목은 기본적으로 부호가 없습니다. 이 항목들은 signed char 또는 unsigned char로 명시적으로 선언될 수 있습니다.

— --signed_chars 옵션을 사용하여 char에 부호를 부여할 수 있습니다.

— --unsigned_chars 옵션을 사용하여 char에 부호를 없앨 수 있습니다.

참고

--signed_chars 및 --unsigned_chars 옵션을 사용하거나 사용하지 않고 컴파일되었으며 인터페이스 또는 데이터 구조를 공유하는 변환 단위를 혼합할 때는 주의해야 합니다.

ARM ABI는 char를 부호 없는 바이트로 정의하며, 이는 RVCT와 함께 제공되는 C++ 라이브러리에서 사용하는 해석입니다.

표 5-1 문자 확장 코드

확장 시퀀스 문자 값 설명

\a 7 주의(벨)

\b 8 백스페이스

\t 9 수평 탭

\n 10 새 라인(줄 바꿈)

\v 11 수직 탭

\f 12 폼 피드

\r 13 캐리지 리턴

\xnn 0xnn 16진수 ASCII 코드

\nnn 0nnn 8진수 ASCII 코드



• 다중 바이트 문자를 넓은 문자 상수를 위한 넓은 문자 코드로 전환하는 데 로케일이 사용되지 않습니다. 이것은 일반적인 구현과 관련이 없습니다.

5.1.2 기본 데이터 유형

이 단원에서는 ARM C 및 C++에서 기본 데이터 유형을 구현하는 방법에 대해 설명합니다.

기본 데이터 유형의 크기와 정렬

표 5-2에서는 기본 데이터 유형의 크기와 기본 정렬을 보여 줍니다.

표 5-2 데이터 유형의 크기와 정렬

형식 크기(비트) 기본 정렬(바이트)

char 8 1 (바이트 단위 정렬)

short 16 2 (하프워드 단위 정렬)

int 32 4 (워드 단위 정렬)

long 32 4 (워드 단위 정렬)

long long 64 8 (더블워드 단위 정렬)

float 32 4 (워드 단위 정렬)

double 64 8 (더블워드 단위 정렬)

long double 64 8 (더블워드 단위 정렬)

모든 포인터 32 4 (워드 단위 정렬)

bool (C++ 전용) 8 1 (바이트 단위 정렬)

_Bool(C 전용a )

a. stdbool.h를 사용하여 C에서 bool 매크로를 정의할 수 있습니다.

8 1 (바이트 단위 정렬)

wchar_t (C++ 전용) 16 2 (하프워드 단위 정렬)



유형 정렬은 컨텍스트에 따라 다릅니다.

• 지역 변수는 보통 레지스터에 보존되지만, 스택으로 스필되면 항상 워드 단위로 정렬됩니다. 예를 들어 스필된 지역 char 변수는 4의 정렬을 갖습니다.

• 패킹된 유형의 기본 정렬은 1입니다.

자세한 내용은 5-7페이지의 구조체, 공용체, 열거 및 비트 필드를 참조하십시오.

정수

정수는 2의 보수 형식으로 표시됩니다. long long의 하위 워드는 리틀엔디안 모드의 하위 주소와 빅엔디안 모드의 상위 주소에 있습니다.

부동 소수점

부동 소수점 수량은 IEEE 형식으로 저장됩니다.

• float 값은 IEEE 단일정밀도 값으로 나타냅니다.

• double 및 long double 값은 IEEE 배정밀도 값으로 나타냅니다.

double과 long double 수량의 경우 부호, 지수, 가수의 가장 중요한 부분을 포함하는 워드는 빅엔디안 모드의 하위 시스템 주소, 리틀엔디안 모드의 상위 시스템 주소에 저장됩니다. 자세한 내용은 5-7페이지의 부동 소수점 유형에 대한 연산을 참조하십시오.

배열과 포인터

다음 사항은 구성원에 대한 포인터를 제외하고 C 및 C++의 객체에 대한 모든 포인터에 적용됩니다.

• 인접 바이트는 1씩 달라지는 주소를 가집니다.

• NULL 매크로는 0의 값으로 확장됩니다.

• 정수와 포인터 간에 캐스트해도 표현이 변경되지 않습니다.

• 컴파일러는 함수에 대한 포인터와 데이터에 대한 포인터 사이의 캐스트에 대해 경고합니다.

• size_t 유형은 unsigned int로 정의됩니다.

• ptrdiff_t 유형은 signed int로 정의됩니다.



5.1.3 기본 데이터 유형에 대한 연산

ARM 컴파일러는 ISO C99 및 ISO C++ 표준의 관련 섹션에서 설정한 일반 산술 변환을 수행합니다. 다음 소단원에서는 산술 연산과 관련된 추가 사항에 대해 설명합니다.

B-7페이지의 식 평가도 참조하십시오.

정수 유형에 대한 연산

다음 사항은 정수 유형에 대한 연산에 적용됩니다.

• 모든 부호 있는 정수의 산술은 2의 보수 표현을 사용합니다.

• 부호 있는 정수 유형에 대한 비트 단위 연산은 2의 보수 표현에서 기본적으로 발생하는 규칙을 따릅니다. 부호 확장은 발생하지 않습니다.

• 부호 있는 수량에서 오른쪽 시프트는 산술입니다.

• int 유형 값의 경우 다음과 같습니다.

— 0 - 127 범위를 벗어난 시프트는 정의되지 않습니다.

— 31보다 큰 왼쪽 시프트는 0의 결과를 제공합니다.

— 31보다 큰 오른쪽 시프트는 부호 없는 값 또는 양의 부호가 있는 값의 시프트에서 0의 결과를 제공합니다. 음의 부호 있는 값의 시프트인 경우에는 -1을 생성합니다.

• long long 유형의 경우 0 - 63 범위를 벗어난 시프트는 정의되지 않습니다.

• ISO C99 표준에 따라 정수를 나눈 후 나머지는 분자와 같은 부호를 갖습니다.

• 정수 유형의 값이 짧은 부호 있는 정수 유형으로 잘리면 결과는 가장 중요한 비트 중 적절한 숫자를 폐기하여 구합니다. 원래 숫자가 양수 또는 음수에 관계 없이 새 유형에 너무 크면 결과의 부호가 원래 숫자의 부호와 같지 않을 수도 있습니다.

• 정수 유형 간의 변환에는 예외가 발생하지 않습니다.

• 정수 오버플로에는 예외가 발생하지 않습니다.

• 정수를 0으로 나누면 기본적으로 0이 반환됩니다.



부동 소수점 유형에 대한 연산

다음 사항은 부동 소수점 유형에 대한 연산에 적용됩니다.

• 기본 IEEE 754 규칙이 적용됩니다.

• 기본적으로 가장 가까운 표현 가능한 값으로 반올림됩니다.

• 부동 소수점 예외는 기본적으로 사용하지 않습니다.

2-63페이지의 --fpmode=model도 참조하십시오.

참고

부동 소수점 처리를 위한 IEEE 754 표준에 따르면 예외에 대한 기본 조치는 트랩 없는 처리입니다. fenv.h의 함수 및 정의를 조정하여 부동 소수점 오류 처리를 수정할 수 있습니다. 자세한 내용은 2-66페이지의 오류 신호, 오류 처리 및 프로그램 종료 조정을 참조하십시오.

포인터 빼기

다음 사항은 C의 모든 포인터에 적용되며 구성원에 대한 포인터를 제외하고 C++의 포인터에 적용됩니다.

• 포인터 한 개를 다른 포인터에서 빼면 그 차이가 식의 결과입니다

((int)a - (int)b) / (int)sizeof(type pointed to)

• 정렬이 객체의 크기와 같은 객체를 포인터가 가리키면 이 정렬은 나누기가 정확하도록 보장합니다.

• 패킹된 유형 및 대부분의 struct처럼 정렬이 객체의 크기보다 작은 객체를 포인터가 가리킬 경우 두 포인터 모두 동일한 배열의 요소를 가리켜야 합니다.

5.1.4 구조체, 공용체, 열거 및 비트 필드

이 단원에서는 구조화된 데이터 유형 union, enum 및 struct의 구현에 대해 설명합니다. 또한 구조체 패딩과 비트 필드 구현에 대해서도 설명합니다.

자세한 내용은 3-21페이지의 익명 클래스, 구조체 및 공용체를 참조하십시오.

공용체

union의 구성원을 다른 유형의 구성원을 통해 액세스하면 결과 값은 원래 유형의 표현으로부터 예상할 수 있습니다. 오류는 발생하지 않습니다.



열거

객체 유형 enum은 enum의 범위가 포함된 최소 정수 유형에서 구현됩니다. 저장 유형 enum은 enum의 열거자 범위에 따라 다음 중 첫 번째입니다.

• --enum_is_int를 사용하지 않을 경우 unsigned char

• --enum_is_int를 사용하지 않을 경우 signed char

• --enum_is_int를 사용하지 않을 경우 unsigned short

• --enum_is_int를 사용하지 않을 경우 signed short

• signed int

• --strict가 있는 C를 제외하고 unsigned int

• --strict가 있는 C를 제외하고 signed long long

• --strict가 있는 C를 제외하고 unsigned long long

이런 방식으로 enum를 구현하면 데이터 크기를 줄일 수 있습니다. 명령- 행 옵션 --enum_is_int는 기본 유형 enum을 최소한 int.만큼 넓게 만들어 줍니다.

자세한 내용은 ARM 아키텍처용 프로시저 호출 표준 사양에서 C 언어 매핑에 대한 설명을 참조하십시오.

참고

--enum_is_int 옵션을 사용하거나 사용하지 않고 컴파일되었으며 인터페이스 또는 데이터 구조를 공유하는 변환 단위를 혼합할 때는 주의해야 합니다.

범위를 벗어난 값의 처리

엄격한 C에서는 열거자 값을 int로 나타낼 수 있어야 합니다. 예를 들어 열거자 값은 -2147483648 ~ +2147483647의 범위에 있어야 합니다. 이전 릴리스의 RVCT에서는 --strict 옵션을 지정하지 않은 경우 값이 범위를 벗어나면 해당 값이 int로 캐스트되고 경고는 표시되지 않았습니다.

RVCT v2.2 이상에서는 범위를 벗어난 열거자 값에 대해 다음과 같은 경고가 발생합니다.

#66: enumeration value is out of "int" range

이런 값은 C++에서와 동일한 방식으로 처리됩니다. 즉, unsigned int, long long 또는 unsigned long long으로 처리됩니다.

범위를 벗어난 값에 대한 경고가 보고되도록 하려면 다음 명령을 사용하여 경고를 오류로 변경하십시오.

armcc --diag_error=66 ...



구조체

다음 사항은 아래 항목에 적용됩니다.

• 모든 C 구조체

• 가상 함수나 기본 클래스를 사용하지 않는 모든 C++ 구조체와 클래스

구조체 정렬

패킹되지 않는 구조체의 정렬은 해당 필드에 필요한 최대 정렬입니다.

필드 정렬

구조체는 최하위 주소에 첫 번째로 명명된 구성요소에 의해 배열됩니다. 필드는 다음과 같이 정렬됩니다.

• char 유형의 필드는 사용 가능한 다음 바이트에 정렬됩니다.

• short 유형의 필드는 짝수 주소의 다음 바이트에 정렬됩니다.

• RVCT v2.0 이상에서는 double 및 long long 데이터 유형이 8바이트 단위로 정렬됩니다. 따라서 ARMv5TE 이상에서 LDRD 및 STRD 명령어를 효율적으로 사용할 수 있습니다.

• 비트 필드 정렬은 비트 필드가 선언되는 방식에 따라 달라집니다. 자세한 내용은 5-13페이지의 패킹된 구조체의 비트 필드를 참조하십시오.

• 다른 모든 유형은 워드 단위로 정렬됩니다.

구조체에는 필드가 정확히 정렬되고 구조체 자체가 정확히 정렬되도록 패딩이 포함될 수 있습니다. 그림 5-1에서는 패킹되지 않은 기존 구조체의 한 예를 보여 줍니다. 바이트 1, 2 및 3은 정확한 필드 정렬을 보장하기 위해 패딩됩니다. 바이트 11 및 12는 정확한 구조체 정렬을 보장하기 위해 패딩됩니다. sizeof() 함수는 패딩을 포함하여 구조체의 크기를 반환합니다.

그림 5-1 패킹되지 않는 기존 구조체의 예

0 1 2 3c

s

x

padding

struct {char c; int x; short s} ex1;

padding

4 5 7 8

9 10 11 12



컴파일러는 구조체의 정의 방식에 따라 다음 방법 중 하나로 구조체를 패딩합니다.

• static 또는 extern으로 정의된 구조체는 0으로 패딩됩니다.

• malloc() 또는 auto를 사용하여 정의된 구조체처럼 스택이나 힙의 구조체는 해당 메모리 위치에 이전에 저장된 것을 사용하여 패딩됩니다. 이런 방식으로 정의된 패딩된 구조를 비교하는 데 memcmp()를 사용할 수 없습니다(5-9페이지의 그림 5-1 참조).

컴파일러가 struct에 패딩을 삽입할 때 생성된 메시지를 보려면 --remarks 옵션을 사용하십시오.

빈 이니셜라이저가 있는 구조는 C++에서 허용됩니다.

struct{

int x;} X = { };

그러나 -cpp 및 --c90 옵션을 사용하여 C 또는 C++를 컴파일하면 오류가 생성됩니다.

패킹된 구조체

구조체 및 구조체 내의 필드의 정렬이 항상 1인 경우 패킹된 구조체는 하나입니다.

__packed 한정자를 사용하여 특정 구조체를 패킹할 수 있습니다. 또한 #pragma pack(n)을 사용하면 정렬되지 않은 데이터가 포함된 모든 구조체가 패킹되도록 할 수 있습니다. 기본 구조체 패킹을 변경하는 명령 행 옵션은 없습니다.

비트 필드

패킹되지 않는 구조체에서 ARM 컴파일러는 컨테이너에 비트 필드를 할당합니다. 컨테이너는 선언된 유형을 가진 정확히 정렬된 객체입니다.

비트 필드는 구성에 따라 첫 번째로 지정된 필드가 워드의 최하위 주소를 가진 비트를 차지하도록 할당됩니다.

리틀엔디안 최하위 주소를 가진다는 것은 중요도가 가장 낮다는 것을 의미합니다.



빅엔디안 최하위 주소를 가진다는 것은 중요도가 가장 높다는 것을 의미합니다.

비트 필드 컨테이너는 어떤 정수 유형도 될 수 있습니다.

참고

엄격한 1990 ISO 표준 C에서 비트 필드에 허용된 유형은 int, signed int 및 unsigned int뿐입니다. int 계열이 아닌 비트 필드의 경우 컴파일러에 오류가 표시됩니다..

signed 또는 unsigned 한정자 없이 선언되는 일반 비트 필드는 unsigned로 처리됩니다. 예를 들어 int x:10은 10비트의 부호 없는 정수를 할당합니다.

비트 필드는 충분한 수의 미할당 비트를 가진 올바른 유형의 첫 번째 컨테이너에 할당됩니다. 예를 들면 다음과 같습니다.

struct X{ int x:10; int y:20;};

첫 번째 선언은 정수 컨테이너를 생성하고 10비트를 x에 할당합니다. 두 번째 선언에서 컴파일러는 충분한 수의 미할당 비트가 있는 기존의 정수 컨테이너를 찾아 x와 동일한 컨테이너에 y를 할당합니다.

비트 필드는 완전히 해당 컨테이너에 포함됩니다. 컨테이너에 들어가지 않는 비트 필드는 동일한 유형을 가진 다음 컨테이너에 배치됩니다. 예를 들어 구조체에 대해 추가 비트 필드가 선언될 경우 z의 선언은 컨테이너를 오버플로합니다.

struct X{ int x:10; int y:20; int z:5;};

컴파일러는 첫 번째 컨테이너의 나머지 2비트를 패딩하고 z에 대한 새 정수 컨테이너를 할당합니다.

비트 필드 컨테이너는 서로 중복될 수 있습니다. 예를 들면 다음과 같습니다.



struct X{ int x:10; char y:2;};

첫 번째 선언은 정수 컨테이너를 생성하고 10비트를 x에 할당합니다. 이 10비트는 정수 컨테이너의 첫 번째 바이트와 두 번째 바이트의 2비트를 차지합니다. 두 번째 선언에서 컴파일러는 char 유형의 컨테이너를 확인합니다. 적합한 컨테이너가 없으므로 컴파일러는 올바르게 정렬된 새 char 컨테이너를 할당합니다.

char의 기본 정렬이 1이므로 컴파일러는 비트 필드를 모두 포함하기 위해 충분한 수의 미할당 비트가 있는 첫 번째 바이트를 검색합니다. 이 예제 구조체에서 int 컨테이너의 두 번째 바이트의 2비트는 x에 할당되고 6비트는 할당되지 않습니다. 컴파일러는 이전 int 컨테이너의 두 번째 바이트에서 시작되는 char 컨테이너를 할당하고, x에 할당되는 처음 2비트를 건너뛰고, 2비트를 y에 할당합니다.

y가 char y:8로 선언될 경우 비트 필드가 컨테이너를 오버플로할 수 없기 때문에 컴파일러는 두 번째 바이트를 패딩하고 새 char 컨테이너를 세 번째 바이트에 할당합니다. 그림 5-2에서는 다음 예제 구조체에 대한 비트 필드 할당을 보여 줍니다.

struct X{ int x:10; char y:8;};

그림 5-2 비트 필드 할당 1

참고

동일한 기본 규칙이 다른 컨테이너 유형을 가진 비트 필드 선언에 적용됩니다. 예를 들어 int 비트 필드를 예제 구조에 추가하면 결과는 다음과 같습니다.

struct X{ int x:10; char y:8; int z:5;}

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

xyunallocated padding

Bit number



컴파일러는 int x:10 컨테이너와 동일한 위치에서 시작되는 int 컨테이너를 할당하고, 바이트 단위 정렬 char 및 5비트 비트 필드를 할당합니다(그림 5-3 참조).

그림 5-3 비트 필드 할당 2

명명되지 않은 0 크기의 비트 필드를 선언함으로써 비트 필드 컨테이너를 명시적으로 패딩할 수 있습니다. 0 크기의 비트 필드는 컨테이너가 비어 있지 않을 경우 컨테이너를 끝까지 채웁니다. 다음 비트 필드 선언은 비어 있는 새 컨테이너를 시작합니다.

패킹된 구조체의 비트 필드

패킹된 구조체의 비트 필드는 1의 정렬을 갖습니다. 따라서 패킹된 구조체의 비트 필드에 대한 최대 비트 패딩은 7비트입니다. 패킹되지 않은 구조체의 경우 최대 패딩은 8*sizeof(container-type)–1 bits입니다.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

xyz padding

Bit number

free



5.2 C++ 구현 정보

이 단원에서는 C++의 언어 구현 정보에 대해 설명합니다.

5.2.1 ::operator new 함수의 사용

ISO C++ 표준에 따라 ::operator new(std::size_t)는 메모리 할당이 실패할 경우 신호 대신 예외를 발생시킵니다. 예외가 포착되지 않을 경우 std::terminate()가 호출됩니다.

컴파일러 옵션 --force_new_nothrow는 컴파일의 새로운 호출을 모두 ::operator new(std::size_t, std::nothrow_t&) 또는 :operator new[](std::size_t, std::nothrow_t&)에 대한 호출로 바꿉니다. 하지만 이렇게 해도 라이브러리의 operator new 호출이나 클래스 관련 operator new에 대한 호출에 영향을 주지 않습니다. 자세한 내용은 2-60페이지의 --force_new_nothrow, --no_force_new_nothrow를 참조하십시오.

레거시 지원

RVCT v2.0에서 ::operator new 함수는 메모리를 모두 소비했을 경우 C++ 예외 대신 SIGOUTOFHEAP 신호를 발생시킵니다. 라이브러리 및 부동 소수점 지원 설명서의 2-108페이지의 ISO C 라이브러리 구현 정의를 참조하십시오.

현재 릴리스에서는 new_handler를 설치하여 신호를 발생시키고 RVCT v2.0 동작을 복원할 수 있습니다.

참고

이러한 동작에 대한 구현 정보는 이후 릴리스에서 변경될 수 있으므로 신뢰하지 마십시오.

5.2.2 임시 배열

ADS v1.2 및 RVCT v1.2 C++ 컴파일러에서는 int a[]와 같은 임시 배역(불완전 배열) 선언을 사용할 수 있습니다. RVCT v2.x 이상의 컴파일러로 C++을 컴파일할 경우 임시 배열을 사용할 수 없습니다.



5.2.3 C++ 함수의 이전 스타일 C 매개변수

ADS v1.2 및 RVCT v1.2 C++ 컴파일러에서는 C++ 함수에 이전 스타일 C 매개 변수를 사용할 수 있습니다. 즉,

void f(x) int x; { }

RVCT v2.x 이상의 컴파일러에서는 코드의 함수에 이전 스타일 매개변수가 포함되어 있을 경우 --anachronisms 컴파일러 옵션을 사용해야 합니다. 컴파일러는 인스턴스를 발견하면 경고합니다.

5.2.4 구식 표현

--anachronisms 옵션을 사용하여 구식 표현을 설정하면 다음과 같은 구식 표현이 허용됩니다.

• 함수 선언에서 overload가 허용됩니다. 이것은 허용되고 무시됩니다.

• 기본 초기화를 사용하여 초기화될 수 있는 정적 데이터 구성원에 정의는 필요하지 않습니다. 구식 표현은 템플릿 클래스의 정적 데이터 구성원에 적용되지 않습니다. 이 구성원은 항상 정의되어야 하기 때문입니다.

• 배열 내 요소의 구성원은 배열 삭제 연산에서 지정될 수 있습니다. 값은 무시됩니다.

• 단일 operator++()와 operator--() 함수는 접두사 및 접미사 연산을 모두 오버로드할 수 있습니다.

• 기본 클래스 이름은 단 하나의 즉치 기본 클래스만 있을 경우 기본 클래스 이니셜라이저에서 생략할 수 있습니다.

• 생성자와 파괴자에서 this 포인터에 할당할 수 있습니다.

• 바운드 함수 포인터 즉, 특정 객체의 구성원 함수에 대한 포인터는 함수에 대한 포인터로 캐스트될 수 있습니다.

• 중첩된 클래스 이름은 이 이름을 가진 다른 클래스가 선언되지 않았을 경우 비 중첩 클래스 이름으로 사용될 수 있습니다. 구식 표현은 템플릿 클래스에 적용되지 않습니다.

• 비 const 유형에 대한 참조는 다른 유형의 값에서 초기화될 수 있습니다. 임시 값이 생성되어 변환된 초기값에서 초기화되고, 참조가 이 임시 값에 설정됩니다.



• 비 const 클래스 유형에 대한 참조는 클래스 유형의 rvalue 또는 이 클래스 유형에서 파생된 클래스에서 초기화될 수 있습니다. 추가 임시 값은 사용되지 않습니다.

• 이전 스타일의 매개변수 선언을 가진 함수가 허용되며 이 함수는 프로토타이핑된 것처럼 함수 오버로딩에 참여할 수 있습니다. 호환성 확인이 완료되면 이러한 함수의 매개 변수 유형에 기본 인수 진급이 적용되지 않으며, 따라서 다음에서 f라는 두 개 함수의 오버로딩이 선언됩니다.

int f(int);int f(x) char x; { return x; }

참고

C에서 이 코드는 올바르지만 다른 의미를 갖습니다. f의 임시 선언 다음에 해당 정의가 옵니다.

5.2.5 템플릿 인스턴스화

ARM 컴파일러는 자동으로 모든 템플릿 인스턴스화를 수행하며 링크 후에는 각 템플릿 엔터티에 하나의 정의만 남도록 합니다. 컴파일러는 명명된 공통 섹션에서 템플릿 엔터티를 내보냄으로써 이 작업을 수행합니다. 따라서 모든 중복된 공통 섹션, 즉 같은 이름을 가진 공통 섹션은 링커에 의해 제거됩니다.

참고

--pending_instantiations 컴파일러 옵션을 사용하여 해당 템플릿의 동시 인스턴스화 수를 제한할 수 있습니다.

자세한 내용은 2-109페이지의 --pending_instantiations=n도 참조하십시오.

암시적 포함

암시적 포함이 사용 가능하면 컴파일러는 .h 파일에서 선언된 템플릿 엔터티를 인스턴스화하기 위한 정의가 필요할 경우 해당 .cc 파일을 암시적으로 포함시켜 정의에 대한 소스 코드를 얻을 수 있습니다. 예를 들어 템플릿 엔터티 ABC::f가 xyz.h 파일에 선언되어 있고 컴파일에서 ABC::f의 인스턴스화가 필요하지만 컴파일로 처리된 소스 코드에 ABC::f의 정의가 나타나지 않는 경우 컴파일러는 xyz.cc 파일이 있는지 확인합니다. 이 파일이 있을 경우 컴파일러는 그 파일이 주 소스 파일의 끝에 포함되어 있는 것처럼 파일을 처리합니다.



컴파일러가 해당 템플릿 엔터티의 템플릿 정의를 찾으려면 템플릿이 선언된 파일의 전체 경로 이름과 파일이 시스템 include 구문(예: #include <file.h>)을 사용하여 포함되었는지 여부를 알아야 합니다. 이 정보는 #line 지시어가 있는 사전 처리된 소스에서는 사용할 수 없습니다. 결과적으로 컴파일러는 #line 지시어가 있는 소스 코드에 대해 암시적 포함을 시도하지 않습니다.

컴파일러는 정의 파일 접미사 .cc 및 .CC를 찾습니다.

명령 행 옵션 --implicit_include 및 --no_implicit_include를 사용하여 암시적 포함 모드를 설정하거나 해제할 수 있습니다.

암시적 포함은 파일의 정상적인 컴파일 중, 즉 -E 명령 행 옵션을 사용하지 않을 때에만 수행됩니다.

자세한 내용은 2-2페이지의 명령 행 옵션을 참조하십시오.

5.2.6 네임스페이스

템플릿 인스턴스화 중 이름 조회를 수행할 때, 일부 이름은 템플릿 정의 컨텍스트에 있어야 합니다. 다른 이름은 템플릿 인스턴스화 컨텍스트에 있어도 됩니다. 컴파일러는 다음과 같은 두 개의 서로 다른 인스턴스화 조회 알고리즘을 구현합니다.

• 표준에서 요구하고 종속적 이름 조회라고도 하는 알고리즘

• 종속적 이름 조회가 구현되기 전에 있었던 알고리즘

종속적 이름 조회는 다른 명령 행 옵션에 의해 명시적으로 비활성화되지 않은 경우 또는 종속적 이름 처리가 구성 플래그 또는 명령 행 옵션 중 하나에 의해 활성화되는 경우에 엄격한 모드에서 수행됩니다.

종속적 이름 조회 처리

종속적 이름 조회를 수행하면 컴파일러는 표준에 지정된 인스턴스화 이름 조회 규칙을 구현합니다. 이에 따라 비클래스 프로토타입 인스턴스화가 수행되어야 합니다. 그 다음 표준의 요구조건에 따라 유형 이름과 템플릿 키워드를 사용하여 코드를 작성해야 합니다.



참조 컨텍스트를 사용하는 조회

종속적 이름 조회를 사용하지 않으면 컴파일러는 기존 코드 및 기존 컴파일러와 좀 더 호환되는 방식으로 표준의 2단계 조회 규칙과 유사한 이름 조회 알고리즘을 사용합니다.

이름이 템플릿 인스턴스화의 일부로 조회되지만 인스턴스화의 지역 컨텍스트에 없으면 통합 인스턴스화 컨텍스트에서 조회됩니다. 이 통합 인스턴스화 컨텍스트에는 템플릿 정의 컨텍스트의 이름과 인스턴스화 컨텍스트의 이름이 모두 포함됩니다. 예를 들면 다음과 같습니다.

namespace N{ int g(int); int x = 0; template <class T> struct A

{ T f(T t) { return g(t); }

T f() { return x; } };}namespace M { int x = 99; double g(double); N::A<int> ai; int i = ai.f(0); // N::A<int>::f(int) calls N::g(int) int i2 = ai.f(); // N::A<int>::f() returns 0 (= N::x) N::A<double> ad; double d = ad.f(0); // N::A<double>::f(double) calls M::g(double) double d2 = ad.f(); // N::A<double>::f() also returns 0 (= N::x)}

템플릿 인스턴스화에서 이름 조회는 다음과 같은 측면에서 규칙을 따르지 않습니다.

• 템플릿 정의 컨텍스트의 이름만 함수가 아닌 이름으로 간주되지만, 조회는 템플릿이 정의된 시점에 보이는 이름에만 제한되지 않습니다.

• 템플릿이 참조된 컨텍스트의 함수는 템플릿의 모든 함수 호출에 대해 고려됩니다. 참조 컨텍스트의 함수는 종속 함수 호출에서만 보입니다.



인수 종속 조회

인수 종속적 조회가 사용 가능하면 인수 종속적 조회를 사용하여 표시되는 함수는 정상 조회에 의해 표시된 함수로 오버로드될 수 있습니다. 표준에 따라 정상 조회로 찾은 이름이 블록 extern 선언이라도 이러한 오버로딩이 발생해야 합니다. 컴파일러는 이 오버로딩을 수행하지만 기본 모드에서 정상 조회로 블록 extern을 찾은 경우 인수 종속적 조회가 수행되지 않습니다.

즉, 프로그램이 네임스페이스를 사용하지 않더라도 컴파일 시 인수 종속적 조회의 사용 여부에 따라 다른 동작을 할 수 있습니다. 예를 들면 다음과 같습니다.

struct A { };A operator+(A, double);void f(){ A a1; A operator+(A, int); a1 + 1.0; // calls operator+(A, double) with arg-dependent lookup} // enabled but otherwise calls operator+(A, int);

5.2.7 C++ 예외 처리

C++ 예외 처리는 RVCT에서 완전 지원됩니다. 하지만 컴파일러는 C++ 예외 처리를 기본적으로 지원하지 않습니다. --exceptions 옵션을 사용하여 C++ 예외 처리를 활성화해야 합니다. 자세한 내용은 2-56페이지의 --exceptions, --no_exceptions를 참조하십시오.

참고

Rogue Wave Standard C++ Library는 C++ 예외가 활성화된 상태로 제공됩니다.

예외 테이블 생성을 제한적으로 제어할 수 있습니다.

런타임 시 함수 해제

기본적으로 --exceptions를 사용하여 컴파일된 함수는 런타임에 해제될 수 있습니다. 자세한 내용은 2-56페이지의 --exceptions, --no_exceptions를 참조하십시오. 함수 해제에는 C++ 자동 변수의 소멸과 스택 프레임에 저장된 레지스터 값의 복원이 포함됩니다. 함수 해제는 수행할 작업을 설명하는 예외 테이블을 생성하여 구현됩니다.



pragma #pragma exceptions_unwind 및 #pragma no_exceptions_unwind를 사용하여 특정 함수에 대한 함수 해제를 활성화 또는 비활성화할 수 있습니다. 자세한 내용은 4-58페이지의 Pragma를 참조하십시오. --exceptions_unwind 옵션은 이 pragma의 초기값을 설정합니다.

어떤 함수에 대해 함수 해제를 비활성화하면 다음과 같은 효과가 발생합니다.

• 예외는 런타임에 해당 함수를 통해 발생될 수 없으며 예외 발생에 대해 스택 해제도 발생하지 않습니다. 해당 언어가 C++일 경우 std::terminate가 호출됩니다.

• 매우 간결한 예외 테이블 표현을 사용하여 이 함수를 설명할 수 있으며, 이 표현은 테이블 최적화를 통해 스마트 링커를 보조합니다.

• 호출자와 호출 수신자가 올바르게 상호 작용해야 하므로 함수 인라인은 제한됩니다.

따라서 추가 소스 장식을 필요로 하지 않는 방식으로 해제를 강제로 방지하는 데 #pragma no_exceptions_unwind를 사용할 수 있습니다.

반대로 C++에서 빈 함수 예외 사양은 보호되는 함수까지 해제를 허용한 다음 ISO C++ 표준에 따라 std::unexpected()를 호출합니다.

5.2.8 Extern 인라인 함수

ISO C++ 표준에 따라 인라인 함수는 사용 위치에 관계 없이 정의되어야 합니다. C++ 컴파일러는 인라인 함수의 여러 라인 외부 복사본이 충돌하는 것을 방지하기 위해 공통 섹션에서 라인 외부 extern 함수를 내보냅니다.

라인 외부 인라인 함수

컴파일러는 다음과 같은 경우 인라인 함수를 라인 외부로 내보냅니다.

• 다음과 같이 함수의 주소가 사용된 경우

inline int g(){

return 1;}int (*fp)() = &g;

• 함수가 인라인될 수 없는 함수(재귀 함수)인 경우

inline unsigned int fact(unsigned int n) { return n < 2 ? 1 : n * fact(n - 1);}



• 컴파일러가 사용하는 발견적 방법에서 함수를 인라인하지 않는 것이 좋다고 결정한 경우. 이 발견적 방법은 -Ospace와 -Otime의 영향을 받습니다. -Otime을 사용할 경우 컴파일러가 더 많은 함수를 인라인합니다. __forceinline을 사용하여 함수를 선언하면 이 발견적 방법을 재정의할 수 있습니다. 예를 들면 다음과 같습니다.

__forceinline int g(){

return 1;}

자세한 내용은 2-61페이지의 --forceinline을 참조하십시오.


부록 A via 파일 구문

이 부록에서는 모든 ARM 개발 도구에서 사용할 수 있는 via 파일의 구문에 대해 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• A-2페이지의 via 파일 개요

• A-3페이지의 구문

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. A-1ID090708 Non-Confidential, Unrestricted Access

via 파일 구문

A.1 via 파일 개요

via 파일은 일반 텍스트 파일로서 명령 행 인수와 ARM 개발 도구에 대한 옵션을 포함합니다. 모든 ARM 명령 행 도구에서 via 파일을 사용할 수 있습니다. 즉, 다음과 함께 --via 명령 행 옵션을 사용하여 명령 행에서 via 파일을 지정할 수 있습니다.

• armcc

• armasm

• armlink

• fromelf

• armar

자세한 내용은 각 도구의 설명서를 참조하십시오.

참고

일반적으로 via 파일을 사용하여 --via를 비롯한 명령 행 옵션을 도구에 지정할 수 있습니다. 따라서 via 파일 내부에서 여러 개의 중첩된 via 파일을 호출할 수 있습니다.

이 단원에서는 다음과 같은 내용이 포함되어 있습니다.

• via 파일 평가

A.1.1 via 파일 평가

via 파일을 지원하는 도구가 호출될 경우 해당 도구는 다음과 같은 기능을 수행합니다.

1. via 파일의 모든 중첩된 --via 명령의 재귀적 처리를 포함하여 처음 지정된 --via via_file 인수를 via 파일에서 추출된 인수 워드의 시퀀스로 대체합니다.

2. 모든 후속 --via via_file 인수를 표시된 순서대로 동일하게 처리합니다.

즉, via 파일은 지정된 순서대로 처리되고, 각 via 파일의 처리가 완료된 후(중첩된 via 파일 처리 포함) 다음 via 파일이 처리됩니다.

A-2 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

via 파일 구문

A.2 구문

via 파일은 다음 구문 규칙을 준수해야 합니다.

• via 파일은 워드 시퀀스를 포함하는 텍스트 파일입니다. 텍스트 파일의 각 워드는 인수 문자열로 변환되어 도구로 전달됩니다.

• 워드는 구분된 문자열을 제외하고 공백이나 행의 끝으로 구분됩니다. 예를 들면 다음과 같습니다.

--c90 --strict(2워드)

--c90--strict(1워드)

• 행 끝은 공백으로 처리됩니다. 예를 들면 다음과 같습니다.

--c90--strict

이것은 다음과 같습니다.

--c90 --strict

• 큰 따옴표(")나 아포스트로피(')로 묶인 문자열은 한 워드로 처리됩니다. 인용된 워드 내에 있는 아포스트로피는 일반 문자로 처리됩니다. 아포스트로피로 구분된 워드 내에서 따옴표는 일반적인 한 문자로 처리됩니다.

따옴표는 공백을 포함하는 파일 이름이나 경로 이름을 구분하는 데 사용됩니다. 예를 들면 다음과 같습니다.

-I C:\My Project\includes(3워드) -I "C:\My Project\includes"(2워드)

아포스트로피는 따옴표를 포함하는 워드를 구분하는 데 사용할 수 있습니다. 예를 들어 다음과 같습니다.

-DNAME='"RealView Compilation Tools"'(한 워드)

• 괄호로 묶인 문자는 한 워드로 처리됩니다. 예를 들면 다음과 같습니다.

--option (x, y, z)(1워드)

--option (x, y, z)(2워드)

• 인용되었거나 아포스트로피로 구분된 문자열 안에서 백슬래시(\) 문자를 사용하여 따옴표, 아포스트로피, 백슬래시 문자를 벗어날 수 있습니다.

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. A-3ID090708 Non-Confidential, Unrestricted Access

via 파일 구문

• 구분된 문자 바로 옆에 있는 워드는 한 워드로 처리됩니다. 예를 들면 다음과 같습니다.

-I"C:\Project\includes"

이것은 한 워드로 처리됩니다.

-IC:\Project\includes

• 첫 번째 비 공백 문자로서 세미콜론(;) 또는 우물 정자(#) 문자로 시작하는 행은 주석 행입니다. 세미콜론이나 샵 문자가 한 행의 다른 곳에 나타날 경우 주석의 시작으로 처리되지 않습니다. 예를 들면 다음과 같습니다.

-o objectname.axf ;this is not a comment

주석은 행의 끝이나 파일 끝에서 끝납니다. 여러 행으로 된 주석도 없고 부분 행 주석도 없습니다.

• 사전 처리기 옵션 -Dsymbol="value"가 포함된 행은 '-Dsymbol="value"' 또는 -Dsymbol='"value"'처럼 작은 따옴표로 구분해야 합니다. 예를 들면 다음과 같습니다.

-c -DFOO_VALUE='"FOO_VALUE"'

A-4 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

부록 B 표준 C 구현 정의

이 부록에서는 C 구현 준수를 위해 ISO C 표준에서 요구하는 정보를 제공합니다. 이 장에는 다음 단원이 포함되어 있습니다.

• B-2페이지의 구현 정의

• B-9페이지의 ISO C 표준에 정의되지 않은 것으로 간주되는 동작

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. B-1ID090708 Non-Confidential, Unrestricted Access

표준 C 구현 정의

B.1 구현 정의

ISO C 표준(ISO/IEC 9899:1990 (E))의 부록 G에는 이식성 문제에 대한 정보가 들어 있습니다. 하위 조항 G3에는 각 구현에서 기술해야 하는 동작이 수록되어 있습니다.

참고

이 부록에서는 4장 컴파일러 관련 기능의 일부인 정보를 중복 제공하지 않습니다. 이 부록은 적용 가능할 경우 참조 정보를 제공합니다.

다음 소단원은 하위 조항 G3의 관련 단원과 대응됩니다. 이러한 소단원에서는 ISO C 표준에 의해 정의되지 않고 구현에 의해 정의되는 ARM C 컴파일러와 C 라이브러리의 기능에 대해 설명합니다.

참고

광범위한 파일 연산에는 wctype.h 및 wchar.h 헤더가 지원되지 않습니다.

B-2 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708


B.1.1 변환

컴파일러에서 생성하는 진단 메시지의 형식은 다음과 같습니다.

source-file, line-number: severity: error-code: explanation

여기서 severity 는 다음 중 하나입니다.

[blank] 심각도가 비어 있을 경우 이것은 설명이며 일반적이지만 때로는 기존 방식과 다른 C 또는 C++의 사용을 의미합니다. 설명은 기본적으로 표시되지 않습니다. 설명 메시지를 표시하려면 --remarks 옵션을 사용합니다. 자세한 내용은 6-4페이지의 진단 메시지의 출력 제어를 참조하십시오. 컴파일은 계속됩니다.

Warning 코드에서 문제를 나타낼 수 있는 일반적이지 않은 상황을 표시합니다. 컴파일은 계속됩니다.

Error 컴파일러를 중단시키는 문제를 나타냅니다. 예를 들어 C 또는 C++ 언어의 구문 또는 의미 규칙 위반을 들 수 있습니다.

Internal fault

컴파일러에 내부 문제가 있음을 나타냅니다. x페이지의 사용자 의견에 나열된 정보를 제공하여 공급업체에 문의하십시오.

위 형식의 다른 인수 설명은 다음과 같습니다.

error-code 오류 유형을 식별하는 번호입니다.

explanation 오류의 텍스트 설명입니다.

자세한 내용은 컴파일러 사용 설명서에서 6장 진단 메시지를 참조하십시오.

B.1.2 환경

ARM 아키텍처 기반 환경에서 main() 인수로의 명령 행 매핑은 구현에 따라 다릅니다. 일반 ARM C 라이브러리는 다음을 지원합니다.

• B-4페이지의 main()

• B-4페이지의 대화형 장치

• B-4페이지의 표준 입력, 출력 및 오류 스트림의 리디렉션



main()

main()에 주어진 인수는 입/출력 리디렉션을 제외한 명령 행의 워드로, 공백이 큰 따옴표 안에 있는 경우를 제외하고 공백으로 구분됩니다.

참고

• 공백 문자는 isspace()가 참인 경우 어떤 문자도 될 수 있습니다.

• 큰 따옴표 또는 큰 따옴표 안에 포함된 백슬래시 문자 \는 백슬래시 문자가 앞에 와야 합니다.

• 큰 따옴표 안에서는 입력/출력 리디렉션이 인식되지 않습니다.

대화형 장치

호스팅되지 않은 ARM C 라이브러리 구현에서 대화형 장치라는 용어는 의미가 없을 수 있습니다. 일반 ARM C 라이브러리는 키보드 입력과 VDU 화면 출력을 처리하는 데 사용되는 :tt라고 하는 한 쌍의 장치를 지원합니다. 일반 구현은 다음과 같습니다.

• 입/출력 리디렉션이 발생하는 경우를 제외하고는 :tt에 연결된 어떤 스트림에서도 버퍼링이 수행되지 않습니다.

• :tt 이외의 장치에 대한 입/출력 리디렉션이 발생하면 전체 파일 버퍼링이 사용됩니다. 그러나 stdout과 stderr이 동일한 파일로 리디렉션된 경우에는 라인 버퍼링이 사용됩니다.

표준 입력, 출력 및 오류 스트림의 리디렉션

일반 ARM C 라이브러리를 사용하여 표준 입력, 출력 및 오류 스트림이 런타임에 리디렉션될 수 있습니다. 예를 들어 mycopy가 표준 입력을 표준 출력으로 복사하는 호스트 디버거에서 실행 중인 프로그램이면 다음 라인이 프로그램을 실행합니다.

mycopy < infile > outfile 2> errfile

그리고 파일을 다음과 같이 리디렉션합니다.

stdin 표준 입력 스트림은 infile로 리디렉션됩니다.

stdout 표준 출력 스트림은 outfile로 리디렉션됩니다.

stderr 표준 오류 스트림은 errfile로 리디렉션됩니다.



다음과 같은 리디렉션이 허용됩니다.

0< filename filename에서 stdin을 읽습니다.

< filename filename에서 stdin을 읽습니다.

1> filename stdout을 filename에 씁니다.

> filename stdout을 filename에 씁니다.

2> filename stderr을 filename에 씁니다.

2>&1 stdout과 동일한 장소에 stderr을 씁니다.

>& file stdout과 stderr 을 모두 filename에 씁니다.

>> filename filename에 stdout을 추가합니다.

>>& filename stdout과 stderr을 모두 filename에 추가합니다.

타겟의 stdin, stdout 및 stderr을 리디렉션하려면 다음과 같이 정의해야 합니다.

#pragma import(_main_redirection)

파일 리디렉션은 다음 중 한 경우에만 수행됩니다.

• 호출하는 운영 체제가 리디렉션을 지원하는 경우

• 프로그램에서 문자를 읽고 쓰고 C 라이브러리 함수 fputc() 및 fgetc()를 대체하지 않는 경우

B.1.3 식별자

자세한 내용은 5-2페이지의 문자 세트와 식별자를 참조하십시오.

B.1.4 문자

자세한 내용은 5-2페이지의 문자 세트와 식별자를 참조하십시오.

B.1.5 정수

자세한 내용은 5-5페이지의 정수를 참조하십시오.

B.1.6 부동 소수점

자세한 내용은 5-5페이지의 부동 소수점을 참조하십시오.



B.1.7 배열과 포인터

자세한 내용은 5-5페이지의 배열과 포인터를 참조하십시오.

B.1.8 레지스터

ARM 컴파일러를 사용하여 원하는 수 만큼의 지역 개체가 스토리지 클래스 register를 갖도록 선언할 수 있습니다.

B.1.9 구조체, 공용체, 열거 및 비트 필드

ISO/IEC C 표준에 따르면 구조화된 데이터 유형에 대한 다음과 같은 구현 세부 사항을 문서화해야 합니다.

• 공용체의 구성원이 다른 유형의 구성원을 사용하여 액세스되는 경우의 결과

• 구조체 구성원의 패딩과 정렬

• 일반 int 비트 필드가 signed int 비트 필드로 처리되는지 아니면 unsigned int 비트 필드로 처리되는지 여부

• 단위 내 비트 필드의 할당 순서

• 비트 필드가 스토리지 단위 경계에 걸쳐 있을 수 있는지 여부

• 열거 유형의 값을 나타내기 위해 선택한 정수 유형

자세한 내용은 5장 C 및 C++ 구현 정보를 참조하십시오.

공용체

자세한 내용은 5-7페이지의 공용체를 참조하십시오.

열거

자세한 내용은 5-8페이지의 열거를 참조하십시오.

구조체의 패딩과 정렬

자세한 내용은 5-9페이지의 구조체를 참조하십시오.



비트 필드

자세한 내용은 5-10페이지의 비트 필드를 참조하십시오.

B.1.10 한정자

휘발성 정규화 형식을 포함하는 객체는 해당 크기 및 정렬로 정의되는 대로 워드, 하드워드 또는 바이트로 액세스됩니다. 단일 워드보다 큰 휘발성 객체의 경우 객체 부분에 대한 액세스 순서는 정의되지 않습니다. 휘발성 비트 필드에 대한 업데이트 시에는 대개 읽기-수정-쓰기를 수행해야 합니다. 정렬된 워드, 하드워드 및 바이트 형식에 대한 액세스는 원자적이며 기타 휘발성 액세스는 반드시 원자적인 것은 아닙니다.

그렇지 않은 경우 소스 코드가 암시하는 순서에 따라 소스 코드가 직접 암시하는 대로 휘발성 정규화 객체에 대한 읽기와 쓰기가 이루어집니다.

B.1.11 식 평가

컴파일러는 괄호가 있는 경우에도 우선순위가 같은 결합 및 가환 연산자만을 포함하는 식의 순서를 변경할 수 있습니다. 예를 들어 a + (b + c)는 a, b, c 정수 식일 경우 (a + b) + c로 계산될 수 있습니다.

시퀀스 지점 사이에서

컴파일러는 괄호에 관계없이 순서대로 식을 계산할 수 있습니다. 따라서 시퀀스 지점 간 식의 부작용이 어떤 순서로든 발생할 수 있습니다.

컴파일러는 함수 인수를 순서에 관계없이 평가할 수 있습니다.

관련 표준이 규정하지 않는 평가 순서의 내용은 다음에 따라 달라질 수 있습니다.

• 컴파일하는 최적화 수준

• 사용 중인 컴파일러의 릴리스



B.1.12 사전 처리 지시어

ISO 표준 C 헤더 파일은 표준에서 설명하는 대로 참조될 수 있습니다. 예를 들어 #include <stdio.h>와 같습니다.

포함 가능한 소스 파일의 인용 이름이 지원됩니다. 컴파일러는 호스트 파일 이름이나 UNIX 파일 이름을 허용합니다. 비 UNIX 호스트에서 UNIX 파일 이름을 사용할 경우 컴파일러는 파일 이름을 지역에서 사용할 수 있는 동등한 이름으로 변환하려 합니다.

인식된 #pragma 지시어는 4-58페이지의 Pragma에 나와 있습니다.

B.1.13 라이브러리 함수

ISO C 라이브러리 변형 목록은 라이브러리 및 부동 소수점 지원 설명서의 1-2페이지의 런타임 라이브러리 정보에 나와 있습니다.

각 C 라이브러리의 정밀한 특성은 특정한 구현에만 있습니다. 일반 ARM C 라이브러리는 다음과 같은 기능을 갖고 있거나 지원합니다.

• NULL 매크로는 정수 상수 0으로 확장됩니다.

• 프로그램이 printf와 같은 예약된 외부 식별자를 다시 정의하면 프로그램이 표준 라이브러리와 링크될 때 오류가 발생할 수 있습니다. 프로그램이 표준 라이브러리와 링크되지 않으면 오류가 감지되지 않습니다.

• __aeabi_assert() 함수는 stderr에 실패 진단에 대한 세부 정보를 표시한 다음 abort() 함수를 호출합니다.

*** assertion failed: expression, file name, line number

참고

assert 매크로의 동작은 #include <assert.h>가 발생한 가장 최근의 작업 조건에 따라 달라집니다. 자세한 내용은 라이브러리 및 부동 소수점 지원 설명서에서 2-42페이지의 프로그램에서 종료를 참조하십시오.

수학 함수, 매크로, 로케일, 신호, 입/출력의 자세한 구현 정보는 라이브러리 및 부동 소수점 지원 설명서에서 2장 C 및 C++ 라이브러리를 참조하십시오.



B.2 ISO C 표준에 정의되지 않은 것으로 간주되는 동작

다음은 ISO C 표준에 의해 정의되지 않은 동작으로 간주됩니다.

• 문자 및 문자열 이스케이프에서 \ 다음에 오는 문자에 특별한 의미가 없을 경우 이스케이프 값은 문자 자체가 됩니다. 예를 들어 \s를 사용하는 경우 s와 같기 때문에 경고가 생성됩니다.

• 명명된 필드가 없고 최소한 1개의 명명되지 않은 필드가 있는 struct는 기본적으로는 허용되지만 엄격한 1990 ISO 표준 C에서는 오류를 생성합니다.


부록 C 표준 C++ 구현 정의

ARM 컴파일러는 C++를 컴파일할 때 C++의 ISO/IEC 표준에서 설명된 대부분의 언어 기능을 지원합니다. 이 부록에서는 표준에 정의된 C++ 언어 기능을 수록했으며 언어 기능이 ARM C++에서 지원되는지 여부를 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• C-3페이지의 정수 변환

• C-4페이지의 순수 가상 함수의 호출

• C-5페이지의 언어 지원의 주요 기능

• C-6페이지의 표준 C++ 라이브러리 구현 정의

참고

이 부록에서는 표준 C 구현의 일부인 정보를 중복 제공하지 않습니다. 자세한 내용은 부록 B 표준 C 구현 정의를 참조하십시오.

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. C-1ID090708 Non-Confidential, Unrestricted Access

표준 C++ 구현 정의

ISO C 모드에서 C++를 컴파일할 경우 ARM 컴파일러는 ARM C 컴파일러와 동일합니다. C 또는 C++와 관련된 구현 기능이 있을 경우 이 기능은 텍스트에 표시됩니다. 표준 C++ 확장에 대해서는 다음을 참조하십시오.

• 3-16페이지의 표준 C++ 언어 확장


• 3-20페이지의 표준 C 및 표준 C++ 언어 확장.

C-2 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708


C.1 정수 변환

정수 변환 동안 대상 유형이 부호가 있는 경우 값은 대상 유형 및 비트 필드 너비로 나타낼 수 있으면 변경되지 않습니다. 그렇지 않을 경우 값은 대상 유형의 크기에 맞게 잘립니다.

참고

이 단원은 ISO/IEC 표준의 4.7 정수 변환 단원과 관련되어 있습니다.



C.2 순수 가상 함수의 호출

순수 가상 함수를 호출하는 것은 잘못된 작업입니다. 코드가 순수 가상 함수를 호출할 경우 컴파일러는 라이브러리 함수 __cxa_pure_virtual에 대한 호출을 포함합니다.

__cxa_pure_virtual은 SIGPVFN 신호를 발생시킵니다. 기본 신호 처리기가 오류 메시지를 표시하고 종료합니다. 자세한 내용은 라이브러리 및 부동 소수점 지원 설명서에서 2-71페이지의 __default_signal_handler()를 참조하십시오.



C.3 언어 지원의 주요 기능

표 C-1은 이번 ARM C++ 릴리스에서 지원하는 언어의 주요 기능을 보여 줍니다.

표 C-1 언어에 대한 주요 기능 지원

주요 기능 ISO/IEC 표준 단원 지원

코어 언어 1 ~ 13 예

템플릿 14 예(내보내기 템플릿은 예외)

예외 15 예

라이브러리 17 ~ 27 라이브러리 및 부동 소수점 지원 설명서의 C-6페이지의 표준 C++ 라이브러리 구현 정의를 참조하십시오.



C.4 표준 C++ 라이브러리 구현 정의

Rouge Wave 라이브러리 버전 2.02.03은 표준에 정의된 라이브러리의 하위 세트를 제공합니다. 1999 ISO C 표준과는 약간 차이가 있습니다. 구현 정의에 대한 자세한 내용은 라이브러리 및 부동 소수점 지원 설명서에서 2-114페이지의 표준 C++ 라이브러리 구현 정의를 참조하십시오.

라이브러리를 사용자 정의 함수와 함께 사용하여 타겟 종속 응용 프로그램을 생성할 수 있습니다. 라이브러리 및 부동 소수점 지원 설명서의 1-2페이지의 런타임 라이브러리 정보를 참조하십시오.


부록 D C 및 C++ 컴파일러 구현 한계

이 부록에서는 ARM 컴파일러로 C 및 C++를 컴파일할 때 발생할 수 있는 구현상의 제한에 대해 설명합니다. 여기에는 다음 단원이 포함되어 있습니다.

• D-2페이지의 C++ ISO/IEC 표준 한계

• D-4페이지의 정수의 한계

• D-6페이지의 부동 소수점 숫자의 한계

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. D-1ID090708 Non-Confidential, Unrestricted Access

C 및 C++ 컴파일러 구현 한계

D.1 C++ ISO/IEC 표준 한계

ISO/IEC C++ 표준에서는 이 표준을 준수하는 컴파일러에서 따라야 하는 최소 제한을 권장합니다. 컴파일러 간에 응용 프로그램을 포팅할 때 이 점에 주의하십시오. 표 D-1에서는 이러한 한계에 대해 간단히 설명합니다.

이 표에서 memory의 한계는 ARM 컴파일러가 사용 가능한 메모리에서 지정한 한계 외에는 한계를 지정하지 않음을 나타냅니다.

표 D-1 구현 한계

설명 권장 사항 ARM

복합 문, 이터레이션 컨트롤 구조체 및 선택 컨트롤 구조체의 중첩 수준

256 메모리

조건부 포함의 중첩 수준 256 메모리

선언에서 산술, 구조체, 공용체 또는 불완전한 유형을 수정하는 포인터, 배열 및 함수 선언자(모든 조합)

256 메모리

완전한 식 내에 괄호 처리된 식의 중첩 수준 256 메모리

내부 식별자 또는 매크로 이름의 첫 문자 수 1024 메모리

외부 식별자의 첫 문자 수 1024 메모리

한 변환 단위의 외부 식별자 65536 메모리

한 블록으로 선언된 블록 유효 범위가 있는 식별자 1024 메모리

한 변환 단위에 동시에 정의된 매크로 식별자 65536 메모리

한 함수 선언의 매개변수 256 메모리

함수 호출의 인수 256 메모리

한 매크로 정의의 매개변수 256 메모리

한 매크로 호출의 인수 256 메모리

논리적 소스 행 하나의 문자. 65536 메모리

연결 뒤의 문자 문자열 리터럴 또는 와이드 문자열 리터럴의 문자 65536 메모리

C 또는 C++ 개체의 크기(배열 포함) 262144 4294967296

#include 파일의 중첩 수준 256 메모리

D-2 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708


중첩된 switch 문을 제외한 switch 문의 Case 레이블 16384 메모리

단일 클래스, 구조체 또는 공용체의 데이터 구성원 16384 메모리

단일 열거의 열거 상수 4096 메모리

단일 struct 선언 목록의 중첩된 클래스, 구조체 또는 공용체 정의 수준

256 메모리

atexit()에 의해 등록된 함수 32 33

직접 및 간접 기본 클래스 16384 메모리

단일 클래스에 대한 직접 기본 클래스 1024 메모리

단일 클래스에 선언된 구성원 4096 메모리

클래스의 가상 함수 최종 오버라이드, 액세스 가능 여부 16384 메모리

클래스의 직접 및 간접 가상 기본 1024 메모리

클래스의 정적 구성원 1024 메모리

클래스의 Friend 선언 4096 메모리

클래스의 Access Control 선언 4096 메모리

생성자 정의의 구성원 이니셜라이저 6144 메모리

한 식별자의 유효 범위 한정 256 메모리

중첩된 외부 지정 1024 메모리

템플릿 선언의 템플릿 인수 1024 메모리

재귀 중첩 템플릿 인스턴스화 17 메모리

try 블록별 처리기 256 메모리

단일 함수 선언의 Throw 지정 256 메모리

표 D-1 구현 한계 (계속)

설명 권장 사항 ARM



D.2 정수의 한계

표 D-2에서는 ARM C 및 C++의 정수 범위를 보여 줍니다. 표에서 Endpoint 열은 범위 끝점의 숫자 값을 제공합니다. Hex value 열은 ARM 컴파일러에서 이 값으로 해석되는 비트 패턴(16진수)을 제공합니다. 이러한 상수는 limits.h include 파일에 정의되어 있습니다.

상수를 입력할 때 크기와 부호를 주의하여 선택하십시오. 상수는 10진수와 16진수/8진수에서 다르게 해석됩니다. 자세한 내용은 viii페이지의 추가 정보에 나와 있는 권장 C 및 C++ 설명서나 적절한 C 또는 C++ 표준을 참조하십시오.

표 D-2 정수 범위

상수 의미 값 Hex 값

CHAR_MAX char의 최대 값 255 0xFF

CHAR_MIN char의 최소 값 0 0x00

SCHAR_MAX signed char의 최대 값 127 0x7F

SCHAR_MIN signed char의 최소 값 –128 0x80

UCHAR_MAX unsigned char의 최대 값 255 0xFF

SHRT_MAX short의 최대 값 32767 0x7FFF

SHRT_MIN short의 최소 값 –32768 0x8000

USHRT_MAX unsigned short의 최대 값 65535 0xFFFF

INT_MAX int의 최대 값 2147483647 0x7FFFFFFF

INT_MIN int의 최소 값 –2147483648 0x80000000

LONG_MAX long의 최대 값 2147483647 0x7FFFFFFF

LONG_MIN long의 최소 값 –2147483648 0x80000000

ULONG_MAX unsigned long의 최대 값 4294967295 0xFFFFFFFF



LLONG_MAX long long의 최대 값 9.2E+18 0x7FFFFFFFFFFFFFFF

LLONG_MIN long long의 최소 값 –9.2E+18 0x8000000000000000

ULLONG_MAX unsigned long long의 최대 값 1.8E+19 0xFFFFFFFFFFFFFFFF

표 D-2 정수 범위 (계속)

상수 의미 값 Hex 값



D.3 부동 소수점 숫자의 한계

이 단원에서는 부동 소수점 숫자의 특성에 대해 설명합니다.

표 D-3에서는 부동 소수점 숫자의 특성, 범위 및 한계를 보여 줍니다. 이러한 상수는 float.h include 파일에 정의되어 있습니다.

표 D-3 부동 소수점 한계

상수 의미 값

FLT_MAX float의 최대 값 3.40282347e+38F

FLT_MIN float의 표준화된 최소 부동 소수점 숫자 값(양수) 1.175494351e–38F

DBL_MAX double의 최대 값 1.79769313486231571e+308

DBL_MIN double의 표준화된 최소 부동 소수점 숫자 값(양수) 2.22507385850720138e–308

LDBL_MAX long double의 최대 값 1.79769313486231571e+308

LDBL_MIN long double의 표준화된 최소 부동 소수점 숫자 값(양수) 2.22507385850720138e–308

FLT_MAX_EXP float 유형에 대한 기본 2 지수의 최대 값 128

FLT_MIN_EXP float 유형에 대한 기본 2 지수의 최소 값 –125

DBL_MAX_EXP double 유형에 대한 기본 2 지수의 최대 값 1024

DBL_MIN_EXP double 유형에 대한 기본 2 지수의 최소 값 –1021

LDBL_MAX_EXP long double 유형에 대한 기본 2 지수의 최대 값 1024

LDBL_MIN_EXP long double 유형에 대한 기본 2 지수의 최소 값 –1021

FLT_MAX_10_EXP float 유형에 대한 기본 10 지수의 최대 값 38

FLT_MIN_10_EXP float 유형에 대한 기본 10 지수의 최소 값 –37

DBL_MAX_10_EXP double 유형에 대한 기본 10 지수의 최대 값 308

DBL_MIN_10_EXP double 유형에 대한 기본 10 지수의 최소 값 –307

LDBL_MAX_10_EXP long double 유형에 대한 기본 10 지수의 최대 값 308

LDBL_MIN_10_EXP long double 유형에 대한 기본 10 지수의 최소 값 –307



표 D-4에서는 부동 소수점 숫자의 다른 특성에 대해 설명합니다. 이러한 상수는 float.h include 파일에도 정의되어 있습니다.

참고

• 부동 소수점 숫자가 더 짧은 부동 소수점 숫자로 변환되는 경우 가장 가까운 대표 숫자로 반올림됩니다.

• 부동 소수점 산술은 IEEE 754를 따릅니다.

표 D-4 기타 부동 소수점 특성

상수 의미 값

FLT_RADIX ARM 부동 소수점 숫자 표현의 기본(기수) 2

FLT_ROUNDS 부동 소수점 숫자의 반올림 모드 1(근삿값)

FLT_DIG float에 대한 정밀도(10진수) 6

DBL_DIG double에 대한 정밀도(10진수) 15

LDBL_DIG long double에 대한 정밀도(10진수) 15

FLT_MANT_DIG float 유형에 대한 정밀도(2진수) 24

DBL_MANT_DIG double 유형에 대한 정밀도(2진수) 53

LDBL_MANT_DIG long double 유형에 대한 정밀도(2진수) 53

FLT_EPSILON float 유형에 대한 1.0 + x != 1.0에서 x의 최소 양수 값 1.19209290e–7F

DBL_EPSILON double 유형에 대한 1.0 + x != 1.0에서 x의 최소 양수 값 2.2204460492503131e–16

LDBL_EPSILON long double 유형에 대한 1.0 + x != 1.0에서 x의 최소 양수 값 2.2204460492503131e–16L


부록 E NEON 지원 사용

이 부록에서는 이 릴리스의 RVCT(RealView Compilation Tools)에서 제공되는 NEON 내장 함수 지원에 대해 설명합니다.

이 부록에는 다음 소단원이 포함되어 있습니다.

• E-2페이지의 소개

• E-3페이지의 벡터 데이터 유형

• E-4페이지의 내장 함수

ARM DUI 0348BK Copyright © 2007-2009 ARM Limited. All rights reserved. E-1ID090708 Non-Confidential, Unrestricted Access

NEON 지원 사용

E.1 소개

RVCT는 A8 및 Thumb 상태의 Cortex-A8 프로세서에 대해 NEON 코드를 생성하는 내장 함수를 제공합니다. NEON 내장 함수는 헤더 파일 arm_neon.h에 정의되어 있습니다. 헤더 파일은 내장 함수와 벡터 유형 세트를 모두 정의합니다.

ARMv7 이전 아키텍처에 대해서는 NEON 내장 함수를 지원하지 않습니다. 이전 아키텍처나 NEON이 포함되지 않은 ARMv7 아키텍처 프로파일을 빌드하는 경우 컴파일러에서 NEON 내장 함수를 일반 함수 호출로 처리합니다. 따라서 링크 타임에 오류가 발생합니다.

E-2 Copyright © 2007-2009 ARM Limited. All rights reserved. ARM DUI 0348BKNon-Confidential, Unrestricted Access ID090708

NEON 지원 사용

E.2 벡터 데이터 유형

벡터를 나타내기 위해 다음 유형을 정의합니다. NEON 벡터 데이터 유형은 다음 패턴에 따라 명명됩니다.

<type><size>x<number of lanes>_t

예를 들어 int16x4_t는 각각 부호 있는 16비트 정수를 포함하는 4개의 레인이 있는 벡터입니다. 표 E-1에서는 벡터 데이터 유형을 나열합니다.

일부 내장 함수는 다음 형식의 벡터 유형 배열을 사용합니다.

<type><size>x<number of lanes>x<length of array>_t

이러한 유형은 이름이 val인 단일 요소를 포함하는 기본 C 구조체로 처리됩니다.

다음은 구조체 정의의 예입니다.

struct int16x4x2_t{ int16x4_t val[2];};

표 E-1에 나열된 벡터 유형을 2 ~ 4의 배열 길이로 정의한 배열 유형이 있습니다.

표 E-1 벡터 데이터 유형

int8x8_t int8x16_t

int16x4_t int16x8_t

int32x2_t int32x4_t

int64x1_t int64x2_t

uint8x8_t uint8x16_t




float16x4_t float16x8_t

float32x2_t float32x4_t

poly8x8_t poly8x16_t

poly16x4_t poly16x8_t


NEON 지원 사용

E.3 내장 함수

이 단원에서 설명하는 내장 함수는 NEON 명령어와 밀접하게 연관되어 있습니다. 각 단원은 동등한 어셈블러 명령어를 지정하는 주석을 가진 함수 프로토타입 목록으로 시작됩니다. 컴파일러가 필요한 의미를 가진 명령어를 선택하지만 반드시 목록에 있는 명령어를 생성하지는 않습니다.

내장 함수는 NEON 통합 어셈블러 구문과 유사한 명명 체계를 사용합니다. 즉, 각 내장 함수의 형식은 다음과 같습니다.

<opname><flags>_<type>

q 플래그가 추가로 제공되어 내장 함수가 128비트 벡터에서 작동하도록 지정합니다.


• vmul_s16은 부호 있는 16비트 값을 가진 벡터 두 개를 곱합니다.

이것은 VMUL.I16 d2, d0, d1로 컴파일됩니다.

• vaddl_u8은 부호 없는 8비트 값이 포함된 두 개의 64비트 벡터를 long 더하기한 것으로, 결과적으로 부호 없는 16비트 값의 128비트 벡터가 됩니다.

이것은 VADDL.U8 q1, d0, d1로 컴파일됩니다.

참고

이 단원의 내장 함수 프로토타입에서는 다음 유형의 주석을 사용합니다.

__const(n) n 인수는 컴파일-시간 상수여야 합니다.

__constrange(min, max)

인수는 min ~ max 범위의 컴파일시간 상수여야 합니다.

__transfersize(n)

내장 함수가 이 포인터에서 n바이트를 로드합니다.

참고

__fp16을 사용하는 NEON 내장 함수 프로토타입은 NEON 반정밀도 VFP 확장을 포함하는 타겟에만 사용할 수 있습니다. __fp16, 사용을 활성화하려면 --fp16_format 명령 행 옵션을 사용합니다. 자세한 내용은 2-62페이지의 --fp16_format=format을 참조하십시오.


NEON 지원 사용

E.3.1 더하기

이 내장 함수는 벡터를 더합니다. 결과의 각 레인은 각 피연산자 벡터의 해당 레인에서 더하기를 수행한 결과입니다. 수행되는 연산은 다음과 같습니다.

• 벡터 더하기: vadd -> Vr[i]:=Va[i]+Vb[i]

• 벡터 long 더하기: vadd -> Vr[i]:=Va[i]+Vb[i]

• E-6페이지의 벡터 wide 더하기: vadd -> Vr[i]:=Va[i]+Vb[i]

• E-6페이지의 벡터 양분 더하기: vhadd -> Vr[i]:=(Va[i]+Vb[i])>>1

• E-6페이지의 벡터 반올림 양분 더하기: vrhadd -> Vr[i]:=(Va[i]+Vb[i]+1)>>1

• E-7페이지의 벡터 포화 더하기: vqadd -> Vr[i]:=sat<size>(Va[i]+Vb[i])

• E-7페이지의 벡터 상위 반 더하기 -> Vr[i]:=Va[i]+Vb[i]

• E-7페이지의 벡터 상위 반 반올림 더하기.

벡터 더하기: vadd -> Vr[i]:=Va[i]+Vb[i]

Vr, Va, Vb는 레인 크기가 같습니다.

int8x8_t vadd_s8(int8x8_t a, int8x8_t b); // VADD.I8 d0,d0,d0 int16x4_t vadd_s16(int16x4_t a, int16x4_t b); // VADD.I16 d0,d0,d0int32x2_t vadd_s32(int32x2_t a, int32x2_t b); // VADD.I32 d0,d0,d0int64x1_t vadd_s64(int64x1_t a, int64x1_t b); // VADD.I64 d0,d0,d0float32x2_t vadd_f32(float32x2_t a, float32x2_t b); // VADD.F32 d0,d0,d0uint8x8_t vadd_u8(uint8x8_t a, uint8x8_t b); // VADD.I8 d0,d0,d0 uint16x4_t vadd_u16(uint16x4_t a, uint16x4_t b); // VADD.I16 d0,d0,d0uint32x2_t vadd_u32(uint32x2_t a, uint32x2_t b); // VADD.I32 d0,d0,d0uint64x1_t vadd_u64(uint64x1_t a, uint64x1_t b); // VADD.I64 d0,d0,d0int8x16_t vaddq_s8(int8x16_t a, int8x16_t b); // VADD.I8 q0,q0,q0 int16x8_t vaddq_s16(int16x8_t a, int16x8_t b); // VADD.I16 q0,q0,q0int32x4_t vaddq_s32(int32x4_t a, int32x4_t b); // VADD.I32 q0,q0,q0int64x2_t vaddq_s64(int64x2_t a, int64x2_t b); // VADD.I64 q0,q0,q0float32x4_t vaddq_f32(float32x4_t a, float32x4_t b); // VADD.F32 q0,q0,q0uint8x16_t vaddq_u8(uint8x16_t a, uint8x16_t b); // VADD.I8 q0,q0,q0 uint16x8_t vaddq_u16(uint16x8_t a, uint16x8_t b); // VADD.I16 q0,q0,q0uint32x4_t vaddq_u32(uint32x4_t a, uint32x4_t b); // VADD.I32 q0,q0,q0uint64x2_t vaddq_u64(uint64x2_t a, uint64x2_t b); // VADD.I64 q0,q0,q0

벡터 long 더하기: vadd -> Vr[i]:=Va[i]+Vb[i]

Va, Vb의 레인 크기는 같으며 결과는 너비가 두 배인 레인의 128비트 벡터가 됩니다.


NEON 지원 사용

int16x8_t vaddl_s8(int8x8_t a, int8x8_t b); // VADDL.S8 q0,d0,d0 int32x4_t vaddl_s16(int16x4_t a, int16x4_t b); // VADDL.S16 q0,d0,d0int64x2_t vaddl_s32(int32x2_t a, int32x2_t b); // VADDL.S32 q0,d0,d0uint16x8_t vaddl_u8(uint8x8_t a, uint8x8_t b); // VADDL.U8 q0,d0,d0 uint32x4_t vaddl_u16(uint16x4_t a, uint16x4_t b); // VADDL.U16 q0,d0,d0uint64x2_t vaddl_u32(uint32x2_t a, uint32x2_t b); // VADDL.U32 q0,d0,d0

벡터 wide 더하기: vadd -> Vr[i]:=Va[i]+Vb[i]

int16x8_t vaddw_s8(int16x8_t a, int8x8_t b); // VADDW.S8 q0,q0,d0 int32x4_t vaddw_s16(int32x4_t a, int16x4_t b); // VADDW.S16 q0,q0,d0int64x2_t vaddw_s32(int64x2_t a, int32x2_t b); // VADDW.S32 q0,q0,d0uint16x8_t vaddw_u8(uint16x8_t a, uint8x8_t b); // VADDW.U8 q0,q0,d0 uint32x4_t vaddw_u16(uint32x4_t a, uint16x4_t b); // VADDW.U16 q0,q0,d0uint64x2_t vaddw_u32(uint64x2_t a, uint32x2_t b); // VADDW.U32 q0,q0,d0

벡터 양분 더하기: vhadd -> Vr[i]:=(Va[i]+Vb[i])>>1

int8x8_t vhadd_s8(int8x8_t a, int8x8_t b); // VHADD.S8 d0,d0,d0 int16x4_t vhadd_s16(int16x4_t a, int16x4_t b); // VHADD.S16 d0,d0,d0int32x2_t vhadd_s32(int32x2_t a, int32x2_t b); // VHADD.S32 d0,d0,d0uint8x8_t vhadd_u8(uint8x8_t a, uint8x8_t b); // VHADD.U8 d0,d0,d0 uint16x4_t vhadd_u16(uint16x4_t a, uint16x4_t b); // VHADD.U16 d0,d0,d0uint32x2_t vhadd_u32(uint32x2_t a, uint32x2_t b); // VHADD.U32 d0,d0,d0int8x16_t vhaddq_s8(int8x16_t a, int8x16_t b); // VHADD.S8 q0,q0,q0 int16x8_t vhaddq_s16(int16x8_t a, int16x8_t b); // VHADD.S16 q0,q0,q0int32x4_t vhaddq_s32(int32x4_t a, int32x4_t b); // VHADD.S32 q0,q0,q0uint8x16_t vhaddq_u8(uint8x16_t a, uint8x16_t b); // VHADD.U8 q0,q0,q0 uint16x8_t vhaddq_u16(uint16x8_t a, uint16x8_t b); // VHADD.U16 q0,q0,q0uint32x4_t vhaddq_u32(uint32x4_t a, uint32x4_t b); // VHADD.U32 q0,q0,q0

벡터 반올림 양분 더하기: vrhadd -> Vr[i]:=(Va[i]+Vb[i]+1)>>1

int8x8_t vrhadd_s8(int8x8_t a, int8x8_t b); // VRHADD.S8 d0,d0,d0 int16x4_t vrhadd_s16(int16x4_t a, int16x4_t b); // VRHADD.S16 d0,d0,d0int32x2_t vrhadd_s32(int32x2_t a, int32x2_t b); // VRHADD.S32 d0,d0,d0uint8x8_t vrhadd_u8(uint8x8_t a, uint8x8_t b); // VRHADD.U8 d0,d0,d0 uint16x4_t vrhadd_u16(uint16x4_t a, uint16x4_t b); // VRHADD.U16 d0,d0,d0uint32x2_t vrhadd_u32(uint32x2_t a, uint32x2_t b); // VRHADD.U32 d0,d0,d0int8x16_t vrhaddq_s8(int8x16_t a, int8x16_t b); // VRHADD.S8 q0,q0,q0 int16x8_t vrhaddq_s16(int16x8_t a, int16x8_t b); // VRHADD.S16 q0,q0,q0int32x4_t vrhaddq_s32(int32x4_t a, int32x4_t b); // VRHADD.S32 q0,q0,q0uint8x16_t vrhaddq_u8(uint8x16_t a, uint8x16_t b); // VRHADD.U8 q0,q0,q0 uint16x8_t vrhaddq_u16(uint16x8_t a, uint16x8_t b); // VRHADD.U16 q0,q0,q0uint32x4_t vrhaddq_u32(uint32x4_t a, uint32x4_t b); // VRHADD.U32 q0,q0,q0


NEON 지원 사용

벡터 포화 더하기: vqadd -> Vr[i]:=sat<size>(Va[i]+Vb[i])

int8x8_t vqadd_s8(int8x8_t a, int8x8_t b); // VQADD.S8 d0,d0,d0 int16x4_t vqadd_s16(int16x4_t a, int16x4_t b); // VQADD.S16 d0,d0,d0int32x2_t vqadd_s32(int32x2_t a, int32x2_t b); // VQADD.S32 d0,d0,d0int64x1_t vqadd_s64(int64x1_t a, int64x1_t b); // VQADD.S64 d0,d0,d0uint8x8_t vqadd_u8(uint8x8_t a, uint8x8_t b); // VQADD.U8 d0,d0,d0 uint16x4_t vqadd_u16(uint16x4_t a, uint16x4_t b); // VQADD.U16 d0,d0,d0uint32x2_t vqadd_u32(uint32x2_t a, uint32x2_t b); // VQADD.U32 d0,d0,d0uint64x1_t vqadd_u64(uint64x1_t a, uint64x1_t b); // VQADD.U64 d0,d0,d0int8x16_t vqaddq_s8(int8x16_t a, int8x16_t b); // VQADD.S8 q0,q0,q0 int16x8_t vqaddq_s16(int16x8_t a, int16x8_t b); // VQADD.S16 q0,q0,q0int32x4_t vqaddq_s32(int32x4_t a, int32x4_t b); // VQADD.S32 q0,q0,q0int64x2_t vqaddq_s64(int64x2_t a, int64x2_t b); // VQADD.S64 q0,q0,q0uint8x16_t vqaddq_u8(uint8x16_t a, uint8x16_t b); // VQADD.U8 q0,q0,q0 uint16x8_t vqaddq_u16(uint16x8_t a, uint16x8_t b); // VQADD.U16 q0,q0,q0uint32x4_t vqaddq_u32(uint32x4_t a, uint32x4_t b); // VQADD.U32 q0,q0,q0uint64x2_t vqaddq_u64(uint64x2_t a, uint64x2_t b); // VQADD.U64 q0,q0,q0

벡터 상위 반 더하기 -> Vr[i]:=Va[i]+Vb[i]

int8x8_t vaddhn_s16(int16x8_t a, int16x8_t b); // VADDHN.I16 d0,q0,q0int16x4_t vaddhn_s32(int32x4_t a, int32x4_t b); // VADDHN.I32 d0,q0,q0int32x2_t vaddhn_s64(int64x2_t a, int64x2_t b); // VADDHN.I64 d0,q0,q0uint8x8_t vaddhn_u16(uint16x8_t a, uint16x8_t b); // VADDHN.I16 d0,q0,q0uint16x4_t vaddhn_u32(uint32x4_t a, uint32x4_t b); // VADDHN.I32 d0,q0,q0uint32x2_t vaddhn_u64(uint64x2_t a, uint64x2_t b); // VADDHN.I64 d0,q0,q0

벡터 상위 반 반올림 더하기

int8x8_t vraddhn_s16(int16x8_t a, int16x8_t b); // VRADDHN.I16 d0,q0,q0int16x4_t vraddhn_s32(int32x4_t a, int32x4_t b); // VRADDHN.I32 d0,q0,q0int32x2_t vraddhn_s64(int64x2_t a, int64x2_t b); // VRADDHN.I64 d0,q0,q0uint8x8_t vraddhn_u16(uint16x8_t a, uint16x8_t b); // VRADDHN.I16 d0,q0,q0uint16x4_t vraddhn_u32(uint32x4_t a, uint32x4_t b); // VRADDHN.I32 d0,q0,q0uint32x2_t vraddhn_u64(uint64x2_t a, uint64x2_t b); // VRADDHN.I64 d0,q0,q0

E.3.2 곱하기

다음 내장 함수는 곱하기를 포함하는 연산을 제공합니다.

벡터 곱하기: vmul -> Vr[i] := Va[i] * Vb[i]

int8x8_t vmul_s8(int8x8_t a, int8x8_t b); // VMUL.I8 d0,d0,d0 int16x4_t vmul_s16(int16x4_t a, int16x4_t b); // VMUL.I16 d0,d0,d0int32x2_t vmul_s32(int32x2_t a, int32x2_t b); // VMUL.I32 d0,d0,d0float32x2_t vmul_f32(float32x2_t a, float32x2_t b); // VMUL.F32 d0,d0,d0


NEON 지원 사용

uint8x8_t vmul_u8(uint8x8_t a, uint8x8_t b); // VMUL.I8 d0,d0,d0 uint16x4_t vmul_u16(uint16x4_t a, uint16x4_t b); // VMUL.I16 d0,d0,d0uint32x2_t vmul_u32(uint32x2_t a, uint32x2_t b); // VMUL.I32 d0,d0,d0poly8x8_t vmul_p8(poly8x8_t a, poly8x8_t b); // VMUL.P8 d0,d0,d0 int8x16_t vmulq_s8(int8x16_t a, int8x16_t b); // VMUL.I8 q0,q0,q0 int16x8_t vmulq_s16(int16x8_t a, int16x8_t b); // VMUL.I16 q0,q0,q0int32x4_t vmulq_s32(int32x4_t a, int32x4_t b); // VMUL.I32 q0,q0,q0float32x4_t vmulq_f32(float32x4_t a, float32x4_t b); // VMUL.F32 q0,q0,q0uint8x16_t vmulq_u8(uint8x16_t a, uint8x16_t b); // VMUL.I8 q0,q0,q0 uint16x8_t vmulq_u16(uint16x8_t a, uint16x8_t b); // VMUL.I16 q0,q0,q0uint32x4_t vmulq_u32(uint32x4_t a, uint32x4_t b); // VMUL.I32 q0,q0,q0poly8x16_t vmulq_p8(poly8x16_t a, poly8x16_t b); // VMUL.P8 q0,q0,q0

벡터 곱하기 누산: vmla -> Vr[i] := Va[i] + Vb[i] * Vc[i]

int8x8_t vmla_s8(int8x8_t a, int8x8_t b, int8x8_t c); // VMLA.I8 d0,d0,d0 int16x4_t vmla_s16(int16x4_t a, int16x4_t b, int16x4_t c); // VMLA.I16 d0,d0,d0int32x2_t vmla_s32(int32x2_t a, int32x2_t b, int32x2_t c); // VMLA.I32 d0,d0,d0float32x2_t vmla_f32(float32x2_t a, float32x2_t b, float32x2_t c); // VMLA.F32 d0,d0,d0uint8x8_t vmla_u8(uint8x8_t a, uint8x8_t b, uint8x8_t c); // VMLA.I8 d0,d0,d0 uint16x4_t vmla_u16(uint16x4_t a, uint16x4_t b, uint16x4_t c); // VMLA.I16 d0,d0,d0uint32x2_t vmla_u32(uint32x2_t a, uint32x2_t b, uint32x2_t c); // VMLA.I32 d0,d0,d0int8x16_t vmlaq_s8(int8x16_t a, int8x16_t b, int8x16_t c); // VMLA.I8 q0,q0,q0 int16x8_t vmlaq_s16(int16x8_t a, int16x8_t b, int16x8_t c); // VMLA.I16 q0,q0,q0int32x4_t vmlaq_s32(int32x4_t a, int32x4_t b, int32x4_t c); // VMLA.I32 q0,q0,q0float32x4_t vmlaq_f32(float32x4_t a, float32x4_t b, float32x4_t c); // VMLA.F32 q0,q0,q0uint8x16_t vmlaq_u8(uint8x16_t a, uint8x16_t b, uint8x16_t c); // VMLA.I8 q0,q0,q0 uint16x8_t vmlaq_u16(uint16x8_t a, uint16x8_t b, uint16x8_t c); // VMLA.I16 q0,q0,q0uint32x4_t vmlaq_u32(uint32x4_t a, uint32x4_t b, uint32x4_t c); // VMLA.I32 q0,q0,q0

벡터 곱하기 누산 long: vmla -> Vr[i] := Va[i] + Vb[i] * Vc[i]

int16x8_t vmlal_s8(int16x8_t a, int8x8_t b, int8x8_t c); // VMLAL.S8 q0,d0,d0 int32x4_t vmlal_s16(int32x4_t a, int16x4_t b, int16x4_t c); // VMLAL.S16 q0,d0,d0int64x2_t vmlal_s32(int64x2_t a, int32x2_t b, int32x2_t c); // VMLAL.S32 q0,d0,d0uint16x8_t vmlal_u8(uint16x8_t a, uint8x8_t b, uint8x8_t c); // VMLAL.U8 q0,d0,d0 uint32x4_t vmlal_u16(uint32x4_t a, uint16x4_t b, uint16x4_t c); // VMLAL.U16 q0,d0,d0uint64x2_t vmlal_u32(uint64x2_t a, uint32x2_t b, uint32x2_t c); // VMLAL.U32 q0,d0,d0

벡터 곱하기 빼기: vmls -> Vr[i] := Va[i] - Vb[i] * Vc[i]

int8x8_t vmls_s8(int8x8_t a, int8x8_t b, int8x8_t c); // VMLS.I8 d0,d0,d0 int16x4_t vmls_s16(int16x4_t a, int16x4_t b, int16x4_t c); // VMLS.I16 d0,d0,d0int32x2_t vmls_s32(int32x2_t a, int32x2_t b, int32x2_t c); // VMLS.I32 d0,d0,d0float32x2_t vmls_f32(float32x2_t a, float32x2_t b, float32x2_t c); // VMLS.F32 d0,d0,d0uint8x8_t vmls_u8(uint8x8_t a, uint8x8_t b, uint8x8_t c); // VMLS.I8 d0,d0,d0 uint16x4_t vmls_u16(uint16x4_t a, uint16x4_t b, uint16x4_t c); // VMLS.I16 d0,d0,d0uint32x2_t vmls_u32(uint32x2_t a, uint32x2_t b, uint32x2_t c); // VMLS.I32 d0,d0,d0


NEON 지원 사용

int8x16_t vmlsq_s8(int8x16_t a, int8x16_t b, int8x16_t c); // VMLS.I8 q0,q0,q0 int16x8_t vmlsq_s16(int16x8_t a, int16x8_t b, int16x8_t c); // VMLS.I16 q0,q0,q0int32x4_t vmlsq_s32(int32x4_t a, int32x4_t b, int32x4_t c); // VMLS.I32 q0,q0,q0float32x4_t vmlsq_f32(float32x4_t a, float32x4_t b, float32x4_t c); // VMLS.F32 q0,q0,q0uint8x16_t vmlsq_u8(uint8x16_t a, uint8x16_t b, uint8x16_t c); // VMLS.I8 q0,q0,q0 uint16x8_t vmlsq_u16(uint16x8_t a, uint16x8_t b, uint16x8_t c); // VMLS.I16 q0,q0,q0uint32x4_t vmlsq_u32(uint32x4_t a, uint32x4_t b, uint32x4_t c); // VMLS.I32 q0,q0,q0

벡터 곱하기 빼기 long

int16x8_t vmlsl_s8(int16x8_t a, int8x8_t b, int8x8_t c); // VMLSL.S8 q0,d0,d0 int32x4_t vmlsl_s16(int32x4_t a, int16x4_t b, int16x4_t c); // VMLSL.S16 q0,d0,d0int64x2_t vmlsl_s32(int64x2_t a, int32x2_t b, int32x2_t c); // VMLSL.S32 q0,d0,d0uint16x8_t vmlsl_u8(uint16x8_t a, uint8x8_t b, uint8x8_t c); // VMLSL.U8 q0,d0,d0 uint32x4_t vmlsl_u16(uint32x4_t a, uint16x4_t b, uint16x4_t c); // VMLSL.U16 q0,d0,d0uint64x2_t vmlsl_u32(uint64x2_t a, uint32x2_t b, uint32x2_t c); // VMLSL.U32 q0,d0,d0

벡터 상위 포화 배수화 곱하기

int16x4_t vqdmulh_s16(int16x4_t a, int16x4_t b); // VQDMULH.S16 d0,d0,d0int32x2_t vqdmulh_s32(int32x2_t a, int32x2_t b); // VQDMULH.S32 d0,d0,d0int16x8_t vqdmulhq_s16(int16x8_t a, int16x8_t b); // VQDMULH.S16 q0,q0,q0int32x4_t vqdmulhq_s32(int32x4_t a, int32x4_t b); // VQDMULH.S32 q0,q0,q0

벡터 상위 포화 반올림 배수화 곱하기

int16x4_t vqrdmulh_s16(int16x4_t a, int16x4_t b); // VQRDMULH.S16 d0,d0,d0int32x2_t vqrdmulh_s32(int32x2_t a, int32x2_t b); // VQRDMULH.S32 d0,d0,d0int16x8_t vqrdmulhq_s16(int16x8_t a, int16x8_t b); // VQRDMULH.S16 q0,q0,q0int32x4_t vqrdmulhq_s32(int32x4_t a, int32x4_t b); // VQRDMULH.S32 q0,q0,q0

벡터 포화 배수화 곱하기 누산 long

int32x4_t vqdmlal_s16(int32x4_t a, int16x4_t b, int16x4_t c); // VQDMLAL.S16 q0,d0,d0int64x2_t vqdmlal_s32(int64x2_t a, int32x2_t b, int32x2_t c); // VQDMLAL.S32 q0,d0,d0

벡터 포화 배수화 곱하기 빼기 long

int32x4_t vqdmlsl_s16(int32x4_t a, int16x4_t b, int16x4_t c); // VQDMLSL.S16 q0,d0,d0int64x2_t vqdmlsl_s32(int64x2_t a, int32x2_t b, int32x2_t c); // VQDMLSL.S32 q0,d0,d0

벡터 long 곱하기

int16x8_t vmull_s8(int8x8_t a, int8x8_t b); // VMULL.S8 q0,d0,d0 int32x4_t vmull_s16(int16x4_t a, int16x4_t b); // VMULL.S16 q0,d0,d0int64x2_t vmull_s32(int32x2_t a, int32x2_t b); // VMULL.S32 q0,d0,d0


NEON 지원 사용

uint16x8_t vmull_u8(uint8x8_t a, uint8x8_t b); // VMULL.U8 q0,d0,d0 uint32x4_t vmull_u16(uint16x4_t a, uint16x4_t b); // VMULL.U16 q0,d0,d0uint64x2_t vmull_u32(uint32x2_t a, uint32x2_t b); // VMULL.U32 q0,d0,d0poly16x8_t vmull_p8(poly8x8_t a, poly8x8_t b); // VMULL.P8 q0,d0,d0

벡터 포화 배수화 long 곱하기

int32x4_t vqdmull_s16(int16x4_t a, int16x4_t b); // VQDMULL.S16 q0,d0,d0int64x2_t vqdmull_s32(int32x2_t a, int32x2_t b); // VQDMULL.S32 q0,d0,d0

E.3.3 빼기

다음 내장 함수는 빼기를 포함하는 연산을 제공합니다.

벡터 빼기

int8x8_t vsub_s8(int8x8_t a, int8x8_t b); // VSUB.I8 d0,d0,d0 int16x4_t vsub_s16(int16x4_t a, int16x4_t b); // VSUB.I16 d0,d0,d0int32x2_t vsub_s32(int32x2_t a, int32x2_t b); // VSUB.I32 d0,d0,d0int64x1_t vsub_s64(int64x1_t a, int64x1_t b); // VSUB.I64 d0,d0,d0float32x2_t vsub_f32(float32x2_t a, float32x2_t b); // VSUB.F32 d0,d0,d0uint8x8_t vsub_u8(uint8x8_t a, uint8x8_t b); // VSUB.I8 d0,d0,d0 uint16x4_t vsub_u16(uint16x4_t a, uint16x4_t b); // VSUB.I16 d0,d0,d0uint32x2_t vsub_u32(uint32x2_t a, uint32x2_t b); // VSUB.I32 d0,d0,d0uint64x1_t vsub_u64(uint64x1_t a, uint64x1_t b); // VSUB.I64 d0,d0,d0int8x16_t vsubq_s8(int8x16_t a, int8x16_t b); // VSUB.I8 q0,q0,q0 int16x8_t vsubq_s16(int16x8_t a, int16x8_t b); // VSUB.I16 q0,q0,q0int32x4_t vsubq_s32(int32x4_t a, int32x4_t b); // VSUB.I32 q0,q0,q0int64x2_t vsubq_s64(int64x2_t a, int64x2_t b); // VSUB.I64 q0,q0,q0float32x4_t vsubq_f32(float32x4_t a, float32x4_t b); // VSUB.F32 q0,q0,q0uint8x16_t vsubq_u8(uint8x16_t a, uint8x16_t b); // VSUB.I8 q0,q0,q0 uint16x8_t vsubq_u16(uint16x8_t a, uint16x8_t b); // VSUB.I16 q0,q0,q0uint32x4_t vsubq_u32(uint32x4_t a, uint32x4_t b); // VSUB.I32 q0,q0,q0uint64x2_t vsubq_u64(uint64x2_t a, uint64x2_t b); // VSUB.I64 q0,q0,q0

벡터 long 빼기: vsub -> Vr[i]:=Va[i]+Vb[i]

int16x8_t vsubl_s8(int8x8_t a, int8x8_t b); // VSUBL.S8 q0,d0,d0 int32x4_t vsubl_s16(int16x4_t a, int16x4_t b); // VSUBL.S16 q0,d0,d0int64x2_t vsubl_s32(int32x2_t a, int32x2_t b); // VSUBL.S32 q0,d0,d0uint16x8_t vsubl_u8(uint8x8_t a, uint8x8_t b); // VSUBL.U8 q0,d0,d0 uint32x4_t vsubl_u16(uint16x4_t a, uint16x4_t b); // VSUBL.U16 q0,d0,d0uint64x2_t vsubl_u32(uint32x2_t a, uint32x2_t b); // VSUBL.U32 q0,d0,d0


NEON 지원 사용

벡터 wide 빼기: vsub -> Vr[i]:=Va[i]+Vb[i]

int16x8_t vsubw_s8(int16x8_t a, int8x8_t b); // VSUBW.S8 q0,q0,d0 int32x4_t vsubw_s16(int32x4_t a, int16x4_t b); // VSUBW.S16 q0,q0,d0int64x2_t vsubw_s32(int64x2_t a, int32x2_t b); // VSUBW.S32 q0,q0,d0uint16x8_t vsubw_u8(uint16x8_t a, uint8x8_t b); // VSUBW.U8 q0,q0,d0 uint32x4_t vsubw_u16(uint32x4_t a, uint16x4_t b); // VSUBW.U16 q0,q0,d0uint64x2_t vsubw_u32(uint64x2_t a, uint32x2_t b); // VSUBW.U32 q0,q0,d0

벡터 포화 빼기

int8x8_t vqsub_s8(int8x8_t a, int8x8_t b); // VQSUB.S8 d0,d0,d0 int16x4_t vqsub_s16(int16x4_t a, int16x4_t b); // VQSUB.S16 d0,d0,d0int32x2_t vqsub_s32(int32x2_t a, int32x2_t b); // VQSUB.S32 d0,d0,d0int64x1_t vqsub_s64(int64x1_t a, int64x1_t b); // VQSUB.S64 d0,d0,d0uint8x8_t vqsub_u8(uint8x8_t a, uint8x8_t b); // VQSUB.U8 d0,d0,d0 uint16x4_t vqsub_u16(uint16x4_t a, uint16x4_t b); // VQSUB.U16 d0,d0,d0uint32x2_t vqsub_u32(uint32x2_t a, uint32x2_t b); // VQSUB.U32 d0,d0,d0uint64x1_t vqsub_u64(uint64x1_t a, uint64x1_t b); // VQSUB.U64 d0,d0,d0int8x16_t vqsubq_s8(int8x16_t a, int8x16_t b); // VQSUB.S8 q0,q0,q0 int16x8_t vqsubq_s16(int16x8_t a, int16x8_t b); // VQSUB.S16 q0,q0,q0int32x4_t vqsubq_s32(int32x4_t a, int32x4_t b); // VQSUB.S32 q0,q0,q0int64x2_t vqsubq_s64(int64x2_t a, int64x2_t b); // VQSUB.S64 q0,q0,q0uint8x16_t vqsubq_u8(uint8x16_t a, uint8x16_t b); // VQSUB.U8 q0,q0,q0 uint16x8_t vqsubq_u16(uint16x8_t a, uint16x8_t b); // VQSUB.U16 q0,q0,q0uint32x4_t vqsubq_u32(uint32x4_t a, uint32x4_t b); // VQSUB.U32 q0,q0,q0uint64x2_t vqsubq_u64(uint64x2_t a, uint64x2_t b); // VQSUB.U64 q0,q0,q0

벡터 양분 빼기

int8x8_t vhsub_s8(int8x8_t a, int8x8_t b); // VHSUB.S8 d0,d0,d0 int16x4_t vhsub_s16(int16x4_t a, int16x4_t b); // VHSUB.S16 d0,d0,d0int32x2_t vhsub_s32(int32x2_t a, int32x2_t b); // VHSUB.S32 d0,d0,d0uint8x8_t vhsub_u8(uint8x8_t a, uint8x8_t b); // VHSUB.U8 d0,d0,d0 uint16x4_t vhsub_u16(uint16x4_t a, uint16x4_t b); // VHSUB.U16 d0,d0,d0uint32x2_t vhsub_u32(uint32x2_t a, uint32x2_t b); // VHSUB.U32 d0,d0,d0int8x16_t vhsubq_s8(int8x16_t a, int8x16_t b); // VHSUB.S8 q0,q0,q0 int16x8_t vhsubq_s16(int16x8_t a, int16x8_t b); // VHSUB.S16 q0,q0,q0int32x4_t vhsubq_s32(int32x4_t a, int32x4_t b); // VHSUB.S32 q0,q0,q0uint8x16_t vhsubq_u8(uint8x16_t a, uint8x16_t b); // VHSUB.U8 q0,q0,q0 uint16x8_t vhsubq_u16(uint16x8_t a, uint16x8_t b); // VHSUB.U16 q0,q0,q0uint32x4_t vhsubq_u32(uint32x4_t a, uint32x4_t b); // VHSUB.U32 q0,q0,q0

벡터 상위 반 빼기

int8x8_t vsubhn_s16(int16x8_t a, int16x8_t b); // VSUBHN.I16 d0,q0,q0int16x4_t vsubhn_s32(int32x4_t a, int32x4_t b); // VSUBHN.I32 d0,q0,q0int32x2_t vsubhn_s64(int64x2_t a, int64x2_t b); // VSUBHN.I64 d0,q0,q0


NEON 지원 사용

uint8x8_t vsubhn_u16(uint16x8_t a, uint16x8_t b); // VSUBHN.I16 d0,q0,q0uint16x4_t vsubhn_u32(uint32x4_t a, uint32x4_t b); // VSUBHN.I32 d0,q0,q0uint32x2_t vsubhn_u64(uint64x2_t a, uint64x2_t b); // VSUBHN.I64 d0,q0,q0

벡터 상위 반 반올림 빼기

int8x8_t vrsubhn_s16(int16x8_t a, int16x8_t b); // VRSUBHN.I16 d0,q0,q0int16x4_t vrsubhn_s32(int32x4_t a, int32x4_t b); // VRSUBHN.I32 d0,q0,q0int32x2_t vrsubhn_s64(int64x2_t a, int64x2_t b); // VRSUBHN.I64 d0,q0,q0uint8x8_t vrsubhn_u16(uint16x8_t a, uint16x8_t b); // VRSUBHN.I16 d0,q0,q0uint16x4_t vrsubhn_u32(uint32x4_t a, uint32x4_t b); // VRSUBHN.I32 d0,q0,q0uint32x2_t vrsubhn_u64(uint64x2_t a, uint64x2_t b); // VRSUBHN.I64 d0,q0,q0

E.3.4 비교

다양한 비교 내장 함수가 제공됩니다. 레인에 대해 비교가 참이면 해당 레인에서 모든 비트가 1로 설정됩니다. 레인에 대해 비교가 거짓이면 모든 비트가 0으로 설정됩니다. 반환 형식은 부호 없는 정수 유형입니다. 즉, 비교 결과를 vbsl 내장 함수에 대한 첫 번째 인수로 사용할 수 있습니다.

벡터 비교 같음

uint8x8_t vceq_s8(int8x8_t a, int8x8_t b); // VCEQ.I8 d0, d0, d0 uint16x4_t vceq_s16(int16x4_t a, int16x4_t b); // VCEQ.I16 d0, d0, d0uint32x2_t vceq_s32(int32x2_t a, int32x2_t b); // VCEQ.I32 d0, d0, d0uint32x2_t vceq_f32(float32x2_t a, float32x2_t b); // VCEQ.F32 d0, d0, d0uint8x8_t vceq_u8(uint8x8_t a, uint8x8_t b); // VCEQ.I8 d0, d0, d0 uint16x4_t vceq_u16(uint16x4_t a, uint16x4_t b); // VCEQ.I16 d0, d0, d0uint32x2_t vceq_u32(uint32x2_t a, uint32x2_t b); // VCEQ.I32 d0, d0, d0uint8x8_t vceq_p8(poly8x8_t a, poly8x8_t b); // VCEQ.I8 d0, d0, d0 uint8x16_t vceqq_s8(int8x16_t a, int8x16_t b); // VCEQ.I8 q0, q0, q0 uint16x8_t vceqq_s16(int16x8_t a, int16x8_t b); // VCEQ.I16 q0, q0, q0uint32x4_t vceqq_s32(int32x4_t a, int32x4_t b); // VCEQ.I32 q0, q0, q0uint32x4_t vceqq_f32(float32x4_t a, float32x4_t b); // VCEQ.F32 q0, q0, q0uint8x16_t vceqq_u8(uint8x16_t a, uint8x16_t b); // VCEQ.I8 q0, q0, q0 uint16x8_t vceqq_u16(uint16x8_t a, uint16x8_t b); // VCEQ.I16 q0, q0, q0uint32x4_t vceqq_u32(uint32x4_t a, uint32x4_t b); // VCEQ.I32 q0, q0, q0uint8x16_t vceqq_p8(poly8x16_t a, poly8x16_t b); // VCEQ.I8 q0, q0, q0

벡터 비교 크거나 같음

uint8x8_t vcge_s8(int8x8_t a, int8x8_t b); // VCGE.S8 d0, d0, d0 uint16x4_t vcge_s16(int16x4_t a, int16x4_t b); // VCGE.S16 d0, d0, d0uint32x2_t vcge_s32(int32x2_t a, int32x2_t b); // VCGE.S32 d0, d0, d0uint32x2_t vcge_f32(float32x2_t a, float32x2_t b); // VCGE.F32 d0, d0, d0uint8x8_t vcge_u8(uint8x8_t a, uint8x8_t b); // VCGE.U8 d0, d0, d0


NEON 지원 사용

uint16x4_t vcge_u16(uint16x4_t a, uint16x4_t b); // VCGE.U16 d0, d0, d0uint32x2_t vcge_u32(uint32x2_t a, uint32x2_t b); // VCGE.U32 d0, d0, d0uint8x16_t vcgeq_s8(int8x16_t a, int8x16_t b); // VCGE.S8 q0, q0, q0 uint16x8_t vcgeq_s16(int16x8_t a, int16x8_t b); // VCGE.S16 q0, q0, q0uint32x4_t vcgeq_s32(int32x4_t a, int32x4_t b); // VCGE.S32 q0, q0, q0uint32x4_t vcgeq_f32(float32x4_t a, float32x4_t b); // VCGE.F32 q0, q0, q0uint8x16_t vcgeq_u8(uint8x16_t a, uint8x16_t b); // VCGE.U8 q0, q0, q0 uint16x8_t vcgeq_u16(uint16x8_t a, uint16x8_t b); // VCGE.U16 q0, q0, q0uint32x4_t vcgeq_u32(uint32x4_t a, uint32x4_t b); // VCGE.U32 q0, q0, q0

벡터 비교 작거나 같음

uint8x8_t vcle_s8(int8x8_t a, int8x8_t b); // VCGE.S8 d0, d0, d0 uint16x4_t vcle_s16(int16x4_t a, int16x4_t b); // VCGE.S16 d0, d0, d0uint32x2_t vcle_s32(int32x2_t a, int32x2_t b); // VCGE.S32 d0, d0, d0uint32x2_t vcle_f32(float32x2_t a, float32x2_t b); // VCGE.F32 d0, d0, d0uint8x8_t vcle_u8(uint8x8_t a, uint8x8_t b); // VCGE.U8 d0, d0, d0 uint16x4_t vcle_u16(uint16x4_t a, uint16x4_t b); // VCGE.U16 d0, d0, d0uint32x2_t vcle_u32(uint32x2_t a, uint32x2_t b); // VCGE.U32 d0, d0, d0uint8x16_t vcleq_s8(int8x16_t a, int8x16_t b); // VCGE.S8 q0, q0, q0 uint16x8_t vcleq_s16(int16x8_t a, int16x8_t b); // VCGE.S16 q0, q0, q0uint32x4_t vcleq_s32(int32x4_t a, int32x4_t b); // VCGE.S32 q0, q0, q0uint32x4_t vcleq_f32(float32x4_t a, float32x4_t b); // VCGE.F32 q0, q0, q0uint8x16_t vcleq_u8(uint8x16_t a, uint8x16_t b); // VCGE.U8 q0, q0, q0 uint16x8_t vcleq_u16(uint16x8_t a, uint16x8_t b); // VCGE.U16 q0, q0, q0uint32x4_t vcleq_u32(uint32x4_t a, uint32x4_t b); // VCGE.U32 q0, q0, q0

벡터 비교 보다 큼

uint8x8_t vcgt_s8(int8x8_t a, int8x8_t b); // VCGT.S8 d0, d0, d0 uint16x4_t vcgt_s16(int16x4_t a, int16x4_t b); // VCGT.S16 d0, d0, d0uint32x2_t vcgt_s32(int32x2_t a, int32x2_t b); // VCGT.S32 d0, d0, d0uint32x2_t vcgt_f32(float32x2_t a, float32x2_t b); // VCGT.F32 d0, d0, d0uint8x8_t vcgt_u8(uint8x8_t a, uint8x8_t b); // VCGT.U8 d0, d0, d0 uint16x4_t vcgt_u16(uint16x4_t a, uint16x4_t b); // VCGT.U16 d0, d0, d0uint32x2_t vcgt_u32(uint32x2_t a, uint32x2_t b); // VCGT.U32 d0, d0, d0uint8x16_t vcgtq_s8(int8x16_t a, int8x16_t b); // VCGT.S8 q0, q0, q0 uint16x8_t vcgtq_s16(int16x8_t a, int16x8_t b); // VCGT.S16 q0, q0, q0uint32x4_t vcgtq_s32(int32x4_t a, int32x4_t b); // VCGT.S32 q0, q0, q0uint32x4_t vcgtq_f32(float32x4_t a, float32x4_t b); // VCGT.F32 q0, q0, q0uint8x16_t vcgtq_u8(uint8x16_t a, uint8x16_t b); // VCGT.U8 q0, q0, q0 uint16x8_t vcgtq_u16(uint16x8_t a, uint16x8_t b); // VCGT.U16 q0, q0, q0uint32x4_t vcgtq_u32(uint32x4_t a, uint32x4_t b); // VCGT.U32 q0, q0, q0


NEON 지원 사용

벡터 비교 보다 작음

uint8x8_t vclt_s8(int8x8_t a, int8x8_t b); // VCGT.S8 d0, d0, d0 uint16x4_t vclt_s16(int16x4_t a, int16x4_t b); // VCGT.S16 d0, d0, d0uint32x2_t vclt_s32(int32x2_t a, int32x2_t b); // VCGT.S32 d0, d0, d0uint32x2_t vclt_f32(float32x2_t a, float32x2_t b); // VCGT.F32 d0, d0, d0uint8x8_t vclt_u8(uint8x8_t a, uint8x8_t b); // VCGT.U8 d0, d0, d0 uint16x4_t vclt_u16(uint16x4_t a, uint16x4_t b); // VCGT.U16 d0, d0, d0uint32x2_t vclt_u32(uint32x2_t a, uint32x2_t b); // VCGT.U32 d0, d0, d0uint8x16_t vcltq_s8(int8x16_t a, int8x16_t b); // VCGT.S8 q0, q0, q0 uint16x8_t vcltq_s16(int16x8_t a, int16x8_t b); // VCGT.S16 q0, q0, q0uint32x4_t vcltq_s32(int32x4_t a, int32x4_t b); // VCGT.S32 q0, q0, q0uint32x4_t vcltq_f32(float32x4_t a, float32x4_t b); // VCGT.F32 q0, q0, q0uint8x16_t vcltq_u8(uint8x16_t a, uint8x16_t b); // VCGT.U8 q0, q0, q0 uint16x8_t vcltq_u16(uint16x8_t a, uint16x8_t b); // VCGT.U16 q0, q0, q0uint32x4_t vcltq_u32(uint32x4_t a, uint32x4_t b); // VCGT.U32 q0, q0, q0

벡터 비교 절대 크거나 같음

uint32x2_t vcage_f32(float32x2_t a, float32x2_t b); // VACGE.F32 d0, d0, d0uint32x4_t vcageq_f32(float32x4_t a, float32x4_t b); // VACGE.F32 q0, q0, q0

벡터 비교 절대 작거나 같음

uint32x2_t vcale_f32(float32x2_t a, float32x2_t b); // VACGE.F32 d0, d0, d0uint32x4_t vcaleq_f32(float32x4_t a, float32x4_t b); // VACGE.F32 q0, q0, q0

벡터 비교 절대 보다 큼

uint32x2_t vcagt_f32(float32x2_t a, float32x2_t b); // VACGT.F32 d0, d0, d0uint32x4_t vcagtq_f32(float32x4_t a, float32x4_t b); // VACGT.F32 q0, q0, q0

벡터 비교 절대 보다 작음

uint32x2_t vcalt_f32(float32x2_t a, float32x2_t b); // VACGT.F32 d0, d0, d0uint32x4_t vcaltq_f32(float32x4_t a, float32x4_t b); // VACGT.F32 q0, q0, q0

벡터 테스트 비트

uint8x8_t vtst_s8(int8x8_t a, int8x8_t b); // VTST.8 d0, d0, d0 uint16x4_t vtst_s16(int16x4_t a, int16x4_t b); // VTST.16 d0, d0, d0uint32x2_t vtst_s32(int32x2_t a, int32x2_t b); // VTST.32 d0, d0, d0uint8x8_t vtst_u8(uint8x8_t a, uint8x8_t b); // VTST.8 d0, d0, d0 uint16x4_t vtst_u16(uint16x4_t a, uint16x4_t b); // VTST.16 d0, d0, d0uint32x2_t vtst_u32(uint32x2_t a, uint32x2_t b); // VTST.32 d0, d0, d0uint8x8_t vtst_p8(poly8x8_t a, poly8x8_t b); // VTST.8 d0, d0, d0 uint8x16_t vtstq_s8(int8x16_t a, int8x16_t b); // VTST.8 q0, q0, q0


NEON 지원 사용

uint16x8_t vtstq_s16(int16x8_t a, int16x8_t b); // VTST.16 q0, q0, q0uint32x4_t vtstq_s32(int32x4_t a, int32x4_t b); // VTST.32 q0, q0, q0uint8x16_t vtstq_u8(uint8x16_t a, uint8x16_t b); // VTST.8 q0, q0, q0 uint16x8_t vtstq_u16(uint16x8_t a, uint16x8_t b); // VTST.16 q0, q0, q0uint32x4_t vtstq_u32(uint32x4_t a, uint32x4_t b); // VTST.32 q0, q0, q0uint8x16_t vtstq_p8(poly8x16_t a, poly8x16_t b); // VTST.8 q0, q0, q0

E.3.5 절대 차이

다음 내장 함수는 절대 차이를 포함하는 연산을 제공합니다.

인수 간 절대 차이: Vr[i] = | Va[i] - Vb[i] |

int8x8_t vabd_s8(int8x8_t a, int8x8_t b); // VABD.S8 d0,d0,d0 int16x4_t vabd_s16(int16x4_t a, int16x4_t b); // VABD.S16 d0,d0,d0int32x2_t vabd_s32(int32x2_t a, int32x2_t b); // VABD.S32 d0,d0,d0uint8x8_t vabd_u8(uint8x8_t a, uint8x8_t b); // VABD.U8 d0,d0,d0 uint16x4_t vabd_u16(uint16x4_t a, uint16x4_t b); // VABD.U16 d0,d0,d0uint32x2_t vabd_u32(uint32x2_t a, uint32x2_t b); // VABD.U32 d0,d0,d0float32x2_t vabd_f32(float32x2_t a, float32x2_t b); // VABD.F32 d0,d0,d0int8x16_t vabdq_s8(int8x16_t a, int8x16_t b); // VABD.S8 q0,q0,q0 int16x8_t vabdq_s16(int16x8_t a, int16x8_t b); // VABD.S16 q0,q0,q0int32x4_t vabdq_s32(int32x4_t a, int32x4_t b); // VABD.S32 q0,q0,q0uint8x16_t vabdq_u8(uint8x16_t a, uint8x16_t b); // VABD.U8 q0,q0,q0 uint16x8_t vabdq_u16(uint16x8_t a, uint16x8_t b); // VABD.U16 q0,q0,q0uint32x4_t vabdq_u32(uint32x4_t a, uint32x4_t b); // VABD.U32 q0,q0,q0float32x4_t vabdq_f32(float32x4_t a, float32x4_t b); // VABD.F32 q0,q0,q0

절대 차이 long

int16x8_t vabdl_s8(int8x8_t a, int8x8_t b); // VABDL.S8 q0,d0,d0 int32x4_t vabdl_s16(int16x4_t a, int16x4_t b); // VABDL.S16 q0,d0,d0int64x2_t vabdl_s32(int32x2_t a, int32x2_t b); // VABDL.S32 q0,d0,d0uint16x8_t vabdl_u8(uint8x8_t a, uint8x8_t b); // VABDL.U8 q0,d0,d0 uint32x4_t vabdl_u16(uint16x4_t a, uint16x4_t b); // VABDL.U16 q0,d0,d0uint64x2_t vabdl_u32(uint32x2_t a, uint32x2_t b); // VABDL.U32 q0,d0,d0

절대 차이 및 누산: Vr[i] = Va[i] + | Vb[i] - Vc[i] |

int8x8_t vaba_s8(int8x8_t a, int8x8_t b, int8x8_t c); // VABA.S8 d0,d0,d0 int16x4_t vaba_s16(int16x4_t a, int16x4_t b, int16x4_t c); // VABA.S16 d0,d0,d0int32x2_t vaba_s32(int32x2_t a, int32x2_t b, int32x2_t c); // VABA.S32 d0,d0,d0uint8x8_t vaba_u8(uint8x8_t a, uint8x8_t b, uint8x8_t c); // VABA.U8 d0,d0,d0 uint16x4_t vaba_u16(uint16x4_t a, uint16x4_t b, uint16x4_t c); // VABA.U16 d0,d0,d0uint32x2_t vaba_u32(uint32x2_t a, uint32x2_t b, uint32x2_t c); // VABA.U32 d0,d0,d0int8x16_t vabaq_s8(int8x16_t a, int8x16_t b, int8x16_t c); // VABA.S8 q0,q0,q0 int16x8_t vabaq_s16(int16x8_t a, int16x8_t b, int16x8_t c); // VABA.S16 q0,q0,q0


NEON 지원 사용

int32x4_t vabaq_s32(int32x4_t a, int32x4_t b, int32x4_t c); // VABA.S32 q0,q0,q0uint8x16_t vabaq_u8(uint8x16_t a, uint8x16_t b, uint8x16_t c); // VABA.U8 q0,q0,q0 uint16x8_t vabaq_u16(uint16x8_t a, uint16x8_t b, uint16x8_t c); // VABA.U16 q0,q0,q0uint32x4_t vabaq_u32(uint32x4_t a, uint32x4_t b, uint32x4_t c); // VABA.U32 q0,q0,q0

절대 차이 및 누산 long

int16x8_t vabal_s8(int16x8_t a, int8x8_t b, int8x8_t c); // VABAL.S8 q0,d0,d0 int32x4_t vabal_s16(int32x4_t a, int16x4_t b, int16x4_t c); // VABAL.S16 q0,d0,d0int64x2_t vabal_s32(int64x2_t a, int32x2_t b, int32x2_t c); // VABAL.S32 q0,d0,d0uint16x8_t vabal_u8(uint16x8_t a, uint8x8_t b, uint8x8_t c); // VABAL.U8 q0,d0,d0 uint32x4_t vabal_u16(uint32x4_t a, uint16x4_t b, uint16x4_t c); // VABAL.U16 q0,d0,d0uint64x2_t vabal_u32(uint64x2_t a, uint32x2_t b, uint32x2_t c); // VABAL.U32 q0,d0,d0

E.3.6 최대값/최소값

다음 내장 함수는 최대값 및 최소값 연산을 제공합니다.

vmax -> Vr[i] := (Va[i] >= Vb[i]) ? Va[i] : Vb[i]

int8x8_t vmax_s8(int8x8_t a, int8x8_t b); // VMAX.S8 d0,d0,d0 int16x4_t vmax_s16(int16x4_t a, int16x4_t b); // VMAX.S16 d0,d0,d0int32x2_t vmax_s32(int32x2_t a, int32x2_t b); // VMAX.S32 d0,d0,d0uint8x8_t vmax_u8(uint8x8_t a, uint8x8_t b); // VMAX.U8 d0,d0,d0 uint16x4_t vmax_u16(uint16x4_t a, uint16x4_t b); // VMAX.U16 d0,d0,d0uint32x2_t vmax_u32(uint32x2_t a, uint32x2_t b); // VMAX.U32 d0,d0,d0float32x2_t vmax_f32(float32x2_t a, float32x2_t b); // VMAX.F32 d0,d0,d0int8x16_t vmaxq_s8(int8x16_t a, int8x16_t b); // VMAX.S8 q0,q0,q0 int16x8_t vmaxq_s16(int16x8_t a, int16x8_t b); // VMAX.S16 q0,q0,q0int32x4_t vmaxq_s32(int32x4_t a, int32x4_t b); // VMAX.S32 q0,q0,q0uint8x16_t vmaxq_u8(uint8x16_t a, uint8x16_t b); // VMAX.U8 q0,q0,q0 uint16x8_t vmaxq_u16(uint16x8_t a, uint16x8_t b); // VMAX.U16 q0,q0,q0uint32x4_t vmaxq_u32(uint32x4_t a, uint32x4_t b); // VMAX.U32 q0,q0,q0float32x4_t vmaxq_f32(float32x4_t a, float32x4_t b); // VMAX.F32 q0,q0,q0

vmin -> Vr[i] := (Va[i] >= Vb[i]) ? Vb[i] : Va[i]

int8x8_t vmin_s8(int8x8_t a, int8x8_t b); // VMIN.S8 d0,d0,d0 int16x4_t vmin_s16(int16x4_t a, int16x4_t b); // VMIN.S16 d0,d0,d0int32x2_t vmin_s32(int32x2_t a, int32x2_t b); // VMIN.S32 d0,d0,d0uint8x8_t vmin_u8(uint8x8_t a, uint8x8_t b); // VMIN.U8 d0,d0,d0 uint16x4_t vmin_u16(uint16x4_t a, uint16x4_t b); // VMIN.U16 d0,d0,d0uint32x2_t vmin_u32(uint32x2_t a, uint32x2_t b); // VMIN.U32 d0,d0,d0float32x2_t vmin_f32(float32x2_t a, float32x2_t b); // VMIN.F32 d0,d0,d0int8x16_t vminq_s8(int8x16_t a, int8x16_t b); // VMIN.S8 q0,q0,q0 int16x8_t vminq_s16(int16x8_t a, int16x8_t b); // VMIN.S16 q0,q0,q0int32x4_t vminq_s32(int32x4_t a, int32x4_t b); // VMIN.S32 q0,q0,q0


NEON 지원 사용

uint8x16_t vminq_u8(uint8x16_t a, uint8x16_t b); // VMIN.U8 q0,q0,q0 uint16x8_t vminq_u16(uint16x8_t a, uint16x8_t b); // VMIN.U16 q0,q0,q0uint32x4_t vminq_u32(uint32x4_t a, uint32x4_t b); // VMIN.U32 q0,q0,q0float32x4_t vminq_f32(float32x4_t a, float32x4_t b); // VMIN.F32 q0,q0,q0

E.3.7 인접 쌍 더하기

다음 내장 함수는 인접 쌍 더하기 연산을 제공합니다.

인접 쌍 더하기

int8x8_t vpadd_s8(int8x8_t a, int8x8_t b); // VPADD.I8 d0,d0,d0 int16x4_t vpadd_s16(int16x4_t a, int16x4_t b); // VPADD.I16 d0,d0,d0int32x2_t vpadd_s32(int32x2_t a, int32x2_t b); // VPADD.I32 d0,d0,d0uint8x8_t vpadd_u8(uint8x8_t a, uint8x8_t b); // VPADD.I8 d0,d0,d0 uint16x4_t vpadd_u16(uint16x4_t a, uint16x4_t b); // VPADD.I16 d0,d0,d0uint32x2_t vpadd_u32(uint32x2_t a, uint32x2_t b); // VPADD.I32 d0,d0,d0float32x2_t vpadd_f32(float32x2_t a, float32x2_t b); // VPADD.F32 d0,d0,d0

Long 인접 쌍 더하기

int16x4_t vpaddl_s8(int8x8_t a); // VPADDL.S8 d0,d0 int32x2_t vpaddl_s16(int16x4_t a); // VPADDL.S16 d0,d0int64x1_t vpaddl_s32(int32x2_t a); // VPADDL.S32 d0,d0uint16x4_t vpaddl_u8(uint8x8_t a); // VPADDL.U8 d0,d0 uint32x2_t vpaddl_u16(uint16x4_t a); // VPADDL.U16 d0,d0uint64x1_t vpaddl_u32(uint32x2_t a); // VPADDL.U32 d0,d0int16x8_t vpaddlq_s8(int8x16_t a); // VPADDL.S8 q0,q0 int32x4_t vpaddlq_s16(int16x8_t a); // VPADDL.S16 q0,q0int64x2_t vpaddlq_s32(int32x4_t a); // VPADDL.S32 q0,q0uint16x8_t vpaddlq_u8(uint8x16_t a); // VPADDL.U8 q0,q0 uint32x4_t vpaddlq_u16(uint16x8_t a); // VPADDL.U16 q0,q0uint64x2_t vpaddlq_u32(uint32x4_t a); // VPADDL.U32 q0,q0

Long 인접 쌍 더하기 및 누산

int16x4_t vpadal_s8(int16x4_t a, int8x8_t b); // VPADAL.S8 d0,d0 int32x2_t vpadal_s16(int32x2_t a, int16x4_t b); // VPADAL.S16 d0,d0int64x1_t vpadal_s32(int64x1_t a, int32x2_t b); // VPADAL.S32 d0,d0uint16x4_t vpadal_u8(uint16x4_t a, uint8x8_t b); // VPADAL.U8 d0,d0 uint32x2_t vpadal_u16(uint32x2_t a, uint16x4_t b); // VPADAL.U16 d0,d0uint64x1_t vpadal_u32(uint64x1_t a, uint32x2_t b); // VPADAL.U32 d0,d0int16x8_t vpadalq_s8(int16x8_t a, int8x16_t b); // VPADAL.S8 q0,q0 int32x4_t vpadalq_s16(int32x4_t a, int16x8_t b); // VPADAL.S16 q0,q0int64x2_t vpadalq_s32(int64x2_t a, int32x4_t b); // VPADAL.S32 q0,q0


NEON 지원 사용

uint16x8_t vpadalq_u8(uint16x8_t a, uint8x16_t b); // VPADAL.U8 q0,q0 uint32x4_t vpadalq_u16(uint32x4_t a, uint16x8_t b); // VPADAL.U16 q0,q0uint64x2_t vpadalq_u32(uint64x2_t a, uint32x4_t b); // VPADAL.U32 q0,q0

E.3.8 최대값 폴딩

vpmax -> 인접 쌍의 최대값을 취합니다.

int8x8_t vpmax_s8(int8x8_t a, int8x8_t b); // VPMAX.S8 d0,d0,d0 int16x4_t vpmax_s16(int16x4_t a, int16x4_t b); // VPMAX.S16 d0,d0,d0int32x2_t vpmax_s32(int32x2_t a, int32x2_t b); // VPMAX.S32 d0,d0,d0uint8x8_t vpmax_u8(uint8x8_t a, uint8x8_t b); // VPMAX.U8 d0,d0,d0 uint16x4_t vpmax_u16(uint16x4_t a, uint16x4_t b); // VPMAX.U16 d0,d0,d0uint32x2_t vpmax_u32(uint32x2_t a, uint32x2_t b); // VPMAX.U32 d0,d0,d0float32x2_t vpmax_f32(float32x2_t a, float32x2_t b); // VPMAX.F32 d0,d0,d0

E.3.9 최소값 폴딩

vpmin -> 인접 쌍의 최소값을 취합니다.

int8x8_t vpmin_s8(int8x8_t a, int8x8_t b); // VPMIN.S8 d0,d0,d0 int16x4_t vpmin_s16(int16x4_t a, int16x4_t b); // VPMIN.S16 d0,d0,d0int32x2_t vpmin_s32(int32x2_t a, int32x2_t b); // VPMIN.S32 d0,d0,d0uint8x8_t vpmin_u8(uint8x8_t a, uint8x8_t b); // VPMIN.U8 d0,d0,d0 uint16x4_t vpmin_u16(uint16x4_t a, uint16x4_t b); // VPMIN.U16 d0,d0,d0uint32x2_t vpmin_u32(uint32x2_t a, uint32x2_t b); // VPMIN.U32 d0,d0,d0float32x2_t vpmin_f32(float32x2_t a, float32x2_t b); // VPMIN.F32 d0,d0,d0

E.3.10 역수/Sqrt

역수 추정/단계 및 1/sqrt 추정/단계

float32x2_t vrecps_f32(float32x2_t a, float32x2_t b); // VRECPS.F32 d0, d0, d0 float32x4_t vrecpsq_f32(float32x4_t a, float32x4_t b); // VRECPS.F32 q0, q0, q0 float32x2_t vrsqrts_f32(float32x2_t a, float32x2_t b); // VRSQRTS.F32 d0, d0, d0float32x4_t vrsqrtsq_f32(float32x4_t a, float32x4_t b); // VRSQRTS.F32 q0, q0, q0

E.3.11 부호 있는 변수 기준 시프트

다음 내장 함수는 부호 있는 변수 기준 시프트를 포함하는 연산을 제공합니다.

벡터 왼쪽으로 시프트: Vr[i] := Va[i] << Vb[i] (음수 값은 오른쪽으로 시프트)

int8x8_t vshl_s8(int8x8_t a, int8x8_t b); // VSHL.S8 d0,d0,d0 int16x4_t vshl_s16(int16x4_t a, int16x4_t b); // VSHL.S16 d0,d0,d0int32x2_t vshl_s32(int32x2_t a, int32x2_t b); // VSHL.S32 d0,d0,d0


NEON 지원 사용

int64x1_t vshl_s64(int64x1_t a, int64x1_t b); // VSHL.S64 d0,d0,d0uint8x8_t vshl_u8(uint8x8_t a, int8x8_t b); // VSHL.U8 d0,d0,d0 uint16x4_t vshl_u16(uint16x4_t a, int16x4_t b); // VSHL.U16 d0,d0,d0uint32x2_t vshl_u32(uint32x2_t a, int32x2_t b); // VSHL.U32 d0,d0,d0uint64x1_t vshl_u64(uint64x1_t a, int64x1_t b); // VSHL.U64 d0,d0,d0int8x16_t vshlq_s8(int8x16_t a, int8x16_t b); // VSHL.S8 q0,q0,q0 int16x8_t vshlq_s16(int16x8_t a, int16x8_t b); // VSHL.S16 q0,q0,q0int32x4_t vshlq_s32(int32x4_t a, int32x4_t b); // VSHL.S32 q0,q0,q0int64x2_t vshlq_s64(int64x2_t a, int64x2_t b); // VSHL.S64 q0,q0,q0uint8x16_t vshlq_u8(uint8x16_t a, int8x16_t b); // VSHL.U8 q0,q0,q0 uint16x8_t vshlq_u16(uint16x8_t a, int16x8_t b); // VSHL.U16 q0,q0,q0uint32x4_t vshlq_u32(uint32x4_t a, int32x4_t b); // VSHL.U32 q0,q0,q0uint64x2_t vshlq_u64(uint64x2_t a, int64x2_t b); // VSHL.U64 q0,q0,q0

벡터 포화 왼쪽으로 시프트: (음수 값은 오른쪽으로 시프트)

int8x8_t vqshl_s8(int8x8_t a, int8x8_t b); // VQSHL.S8 d0,d0,d0 int16x4_t vqshl_s16(int16x4_t a, int16x4_t b); // VQSHL.S16 d0,d0,d0int32x2_t vqshl_s32(int32x2_t a, int32x2_t b); // VQSHL.S32 d0,d0,d0int64x1_t vqshl_s64(int64x1_t a, int64x1_t b); // VQSHL.S64 d0,d0,d0uint8x8_t vqshl_u8(uint8x8_t a, int8x8_t b); // VQSHL.U8 d0,d0,d0 uint16x4_t vqshl_u16(uint16x4_t a, int16x4_t b); // VQSHL.U16 d0,d0,d0uint32x2_t vqshl_u32(uint32x2_t a, int32x2_t b); // VQSHL.U32 d0,d0,d0uint64x1_t vqshl_u64(uint64x1_t a, int64x1_t b); // VQSHL.U64 d0,d0,d0int8x16_t vqshlq_s8(int8x16_t a, int8x16_t b); // VQSHL.S8 q0,q0,q0 int16x8_t vqshlq_s16(int16x8_t a, int16x8_t b); // VQSHL.S16 q0,q0,q0int32x4_t vqshlq_s32(int32x4_t a, int32x4_t b); // VQSHL.S32 q0,q0,q0int64x2_t vqshlq_s64(int64x2_t a, int64x2_t b); // VQSHL.S64 q0,q0,q0uint8x16_t vqshlq_u8(uint8x16_t a, int8x16_t b); // VQSHL.U8 q0,q0,q0 uint16x8_t vqshlq_u16(uint16x8_t a, int16x8_t b); // VQSHL.U16 q0,q0,q0uint32x4_t vqshlq_u32(uint32x4_t a, int32x4_t b); // VQSHL.U32 q0,q0,q0uint64x2_t vqshlq_u64(uint64x2_t a, int64x2_t b); // VQSHL.U64 q0,q0,q0

벡터 반올림 왼쪽으로 시프트: (음수 값은 오른쪽으로 시프트)

int8x8_t vrshl_s8(int8x8_t a, int8x8_t b); // VRSHL.S8 d0,d0,d0 int16x4_t vrshl_s16(int16x4_t a, int16x4_t b); // VRSHL.S16 d0,d0,d0int32x2_t vrshl_s32(int32x2_t a, int32x2_t b); // VRSHL.S32 d0,d0,d0int64x1_t vrshl_s64(int64x1_t a, int64x1_t b); // VRSHL.S64 d0,d0,d0uint8x8_t vrshl_u8(uint8x8_t a, int8x8_t b); // VRSHL.U8 d0,d0,d0 uint16x4_t vrshl_u16(uint16x4_t a, int16x4_t b); // VRSHL.U16 d0,d0,d0uint32x2_t vrshl_u32(uint32x2_t a, int32x2_t b); // VRSHL.U32 d0,d0,d0uint64x1_t vrshl_u64(uint64x1_t a, int64x1_t b); // VRSHL.U64 d0,d0,d0int8x16_t vrshlq_s8(int8x16_t a, int8x16_t b); // VRSHL.S8 q0,q0,q0 int16x8_t vrshlq_s16(int16x8_t a, int16x8_t b); // VRSHL.S16 q0,q0,q0int32x4_t vrshlq_s32(int32x4_t a, int32x4_t b); // VRSHL.S32 q0,q0,q0int64x2_t vrshlq_s64(int64x2_t a, int64x2_t b); // VRSHL.S64 q0,q0,q0uint8x16_t vrshlq_u8(uint8x16_t a, int8x16_t b); // VRSHL.U8 q0,q0,q0


NEON 지원 사용

uint16x8_t vrshlq_u16(uint16x8_t a, int16x8_t b); // VRSHL.U16 q0,q0,q0uint32x4_t vrshlq_u32(uint32x4_t a, int32x4_t b); // VRSHL.U32 q0,q0,q0uint64x2_t vrshlq_u64(uint64x2_t a, int64x2_t b); // VRSHL.U64 q0,q0,q0

벡터 포화 반올림 왼쪽으로 시프트: (음수 값은 오른쪽으로 시프트)

int8x8_t vqrshl_s8(int8x8_t a, int8x8_t b); // VQRSHL.S8 d0,d0,d0 int16x4_t vqrshl_s16(int16x4_t a, int16x4_t b); // VQRSHL.S16 d0,d0,d0int32x2_t vqrshl_s32(int32x2_t a, int32x2_t b); // VQRSHL.S32 d0,d0,d0int64x1_t vqrshl_s64(int64x1_t a, int64x1_t b); // VQRSHL.S64 d0,d0,d0uint8x8_t vqrshl_u8(uint8x8_t a, int8x8_t b); // VQRSHL.U8 d0,d0,d0 uint16x4_t vqrshl_u16(uint16x4_t a, int16x4_t b); // VQRSHL.U16 d0,d0,d0uint32x2_t vqrshl_u32(uint32x2_t a, int32x2_t b); // VQRSHL.U32 d0,d0,d0uint64x1_t vqrshl_u64(uint64x1_t a, int64x1_t b); // VQRSHL.U64 d0,d0,d0int8x16_t vqrshlq_s8(int8x16_t a, int8x16_t b); // VQRSHL.S8 q0,q0,q0 int16x8_t vqrshlq_s16(int16x8_t a, int16x8_t b); // VQRSHL.S16 q0,q0,q0int32x4_t vqrshlq_s32(int32x4_t a, int32x4_t b); // VQRSHL.S32 q0,q0,q0int64x2_t vqrshlq_s64(int64x2_t a, int64x2_t b); // VQRSHL.S64 q0,q0,q0uint8x16_t vqrshlq_u8(uint8x16_t a, int8x16_t b); // VQRSHL.U8 q0,q0,q0 uint16x8_t vqrshlq_u16(uint16x8_t a, int16x8_t b); // VQRSHL.U16 q0,q0,q0uint32x4_t vqrshlq_u32(uint32x4_t a, int32x4_t b); // VQRSHL.U32 q0,q0,q0uint64x2_t vqrshlq_u64(uint64x2_t a, int64x2_t b); // VQRSHL.U64 q0,q0,q0

E.3.12 상수 기준 시프트

다음 내장 함수는 상수 기준 시프트에 대한 연산을 제공합니다.

상수 기준 벡터 오른쪽으로 시프트

int8x8_t vshr_n_s8(int8x8_t a, __constrange(1,8) int b); // VSHR.S8 d0,d0,#8 int16x4_t vshr_n_s16(int16x4_t a, __constrange(1,16) int b); // VSHR.S16 d0,d0,#16int32x2_t vshr_n_s32(int32x2_t a, __constrange(1,32) int b); // VSHR.S32 d0,d0,#32int64x1_t vshr_n_s64(int64x1_t a, __constrange(1,64) int b); // VSHR.S64 d0,d0,#64uint8x8_t vshr_n_u8(uint8x8_t a, __constrange(1,8) int b); // VSHR.U8 d0,d0,#8 uint16x4_t vshr_n_u16(uint16x4_t a, __constrange(1,16) int b); // VSHR.U16 d0,d0,#16uint32x2_t vshr_n_u32(uint32x2_t a, __constrange(1,32) int b); // VSHR.U32 d0,d0,#32uint64x1_t vshr_n_u64(uint64x1_t a, __constrange(1,64) int b); // VSHR.U64 d0,d0,#64int8x16_t vshrq_n_s8(int8x16_t a, __constrange(1,8) int b); // VSHR.S8 q0,q0,#8 int16x8_t vshrq_n_s16(int16x8_t a, __constrange(1,16) int b); // VSHR.S16 q0,q0,#16int32x4_t vshrq_n_s32(int32x4_t a, __constrange(1,32) int b); // VSHR.S32 q0,q0,#32int64x2_t vshrq_n_s64(int64x2_t a, __constrange(1,64) int b); // VSHR.S64 q0,q0,#64uint8x16_t vshrq_n_u8(uint8x16_t a, __constrange(1,8) int b); // VSHR.U8 q0,q0,#8 uint16x8_t vshrq_n_u16(uint16x8_t a, __constrange(1,16) int b); // VSHR.U16 q0,q0,#16uint32x4_t vshrq_n_u32(uint32x4_t a, __constrange(1,32) int b); // VSHR.U32 q0,q0,#32uint64x2_t vshrq_n_u64(uint64x2_t a, __constrange(1,64) int b); // VSHR.U64 q0,q0,#64


NEON 지원 사용

상수 기준 벡터 왼쪽으로 시프트

int8x8_t vshl_n_s8(int8x8_t a, __constrange(0,7) int b); // VSHL.I8 d0,d0,#0 int16x4_t vshl_n_s16(int16x4_t a, __constrange(0,15) int b); // VSHL.I16 d0,d0,#0int32x2_t vshl_n_s32(int32x2_t a, __constrange(0,31) int b); // VSHL.I32 d0,d0,#0int64x1_t vshl_n_s64(int64x1_t a, __constrange(0,63) int b); // VSHL.I64 d0,d0,#0uint8x8_t vshl_n_u8(uint8x8_t a, __constrange(0,7) int b); // VSHL.I8 d0,d0,#0 uint16x4_t vshl_n_u16(uint16x4_t a, __constrange(0,15) int b); // VSHL.I16 d0,d0,#0uint32x2_t vshl_n_u32(uint32x2_t a, __constrange(0,31) int b); // VSHL.I32 d0,d0,#0uint64x1_t vshl_n_u64(uint64x1_t a, __constrange(0,63) int b); // VSHL.I64 d0,d0,#0int8x16_t vshlq_n_s8(int8x16_t a, __constrange(0,7) int b); // VSHL.I8 q0,q0,#0 int16x8_t vshlq_n_s16(int16x8_t a, __constrange(0,15) int b); // VSHL.I16 q0,q0,#0int32x4_t vshlq_n_s32(int32x4_t a, __constrange(0,31) int b); // VSHL.I32 q0,q0,#0int64x2_t vshlq_n_s64(int64x2_t a, __constrange(0,63) int b); // VSHL.I64 q0,q0,#0uint8x16_t vshlq_n_u8(uint8x16_t a, __constrange(0,7) int b); // VSHL.I8 q0,q0,#0 uint16x8_t vshlq_n_u16(uint16x8_t a, __constrange(0,15) int b); // VSHL.I16 q0,q0,#0uint32x4_t vshlq_n_u32(uint32x4_t a, __constrange(0,31) int b); // VSHL.I32 q0,q0,#0uint64x2_t vshlq_n_u64(uint64x2_t a, __constrange(0,63) int b); // VSHL.I64 q0,q0,#0

상수 기준 벡터 반올림 오른쪽으로 시프트

int8x8_t vrshr_n_s8(int8x8_t a, __constrange(1,8) int b); // VRSHR.S8 d0,d0,#8 int16x4_t vrshr_n_s16(int16x4_t a, __constrange(1,16) int b); // VRSHR.S16 d0,d0,#16int32x2_t vrshr_n_s32(int32x2_t a, __constrange(1,32) int b); // VRSHR.S32 d0,d0,#32int64x1_t vrshr_n_s64(int64x1_t a, __constrange(1,64) int b); // VRSHR.S64 d0,d0,#64uint8x8_t vrshr_n_u8(uint8x8_t a, __constrange(1,8) int b); // VRSHR.U8 d0,d0,#8 uint16x4_t vrshr_n_u16(uint16x4_t a, __constrange(1,16) int b); // VRSHR.U16 d0,d0,#16uint32x2_t vrshr_n_u32(uint32x2_t a, __constrange(1,32) int b); // VRSHR.U32 d0,d0,#32uint64x1_t vrshr_n_u64(uint64x1_t a, __constrange(1,64) int b); // VRSHR.U64 d0,d0,#64int8x16_t vrshrq_n_s8(int8x16_t a, __constrange(1,8) int b); // VRSHR.S8 q0,q0,#8 int16x8_t vrshrq_n_s16(int16x8_t a, __constrange(1,16) int b); // VRSHR.S16 q0,q0,#16int32x4_t vrshrq_n_s32(int32x4_t a, __constrange(1,32) int b); // VRSHR.S32 q0,q0,#32int64x2_t vrshrq_n_s64(int64x2_t a, __constrange(1,64) int b); // VRSHR.S64 q0,q0,#64uint8x16_t vrshrq_n_u8(uint8x16_t a, __constrange(1,8) int b); // VRSHR.U8 q0,q0,#8 uint16x8_t vrshrq_n_u16(uint16x8_t a, __constrange(1,16) int b); // VRSHR.U16 q0,q0,#16uint32x4_t vrshrq_n_u32(uint32x4_t a, __constrange(1,32) int b); // VRSHR.U32 q0,q0,#32uint64x2_t vrshrq_n_u64(uint64x2_t a, __constrange(1,64) int b); // VRSHR.U64 q0,q0,#64

상수 및 누산 기준 벡터 오른쪽으로 시프트

int8x8_t vsra_n_s8(int8x8_t a, int8x8_t b, __constrange(1,8) int c); // VSRA.S8 d0,d0,#8 int16x4_t vsra_n_s16(int16x4_t a, int16x4_t b, __constrange(1,16) int c); // VSRA.S16 d0,d0,#16int32x2_t vsra_n_s32(int32x2_t a, int32x2_t b, __constrange(1,32) int c); // VSRA.S32 d0,d0,#32int64x1_t vsra_n_s64(int64x1_t a, int64x1_t b, __constrange(1,64) int c); // VSRA.S64 d0,d0,#64uint8x8_t vsra_n_u8(uint8x8_t a, uint8x8_t b, __constrange(1,8) int c); // VSRA.U8 d0,d0,#8 uint16x4_t vsra_n_u16(uint16x4_t a, uint16x4_t b, __constrange(1,16) int c); // VSRA.U16 d0,d0,#16uint32x2_t vsra_n_u32(uint32x2_t a, uint32x2_t b, __constrange(1,32) int c); // VSRA.U32 d0,d0,#32uint64x1_t vsra_n_u64(uint64x1_t a, uint64x1_t b, __constrange(1,64) int c); // VSRA.U64 d0,d0,#64


NEON 지원 사용

int8x16_t vsraq_n_s8(int8x16_t a, int8x16_t b, __constrange(1,8) int c); // VSRA.S8 q0,q0,#8 int16x8_t vsraq_n_s16(int16x8_t a, int16x8_t b, __constrange(1,16) int c); // VSRA.S16 q0,q0,#16int32x4_t vsraq_n_s32(int32x4_t a, int32x4_t b, __constrange(1,32) int c); // VSRA.S32 q0,q0,#32int64x2_t vsraq_n_s64(int64x2_t a, int64x2_t b, __constrange(1,64) int c); // VSRA.S64 q0,q0,#64uint8x16_t vsraq_n_u8(uint8x16_t a, uint8x16_t b, __constrange(1,8) int c); // VSRA.U8 q0,q0,#8 uint16x8_t vsraq_n_u16(uint16x8_t a, uint16x8_t b, __constrange(1,16) int c); // VSRA.U16 q0,q0,#16uint32x4_t vsraq_n_u32(uint32x4_t a, uint32x4_t b, __constrange(1,32) int c); // VSRA.U32 q0,q0,#32uint64x2_t vsraq_n_u64(uint64x2_t a, uint64x2_t b, __constrange(1,64) int c); // VSRA.U64 q0,q0,#64

상수 및 누산 기준 벡터 반올림 오른쪽으로 시프트

int8x8_t vrsra_n_s8(int8x8_t a, int8x8_t b, __constrange(1,8) int c); // VRSRA.S8 d0,d0,#8 int16x4_t vrsra_n_s16(int16x4_t a, int16x4_t b, __constrange(1,16) int c); // VRSRA.S16 d0,d0,#16int32x2_t vrsra_n_s32(int32x2_t a, int32x2_t b, __constrange(1,32) int c); // VRSRA.S32 d0,d0,#32int64x1_t vrsra_n_s64(int64x1_t a, int64x1_t b, __constrange(1,64) int c); // VRSRA.S64 d0,d0,#64uint8x8_t vrsra_n_u8(uint8x8_t a, uint8x8_t b, __constrange(1,8) int c); // VRSRA.U8 d0,d0,#8 uint16x4_t vrsra_n_u16(uint16x4_t a, uint16x4_t b, __constrange(1,16) int c); // VRSRA.U16 d0,d0,#16uint32x2_t vrsra_n_u32(uint32x2_t a, uint32x2_t b, __constrange(1,32) int c); // VRSRA.U32 d0,d0,#32uint64x1_t vrsra_n_u64(uint64x1_t a, uint64x1_t b, __constrange(1,64) int c); // VRSRA.U64 d0,d0,#64int8x16_t vrsraq_n_s8(int8x16_t a, int8x16_t b, __constrange(1,8) int c); // VRSRA.S8 q0,q0,#8 int16x8_t vrsraq_n_s16(int16x8_t a, int16x8_t b, __constrange(1,16) int c); // VRSRA.S16 q0,q0,#16int32x4_t vrsraq_n_s32(int32x4_t a, int32x4_t b, __constrange(1,32) int c); // VRSRA.S32 q0,q0,#32int64x2_t vrsraq_n_s64(int64x2_t a, int64x2_t b, __constrange(1,64) int c); // VRSRA.S64 q0,q0,#64uint8x16_t vrsraq_n_u8(uint8x16_t a, uint8x16_t b, __constrange(1,8) int c); // VRSRA.U8 q0,q0,#8 uint16x8_t vrsraq_n_u16(uint16x8_t a, uint16x8_t b, __constrange(1,16) int c); // VRSRA.U16 q0,q0,#16uint32x4_t vrsraq_n_u32(uint32x4_t a, uint32x4_t b, __constrange(1,32) int c); // VRSRA.U32 q0,q0,#32uint64x2_t vrsraq_n_u64(uint64x2_t a, uint64x2_t b, __constrange(1,64) int c); // VRSRA.U64 q0,q0,#64

상수 기준 벡터 포화 왼쪽으로 시프트

int8x8_t vqshl_n_s8(int8x8_t a, __constrange(0,7) int b); // VQSHL.S8 d0,d0,#0 int16x4_t vqshl_n_s16(int16x4_t a, __constrange(0,15) int b); // VQSHL.S16 d0,d0,#0int32x2_t vqshl_n_s32(int32x2_t a, __constrange(0,31) int b); // VQSHL.S32 d0,d0,#0int64x1_t vqshl_n_s64(int64x1_t a, __constrange(0,63) int b); // VQSHL.S64 d0,d0,#0uint8x8_t vqshl_n_u8(uint8x8_t a, __constrange(0,7) int b); // VQSHL.U8 d0,d0,#0 uint16x4_t vqshl_n_u16(uint16x4_t a, __constrange(0,15) int b); // VQSHL.U16 d0,d0,#0uint32x2_t vqshl_n_u32(uint32x2_t a, __constrange(0,31) int b); // VQSHL.U32 d0,d0,#0uint64x1_t vqshl_n_u64(uint64x1_t a, __constrange(0,63) int b); // VQSHL.U64 d0,d0,#0int8x16_t vqshlq_n_s8(int8x16_t a, __constrange(0,7) int b); // VQSHL.S8 q0,q0,#0 int16x8_t vqshlq_n_s16(int16x8_t a, __constrange(0,15) int b); // VQSHL.S16 q0,q0,#0int32x4_t vqshlq_n_s32(int32x4_t a, __constrange(0,31) int b); // VQSHL.S32 q0,q0,#0int64x2_t vqshlq_n_s64(int64x2_t a, __constrange(0,63) int b); // VQSHL.S64 q0,q0,#0uint8x16_t vqshlq_n_u8(uint8x16_t a, __constrange(0,7) int b); // VQSHL.U8 q0,q0,#0 uint16x8_t vqshlq_n_u16(uint16x8_t a, __constrange(0,15) int b); // VQSHL.U16 q0,q0,#0uint32x4_t vqshlq_n_u32(uint32x4_t a, __constrange(0,31) int b); // VQSHL.U32 q0,q0,#0uint64x2_t vqshlq_n_u64(uint64x2_t a, __constrange(0,63) int b); // VQSHL.U64 q0,q0,#0


NEON 지원 사용

상수 기준 부호 있는- >부호 없는 벡터 포화 왼쪽으로 시프트

uint8x8_t vqshlu_n_s8(int8x8_t a, __constrange(0,7) int b); // VQSHLU.S8 d0,d0,#0 uint16x4_t vqshlu_n_s16(int16x4_t a, __constrange(0,15) int b); // VQSHLU.S16 d0,d0,#0uint32x2_t vqshlu_n_s32(int32x2_t a, __constrange(0,31) int b); // VQSHLU.S32 d0,d0,#0uint64x1_t vqshlu_n_s64(int64x1_t a, __constrange(0,63) int b); // VQSHLU.S64 d0,d0,#0uint8x16_t vqshluq_n_s8(int8x16_t a, __constrange(0,7) int b); // VQSHLU.S8 q0,q0,#0 uint16x8_t vqshluq_n_s16(int16x8_t a, __constrange(0,15) int b); // VQSHLU.S16 q0,q0,#0uint32x4_t vqshluq_n_s32(int32x4_t a, __constrange(0,31) int b); // VQSHLU.S32 q0,q0,#0uint64x2_t vqshluq_n_s64(int64x2_t a, __constrange(0,63) int b); // VQSHLU.S64 q0,q0,#0

상수 기준 벡터 축소 포화 오른쪽으로 시프트

int8x8_t vshrn_n_s16(int16x8_t a, __constrange(1,8) int b); // VSHRN.I16 d0,q0,#8 int16x4_t vshrn_n_s32(int32x4_t a, __constrange(1,16) int b); // VSHRN.I32 d0,q0,#16int32x2_t vshrn_n_s64(int64x2_t a, __constrange(1,32) int b); // VSHRN.I64 d0,q0,#32uint8x8_t vshrn_n_u16(uint16x8_t a, __constrange(1,8) int b); // VSHRN.I16 d0,q0,#8 uint16x4_t vshrn_n_u32(uint32x4_t a, __constrange(1,16) int b); // VSHRN.I32 d0,q0,#16uint32x2_t vshrn_n_u64(uint64x2_t a, __constrange(1,32) int b); // VSHRN.I64 d0,q0,#32

상수 기준 부호 있는- >부호 없는 벡터 축소 포화 오른쪽으로 시프트

uint8x8_t vqshrun_n_s16(int16x8_t a, __constrange(1,8) int b); // VQSHRUN.S16 d0,q0,#8 uint16x4_t vqshrun_n_s32(int32x4_t a, __constrange(1,16) int b); // VQSHRUN.S32 d0,q0,#16uint32x2_t vqshrun_n_s64(int64x2_t a, __constrange(1,32) int b); // VQSHRUN.S64 d0,q0,#32

상수 기준 부호 있는- >부호 없는 벡터 반올림 축소 포화 오른쪽으로 시프트

uint8x8_t vqrshrun_n_s16(int16x8_t a, __constrange(1,8) int b); // VQRSHRUN.S16 d0,q0,#8 uint16x4_t vqrshrun_n_s32(int32x4_t a, __constrange(1,16) int b); // VQRSHRUN.S32 d0,q0,#16uint32x2_t vqrshrun_n_s64(int64x2_t a, __constrange(1,32) int b); // VQRSHRUN.S64 d0,q0,#32

상수 기준 벡터 축소 포화 오른쪽으로 시프트

int8x8_t vqshrn_n_s16(int16x8_t a, __constrange(1,8) int b); // VQSHRN.S16 d0,q0,#8 int16x4_t vqshrn_n_s32(int32x4_t a, __constrange(1,16) int b); // VQSHRN.S32 d0,q0,#16int32x2_t vqshrn_n_s64(int64x2_t a, __constrange(1,32) int b); // VQSHRN.S64 d0,q0,#32uint8x8_t vqshrn_n_u16(uint16x8_t a, __constrange(1,8) int b); // VQSHRN.U16 d0,q0,#8 uint16x4_t vqshrn_n_u32(uint32x4_t a, __constrange(1,16) int b); // VQSHRN.U32 d0,q0,#16uint32x2_t vqshrn_n_u64(uint64x2_t a, __constrange(1,32) int b); // VQSHRN.U64 d0,q0,#32

상수 기준 벡터 반올림 축소 오른쪽으로 시프트

int8x8_t vrshrn_n_s16(int16x8_t a, __constrange(1,8) int b); // VRSHRN.I16 d0,q0,#8 int16x4_t vrshrn_n_s32(int32x4_t a, __constrange(1,16) int b); // VRSHRN.I32 d0,q0,#16int32x2_t vrshrn_n_s64(int64x2_t a, __constrange(1,32) int b); // VRSHRN.I64 d0,q0,#32uint8x8_t vrshrn_n_u16(uint16x8_t a, __constrange(1,8) int b); // VRSHRN.I16 d0,q0,#8


NEON 지원 사용

uint16x4_t vrshrn_n_u32(uint32x4_t a, __constrange(1,16) int b); // VRSHRN.I32 d0,q0,#16uint32x2_t vrshrn_n_u64(uint64x2_t a, __constrange(1,32) int b); // VRSHRN.I64 d0,q0,#32

상수 기준 벡터 반올림 축소 포화 오른쪽으로 시프트

int8x8_t vqrshrn_n_s16(int16x8_t a, __constrange(1,8) int b); // VQRSHRN.S16 d0,q0,#8 int16x4_t vqrshrn_n_s32(int32x4_t a, __constrange(1,16) int b); // VQRSHRN.S32 d0,q0,#16int32x2_t vqrshrn_n_s64(int64x2_t a, __constrange(1,32) int b); // VQRSHRN.S64 d0,q0,#32uint8x8_t vqrshrn_n_u16(uint16x8_t a, __constrange(1,8) int b); // VQRSHRN.U16 d0,q0,#8 uint16x4_t vqrshrn_n_u32(uint32x4_t a, __constrange(1,16) int b); // VQRSHRN.U32 d0,q0,#16uint32x2_t vqrshrn_n_u64(uint64x2_t a, __constrange(1,32) int b); // VQRSHRN.U64 d0,q0,#32

상수 기준 벡터 확장 왼쪽으로 시프트

int16x8_t vshll_n_s8(int8x8_t a, __constrange(0,8) int b); // VSHLL.S8 q0,d0,#0 int32x4_t vshll_n_s16(int16x4_t a, __constrange(0,16) int b); // VSHLL.S16 q0,d0,#0int64x2_t vshll_n_s32(int32x2_t a, __constrange(0,32) int b); // VSHLL.S32 q0,d0,#0uint16x8_t vshll_n_u8(uint8x8_t a, __constrange(0,8) int b); // VSHLL.U8 q0,d0,#0 uint32x4_t vshll_n_u16(uint16x4_t a, __constrange(0,16) int b); // VSHLL.U16 q0,d0,#0uint64x2_t vshll_n_u32(uint32x2_t a, __constrange(0,32) int b); // VSHLL.U32 q0,d0,#0

E.3.13 삽입하여 시프트

다음 내장 함수는 삽입하여 시프트를 포함하는 연산을 제공합니다.

벡터 오른쪽으로 시프트 및 삽입

int8x8_t vsri_n_s8(int8x8_t a, int8x8_t b, __constrange(1,8) int c); // VSRI.8 d0,d0,#8 int16x4_t vsri_n_s16(int16x4_t a, int16x4_t b, __constrange(1,16) int c); // VSRI.16 d0,d0,#16int32x2_t vsri_n_s32(int32x2_t a, int32x2_t b, __constrange(1,32) int c); // VSRI.32 d0,d0,#32int64x1_t vsri_n_s64(int64x1_t a, int64x1_t b, __constrange(1,64) int c); // VSRI.64 d0,d0,#64uint8x8_t vsri_n_u8(uint8x8_t a, uint8x8_t b, __constrange(1,8) int c); // VSRI.8 d0,d0,#8 uint16x4_t vsri_n_u16(uint16x4_t a, uint16x4_t b, __constrange(1,16) int c); // VSRI.16 d0,d0,#16uint32x2_t vsri_n_u32(uint32x2_t a, uint32x2_t b, __constrange(1,32) int c); // VSRI.32 d0,d0,#32uint64x1_t vsri_n_u64(uint64x1_t a, uint64x1_t b, __constrange(1,64) int c); // VSRI.64 d0,d0,#64poly8x8_t vsri_n_p8(poly8x8_t a, poly8x8_t b, __constrange(1,8) int c); // VSRI.8 d0,d0,#8poly16x4_t vsri_n_p16(poly16x4_t a, poly16x4_t b, __constrange(1,16) int c); // VSRI.16 d0,d0,#16int8x16_t vsriq_n_s8(int8x16_t a, int8x16_t b, __constrange(1,8) int c); // VSRI.8 q0,q0,#8 int16x8_t vsriq_n_s16(int16x8_t a, int16x8_t b, __constrange(1,16) int c); // VSRI.16 q0,q0,#16int32x4_t vsriq_n_s32(int32x4_t a, int32x4_t b, __constrange(1,32) int c); // VSRI.32 q0,q0,#32int64x2_t vsriq_n_s64(int64x2_t a, int64x2_t b, __constrange(1,64) int c); // VSRI.64 q0,q0,#64uint8x16_t vsriq_n_u8(uint8x16_t a, uint8x16_t b, __constrange(1,8) int c); // VSRI.8 q0,q0,#8 uint16x8_t vsriq_n_u16(uint16x8_t a, uint16x8_t b, __constrange(1,16) int c); // VSRI.16 q0,q0,#16uint32x4_t vsriq_n_u32(uint32x4_t a, uint32x4_t b, __constrange(1,32) int c); // VSRI.32 q0,q0,#32uint64x2_t vsriq_n_u64(uint64x2_t a, uint64x2_t b, __constrange(1,64) int c); // VSRI.64 q0,q0,#64


NEON 지원 사용

poly8x16_t vsriq_n_p8(poly8x16_t a, poly8x16_t b, __constrange(1,8) int c); // VSRI.8 q0,q0,#8poly16x8_t vsriq_n_p16(poly16x8_t a, poly16x8_t b, __constrange(1,16) int c); // VSRI.16 q0,q0,#16

벡터 왼쪽으로 시프트 및 삽입

int8x8_t vsli_n_s8(int8x8_t a, int8x8_t b, __constrange(0,7) int c); // VSLI.8 d0,d0,#0 int16x4_t vsli_n_s16(int16x4_t a, int16x4_t b, __constrange(0,15) int c); // VSLI.16 d0,d0,#0int32x2_t vsli_n_s32(int32x2_t a, int32x2_t b, __constrange(0,31) int c); // VSLI.32 d0,d0,#0int64x1_t vsli_n_s64(int64x1_t a, int64x1_t b, __constrange(0,63) int c); // VSLI.64 d0,d0,#0uint8x8_t vsli_n_u8(uint8x8_t a, uint8x8_t b, __constrange(0,7) int c); // VSLI.8 d0,d0,#0 uint16x4_t vsli_n_u16(uint16x4_t a, uint16x4_t b, __constrange(0,15) int c); // VSLI.16 d0,d0,#0uint32x2_t vsli_n_u32(uint32x2_t a, uint32x2_t b, __constrange(0,31) int c); // VSLI.32 d0,d0,#0uint64x1_t vsli_n_u64(uint64x1_t a, uint64x1_t b, __constrange(0,63) int c); // VSLI.64 d0,d0,#0poly8x8_t vsli_n_p8(poly8x8_t a, poly8x8_t b, __constrange(0,7) int c); // VSLI.8 d0,d0,#0poly16x4_t vsli_n_p16(poly16x4_t a, poly16x4_t b, __constrange(0,15) int c); // VSLI.16 d0,d0,#0int8x16_t vsliq_n_s8(int8x16_t a, int8x16_t b, __constrange(0,7) int c); // VSLI.8 q0,q0,#0 int16x8_t vsliq_n_s16(int16x8_t a, int16x8_t b, __constrange(0,15) int c); // VSLI.16 q0,q0,#0int32x4_t vsliq_n_s32(int32x4_t a, int32x4_t b, __constrange(0,31) int c); // VSLI.32 q0,q0,#0int64x2_t vsliq_n_s64(int64x2_t a, int64x2_t b, __constrange(0,63) int c); // VSLI.64 q0,q0,#0uint8x16_t vsliq_n_u8(uint8x16_t a, uint8x16_t b, __constrange(0,7) int c); // VSLI.8 q0,q0,#0 uint16x8_t vsliq_n_u16(uint16x8_t a, uint16x8_t b, __constrange(0,15) int c); // VSLI.16 q0,q0,#0uint32x4_t vsliq_n_u32(uint32x4_t a, uint32x4_t b, __constrange(0,31) int c); // VSLI.32 q0,q0,#0uint64x2_t vsliq_n_u64(uint64x2_t a, uint64x2_t b, __constrange(0,63) int c); // VSLI.64 q0,q0,#0poly8x16_t vsliq_n_p8(poly8x16_t a, poly8x16_t b, __constrange(0,7) int c); // VSLI.8 q0,q0,#0poly16x8_t vsliq_n_p16(poly16x8_t a, poly16x8_t b, __constrange(0,15) int c); // VSLI.16 q0,q0,#0

E.3.14 단일 벡터 로드 및 저장

일부 유형의 단일 벡터 로드 및 저장을 수행합니다.

uint8x16_t vld1q_u8(__transfersize(16) uint8_t const * ptr); // VLD1.8 {d0, d1}, [r0]uint16x8_t vld1q_u16(__transfersize(8) uint16_t const * ptr); // VLD1.16 {d0, d1}, [r0]uint32x4_t vld1q_u32(__transfersize(4) uint32_t const * ptr); // VLD1.32 {d0, d1}, [r0]uint64x2_t vld1q_u64(__transfersize(2) uint64_t const * ptr); // VLD1.64 {d0, d1}, [r0]int8x16_t vld1q_s8(__transfersize(16) int8_t const * ptr); // VLD1.8 {d0, d1}, [r0]int16x8_t vld1q_s16(__transfersize(8) int16_t const * ptr); // VLD1.16 {d0, d1}, [r0]int32x4_t vld1q_s32(__transfersize(4) int32_t const * ptr); // VLD1.32 {d0, d1}, [r0]int64x2_t vld1q_s64(__transfersize(2) int64_t const * ptr); // VLD1.64 {d0, d1}, [r0]float16x8_t vld1q_f16(__transfersize(8) __fp16 const * ptr); // VLD1.16 {d0, d1}, [r0]


NEON 지원 사용

float32x4_t vld1q_f32(__transfersize(4) float32_t const * ptr); // VLD1.32 {d0, d1}, [r0]poly8x16_t vld1q_p8(__transfersize(16) poly8_t const * ptr); // VLD1.8 {d0, d1}, [r0]poly16x8_t vld1q_p16(__transfersize(8) poly16_t const * ptr); // VLD1.16 {d0, d1}, [r0]uint8x8_t vld1_u8(__transfersize(8) uint8_t const * ptr); // VLD1.8 {d0}, [r0]uint16x4_t vld1_u16(__transfersize(4) uint16_t const * ptr); // VLD1.16 {d0}, [r0]uint32x2_t vld1_u32(__transfersize(2) uint32_t const * ptr); // VLD1.32 {d0}, [r0]uint64x1_t vld1_u64(__transfersize(1) uint64_t const * ptr); // VLD1.64 {d0}, [r0]int8x8_t vld1_s8(__transfersize(8) int8_t const * ptr); // VLD1.8 {d0}, [r0]int16x4_t vld1_s16(__transfersize(4) int16_t const * ptr); // VLD1.16 {d0}, [r0]int32x2_t vld1_s32(__transfersize(2) int32_t const * ptr); // VLD1.32 {d0}, [r0]int64x1_t vld1_s64(__transfersize(1) int64_t const * ptr); // VLD1.64 {d0}, [r0]float16x4_t vld1_f16(__transfersize(4) __fp16 const * ptr); // VLD1.16 {d0}, [r0]float32x2_t vld1_f32(__transfersize(2) float32_t const * ptr); // VLD1.32 {d0}, [r0]poly8x8_t vld1_p8(__transfersize(8) poly8_t const * ptr); // VLD1.8 {d0}, [r0]poly16x4_t vld1_p16(__transfersize(4) poly16_t const * ptr); // VLD1.16 {d0}, [r0]uint8x16_t vld1q_lane_u8(__transfersize(1) uint8_t const * ptr, uint8x16_t vec, __constrange(0,15) int lane);

// VLD1.8 {d0[0]}, [r0]uint16x8_t vld1q_lane_u16(__transfersize(1) uint16_t const * ptr, uint16x8_t vec, __constrange(0,7) int lane); // VLD1.16 {d0[0]}, [r0]uint32x4_t vld1q_lane_u32(__transfersize(1) uint32_t const * ptr, uint32x4_t vec, __constrange(0,3) int lane); // VLD1.32 {d0[0]}, [r0]uint64x2_t vld1q_lane_u64(__transfersize(1) uint64_t const * ptr, uint64x2_t vec, __constrange(0,1) int lane); // VLD1.64 {d0}, [r0]int8x16_t vld1q_lane_s8(__transfersize(1) int8_t const * ptr, int8x16_t vec, __constrange(0,15) int lane); // VLD1.8 {d0[0]}, [r0]int16x8_t vld1q_lane_s16(__transfersize(1) int16_t const * ptr, int16x8_t vec, __constrange(0,7) int lane); // VLD1.16 {d0[0]}, [r0]int32x4_t vld1q_lane_s32(__transfersize(1) int32_t const * ptr, int32x4_t vec, __constrange(0,3) int


NEON 지원 사용

lane); // VLD1.32 {d0[0]}, [r0]float16x4_t vld1q_lane_f16(__transfersize(1) __fp16 const * ptr, float16x4_t vec, __constrange(0,3) int lane); // VLD1.16 {d0[0]}, [r0]float16x8_t vld1q_lane_f16(__transfersize(1) __fp16 const * ptr, float16x8_t vec, __constrange(0,7) int lane); // VLD1.16 {d0[0]}, [r0]float32x4_t vld1q_lane_f32(__transfersize(1) float32_t const * ptr, float32x4_t vec, __constrange(0,3) int lane); // VLD1.32 {d0[0]}, [r0]int64x2_t vld1q_lane_s64(__transfersize(1) int64_t const * ptr, int64x2_t vec, __constrange(0,1) int lane); // VLD1.64 {d0}, [r0]poly8x16_t vld1q_lane_p8(__transfersize(1) poly8_t const * ptr, poly8x16_t vec, __constrange(0,15) int lane); // VLD1.8 {d0[0]}, [r0]poly16x8_t vld1q_lane_p16(__transfersize(1) poly16_t const * ptr, poly16x8_t vec, __constrange(0,7) int lane); // VLD1.16 {d0[0]}, [r0]uint8x8_t vld1_lane_u8(__transfersize(1) uint8_t const * ptr, uint8x8_t vec, __constrange(0,7) int lane); // VLD1.8 {d0[0]}, [r0]uint16x4_t vld1_lane_u16(__transfersize(1) uint16_t const * ptr, uint16x4_t vec, __constrange(0,3) int lane); // VLD1.16 {d0[0]}, [r0]uint32x2_t vld1_lane_u32(__transfersize(1) uint32_t const * ptr, uint32x2_t vec, __constrange(0,1) int lane); // VLD1.32 {d0[0]}, [r0]uint64x1_t vld1_lane_u64(__transfersize(1) uint64_t const * ptr, uint64x1_t vec, __constrange(0,0) int lane); // VLD1.64 {d0}, [r0]int8x8_t vld1_lane_s8(__transfersize(1) int8_t const * ptr, int8x8_t vec, __constrange(0,7) int lane);

// VLD1.8 {d0[0]}, [r0]int16x4_t vld1_lane_s16(__transfersize(1) int16_t const * ptr, int16x4_t vec, __constrange(0,3) int lane); // VLD1.16 {d0[0]}, [r0]int32x2_t vld1_lane_s32(__transfersize(1) int32_t const * ptr, int32x2_t vec, __constrange(0,1) int lane); // VLD1.32 {d0[0]}, [r0]float32x2_t vld1_lane_f32(__transfersize(1) float32_t const * ptr, float32x2_t vec, __constrange(0,1) int lane); // VLD1.32 {d0[0]}, [r0]int64x1_t vld1_lane_s64(__transfersize(1) int64_t const * ptr, int64x1_t vec, __constrange(0,0) int lane); // VLD1.64 {d0}, [r0]poly8x8_t vld1_lane_p8(__transfersize(1) poly8_t const * ptr, poly8x8_t vec, __constrange(0,7) int lane); // VLD1.8 {d0[0]}, [r0]


NEON 지원 사용

poly16x4_t vld1_lane_p16(__transfersize(1) poly16_t const * ptr, poly16x4_t vec, __constrange(0,3) int lane); // VLD1.16 {d0[0]}, [r0]uint8x16_t vld1q_dup_u8(__transfersize(1) uint8_t const * ptr); // VLD1.8 {d0[]}, [r0]uint16x8_t vld1q_dup_u16(__transfersize(1) uint16_t const * ptr); // VLD1.16 {d0[]}, [r0]uint32x4_t vld1q_dup_u32(__transfersize(1) uint32_t const * ptr); // VLD1.32 {d0[]}, [r0]uint64x2_t vld1q_dup_u64(__transfersize(1) uint64_t const * ptr); // VLD1.64 {d0}, [r0]int8x16_t vld1q_dup_s8(__transfersize(1) int8_t const * ptr); // VLD1.8 {d0[]}, [r0]int16x8_t vld1q_dup_s16(__transfersize(1) int16_t const * ptr); // VLD1.16 {d0[]}, [r0]int32x4_t vld1q_dup_s32(__transfersize(1) int32_t const * ptr); // VLD1.32 {d0[]}, [r0]int64x2_t vld1q_dup_s64(__transfersize(1) int64_t const * ptr); // VLD1.64 {d0}, [r0]float16x8_t vld1q_dup_f16(__transfersize(1) __fp16 const * ptr); // VLD1.16 {d0[]}, [r0]float32x4_t vld1q_dup_f32(__transfersize(1) float32_t const * ptr); // VLD1.32 {d0[]}, [r0]poly8x16_t vld1q_dup_p8(__transfersize(1) poly8_t const * ptr); // VLD1.8 {d0[]}, [r0]poly16x8_t vld1q_dup_p16(__transfersize(1) poly16_t const * ptr); // VLD1.16 {d0[]}, [r0]uint8x8_t vld1_dup_u8(__transfersize(1) uint8_t const * ptr); // VLD1.8 {d0[]}, [r0]uint16x4_t vld1_dup_u16(__transfersize(1) uint16_t const * ptr); // VLD1.16 {d0[]}, [r0]uint32x2_t vld1_dup_u32(__transfersize(1) uint32_t const * ptr); // VLD1.32 {d0[]}, [r0]uint64x1_t vld1_dup_u64(__transfersize(1) uint64_t const * ptr);

// VLD1.64 {d0}, [r0]int8x8_t vld1_dup_s8(__transfersize(1) int8_t const * ptr); // VLD1.8 {d0[]}, [r0]int16x4_t vld1_dup_s16(__transfersize(1) int16_t const * ptr); // VLD1.16 {d0[]}, [r0]int32x2_t vld1_dup_s32(__transfersize(1) int32_t const * ptr); // VLD1.32 {d0[]}, [r0]int64x1_t vld1_dup_s64(__transfersize(1) int64_t const * ptr); // VLD1.64 {d0}, [r0]float16x4_t vld1_dup_f16(__transfersize(1) __fp16 const * ptr); // VLD1.16 {d0[]}, [r0]float32x2_t vld1_dup_f32(__transfersize(1) float32_t const * ptr); // VLD1.32 {d0[]}, [r0]poly8x8_t vld1_dup_p8(__transfersize(1) poly8_t const * ptr); // VLD1.8 {d0[]}, [r0]


NEON 지원 사용

poly16x4_t vld1_dup_p16(__transfersize(1) poly16_t const * ptr); // VLD1.16 {d0[]}, [r0]void vst1q_u8(__transfersize(16) uint8_t * ptr, uint8x16_t val); // VST1.8 {d0, d1}, [r0]void vst1q_u16(__transfersize(8) uint16_t * ptr, uint16x8_t val); // VST1.16 {d0, d1}, [r0]void vst1q_u32(__transfersize(4) uint32_t * ptr, uint32x4_t val); // VST1.32 {d0, d1}, [r0]void vst1q_u64(__transfersize(2) uint64_t * ptr, uint64x2_t val); // VST1.64 {d0, d1}, [r0]void vst1q_s8(__transfersize(16) int8_t * ptr, int8x16_t val); // VST1.8 {d0, d1}, [r0]void vst1q_s16(__transfersize(8) int16_t * ptr, int16x8_t val); // VST1.16 {d0, d1}, [r0]void vst1q_s32(__transfersize(4) int32_t * ptr, int32x4_t val); // VST1.32 {d0, d1}, [r0]void vst1q_s64(__transfersize(2) int64_t * ptr, int64x2_t val); // VST1.64 {d0, d1}, [r0]void vst1q_f16(__transfersize(8) __fp16 * ptr, float16x8_t val); // VST1.16 {d0, d1}, [r0]void vst1q_f32(__transfersize(4) float32_t * ptr, float32x4_t val); // VST1.32 {d0, d1}, [r0]void vst1q_p8(__transfersize(16) poly8_t * ptr, poly8x16_t val); // VST1.8 {d0, d1}, [r0]void vst1q_p16(__transfersize(8) poly16_t * ptr, poly16x8_t val); // VST1.16 {d0, d1}, [r0]void vst1_u8(__transfersize(8) uint8_t * ptr, uint8x8_t val); // VST1.8 {d0}, [r0]void vst1_u16(__transfersize(4) uint16_t * ptr, uint16x4_t val); // VST1.16 {d0}, [r0]void vst1_u32(__transfersize(2) uint32_t * ptr, uint32x2_t val); // VST1.32 {d0}, [r0]void vst1_u64(__transfersize(1) uint64_t * ptr, uint64x1_t val); // VST1.64 {d0}, [r0]void vst1_s8(__transfersize(8) int8_t * ptr, int8x8_t val);

// VST1.8 {d0}, [r0]void vst1_s16(__transfersize(4) int16_t * ptr, int16x4_t val); // VST1.16 {d0}, [r0]void vst1_s32(__transfersize(2) int32_t * ptr, int32x2_t val); // VST1.32 {d0}, [r0]void vst1_s64(__transfersize(1) int64_t * ptr, int64x1_t val); // VST1.64 {d0}, [r0]void vst1_f16(__transfersize(4) __fp16 * ptr, float16x4_t val); // VST1.16 {d0}, [r0]void vst1_f32(__transfersize(2) float32_t * ptr, float32x2_t val); // VST1.32 {d0}, [r0]void vst1_p8(__transfersize(8) poly8_t * ptr, poly8x8_t val); // VST1.8 {d0}, [r0]void vst1_p16(__transfersize(4) poly16_t * ptr, poly16x4_t val);


NEON 지원 사용

// VST1.16 {d0}, [r0]void vst1q_lane_u8(__transfersize(1) uint8_t * ptr, uint8x16_t val, __constrange(0,15) int lane); // VST1.8 {d0[0]}, [r0]void vst1q_lane_u16(__transfersize(1) uint16_t * ptr, uint16x8_t val, __constrange(0,7) int lane); // VST1.16 {d0[0]}, [r0]void vst1q_lane_u32(__transfersize(1) uint32_t * ptr, uint32x4_t val, __constrange(0,3) int lane); // VST1.32 {d0[0]}, [r0]void vst1q_lane_u64(__transfersize(1) uint64_t * ptr, uint64x2_t val, __constrange(0,1) int lane); // VST1.64 {d0}, [r0]void vst1q_lane_s8(__transfersize(1) int8_t * ptr, int8x16_t val, __constrange(0,15) int lane); // VST1.8 {d0[0]}, [r0]void vst1q_lane_s16(__transfersize(1) int16_t * ptr, int16x8_t val, __constrange(0,7) int lane); // VST1.16 {d0[0]}, [r0]void vst1q_lane_s32(__transfersize(1) int32_t * ptr, int32x4_t val, __constrange(0,3) int lane); // VST1.32 {d0[0]}, [r0]void vst1q_lane_s64(__transfersize(1) int64_t * ptr, int64x2_t val, __constrange(0,1) int lane); // VST1.64 {d0}, [r0]void vst1q_lane_f16(__transfersize(1) __fp16 * ptr, float16x8_t val, __constrange(0,7) int lane); // VST1.16 {d0[0]}, [r0]void vst1q_lane_f32(__transfersize(1) float32_t * ptr, float32x4_t val, __constrange(0,3) int lane); // VST1.32 {d0[0]}, [r0]void vst1q_lane_p8(__transfersize(1) poly8_t * ptr, poly8x16_t val, __constrange(0,15) int lane); // VST1.8 {d0[0]}, [r0]void vst1q_lane_p16(__transfersize(1) poly16_t * ptr, poly16x8_t val, __constrange(0,7) int lane); // VST1.16 {d0[0]}, [r0]void vst1_lane_u8(__transfersize(1) uint8_t * ptr, uint8x8_t val, __constrange(0,7) int lane); // VST1.8 {d0[0]}, [r0]void vst1_lane_u16(__transfersize(1) uint16_t * ptr, uint16x4_t val, __constrange(0,3) int lane); // VST1.16 {d0[0]}, [r0]void vst1_lane_u32(__transfersize(1) uint32_t * ptr, uint32x2_t val, __constrange(0,1) int lane); // VST1.32 {d0[0]}, [r0]void vst1_lane_u64(__transfersize(1) uint64_t * ptr, uint64x1_t val, __constrange(0,0) int lane); // VST1.64 {d0}, [r0]void vst1_lane_s8(__transfersize(1) int8_t * ptr, int8x8_t val, __constrange(0,7) int lane); // VST1.8 {d0[0]}, [r0]void vst1_lane_s16(__transfersize(1) int16_t * ptr, int16x4_t val, __constrange(0,3) int lane);

// VST1.16 {d0[0]}, [r0]void vst1_lane_s32(__transfersize(1) int32_t * ptr, int32x2_t val, __constrange(0,1) int lane); // VST1.32 {d0[0]}, [r0]void vst1_lane_s64(__transfersize(1) int64_t * ptr, int64x1_t val, __constrange(0,0) int lane); // VST1.64 {d0}, [r0]void vst1_lane_f16(__transfersize(1) __fp16 * ptr, float16x4_t val, __constrange(0,3) int lane); // VST1.16 {d0[0]}, [r0]void vst1_lane_f32(__transfersize(1) float32_t * ptr, float32x2_t val, __constrange(0,1) int lane); // VST1.32 {d0[0]}, [r0]void vst1_lane_p8(__transfersize(1) poly8_t * ptr, poly8x8_t val, __constrange(0,7) int lane); // VST1.8 {d0[0]}, [r0]


NEON 지원 사용

void vst1_lane_p16(__transfersize(1) poly16_t * ptr, poly16x4_t val, __constrange(0,3) int lane); // VST1.16 {d0[0]}, [r0]

E.3.15 N 요소 구조체 로드 및 저장

다음 내장 함수는 n- 요소 구조체를 로드하거나 저장합니다. 배열 구조체는 유사하게 정의됩니다. 예를 들어 int16x4x2_t 구조체는 다음과 같이 정의됩니다.

struct int16x4x2_t{ int16x4_t val[2];};

uint8x16x2_t vld2q_u8(__transfersize(32) uint8_t const * ptr); // VLD2.8 {d0, d2}, [r0]uint16x8x2_t vld2q_u16(__transfersize(16) uint16_t const * ptr); // VLD2.16 {d0, d2}, [r0]uint32x4x2_t vld2q_u32(__transfersize(8) uint32_t const * ptr); // VLD2.32 {d0, d2}, [r0]int8x16x2_t vld2q_s8(__transfersize(32) int8_t const * ptr); // VLD2.8 {d0, d2}, [r0]int16x8x2_t vld2q_s16(__transfersize(16) int16_t const * ptr); // VLD2.16 {d0, d2}, [r0]int32x4x2_t vld2q_s32(__transfersize(8) int32_t const * ptr); // VLD2.32 {d0, d2}, [r0]float16x8x2_t vld2q_f16(__transfersize(16) __fp16 const * ptr); // VLD2.16 {d0, d2}, [r0]float32x4x2_t vld2q_f32(__transfersize(8) float32_t const * ptr); // VLD2.32 {d0, d2}, [r0]poly8x16x2_t vld2q_p8(__transfersize(32) poly8_t const * ptr); // VLD2.8 {d0, d2}, [r0]poly16x8x2_t vld2q_p16(__transfersize(16) poly16_t const * ptr); // VLD2.16 {d0, d2}, [r0]uint8x8x2_t vld2_u8(__transfersize(16) uint8_t const * ptr); // VLD2.8 {d0, d1}, [r0]uint16x4x2_t vld2_u16(__transfersize(8) uint16_t const * ptr); // VLD2.16 {d0, d1}, [r0]uint32x2x2_t vld2_u32(__transfersize(4) uint32_t const * ptr); // VLD2.32 {d0, d1}, [r0]uint64x1x2_t vld2_u64(__transfersize(2) uint64_t const * ptr); // VLD1.64 {d0, d1}, [r0]int8x8x2_t vld2_s8(__transfersize(16) int8_t const * ptr); // VLD2.8 {d0, d1}, [r0]int16x4x2_t vld2_s16(__transfersize(8) int16_t const * ptr); // VLD2.16 {d0, d1}, [r0]int32x2x2_t vld2_s32(__transfersize(4) int32_t const * ptr); // VLD2.32 {d0, d1}, [r0]int64x1x2_t vld2_s64(__transfersize(2) int64_t const * ptr); // VLD1.64 {d0, d1}, [r0]float16x4x2_t vld2_f16(__transfersize(8) __fp16 const * ptr);


NEON 지원 사용

// VLD2.16 {d0, d1}, [r0]float32x2x2_t vld2_f32(__transfersize(4) float32_t const * ptr); // VLD2.32 {d0, d1}, [r0]poly8x8x2_t vld2_p8(__transfersize(16) poly8_t const * ptr); // VLD2.8 {d0, d1}, [r0]poly16x4x2_t vld2_p16(__transfersize(8) poly16_t const * ptr); // VLD2.16 {d0, d1}, [r0]uint8x16x3_t vld3q_u8(__transfersize(48) uint8_t const * ptr); // VLD3.8 {d0, d2, d4}, [r0]uint16x8x3_t vld3q_u16(__transfersize(24) uint16_t const * ptr); // VLD3.16 {d0, d2, d4}, [r0]uint32x4x3_t vld3q_u32(__transfersize(12) uint32_t const * ptr); // VLD3.32 {d0, d2, d4}, [r0]int8x16x3_t vld3q_s8(__transfersize(48) int8_t const * ptr); // VLD3.8 {d0, d2, d4}, [r0]int16x8x3_t vld3q_s16(__transfersize(24) int16_t const * ptr); // VLD3.16 {d0, d2, d4}, [r0]int32x4x3_t vld3q_s32(__transfersize(12) int32_t const * ptr); // VLD3.32 {d0, d2, d4}, [r0]float16x8x3_t vld3q_f16(__transfersize(24) __fp16 const * ptr); // VLD3.16 {d0, d2, d4}, [r0]float32x4x3_t vld3q_f32(__transfersize(12) float32_t const * ptr); // VLD3.32 {d0, d2, d4}, [r0]poly8x16x3_t vld3q_p8(__transfersize(48) poly8_t const * ptr); // VLD3.8 {d0, d2, d4}, [r0]poly16x8x3_t vld3q_p16(__transfersize(24) poly16_t const * ptr); // VLD3.16 {d0, d2, d4}, [r0]uint8x8x3_t vld3_u8(__transfersize(24) uint8_t const * ptr); // VLD3.8 {d0, d1, d2}, [r0]uint16x4x3_t vld3_u16(__transfersize(12) uint16_t const * ptr); // VLD3.16 {d0, d1, d2}, [r0]uint32x2x3_t vld3_u32(__transfersize(6) uint32_t const * ptr); // VLD3.32 {d0, d1, d2}, [r0]uint64x1x3_t vld3_u64(__transfersize(3) uint64_t const * ptr); // VLD1.64 {d0, d1, d2}, [r0]int8x8x3_t vld3_s8(__transfersize(24) int8_t const * ptr); // VLD3.8 {d0, d1, d2}, [r0]int16x4x3_t vld3_s16(__transfersize(12) int16_t const * ptr); // VLD3.16 {d0, d1, d2}, [r0]

int32x2x3_t vld3_s32(__transfersize(6) int32_t const * ptr); // VLD3.32 {d0, d1, d2}, [r0]int64x1x3_t vld3_s64(__transfersize(3) int64_t const * ptr); // VLD1.64 {d0, d1, d2}, [r0]float16x4x3_t vld3_f16(__transfersize(12) __fp16 const * ptr); // VLD3.16 {d0, d1, d2}, [r0]float32x2x3_t vld3_f32(__transfersize(6) float32_t const * ptr); // VLD3.32 {d0, d1, d2}, [r0]poly8x8x3_t vld3_p8(__transfersize(24) poly8_t const * ptr); // VLD3.8 {d0, d1, d2}, [r0]


NEON 지원 사용

poly16x4x3_t vld3_p16(__transfersize(12) poly16_t const * ptr); // VLD3.16 {d0, d1, d2}, [r0]uint8x16x4_t vld4q_u8(__transfersize(64) uint8_t const * ptr); // VLD4.8 {d0, d2, d4, d6}, [r0]uint16x8x4_t vld4q_u16(__transfersize(32) uint16_t const * ptr); // VLD4.16 {d0, d2, d4, d6}, [r0]uint32x4x4_t vld4q_u32(__transfersize(16) uint32_t const * ptr); // VLD4.32 {d0, d2, d4, d6}, [r0]int8x16x4_t vld4q_s8(__transfersize(64) int8_t const * ptr); // VLD4.8 {d0, d2, d4, d6}, [r0]int16x8x4_t vld4q_s16(__transfersize(32) int16_t const * ptr); // VLD4.16 {d0, d2, d4, d6}, [r0]int32x4x4_t vld4q_s32(__transfersize(16) int32_t const * ptr); // VLD4.32 {d0, d2, d4, d6}, [r0]float16x8x4_t vld4q_f16(__transfersize(32) __fp16 const * ptr); // VLD4.16 {d0, d2, d4, d6}, [r0]float32x4x4_t vld4q_f32(__transfersize(16) float32_t const * ptr); // VLD4.32 {d0, d2, d4, d6}, [r0]poly8x16x4_t vld4q_p8(__transfersize(64) poly8_t const * ptr); // VLD4.8 {d0, d2, d4, d6}, [r0]poly16x8x4_t vld4q_p16(__transfersize(32) poly16_t const * ptr); // VLD4.16 {d0, d2, d4, d6}, [r0]uint8x8x4_t vld4_u8(__transfersize(32) uint8_t const * ptr); // VLD4.8 {d0, d1, d2, d3}, [r0]uint16x4x4_t vld4_u16(__transfersize(16) uint16_t const * ptr); // VLD4.16 {d0, d1, d2, d3}, [r0]uint32x2x4_t vld4_u32(__transfersize(8) uint32_t const * ptr); // VLD4.32 {d0, d1, d2, d3}, [r0]uint64x1x4_t vld4_u64(__transfersize(4) uint64_t const * ptr); // VLD1.64 {d0, d1, d2, d3}, [r0]int8x8x4_t vld4_s8(__transfersize(32) int8_t const * ptr); // VLD4.8 {d0, d1, d2, d3}, [r0]int16x4x4_t vld4_s16(__transfersize(16) int16_t const * ptr); // VLD4.16 {d0, d1, d2, d3}, [r0]int32x2x4_t vld4_s32(__transfersize(8) int32_t const * ptr); // VLD4.32 {d0, d1, d2, d3}, [r0]int64x1x4_t vld4_s64(__transfersize(4) int64_t const * ptr); // VLD1.64 {d0, d1, d2, d3}, [r0]float16x4x4_t vld4_f16(__transfersize(16) __fp16 const * ptr); // VLD4.16 {d0, d1, d2, d3}, [r0]

float32x2x4_t vld4_f32(__transfersize(8) float32_t const * ptr); // VLD4.32 {d0, d1, d2, d3}, [r0]poly8x8x4_t vld4_p8(__transfersize(32) poly8_t const * ptr); // VLD4.8 {d0, d1, d2, d3}, [r0]poly16x4x4_t vld4_p16(__transfersize(16) poly16_t const * ptr); // VLD4.16 {d0, d1, d2, d3}, [r0]uint8x8x2_t vld2_dup_u8(__transfersize(2) uint8_t const * ptr); // VLD2.8 {d0[], d1[]}, [r0]uint16x4x2_t vld2_dup_u16(__transfersize(2) uint16_t const * ptr);


NEON 지원 사용

// VLD2.16 {d0[], d1[]}, [r0]uint32x2x2_t vld2_dup_u32(__transfersize(2) uint32_t const * ptr); // VLD2.32 {d0[], d1[]}, [r0]uint64x1x2_t vld2_dup_u64(__transfersize(2) uint64_t const * ptr); // VLD1.64 {d0, d1}, [r0]int8x8x2_t vld2_dup_s8(__transfersize(2) int8_t const * ptr); // VLD2.8 {d0[], d1[]}, [r0]int16x4x2_t vld2_dup_s16(__transfersize(2) int16_t const * ptr); // VLD2.16 {d0[], d1[]}, [r0]int32x2x2_t vld2_dup_s32(__transfersize(2) int32_t const * ptr); // VLD2.32 {d0[], d1[]}, [r0]int64x1x2_t vld2_dup_s64(__transfersize(2) int64_t const * ptr); // VLD1.64 {d0, d1}, [r0]float16x4x2_t vld2_dup_f16(__transfersize(2) __fp16 const * ptr); // VLD2.16 {d0[], d1[]}, [r0]float32x2x2_t vld2_dup_f32(__transfersize(2) float32_t const * ptr); // VLD2.32 {d0[], d1[]}, [r0]poly8x8x2_t vld2_dup_p8(__transfersize(2) poly8_t const * ptr); // VLD2.8 {d0[], d1[]}, [r0]poly16x4x2_t vld2_dup_p16(__transfersize(2) poly16_t const * ptr); // VLD2.16 {d0[], d1[]}, [r0]uint8x8x3_t vld3_dup_u8(__transfersize(3) uint8_t const * ptr); // VLD3.8 {d0[], d1[], d2[]}, [r0]uint16x4x3_t vld3_dup_u16(__transfersize(3) uint16_t const * ptr); // VLD3.16 {d0[], d1[], d2[]}, [r0]uint32x2x3_t vld3_dup_u32(__transfersize(3) uint32_t const * ptr); // VLD3.32 {d0[], d1[], d2[]}, [r0]uint64x1x3_t vld3_dup_u64(__transfersize(3) uint64_t const * ptr); // VLD1.64 {d0, d1, d2}, [r0]int8x8x3_t vld3_dup_s8(__transfersize(3) int8_t const * ptr); // VLD3.8 {d0[], d1[], d2[]}, [r0]int16x4x3_t vld3_dup_s16(__transfersize(3) int16_t const * ptr); // VLD3.16 {d0[], d1[], d2[]}, [r0]int32x2x3_t vld3_dup_s32(__transfersize(3) int32_t const * ptr); // VLD3.32 {d0[], d1[], d2[]}, [r0]int64x1x3_t vld3_dup_s64(__transfersize(3) int64_t const * ptr); // VLD1.64 {d0, d1, d2}, [r0]float16x4x3_t vld3_dup_f16(__transfersize(3) __fp16 const * ptr); // VLD3.16 {d0[], d1[], d2[]}, [r0]float32x2x3_t vld3_dup_f32(__transfersize(3) float32_t const * ptr); // VLD3.32 {d0[], d1[], d2[]}, [r0]

poly8x8x3_t vld3_dup_p8(__transfersize(3) poly8_t const * ptr); // VLD3.8 {d0[], d1[], d2[]}, [r0]poly16x4x3_t vld3_dup_p16(__transfersize(3) poly16_t const * ptr); // VLD3.16 {d0[], d1[], d2[]}, [r0]uint8x8x4_t vld4_dup_u8(__transfersize(4) uint8_t const * ptr); // VLD4.8 {d0[], d1[], d2[], d3[]}, [r0]uint16x4x4_t vld4_dup_u16(__transfersize(4) uint16_t const * ptr); // VLD4.16 {d0[], d1[], d2[], d3[]}, [r0]


NEON 지원 사용

uint32x2x4_t vld4_dup_u32(__transfersize(4) uint32_t const * ptr); // VLD4.32 {d0[], d1[], d2[], d3[]}, [r0]uint64x1x4_t vld4_dup_u64(__transfersize(4) uint64_t const * ptr); // VLD1.64 {d0, d1, d2, d3}, [r0]int8x8x4_t vld4_dup_s8(__transfersize(4) int8_t const * ptr); // VLD4.8 {d0[], d1[], d2[], d3[]}, [r0]int16x4x4_t vld4_dup_s16(__transfersize(4) int16_t const * ptr); // VLD4.16 {d0[], d1[], d2[], d3[]}, [r0]int32x2x4_t vld4_dup_s32(__transfersize(4) int32_t const * ptr); // VLD4.32 {d0[], d1[], d2[], d3[]}, [r0]int64x1x4_t vld4_dup_s64(__transfersize(4) int64_t const * ptr); // VLD1.64 {d0, d1, d2, d3}, [r0]float16x4x4_t vld4_dup_f16(__transfersize(4) __fp16 const * ptr); // VLD4.16 {d0[], d1[], d2[], d3[]}, [r0]float32x2x4_t vld4_dup_f32(__transfersize(4) float32_t const * ptr); // VLD4.32 {d0[], d1[], d2[], d3[]}, [r0]poly8x8x4_t vld4_dup_p8(__transfersize(4) poly8_t const * ptr); // VLD4.8 {d0[], d1[], d2[], d3[]}, [r0]poly16x4x4_t vld4_dup_p16(__transfersize(4) poly16_t const * ptr); // VLD4.16 {d0[], d1[], d2[], d3[]}, [r0]uint16x8x2_t vld2q_lane_u16(__transfersize(2) uint16_t const * ptr, uint16x8x2_t src, __constrange(0,7) int lane); // VLD2.16 {d0[0], d2[0]}, [r0]uint32x4x2_t vld2q_lane_u32(__transfersize(2) uint32_t const * ptr, uint32x4x2_t src, __constrange(0,3) int lane); // VLD2.32 {d0[0], d2[0]}, [r0]int16x8x2_t vld2q_lane_s16(__transfersize(2) int16_t const * ptr, int16x8x2_t src, __constrange(0,7) int lane); // VLD2.16 {d0[0], d2[0]}, [r0]int32x4x2_t vld2q_lane_s32(__transfersize(2) int32_t const * ptr, int32x4x2_t src, __constrange(0,3) int lane); // VLD2.32 {d0[0], d2[0]}, [r0]float16x8x2_t vld2q_lane_f16(__transfersize(2) __fp16 const * ptr, float16x8x2_t src, __constrange(0,7) int lane); // VLD2.16 {d0[0], d2[0]}, [r0]float32x4x2_t vld2q_lane_f32(__transfersize(2) float32_t const * ptr, float32x4x2_t src, __constrange(0,3) int lane); // VLD2.32 {d0[0], d2[0]}, [r0]poly16x8x2_t vld2q_lane_p16(__transfersize(2) poly16_t const * ptr, poly16x8x2_t src, __constrange(0,7) int lane); // VLD2.16 {d0[0], d2[0]}, [r0]uint8x8x2_t vld2_lane_u8(__transfersize(2) uint8_t const * ptr, uint8x8x2_t src, __constrange(0,7) int lane); // VLD2.8 {d0[0], d1[0]}, [r0]uint16x4x2_t vld2_lane_u16(__transfersize(2) uint16_t const * ptr, uint16x4x2_t src, __constrange(0,3) int lane); // VLD2.16 {d0[0], d1[0]}, [r0]uint32x2x2_t vld2_lane_u32(__transfersize(2) uint32_t const * ptr, uint32x2x2_t src, __constrange(0,1) int lane); // VLD2.32 {d0[0], d1[0]}, [r0]


NEON 지원 사용

int8x8x2_t vld2_lane_s8(__transfersize(2) int8_t const * ptr, int8x8x2_t src, __constrange(0,7) int lane); // VLD2.8 {d0[0], d1[0]}, [r0]int16x4x2_t vld2_lane_s16(__transfersize(2) int16_t const * ptr, int16x4x2_t src, __constrange(0,3) int lane); // VLD2.16 {d0[0], d1[0]}, [r0]int32x2x2_t vld2_lane_s32(__transfersize(2) int32_t const * ptr, int32x2x2_t src, __constrange(0,1) int lane); // VLD2.32 {d0[0], d1[0]}, [r0]float16x4x2_t vld2_lane_f32(__transfersize(2) __fp16 const * ptr, float16x4x2_t src, __constrange(0,3) int lane); // VLD2.16 {d0[0], d1[0]}, [r0]float32x2x2_t vld2_lane_f32(__transfersize(2) float32_t const * ptr, float32x2x2_t src, __constrange(0,1) int lane); // VLD2.32 {d0[0], d1[0]}, [r0]poly8x8x2_t vld2_lane_p8(__transfersize(2) poly8_t const * ptr, poly8x8x2_t src, __constrange(0,7) int lane); // VLD2.8 {d0[0], d1[0]}, [r0]poly16x4x2_t vld2_lane_p16(__transfersize(2) poly16_t const * ptr, poly16x4x2_t src, __constrange(0,3) int lane); // VLD2.16 {d0[0], d1[0]}, [r0]uint16x8x3_t vld3q_lane_u16(__transfersize(3) uint16_t const * ptr, uint16x8x3_t src, __constrange(0,7) int lane); // VLD3.16 {d0[0], d2[0], d4[0]}, [r0]uint32x4x3_t vld3q_lane_u32(__transfersize(3) uint32_t const * ptr, uint32x4x3_t src, __constrange(0,3) int lane); // VLD3.32 {d0[0], d2[0], d4[0]}, [r0]int16x8x3_t vld3q_lane_s16(__transfersize(3) int16_t const * ptr, int16x8x3_t src, __constrange(0,7) int lane); // VLD3.16 {d0[0], d2[0], d4[0]}, [r0]int32x4x3_t vld3q_lane_s32(__transfersize(3) int32_t const * ptr, int32x4x3_t src, __constrange(0,3) int lane); // VLD3.32 {d0[0], d2[0], d4[0]}, [r0]float16x8x3_t vld3q_lane_f32(__transfersize(3) __fp16 const * ptr, float16x8x3_t src, __constrange(0,7) int lane); // VLD3.16 {d0[0], d2[0], d4[0]}, [r0]float32x4x3_t vld3q_lane_f32(__transfersize(3) float32_t const * ptr, float32x4x3_t src, __constrange(0,3) int lane); // VLD3.32 {d0[0], d2[0], d4[0]}, [r0]poly16x8x3_t vld3q_lane_p16(__transfersize(3) poly16_t const * ptr, poly16x8x3_t src, __constrange(0,7) int lane); // VLD3.16 {d0[0], d2[0], d4[0]}, [r0]

uint8x8x3_t vld3_lane_u8(__transfersize(3) uint8_t const * ptr, uint8x8x3_t src, __constrange(0,7) int lane); // VLD3.8 {d0[0], d1[0], d2[0]}, [r0]uint16x4x3_t vld3_lane_u16(__transfersize(3) uint16_t const * ptr, uint16x4x3_t src, __constrange(0,3) int lane); // VLD3.16 {d0[0], d1[0], d2[0]}, [r0]uint32x2x3_t vld3_lane_u32(__transfersize(3) uint32_t const * ptr, uint32x2x3_t src, __constrange(0,1)


NEON 지원 사용

int lane); // VLD3.32 {d0[0], d1[0], d2[0]}, [r0]int8x8x3_t vld3_lane_s8(__transfersize(3) int8_t const * ptr, int8x8x3_t src, __constrange(0,7) int lane); // VLD3.8 {d0[0], d1[0], d2[0]}, [r0]int16x4x3_t vld3_lane_s16(__transfersize(3) int16_t const * ptr, int16x4x3_t src, __constrange(0,3) int lane); // VLD3.16 {d0[0], d1[0], d2[0]}, [r0]int32x2x3_t vld3_lane_s32(__transfersize(3) int32_t const * ptr, int32x2x3_t src, __constrange(0,1) int lane); // VLD3.32 {d0[0], d1[0], d2[0]}, [r0]float16x4x3_t vld3_lane_f16(__transfersize(3) __fp16 const * ptr, float16x4x3_t src, __constrange(0,3) int lane); // VLD3.16 {d0[0], d1[0], d2[0]}, [r0]float32x2x3_t vld3_lane_f32(__transfersize(3) float32_t const * ptr, float32x2x3_t src, __constrange(0,1) int lane); // VLD3.32 {d0[0], d1[0], d2[0]}, [r0]poly8x8x3_t vld3_lane_p8(__transfersize(3) poly8_t const * ptr, poly8x8x3_t src, __constrange(0,7) int lane); // VLD3.8 {d0[0], d1[0], d2[0]}, [r0]poly16x4x3_t vld3_lane_p16(__transfersize(3) poly16_t const * ptr, poly16x4x3_t src, __constrange(0,3) int lane); // VLD3.16 {d0[0], d1[0], d2[0]}, [r0]uint16x8x4_t vld4q_lane_u16(__transfersize(4) uint16_t const * ptr, uint16x8x4_t src, __constrange(0,7) int lane); // VLD4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]uint32x4x4_t vld4q_lane_u32(__transfersize(4) uint32_t const * ptr, uint32x4x4_t src, __constrange(0,3) int lane); // VLD4.32 {d0[0], d2[0], d4[0], d6[0]}, [r0]int16x8x4_t vld4q_lane_s16(__transfersize(4) int16_t const * ptr, int16x8x4_t src, __constrange(0,7) int lane); // VLD4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]int32x4x4_t vld4q_lane_s32(__transfersize(4) int32_t const * ptr, int32x4x4_t src, __constrange(0,3) int lane); // VLD4.32 {d0[0], d2[0], d4[0], d6[0]}, [r0]float16x8x4_t vld4q_lane_f32(__transfersize(4) __fp16 const * ptr, float16x8x4_t src, __constrange(0,7) int lane); // VLD4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]float32x4x4_t vld4q_lane_f32(__transfersize(4) float32_t const * ptr, float32x4x4_t src, __constrange(0,3) int lane); // VLD4.32 {d0[0], d2[0], d4[0], d6[0]}, [r0]poly16x8x4_t vld4q_lane_p16(__transfersize(4) poly16_t const * ptr, poly16x8x4_t src, __constrange(0,7) int lane);

// VLD4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]uint8x8x4_t vld4_lane_u8(__transfersize(4) uint8_t const * ptr, uint8x8x4_t src, __constrange(0,7) int lane); // VLD4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0]uint16x4x4_t vld4_lane_u16(__transfersize(4) uint16_t const * ptr, uint16x4x4_t src, __constrange(0,3) int lane);


NEON 지원 사용

// VLD4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]uint32x2x4_t vld4_lane_u32(__transfersize(4) uint32_t const * ptr, uint32x2x4_t src, __constrange(0,1) int lane); // VLD4.32 {d0[0], d1[0], d2[0], d3[0]}, [r0]int8x8x4_t vld4_lane_s8(__transfersize(4) int8_t const * ptr, int8x8x4_t src, __constrange(0,7) int lane); // VLD4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0]int16x4x4_t vld4_lane_s16(__transfersize(4) int16_t const * ptr, int16x4x4_t src, __constrange(0,3) int lane); // VLD4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]int32x2x4_t vld4_lane_s32(__transfersize(4) int32_t const * ptr, int32x2x4_t src, __constrange(0,1) int lane); // VLD4.32 {d0[0], d1[0], d2[0], d3[0]}, [r0]float16x4x4_t vld4_lane_f16(__transfersize(4) __fp16 const * ptr, float16x4x4_t src, __constrange(0,3) int lane); // VLD4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]float32x2x4_t vld4_lane_f32(__transfersize(4) float32_t const * ptr, float32x2x4_t src, __constrange(0,1) int lane); // VLD4.32 {d0[0], d1[0], d2[0], d3[0]}, [r0]poly8x8x4_t vld4_lane_p8(__transfersize(4) poly8_t const * ptr, poly8x8x4_t src, __constrange(0,7) int lane); // VLD4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0]poly16x4x4_t vld4_lane_p16(__transfersize(4) poly16_t const * ptr, poly16x4x4_t src, __constrange(0,3) int lane); // VLD4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst2q_u8(__transfersize(32) uint8_t * ptr, uint8x16x2_t val); // VST2.8 {d0, d2}, [r0]void vst2q_u16(__transfersize(16) uint16_t * ptr, uint16x8x2_t val); // VST2.16 {d0, d2}, [r0]void vst2q_u32(__transfersize(8) uint32_t * ptr, uint32x4x2_t val); // VST2.32 {d0, d2}, [r0]void vst2q_s8(__transfersize(32) int8_t * ptr, int8x16x2_t val); // VST2.8 {d0, d2}, [r0]void vst2q_s16(__transfersize(16) int16_t * ptr, int16x8x2_t val); // VST2.16 {d0, d2}, [r0]void vst2q_s32(__transfersize(8) int32_t * ptr, int32x4x2_t val); // VST2.32 {d0, d2}, [r0]void vst2q_f16(__transfersize(16) __fp16 * ptr, float16x8x2_t val); // VST2.16 {d0, d2}, [r0]void vst2q_f32(__transfersize(8) float32_t * ptr, float32x4x2_t val); // VST2.32 {d0, d2}, [r0]void vst2q_p8(__transfersize(32) poly8_t * ptr, poly8x16x2_t val); // VST2.8 {d0, d2}, [r0]void vst2q_p16(__transfersize(16) poly16_t * ptr, poly16x8x2_t val);

// VST2.16 {d0, d2}, [r0]void vst2_u8(__transfersize(16) uint8_t * ptr, uint8x8x2_t val); // VST2.8 {d0, d1}, [r0]void vst2_u16(__transfersize(8) uint16_t * ptr, uint16x4x2_t val); // VST2.16 {d0, d1}, [r0]


NEON 지원 사용

void vst2_u32(__transfersize(4) uint32_t * ptr, uint32x2x2_t val); // VST2.32 {d0, d1}, [r0]void vst2_u64(__transfersize(2) uint64_t * ptr, uint64x1x2_t val); // VST1.64 {d0, d1}, [r0]void vst2_s8(__transfersize(16) int8_t * ptr, int8x8x2_t val); // VST2.8 {d0, d1}, [r0]void vst2_s16(__transfersize(8) int16_t * ptr, int16x4x2_t val); // VST2.16 {d0, d1}, [r0]void vst2_s32(__transfersize(4) int32_t * ptr, int32x2x2_t val); // VST2.32 {d0, d1}, [r0]void vst2_s64(__transfersize(2) int64_t * ptr, int64x1x2_t val); // VST1.64 {d0, d1}, [r0]void vst2_f16(__transfersize(8) __fp16 * ptr, float16x4x2_t val); // VST2.16 {d0, d1}, [r0]void vst2_f32(__transfersize(4) float32_t * ptr, float32x2x2_t val); // VST2.32 {d0, d1}, [r0]void vst2_p8(__transfersize(16) poly8_t * ptr, poly8x8x2_t val); // VST2.8 {d0, d1}, [r0]void vst2_p16(__transfersize(8) poly16_t * ptr, poly16x4x2_t val); // VST2.16 {d0, d1}, [r0]void vst3q_u8(__transfersize(48) uint8_t * ptr, uint8x16x3_t val); // VST3.8 {d0, d2, d4}, [r0]void vst3q_u16(__transfersize(24) uint16_t * ptr, uint16x8x3_t val); // VST3.16 {d0, d2, d4}, [r0]void vst3q_u32(__transfersize(12) uint32_t * ptr, uint32x4x3_t val); // VST3.32 {d0, d2, d4}, [r0]void vst3q_s8(__transfersize(48) int8_t * ptr, int8x16x3_t val); // VST3.8 {d0, d2, d4}, [r0]void vst3q_s16(__transfersize(24) int16_t * ptr, int16x8x3_t val); // VST3.16 {d0, d2, d4}, [r0]void vst3q_s32(__transfersize(12) int32_t * ptr, int32x4x3_t val); // VST3.32 {d0, d2, d4}, [r0]void vst3q_f16(__transfersize(24) __fp16 * ptr, float16x8x3_t val); // VST3.16 {d0, d2, d4}, [r0]void vst3q_f32(__transfersize(12) float32_t * ptr, float32x4x3_t val); // VST3.32 {d0, d2, d4}, [r0]void vst3q_p8(__transfersize(48) poly8_t * ptr, poly8x16x3_t val); // VST3.8 {d0, d2, d4}, [r0]void vst3q_p16(__transfersize(24) poly16_t * ptr, poly16x8x3_t val); // VST3.16 {d0, d2, d4}, [r0]void vst3_u8(__transfersize(24) uint8_t * ptr, uint8x8x3_t val); // VST3.8 {d0, d1, d2}, [r0]void vst3_u16(__transfersize(12) uint16_t * ptr, uint16x4x3_t val); // VST3.16 {d0, d1, d2}, [r0]void vst3_u32(__transfersize(6) uint32_t * ptr, uint32x2x3_t val);

// VST3.32 {d0, d1, d2}, [r0]void vst3_u64(__transfersize(3) uint64_t * ptr, uint64x1x3_t val); // VST1.64 {d0, d1, d2}, [r0]void vst3_s8(__transfersize(24) int8_t * ptr, int8x8x3_t val);


NEON 지원 사용

// VST3.8 {d0, d1, d2}, [r0]void vst3_s16(__transfersize(12) int16_t * ptr, int16x4x3_t val); // VST3.16 {d0, d1, d2}, [r0]void vst3_s32(__transfersize(6) int32_t * ptr, int32x2x3_t val); // VST3.32 {d0, d1, d2}, [r0]void vst3_s64(__transfersize(3) int64_t * ptr, int64x1x3_t val); // VST1.64 {d0, d1, d2}, [r0]void vst3_f16(__transfersize(12) __fp16 * ptr, float16x4x3_t val); // VST3.16 {d0, d1, d2}, [r0]void vst3_f32(__transfersize(6) float32_t * ptr, float32x2x3_t val); // VST3.32 {d0, d1, d2}, [r0]void vst3_p8(__transfersize(24) poly8_t * ptr, poly8x8x3_t val); // VST3.8 {d0, d1, d2}, [r0]void vst3_p16(__transfersize(12) poly16_t * ptr, poly16x4x3_t val); // VST3.16 {d0, d1, d2}, [r0]void vst4q_u8(__transfersize(64) uint8_t * ptr, uint8x16x4_t val); // VST4.8 {d0, d2, d4, d6}, [r0]void vst4q_u16(__transfersize(32) uint16_t * ptr, uint16x8x4_t val); // VST4.16 {d0, d2, d4, d6}, [r0]void vst4q_u32(__transfersize(16) uint32_t * ptr, uint32x4x4_t val); // VST4.32 {d0, d2, d4, d6}, [r0]void vst4q_s8(__transfersize(64) int8_t * ptr, int8x16x4_t val); // VST4.8 {d0, d2, d4, d6}, [r0]void vst4q_s16(__transfersize(32) int16_t * ptr, int16x8x4_t val); // VST4.16 {d0, d2, d4, d6}, [r0]void vst4q_s32(__transfersize(16) int32_t * ptr, int32x4x4_t val); // VST4.32 {d0, d2, d4, d6}, [r0]void vst4q_f16(__transfersize(32) __fp16 * ptr, float16x8x4_t val); // VST4.16 {d0, d2, d4, d6}, [r0]void vst4q_f32(__transfersize(16) float32_t * ptr, float32x4x4_t val); // VST4.32 {d0, d2, d4, d6}, [r0]void vst4q_p8(__transfersize(64) poly8_t * ptr, poly8x16x4_t val); // VST4.8 {d0, d2, d4, d6}, [r0]void vst4q_p16(__transfersize(32) poly16_t * ptr, poly16x8x4_t val); // VST4.16 {d0, d2, d4, d6}, [r0]void vst4_u8(__transfersize(32) uint8_t * ptr, uint8x8x4_t val); // VST4.8 {d0, d1, d2, d3}, [r0]void vst4_u16(__transfersize(16) uint16_t * ptr, uint16x4x4_t val); // VST4.16 {d0, d1, d2, d3}, [r0]void vst4_u32(__transfersize(8) uint32_t * ptr, uint32x2x4_t val); // VST4.32 {d0, d1, d2, d3}, [r0]void vst4_u64(__transfersize(4) uint64_t * ptr, uint64x1x4_t val); // VST1.64 {d0, d1, d2, d3}, [r0]void vst4_s8(__transfersize(32) int8_t * ptr, int8x8x4_t val); // VST4.8 {d0, d1, d2, d3}, [r0]void vst4_s16(__transfersize(16) int16_t * ptr, int16x4x4_t val);

// VST4.16 {d0, d1, d2, d3}, [r0]void vst4_s32(__transfersize(8) int32_t * ptr, int32x2x4_t val); // VST4.32 {d0, d1, d2, d3}, [r0]


NEON 지원 사용

void vst4_s64(__transfersize(4) int64_t * ptr, int64x1x4_t val); // VST1.64 {d0, d1, d2, d3}, [r0]void vst4_f16(__transfersize(16) __fp16 * ptr, float16x4x4_t val); // VST4.16 {d0, d1, d2, d3}, [r0]void vst4_f32(__transfersize(8) float32_t * ptr, float32x2x4_t val); // VST4.32 {d0, d1, d2, d3}, [r0]void vst4_p8(__transfersize(32) poly8_t * ptr, poly8x8x4_t val); // VST4.8 {d0, d1, d2, d3}, [r0]void vst4_p16(__transfersize(16) poly16_t * ptr, poly16x4x4_t val); // VST4.16 {d0, d1, d2, d3}, [r0]void vst2q_lane_u16(__transfersize(2) uint16_t * ptr, uint16x8x2_t val, __constrange(0,7) int lane); // VST2.16 {d0[0], d2[0]}, [r0]void vst2q_lane_u32(__transfersize(2) uint32_t * ptr, uint32x4x2_t val, __constrange(0,3) int lane); // VST2.32 {d0[0], d2[0]}, [r0]void vst2q_lane_s16(__transfersize(2) int16_t * ptr, int16x8x2_t val, __constrange(0,7) int lane); // VST2.16 {d0[0], d2[0]}, [r0]void vst2q_lane_s32(__transfersize(2) int32_t * ptr, int32x4x2_t val, __constrange(0,3) int lane); // VST2.32 {d0[0], d2[0]}, [r0]void vst2q_lane_f16(__transfersize(2) __fp16 * ptr, float16x8x2_t val, __constrange(0,7) int lane); // VST2.16 {d0[0], d2[0]}, [r0]void vst2q_lane_f32(__transfersize(2) float32_t * ptr, float32x4x2_t val, __constrange(0,3) int lane); // VST2.32 {d0[0], d2[0]}, [r0]void vst2q_lane_p16(__transfersize(2) poly16_t * ptr, poly16x8x2_t val, __constrange(0,7) int lane); // VST2.16 {d0[0], d2[0]}, [r0]void vst2_lane_u8(__transfersize(2) uint8_t * ptr, uint8x8x2_t val, __constrange(0,7) int lane); // VST2.8 {d0[0], d1[0]}, [r0]void vst2_lane_u16(__transfersize(2) uint16_t * ptr, uint16x4x2_t val, __constrange(0,3) int lane); // VST2.16 {d0[0], d1[0]}, [r0]void vst2_lane_u32(__transfersize(2) uint32_t * ptr, uint32x2x2_t val, __constrange(0,1) int lane); // VST2.32 {d0[0], d1[0]}, [r0]void vst2_lane_s8(__transfersize(2) int8_t * ptr, int8x8x2_t val, __constrange(0,7) int lane); // VST2.8 {d0[0], d1[0]}, [r0]void vst2_lane_s16(__transfersize(2) int16_t * ptr, int16x4x2_t val, __constrange(0,3) int lane); // VST2.16 {d0[0], d1[0]}, [r0]void vst2_lane_s32(__transfersize(2) int32_t * ptr, int32x2x2_t val, __constrange(0,1) int lane); // VST2.32 {d0[0], d1[0]}, [r0]void vst2_lane_f16(__transfersize(2) __fp16 * ptr, float16x4x2_t val, __constrange(0,3) int lane); // VST2.16 {d0[0], d1[0]}, [r0]void vst2_lane_f32(__transfersize(2) float32_t * ptr, float32x2x2_t val, __constrange(0,1) int lane); // VST2.32 {d0[0], d1[0]}, [r0]void vst2_lane_p8(__transfersize(2) poly8_t * ptr, poly8x8x2_t val, __constrange(0,7) int lane); // VST2.8 {d0[0], d1[0]}, [r0]void vst2_lane_p16(__transfersize(2) poly16_t * ptr, poly16x4x2_t val, __constrange(0,3) int lane); // VST2.16 {d0[0], d1[0]}, [r0]void vst3q_lane_u16(__transfersize(3) uint16_t * ptr, uint16x8x3_t val, __constrange(0,7) int lane); // VST3.16 {d0[0], d2[0], d4[0]}, [r0]void vst3q_lane_u32(__transfersize(3) uint32_t * ptr, uint32x4x3_t val, __constrange(0,3) int lane);


NEON 지원 사용

// VST3.32 {d0[0], d2[0], d4[0]}, [r0]void vst3q_lane_s16(__transfersize(3) int16_t * ptr, int16x8x3_t val, __constrange(0,7) int lane); // VST3.16 {d0[0], d2[0], d4[0]}, [r0]void vst3q_lane_s32(__transfersize(3) int32_t * ptr, int32x4x3_t val, __constrange(0,3) int lane); // VST3.32 {d0[0], d2[0], d4[0]}, [r0]void vst3q_lane_f16(__transfersize(3) __fp16 * ptr, float16x8x3_t val, __constrange(0,7) int lane); // VST3.16 {d0[0], d2[0], d4[0]}, [r0]void vst3q_lane_f32(__transfersize(3) float32_t * ptr, float32x4x3_t val, __constrange(0,3) int lane); // VST3.32 {d0[0], d2[0], d4[0]}, [r0]void vst3q_lane_p16(__transfersize(3) poly16_t * ptr, poly16x8x3_t val, __constrange(0,7) int lane); // VST3.16 {d0[0], d2[0], d4[0]}, [r0]void vst3_lane_u8(__transfersize(3) uint8_t * ptr, uint8x8x3_t val, __constrange(0,7) int lane); // VST3.8 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_u16(__transfersize(3) uint16_t * ptr, uint16x4x3_t val, __constrange(0,3) int lane); // VST3.16 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_u32(__transfersize(3) uint32_t * ptr, uint32x2x3_t val, __constrange(0,1) int lane); // VST3.32 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_s8(__transfersize(3) int8_t * ptr, int8x8x3_t val, __constrange(0,7) int lane); // VST3.8 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_s16(__transfersize(3) int16_t * ptr, int16x4x3_t val, __constrange(0,3) int lane); // VST3.16 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_s32(__transfersize(3) int32_t * ptr, int32x2x3_t val, __constrange(0,1) int lane); // VST3.32 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_f16(__transfersize(3) __fp16 * ptr, float16x4x3_t val, __constrange(0,3) int lane); // VST3.16 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_f32(__transfersize(3) float32_t * ptr, float32x2x3_t val, __constrange(0,1) int lane); // VST3.32 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_p8(__transfersize(3) poly8_t * ptr, poly8x8x3_t val, __constrange(0,7) int lane); // VST3.8 {d0[0], d1[0], d2[0]}, [r0]void vst3_lane_p16(__transfersize(3) poly16_t * ptr, poly16x4x3_t val, __constrange(0,3) int lane); // VST3.16 {d0[0], d1[0], d2[0]}, [r0]void vst4q_lane_u16(__transfersize(4) uint16_t * ptr, uint16x8x4_t val, __constrange(0,7) int lane); // VST4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4q_lane_u32(__transfersize(4) uint32_t * ptr, uint32x4x4_t val, __constrange(0,3) int lane); // VST4.32 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4q_lane_s16(__transfersize(4) int16_t * ptr, int16x8x4_t val, __constrange(0,7) int lane); // VST4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4q_lane_s32(__transfersize(4) int32_t * ptr, int32x4x4_t val, __constrange(0,3) int lane); // VST4.32 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4q_lane_f16(__transfersize(4) __fp16 * ptr, float16x8x4_t val, __constrange(0,7) int lane); // VST4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4q_lane_f32(__transfersize(4) float32_t * ptr, float32x4x4_t val, __constrange(0,3) int lane); // VST4.32 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4q_lane_p16(__transfersize(4) poly16_t * ptr, poly16x8x4_t val, __constrange(0,7) int lane); // VST4.16 {d0[0], d2[0], d4[0], d6[0]}, [r0]void vst4_lane_u8(__transfersize(4) uint8_t * ptr, uint8x8x4_t val, __constrange(0,7) int lane); // VST4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_u16(__transfersize(4) uint16_t * ptr, uint16x4x4_t val, __constrange(0,3) int lane); // VST4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]


NEON 지원 사용

void vst4_lane_u32(__transfersize(4) uint32_t * ptr, uint32x2x4_t val, __constrange(0,1) int lane);

// VST4.32 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_s8(__transfersize(4) int8_t * ptr, int8x8x4_t val, __constrange(0,7) int lane); // VST4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_s16(__transfersize(4) int16_t * ptr, int16x4x4_t val, __constrange(0,3) int lane); // VST4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_s32(__transfersize(4) int32_t * ptr, int32x2x4_t val, __constrange(0,1) int lane); // VST4.32 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_f16(__transfersize(4) __fp16 * ptr, float16x4x4_t val, __constrange(0,3) int lane); // VST4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_f32(__transfersize(4) float32_t * ptr, float32x2x4_t val, __constrange(0,1) int lane); // VST4.32 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_p8(__transfersize(4) poly8_t * ptr, poly8x8x4_t val, __constrange(0,7) int lane); // VST4.8 {d0[0], d1[0], d2[0], d3[0]}, [r0]void vst4_lane_p16(__transfersize(4) poly16_t * ptr, poly16x4x4_t val, __constrange(0,3) int lane); // VST4.16 {d0[0], d1[0], d2[0], d3[0]}, [r0]

E.3.16 벡터에서 레인 추출

다음 내장 함수는 벡터에서 단일 레인(요소)을 추출합니다.

uint8_t vget_lane_u8(uint8x8_t vec, __constrange(0,7) int lane); // VMOV.U8 r0, d0[0] uint16_t vget_lane_u16(uint16x4_t vec, __constrange(0,3) int lane); // VMOV.U16 r0, d0[0]uint32_t vget_lane_u32(uint32x2_t vec, __constrange(0,1) int lane); // VMOV.32 r0, d0[0] int8_t vget_lane_s8(int8x8_t vec, __constrange(0,7) int lane); // VMOV.S8 r0, d0[0] int16_t vget_lane_s16(int16x4_t vec, __constrange(0,3) int lane); // VMOV.S16 r0, d0[0]int32_t vget_lane_s32(int32x2_t vec, __constrange(0,1) int lane); // VMOV.32 r0, d0[0] poly8_t vget_lane_p8(poly8x8_t vec, __constrange(0,7) int lane); // VMOV.U8 r0, d0[0] poly16_t vget_lane_p16(poly16x4_t vec, __constrange(0,3) int lane); // VMOV.U16 r0, d0[0]float32_t vget_lane_f32(float32x2_t vec, __constrange(0,1) int lane); // VMOV.32 r0, d0[0] uint8_t vgetq_lane_u8(uint8x16_t vec, __constrange(0,15) int lane); // VMOV.U8 r0, d0[0] uint16_t vgetq_lane_u16(uint16x8_t vec, __constrange(0,7) int lane); // VMOV.U16 r0, d0[0]uint32_t vgetq_lane_u32(uint32x4_t vec, __constrange(0,3) int lane); // VMOV.32 r0, d0[0] int8_t vgetq_lane_s8(int8x16_t vec, __constrange(0,15) int lane); // VMOV.S8 r0, d0[0] int16_t vgetq_lane_s16(int16x8_t vec, __constrange(0,7) int lane); // VMOV.S16 r0, d0[0]int32_t vgetq_lane_s32(int32x4_t vec, __constrange(0,3) int lane); // VMOV.32 r0, d0[0] poly8_t vgetq_lane_p8(poly8x16_t vec, __constrange(0,15) int lane); // VMOV.U8 r0, d0[0] poly16_t vgetq_lane_p16(poly16x8_t vec, __constrange(0,7) int lane); // VMOV.U16 r0, d0[0]float32_t vgetq_lane_f32(float32x4_t vec, __constrange(0,3) int lane); // VMOV.32 r0, d0[0] int64_t vget_lane_s64(int64x1_t vec, __constrange(0,0) int lane); // VMOV r0,r0,d0 uint64_t vget_lane_u64(uint64x1_t vec, __constrange(0,0) int lane); // VMOV r0,r0,d0 int64_t vgetq_lane_s64(int64x2_t vec, __constrange(0,1) int lane); // VMOV r0,r0,d0 uint64_t vgetq_lane_u64(uint64x2_t vec, __constrange(0,1) int lane); // VMOV r0,r0,d0

E.3.17 벡터 내에 레인 설정

다음 내장 함수는 벡터 내에 단일 레인(요소)을 설정합니다.


NEON 지원 사용

uint8x8_t vset_lane_u8(uint8_t value, uint8x8_t vec, __constrange(0,7) int lane); // VMOV.8 d0[0],r0uint16x4_t vset_lane_u16(uint16_t value, uint16x4_t vec, __constrange(0,3) int lane); // VMOV.16 d0[0],r0uint32x2_t vset_lane_u32(uint32_t value, uint32x2_t vec, __constrange(0,1) int lane); // VMOV.32 d0[0],r0int8x8_t vset_lane_s8(int8_t value, int8x8_t vec, __constrange(0,7) int lane); // VMOV.8 d0[0],r0int16x4_t vset_lane_s16(int16_t value, int16x4_t vec, __constrange(0,3) int lane); // VMOV.16 d0[0],r0int32x2_t vset_lane_s32(int32_t value, int32x2_t vec, __constrange(0,1) int lane); // VMOV.32 d0[0],r0poly8x8_t vset_lane_p8(poly8_t value, poly8x8_t vec, __constrange(0,7) int lane); // VMOV.8 d0[0],r0poly16x4_t vset_lane_p16(poly16_t value, poly16x4_t vec, __constrange(0,3) int lane); // VMOV.16 d0[0],r0float32x2_t vset_lane_f32(float32_t value, float32x2_t vec, __constrange(0,1) int lane); // VMOV.32 d0[0],r0uint8x16_t vsetq_lane_u8(uint8_t value, uint8x16_t vec, __constrange(0,15) int lane); // VMOV.8 d0[0],r0uint16x8_t vsetq_lane_u16(uint16_t value, uint16x8_t vec, __constrange(0,7) int lane); // VMOV.16 d0[0],r0uint32x4_t vsetq_lane_u32(uint32_t value, uint32x4_t vec, __constrange(0,3) int lane); // VMOV.32 d0[0],r0int8x16_t vsetq_lane_s8(int8_t value, int8x16_t vec, __constrange(0,15) int lane); // VMOV.8 d0[0],r0int16x8_t vsetq_lane_s16(int16_t value, int16x8_t vec, __constrange(0,7) int lane); // VMOV.16 d0[0],r0int32x4_t vsetq_lane_s32(int32_t value, int32x4_t vec, __constrange(0,3) int lane); // VMOV.32 d0[0],r0poly8x16_t vsetq_lane_p8(poly8_t value, poly8x16_t vec, __constrange(0,15) int lane); // VMOV.8 d0[0],r0poly16x8_t vsetq_lane_p16(poly16_t value, poly16x8_t vec, __constrange(0,7) int lane); // VMOV.16 d0[0],r0float32x4_t vsetq_lane_f32(float32_t value, float32x4_t vec, __constrange(0,3) int lane); // VMOV.32 d0[0],r0int64x1_t vset_lane_s64(int64_t value, int64x1_t vec, __constrange(0,0) int lane); // VMOV d0,r0,r0uint64x1_t vset_lane_u64(uint64_t value, uint64x1_t vec, __constrange(0,0) int lane); // VMOV d0,r0,r0int64x2_t vsetq_lane_s64(int64_t value, int64x2_t vec, __constrange(0,1) int lane); // VMOV d0,r0,r0uint64x2_t vsetq_lane_u64(uint64_t value, uint64x2_t vec, __constrange(0,1) int lane); // VMOV d0,r0,r0

E.3.18 비트 패턴에서 벡터 초기화

다음 내장 함수는 리터럴 비트 패턴에서 벡터를 생성합니다.


NEON 지원 사용

int8x8_t vcreate_s8(uint64_t a); // VMOV d0,r0,r0int16x4_t vcreate_s16(uint64_t a); // VMOV d0,r0,r0int32x2_t vcreate_s32(uint64_t a); // VMOV d0,r0,r0float16x4_t vcreate_f16(uint64_t a); // VMOV d0,r0,r0float32x2_t vcreate_f32(uint64_t a); // VMOV d0,r0,r0uint8x8_t vcreate_u8(uint64_t a); // VMOV d0,r0,r0uint16x4_t vcreate_u16(uint64_t a); // VMOV d0,r0,r0uint32x2_t vcreate_u32(uint64_t a); // VMOV d0,r0,r0uint64x1_t vcreate_u64(uint64_t a); // VMOV d0,r0,r0poly8x8_t vcreate_p8(uint64_t a); // VMOV d0,r0,r0poly16x4_t vcreate_p16(uint64_t a); // VMOV d0,r0,r0int64x1_t vcreate_s64(uint64_t a); // VMOV d0,r0,r0

E.3.19 모든 레인을 같은 값으로 설정

다음 내장 함수는 모든 레인을 같은 값으로 설정합니다.

모든 레인을 같은 값으로 설정

uint8x8_t vdup_n_u8(uint8_t value); // VDUP.8 d0,r0 uint16x4_t vdup_n_u16(uint16_t value); // VDUP.16 d0,r0uint32x2_t vdup_n_u32(uint32_t value); // VDUP.32 d0,r0int8x8_t vdup_n_s8(int8_t value); // VDUP.8 d0,r0 int16x4_t vdup_n_s16(int16_t value); // VDUP.16 d0,r0int32x2_t vdup_n_s32(int32_t value); // VDUP.32 d0,r0poly8x8_t vdup_n_p8(poly8_t value); // VDUP.8 d0,r0 poly16x4_t vdup_n_p16(poly16_t value); // VDUP.16 d0,r0float32x2_t vdup_n_f32(float32_t value); // VDUP.32 d0,r0uint8x16_t vdupq_n_u8(uint8_t value); // VDUP.8 q0,r0 uint16x8_t vdupq_n_u16(uint16_t value); // VDUP.16 q0,r0uint32x4_t vdupq_n_u32(uint32_t value); // VDUP.32 q0,r0int8x16_t vdupq_n_s8(int8_t value); // VDUP.8 q0,r0 int16x8_t vdupq_n_s16(int16_t value); // VDUP.16 q0,r0int32x4_t vdupq_n_s32(int32_t value); // VDUP.32 q0,r0poly8x16_t vdupq_n_p8(poly8_t value); // VDUP.8 q0,r0 poly16x8_t vdupq_n_p16(poly16_t value); // VDUP.16 q0,r0float32x4_t vdupq_n_f32(float32_t value); // VDUP.32 q0,r0int64x1_t vdup_n_s64(int64_t value); // VMOV d0,r0,r0uint64x1_t vdup_n_u64(uint64_t value); // VMOV d0,r0,r0int64x2_t vdupq_n_s64(int64_t value); // VMOV d0,r0,r0uint64x2_t vdupq_n_u64(uint64_t value); // VMOV d0,r0,r0uint8x8_t vmov_n_u8(uint8_t value); // VDUP.8 d0,r0 uint16x4_t vmov_n_u16(uint16_t value); // VDUP.16 d0,r0uint32x2_t vmov_n_u32(uint32_t value); // VDUP.32 d0,r0int8x8_t vmov_n_s8(int8_t value); // VDUP.8 d0,r0 int16x4_t vmov_n_s16(int16_t value); // VDUP.16 d0,r0int32x2_t vmov_n_s32(int32_t value); // VDUP.32 d0,r0poly8x8_t vmov_n_p8(poly8_t value); // VDUP.8 d0,r0


NEON 지원 사용

poly16x4_t vmov_n_p16(poly16_t value); // VDUP.16 d0,r0float32x2_t vmov_n_f32(float32_t value); // VDUP.32 d0,r0uint8x16_t vmovq_n_u8(uint8_t value); // VDUP.8 q0,r0 uint16x8_t vmovq_n_u16(uint16_t value); // VDUP.16 q0,r0uint32x4_t vmovq_n_u32(uint32_t value); // VDUP.32 q0,r0int8x16_t vmovq_n_s8(int8_t value); // VDUP.8 q0,r0 int16x8_t vmovq_n_s16(int16_t value); // VDUP.16 q0,r0int32x4_t vmovq_n_s32(int32_t value); // VDUP.32 q0,r0poly8x16_t vmovq_n_p8(poly8_t value); // VDUP.8 q0,r0 poly16x8_t vmovq_n_p16(poly16_t value); // VDUP.16 q0,r0float32x4_t vmovq_n_f32(float32_t value); // VDUP.32 q0,r0int64x1_t vmov_n_s64(int64_t value); // VMOV d0,r0,r0uint64x1_t vmov_n_u64(uint64_t value); // VMOV d0,r0,r0int64x2_t vmovq_n_s64(int64_t value); // VMOV d0,r0,r0uint64x2_t vmovq_n_u64(uint64_t value); // VMOV d0,r0,r0

모든 레인을 벡터에 있는 한 레인의 값으로 설정

uint8x8_t vdup_lane_u8(uint8x8_t vec, __constrange(0,7) int lane); // VDUP.8 d0,d0[0] uint16x4_t vdup_lane_u16(uint16x4_t vec, __constrange(0,3) int lane); // VDUP.16 d0,d0[0]uint32x2_t vdup_lane_u32(uint32x2_t vec, __constrange(0,1) int lane); // VDUP.32 d0,d0[0]int8x8_t vdup_lane_s8(int8x8_t vec, __constrange(0,7) int lane); // VDUP.8 d0,d0[0] int16x4_t vdup_lane_s16(int16x4_t vec, __constrange(0,3) int lane); // VDUP.16 d0,d0[0]int32x2_t vdup_lane_s32(int32x2_t vec, __constrange(0,1) int lane); // VDUP.32 d0,d0[0]poly8x8_t vdup_lane_p8(poly8x8_t vec, __constrange(0,7) int lane); // VDUP.8 d0,d0[0] poly16x4_t vdup_lane_p16(poly16x4_t vec, __constrange(0,3) int lane); // VDUP.16 d0,d0[0]float32x2_t vdup_lane_f32(float32x2_t vec, __constrange(0,1) int lane); // VDUP.32 d0,d0[0]uint8x16_t vdupq_lane_u8(uint8x8_t vec, __constrange(0,7) int lane); // VDUP.8 q0,d0[0] uint16x8_t vdupq_lane_u16(uint16x4_t vec, __constrange(0,3) int lane); // VDUP.16 q0,d0[0]uint32x4_t vdupq_lane_u32(uint32x2_t vec, __constrange(0,1) int lane); // VDUP.32 q0,d0[0]int8x16_t vdupq_lane_s8(int8x8_t vec, __constrange(0,7) int lane); // VDUP.8 q0,d0[0] int16x8_t vdupq_lane_s16(int16x4_t vec, __constrange(0,3) int lane); // VDUP.16 q0,d0[0]int32x4_t vdupq_lane_s32(int32x2_t vec, __constrange(0,1) int lane); // VDUP.32 q0,d0[0]poly8x16_t vdupq_lane_p8(poly8x8_t vec, __constrange(0,7) int lane); // VDUP.8 q0,d0[0] poly16x8_t vdupq_lane_p16(poly16x4_t vec, __constrange(0,3) int lane); // VDUP.16 q0,d0[0]float32x4_t vdupq_lane_f32(float32x2_t vec, __constrange(0,1) int lane); // VDUP.32 q0,d0[0]int64x1_t vdup_lane_s64(int64x1_t vec, __constrange(0,0) int lane); // VMOV d0,d0 uint64x1_t vdup_lane_u64(uint64x1_t vec, __constrange(0,0) int lane); // VMOV d0,d0 int64x2_t vdupq_lane_s64(int64x1_t vec, __constrange(0,0) int lane); // VMOV q0,q0 uint64x2_t vdupq_lane_u64(uint64x1_t vec, __constrange(0,0) int lane); // VMOV q0,q0

E.3.20 벡터 결합

다음 내장 함수는 두 개의 64비트 벡터를 한 개의 128비트 벡터로 결합합니다.

int8x16_t vcombine_s8(int8x8_t low, int8x8_t high); // VMOV d0,d0int16x8_t vcombine_s16(int16x4_t low, int16x4_t high); // VMOV d0,d0int32x4_t vcombine_s32(int32x2_t low, int32x2_t high); // VMOV d0,d0


NEON 지원 사용

int64x2_t vcombine_s64(int64x1_t low, int64x1_t high); // VMOV d0,d0float16x8_t vcombine_f16(float16x4_t low, float16x4_t high); // VMOV d0,d0float32x4_t vcombine_f32(float32x2_t low, float32x2_t high); // VMOV d0,d0uint8x16_t vcombine_u8(uint8x8_t low, uint8x8_t high); // VMOV d0,d0uint16x8_t vcombine_u16(uint16x4_t low, uint16x4_t high); // VMOV d0,d0uint32x4_t vcombine_u32(uint32x2_t low, uint32x2_t high); // VMOV d0,d0uint64x2_t vcombine_u64(uint64x1_t low, uint64x1_t high); // VMOV d0,d0poly8x16_t vcombine_p8(poly8x8_t low, poly8x8_t high); // VMOV d0,d0poly16x8_t vcombine_p16(poly16x4_t low, poly16x4_t high); // VMOV d0,d0

E.3.21 벡터 분할

다음 내장 함수는 128비트 벡터를 2개의 구성요소 64비트 벡터로 분할합니다.

int8x8_t vget_high_s8(int8x16_t a); // VMOV d0,d0int16x4_t vget_high_s16(int16x8_t a); // VMOV d0,d0int32x2_t vget_high_s32(int32x4_t a); // VMOV d0,d0int64x1_t vget_high_s64(int64x2_t a); // VMOV d0,d0float16x4_t vget_high_f16(float16x8_t a); // VMOV d0,d0float32x2_t vget_high_f32(float32x4_t a); // VMOV d0,d0uint8x8_t vget_high_u8(uint8x16_t a); // VMOV d0,d0uint16x4_t vget_high_u16(uint16x8_t a); // VMOV d0,d0uint32x2_t vget_high_u32(uint32x4_t a); // VMOV d0,d0uint64x1_t vget_high_u64(uint64x2_t a); // VMOV d0,d0poly8x8_t vget_high_p8(poly8x16_t a); // VMOV d0,d0poly16x4_t vget_high_p16(poly16x8_t a); // VMOV d0,d0int8x8_t vget_low_s8(int8x16_t a); // VMOV d0,d0int16x4_t vget_low_s16(int16x8_t a); // VMOV d0,d0int32x2_t vget_low_s32(int32x4_t a); // VMOV d0,d0int64x1_t vget_low_s64(int64x2_t a); // VMOV d0,d0float16x4_t vget_low_f16(float16x8_t a); // VMOV d0,d0float32x2_t vget_low_f32(float32x4_t a); // VMOV d0,d0uint8x8_t vget_low_u8(uint8x16_t a); // VMOV d0,d0uint16x4_t vget_low_u16(uint16x8_t a); // VMOV d0,d0uint32x2_t vget_low_u32(uint32x4_t a); // VMOV d0,d0uint64x1_t vget_low_u64(uint64x2_t a); // VMOV d0,d0poly8x8_t vget_low_p8(poly8x16_t a); // VMOV d0,d0poly16x4_t vget_low_p16(poly16x8_t a); // VMOV d0,d0

E.3.22 벡터 변환

다음 내장 함수는 벡터를 변환하는 데 사용됩니다.

부동 값에서 변환

int32x2_t vcvt_s32_f32(float32x2_t a); // VCVT.S32.F32 d0, d0 uint32x2_t vcvt_u32_f32(float32x2_t a); // VCVT.U32.F32 d0, d0 int32x4_t vcvtq_s32_f32(float32x4_t a); // VCVT.S32.F32 q0, q0


NEON 지원 사용

uint32x4_t vcvtq_u32_f32(float32x4_t a); // VCVT.U32.F32 q0, q0 int32x2_t vcvt_n_s32_f32(float32x2_t a, __constrange(1,32) int b); // VCVT.S32.F32 d0, d0, #32uint32x2_t vcvt_n_u32_f32(float32x2_t a, __constrange(1,32) int b); // VCVT.U32.F32 d0, d0, #32int32x4_t vcvtq_n_s32_f32(float32x4_t a, __constrange(1,32) int b); // VCVT.S32.F32 q0, q0, #32uint32x4_t vcvtq_n_u32_f32(float32x4_t a, __constrange(1,32) int b); // VCVT.U32.F32 q0, q0, #32

부동 값으로 변환

float32x2_t vcvt_f32_s32(int32x2_t a); // VCVT.F32.S32 d0, d0 float32x2_t vcvt_f32_u32(uint32x2_t a); // VCVT.F32.U32 d0, d0 float32x4_t vcvtq_f32_s32(int32x4_t a); // VCVT.F32.S32 q0, q0 float32x4_t vcvtq_f32_u32(uint32x4_t a); // VCVT.F32.U32 q0, q0 float32x2_t vcvt_n_f32_s32(int32x2_t a, __constrange(1,32) int b); // VCVT.F32.S32 d0, d0, #32float32x2_t vcvt_n_f32_u32(uint32x2_t a, __constrange(1,32) int b); // VCVT.F32.U32 d0, d0, #32float32x4_t vcvtq_n_f32_s32(int32x4_t a, __constrange(1,32) int b); // VCVT.F32.S32 q0, q0, #32float32x4_t vcvtq_n_f32_u32(uint32x4_t a, __constrange(1,32) int b); // VCVT.F32.U32 q0, q0, #32

float 간 변환

float16x4_t vcvt_f16_f32(float32x4_t a); // VCVT.F16.F32 d0, q0float32x4_t vcvt_f32_f16(float16x4_t a); // VCVT.F32.F16 q0, d0

벡터 축소 정수

int8x8_t vmovn_s16(int16x8_t a); // VMOVN.I16 d0,q0int16x4_t vmovn_s32(int32x4_t a); // VMOVN.I32 d0,q0int32x2_t vmovn_s64(int64x2_t a); // VMOVN.I64 d0,q0uint8x8_t vmovn_u16(uint16x8_t a); // VMOVN.I16 d0,q0uint16x4_t vmovn_u32(uint32x4_t a); // VMOVN.I32 d0,q0uint32x2_t vmovn_u64(uint64x2_t a); // VMOVN.I64 d0,q0

벡터 long 이동

int16x8_t vmovl_s8(int8x8_t a); // VMOVL.S8 q0,d0 int32x4_t vmovl_s16(int16x4_t a); // VMOVL.S16 q0,d0int64x2_t vmovl_s32(int32x2_t a); // VMOVL.S32 q0,d0uint16x8_t vmovl_u8(uint8x8_t a); // VMOVL.U8 q0,d0 uint32x4_t vmovl_u16(uint16x4_t a); // VMOVL.U16 q0,d0uint64x2_t vmovl_u32(uint32x2_t a); // VMOVL.U32 q0,d0

벡터 포화 축소 정수

int8x8_t vqmovn_s16(int16x8_t a); // VQMOVN.S16 d0,q0int16x4_t vqmovn_s32(int32x4_t a); // VQMOVN.S32 d0,q0int32x2_t vqmovn_s64(int64x2_t a); // VQMOVN.S64 d0,q0


NEON 지원 사용

uint8x8_t vqmovn_u16(uint16x8_t a); // VQMOVN.U16 d0,q0uint16x4_t vqmovn_u32(uint32x4_t a); // VQMOVN.U32 d0,q0uint32x2_t vqmovn_u64(uint64x2_t a); // VQMOVN.U64 d0,q0

부호 있는- >부호 없는 벡터 포화 축소 정수

uint8x8_t vqmovun_s16(int16x8_t a); // VQMOVUN.S16 d0,q0uint16x4_t vqmovun_s32(int32x4_t a); // VQMOVUN.S32 d0,q0uint32x2_t vqmovun_s64(int64x2_t a); // VQMOVUN.S64 d0,q0

E.3.23 테이블 조회

uint8x8_t vtbl1_u8(uint8x8_t a, uint8x8_t b); // VTBL.8 d0, {d0}, d0 int8x8_t vtbl1_s8(int8x8_t a, int8x8_t b); // VTBL.8 d0, {d0}, d0poly8x8_t vtbl1_p8(poly8x8_t a, uint8x8_t b); // VTBL.8 d0, {d0}, d0 uint8x8_t vtbl2_u8(uint8x8x2_t a, uint8x8_t b); // VTBL.8 d0, {d0, d1}, d0 int8x8_t vtbl2_s8(int8x8x2_t a, int8x8_t b); // VTBL.8 d0, {d0, d1}, d0 poly8x8_t vtbl2_p8(poly8x8x2_t a, uint8x8_t b); // VTBL.8 d0, {d0, d1}, d0 uint8x8_t vtbl3_u8(uint8x8x3_t a, uint8x8_t b); // VTBL.8 d0, {d0, d1, d2}, d0 int8x8_t vtbl3_s8(int8x8x3_t a, int8x8_t b); // VTBL.8 d0, {d0, d1, d2}, d0poly8x8_t vtbl3_p8(poly8x8x3_t a, uint8x8_t b); // VTBL.8 d0, {d0, d1, d2}, d0 uint8x8_t vtbl4_u8(uint8x8x4_t a, uint8x8_t b); // VTBL.8 d0, {d0, d1, d2, d3}, d0int8x8_t vtbl4_s8(int8x8x4_t a, int8x8_t b); // VTBL.8 d0, {d0, d1, d2, d3}, d0poly8x8_t vtbl4_p8(poly8x8x4_t a, uint8x8_t b); // VTBL.8 d0, {d0, d1, d2, d3}, d0

E.3.24 확장된 테이블 조회 내장 함수

uint8x8_t vtbx1_u8(uint8x8_t a, uint8x8_t b, uint8x8_t c); // VTBX.8 d0, {d0}, d0 int8x8_t vtbx1_s8(int8x8_t a, int8x8_t b, int8x8_t c); // VTBX.8 d0, {d0}, d0 poly8x8_t vtbx1_p8(poly8x8_t a, poly8x8_t b, uint8x8_t c); // VTBX.8 d0, {d0}, d0 uint8x8_t vtbx2_u8(uint8x8_t a, uint8x8x2_t b, uint8x8_t c); // VTBX.8 d0, {d0, d1}, d0 int8x8_t vtbx2_s8(int8x8_t a, int8x8x2_t b, int8x8_t c); // VTBX.8 d0, {d0, d1}, d0 poly8x8_t vtbx2_p8(poly8x8_t a, poly8x8x2_t b, uint8x8_t c); // VTBX.8 d0, {d0, d1}, d0 uint8x8_t vtbx3_u8(uint8x8_t a, uint8x8x3_t b, uint8x8_t c); // VTBX.8 d0, {d0, d1, d2}, d0 int8x8_t vtbx3_s8(int8x8_t a, int8x8x3_t b, int8x8_t c); // VTBX.8 d0, {d0, d1, d2}, d0poly8x8_t vtbx3_p8(poly8x8_t a, poly8x8x3_t b, uint8x8_t c); // VTBX.8 d0, {d0, d1, d2}, d0 uint8x8_t vtbx4_u8(uint8x8_t a, uint8x8x4_t b, uint8x8_t c); // VTBX.8 d0, {d0, d1, d2, d3}, d0int8x8_t vtbx4_s8(int8x8_t a, int8x8x4_t b, int8x8_t c); // VTBX.8 d0, {d0, d1, d2, d3}, d0poly8x8_t vtbx4_p8(poly8x8_t a, poly8x8x4_t b, uint8x8_t c); // VTBX.8 d0, {d0, d1, d2, d3}, d0

E.3.25 스칼라 값이 있는 연산

스칼라 인수가 상수이거나 vget_lane 내장 함수 중 하나를 사용하는 경우에만 다음 내장 함수에 대해 유효한 코드를 생성할 수 있습니다.


NEON 지원 사용

스칼라가 있는 벡터 곱하기 누산

int16x4_t vmla_lane_s16(int16x4_t a, int16x4_t b, int16x4_t v, __constrange(0,3) int l); // VMLA.I16 d0, d0, d0[0]int32x2_t vmla_lane_s32(int32x2_t a, int32x2_t b, int32x2_t v, __constrange(0,1) int l); // VMLA.I32 d0, d0, d0[0]uint16x4_t vmla_lane_u16(uint16x4_t a, uint16x4_t b, uint16x4_t v, __constrange(0,3) int l); // VMLA.I16 d0, d0, d0[0]uint32x2_t vmla_lane_u32(uint32x2_t a, uint32x2_t b, uint32x2_t v, __constrange(0,1) int l); // VMLA.I32 d0, d0, d0[0]float32x2_t vmla_lane_f32(float32x2_t a, float32x2_t b, float32x2_t v, __constrange(0,1) int l); // VMLA.F32 d0, d0, d0[0]int16x8_t vmlaq_lane_s16(int16x8_t a, int16x8_t b, int16x4_t v, __constrange(0,3) int l); // VMLA.I16 q0, q0, d0[0]int32x4_t vmlaq_lane_s32(int32x4_t a, int32x4_t b, int32x2_t v, __constrange(0,1) int l); // VMLA.I32 q0, q0, d0[0]uint16x8_t vmlaq_lane_u16(uint16x8_t a, uint16x8_t b, uint16x4_t v, __constrange(0,3) int l); // VMLA.I16 q0, q0, d0[0]uint32x4_t vmlaq_lane_u32(uint32x4_t a, uint32x4_t b, uint32x2_t v, __constrange(0,1) int l); // VMLA.I32 q0, q0, d0[0]float32x4_t vmlaq_lane_f32(float32x4_t a, float32x4_t b, float32x2_t v, __constrange(0,1) int l); // VMLA.F32 q0, q0, d0[0]

스칼라가 있는 벡터 확장 곱하기 누산

int32x4_t vmlal_lane_s16(int32x4_t a, int16x4_t b, int16x4_t v, __constrange(0,3) int l); // VMLAL.S16 q0, d0, d0[0]int64x2_t vmlal_lane_s32(int64x2_t a, int32x2_t b, int32x2_t v, __constrange(0,1) int l); // VMLAL.S32 q0, d0, d0[0]uint32x4_t vmlal_lane_u16(uint32x4_t a, uint16x4_t b, uint16x4_t v, __constrange(0,3) int l); // VMLAL.U16 q0, d0, d0[0]uint64x2_t vmlal_lane_u32(uint64x2_t a, uint32x2_t b, uint32x2_t v, __constrange(0,1) int l); // VMLAL.U32 q0, d0, d0[0]

스칼라가 있는 벡터 확장 포화 배수화 곱하기 누산

int32x4_t vqdmlal_lane_s16(int32x4_t a, int16x4_t b, int16x4_t v, __constrange(0,3) int l); // VQDMLAL.S16 q0, d0, d0[0]int64x2_t vqdmlal_lane_s32(int64x2_t a, int32x2_t b, int32x2_t v, __constrange(0,1) int l); // VQDMLAL.S32 q0, d0, d0[0]

스칼라가 있는 벡터 곱하기 빼기

int16x4_t vmls_lane_s16(int16x4_t a, int16x4_t b, int16x4_t v, __constrange(0,3) int l); // VMLS.I16 d0, d0, d0[0]int32x2_t vmls_lane_s32(int32x2_t a, int32x2_t b, int32x2_t v, __constrange(0,1) int l); // VMLS.I32 d0, d0, d0[0]uint16x4_t vmls_lane_u16(uint16x4_t a, uint16x4_t b, uint16x4_t v, __constrange(0,3) int l);


NEON 지원 사용

// VMLS.I16 d0, d0, d0[0]uint32x2_t vmls_lane_u32(uint32x2_t a, uint32x2_t b, uint32x2_t v, __constrange(0,1) int l); // VMLS.I32 d0, d0, d0[0]float32x2_t vmls_lane_f32(float32x2_t a, float32x2_t b, float32x2_t v, __constrange(0,1) int l); // VMLS.F32 d0, d0, d0[0]int16x8_t vmlsq_lane_s16(int16x8_t a, int16x8_t b, int16x4_t v, __constrange(0,3) int l); // VMLS.I16 q0, q0, d0[0]int32x4_t vmlsq_lane_s32(int32x4_t a, int32x4_t b, int32x2_t v, __constrange(0,1) int l); // VMLS.I32 q0, q0, d0[0]uint16x8_t vmlsq_lane_u16(uint16x8_t a, uint16x8_t b, uint16x4_t v, __constrange(0,3) int l); // VMLS.I16 q0, q0, d0[0]uint32x4_t vmlsq_lane_u32(uint32x4_t a, uint32x4_t b, uint32x2_t v, __constrange(0,1) int l); // VMLS.I32 q0, q0, d0[0]float32x4_t vmlsq_lane_f32(float32x4_t a, float32x4_t b, float32x2_t v, __constrange(0,1) int l); // VMLS.F32 q0, q0, d0[0]

스칼라가 있는 벡터 확장 곱하기 빼기

int32x4_t vmlsl_lane_s16(int32x4_t a, int16x4_t b, int16x4_t v, __constrange(0,3) int l); // VMLSL.S16 q0, d0, d0[0]int64x2_t vmlsl_lane_s32(int64x2_t a, int32x2_t b, int32x2_t v, __constrange(0,1) int l); // VMLSL.S32 q0, d0, d0[0]uint32x4_t vmlsl_lane_u16(uint32x4_t a, uint16x4_t b, uint16x4_t v, __constrange(0,3) int l); // VMLSL.U16 q0, d0, d0[0]uint64x2_t vmlsl_lane_u32(uint64x2_t a, uint32x2_t b, uint32x2_t v, __constrange(0,1) int l); // VMLSL.U32 q0, d0, d0[0]

스칼라가 있는 벡터 확장 포화 배수화 곱하기 빼기

int32x4_t vqdmlsl_lane_s16(int32x4_t a, int16x4_t b, int16x4_t v, __constrange(0,3) int l); // VQDMLSL.S16 q0, d0, d0[0]int64x2_t vqdmlsl_lane_s32(int64x2_t a, int32x2_t b, int32x2_t v, __constrange(0,1) int l); // VQDMLSL.S32 q0, d0, d0[0]

스칼라 기준 벡터 곱하기

int16x4_t vmul_n_s16(int16x4_t a, int16_t b); // VMUL.I16 d0,d0,d0[0]int32x2_t vmul_n_s32(int32x2_t a, int32_t b); // VMUL.I32 d0,d0,d0[0]float32x2_t vmul_n_f32(float32x2_t a, float32_t b); // VMUL.F32 d0,d0,d0[0]uint16x4_t vmul_n_u16(uint16x4_t a, uint16_t b); // VMUL.I16 d0,d0,d0[0]uint32x2_t vmul_n_u32(uint32x2_t a, uint32_t b); // VMUL.I32 d0,d0,d0[0]int16x8_t vmulq_n_s16(int16x8_t a, int16_t b); // VMUL.I16 q0,q0,d0[0]int32x4_t vmulq_n_s32(int32x4_t a, int32_t b); // VMUL.I32 q0,q0,d0[0]float32x4_t vmulq_n_f32(float32x4_t a, float32_t b); // VMUL.F32 q0,q0,d0[0]uint16x8_t vmulq_n_u16(uint16x8_t a, uint16_t b); // VMUL.I16 q0,q0,d0[0]uint32x4_t vmulq_n_u32(uint32x4_t a, uint32_t b); // VMUL.I32 q0,q0,d0[0]


NEON 지원 사용

스칼라가 있는 벡터 long 곱하기

int32x4_t vmull_n_s16(int16x4_t vec1, int16_t val2); // VMULL.S16 q0,d0,d0[0]int64x2_t vmull_n_s32(int32x2_t vec1, int32_t val2); // VMULL.S32 q0,d0,d0[0]uint32x4_t vmull_n_u16(uint16x4_t vec1, uint16_t val2); // VMULL.U16 q0,d0,d0[0]uint64x2_t vmull_n_u32(uint32x2_t vec1, uint32_t val2); // VMULL.U32 q0,d0,d0[0]

스칼라 기준 벡터 long 곱하기

int32x4_t vmull_lane_s16(int16x4_t vec1, int16x4_t val2, __constrange(0, 3) int val3);// VMULL.S16 q0,d0,d0[0]int64x2_t

vmull_lane_s32(int32x2_t vec1, int32x2_t val2, __constrange(0, 1) int val3);// VMULL.S32 q0,d0,d0[0]uint32x4_t

vmull_lane_u16(uint16x4_t vec1, uint16x4_t val2, __constrange(0, 3) int val3);// VMULL.U16 q0,d0,d0[0]uint64x2_t

vmull_lane_u32(uint32x2_t vec1, uint32x2_t val2, __constrange(0, 1) int val3);// VMULL.U32 q0,d0,d0[0]

스칼라가 있는 벡터 포화 배수화 long 곱하기

int32x4_t vqdmull_n_s16(int16x4_t vec1, int16_t val2); // VQDMULL.S16 q0,d0,d0[0]int64x2_t vqdmull_n_s32(int32x2_t vec1, int32_t val2); // VQDMULL.S32 q0,d0,d0[0]

스칼라 기준 포화 배수화 long 곱하기

int32x4_t vqdmull_lane_s16(int16x4_t vec1, int16x4_t val2, __constrange(0, 3) int val3);// VQDMULL.S16 q0,d0,d0[0]

int64x2_t vqdmull_lane_s32(int32x2_t vec1, int32x2_t val2, __constrange(0, 1) int val3);// VQDMULL.S32 q0,d0,d0[0]

스칼라가 있는 벡터 상위 포화 배수화 곱하기

int16x4_t vqdmulh_n_s16(int16x4_t vec1, int16_t val2); // VQDMULH.S16 d0,d0,d0[0]int32x2_t vqdmulh_n_s32(int32x2_t vec1, int32_t val2); // VQDMULH.S32 d0,d0,d0[0]int16x8_t vqdmulhq_n_s16(int16x8_t vec1, int16_t val2); // VQDMULH.S16 q0,q0,d0[0]int32x4_t vqdmulhq_n_s32(int32x4_t vec1, int32_t val2); // VQDMULH.S32 q0,q0,d0[0]

스칼라 기준 벡터 상위 포화 배수화 곱하기

int16x4_t vqdmulh_lane_s16(int16x4_t vec1, int16x4_t val2, __constrange(0, 3) int val3);// VQDMULH.S16 d0,d0,d0[0]

int32x2_t vqdmulh_lane_s32(int32x2_t vec1, int32x2_t val2, __constrange(0, 1) int val3);// VQDMULH.S32 d0,d0,d0[0]

int16x8_t vqdmulhq_lane_s16(int16x8_t vec1, int16x4_t val2, __constrange(0, 3) int val3);// VQDMULH.S16 q0,q0,d0[0]


NEON 지원 사용

int32x4_t vqdmulhq_lane_s32(int32x4_t vec1, int32x2_t val2, __constrange(0, 1) int val3);// VQDMULH.S32 q0,q0,d0[0]

스칼라가 있는 벡터 상위 포화 반올림 배수화 곱하기

int16x4_t vqrdmulh_n_s16(int16x4_t vec1, int16_t val2); // VQRDMULH.S16 d0,d0,d0[0]int32x2_t vqrdmulh_n_s32(int32x2_t vec1, int32_t val2); // VQRDMULH.S32 d0,d0,d0[0]int16x8_t vqrdmulhq_n_s16(int16x8_t vec1, int16_t val2); // VQRDMULH.S16 q0,q0,d0[0]int32x4_t vqrdmulhq_n_s32(int32x4_t vec1, int32_t val2); // VQRDMULH.S32 q0,q0,d0[0]

스칼라 기준 벡터 상위 반올림 포화 배수화 곱하기

int16x4_t vqrdmulh_lane_s16(int16x4_t vec1, int16x4_t val2, __constrange(0, 3) int val3);// VQRDMULH.S16 d0,d0,d0[0]

int32x2_t vqrdmulh_lane_s32(int32x2_t vec1, int32x2_t val2, __constrange(0, 1) int val3);// VQRDMULH.S32 d0,d0,d0[0]

int16x8_t vqrdmulhq_lane_s16(int16x8_t vec1, int16x4_t val2, __constrange(0, 3) int val3);// VQRDMULH.S16 q0,q0,d0[0]

int32x4_t vqrdmulhq_lane_s32(int32x4_t vec1, int32x2_t val2, __constrange(0, 1) int val3);// VQRDMULH.S32 q0,q0,d0[0]

스칼라가 있는 벡터 곱하기 누산

int16x4_t vmla_n_s16(int16x4_t a, int16x4_t b, int16_t c); // VMLA.I16 d0, d0, d0[0] int32x2_t vmla_n_s32(int32x2_t a, int32x2_t b, int32_t c); // VMLA.I32 d0, d0, d0[0] uint16x4_t vmla_n_u16(uint16x4_t a, uint16x4_t b, uint16_t c); // VMLA.I16 d0, d0, d0[0] uint32x2_t vmla_n_u32(uint32x2_t a, uint32x2_t b, uint32_t c); // VMLA.I32 d0, d0, d0[0] float32x2_t vmla_n_f32(float32x2_t a, float32x2_t b, float32_t c); // VMLA.F32 d0, d0, d0[0] int16x8_t vmlaq_n_s16(int16x8_t a, int16x8_t b, int16_t c); // VMLA.I16 q0, q0, d0[0] int32x4_t vmlaq_n_s32(int32x4_t a, int32x4_t b, int32_t c); // VMLA.I32 q0, q0, d0[0] uint16x8_t vmlaq_n_u16(uint16x8_t a, uint16x8_t b, uint16_t c); // VMLA.I16 q0, q0, d0[0] uint32x4_t vmlaq_n_u32(uint32x4_t a, uint32x4_t b, uint32_t c); // VMLA.I32 q0, q0, d0[0] float32x4_t vmlaq_n_f32(float32x4_t a, float32x4_t b, float32_t c); // VMLA.F32 q0, q0, d0[0]

스칼라가 있는 벡터 확장 곱하기 누산

int32x4_t vmlal_n_s16(int32x4_t a, int16x4_t b, int16_t c); // VMLAL.S16 q0, d0, d0[0] int64x2_t vmlal_n_s32(int64x2_t a, int32x2_t b, int32_t c); // VMLAL.S32 q0, d0, d0[0] uint32x4_t vmlal_n_u16(uint32x4_t a, uint16x4_t b, uint16_t c); // VMLAL.U16 q0, d0, d0[0] uint64x2_t vmlal_n_u32(uint64x2_t a, uint32x2_t b, uint32_t c); // VMLAL.U32 q0, d0, d0[0]

스칼라가 있는 벡터 확장 포화 배수화 곱하기 누산

int32x4_t vqdmlal_n_s16(int32x4_t a, int16x4_t b, int16_t c); // VQDMLAL.S16 q0, d0, d0[0] int64x2_t vqdmlal_n_s32(int64x2_t a, int32x2_t b, int32_t c); // VQDMLAL.S32 q0, d0, d0[0]


NEON 지원 사용

스칼라가 있는 벡터 곱하기 빼기

int16x4_t vmls_n_s16(int16x4_t a, int16x4_t b, int16_t c); // VMLS.I16 d0, d0, d0[0] int32x2_t vmls_n_s32(int32x2_t a, int32x2_t b, int32_t c); // VMLS.I32 d0, d0, d0[0] uint16x4_t vmls_n_u16(uint16x4_t a, uint16x4_t b, uint16_t c); // VMLS.I16 d0, d0, d0[0] uint32x2_t vmls_n_u32(uint32x2_t a, uint32x2_t b, uint32_t c); // VMLS.I32 d0, d0, d0[0] float32x2_t vmls_n_f32(float32x2_t a, float32x2_t b, float32_t c); // VMLS.F32 d0, d0, d0[0] int16x8_t vmlsq_n_s16(int16x8_t a, int16x8_t b, int16_t c); // VMLS.I16 q0, q0, d0[0] int32x4_t vmlsq_n_s32(int32x4_t a, int32x4_t b, int32_t c); // VMLS.I32 q0, q0, d0[0] uint16x8_t vmlsq_n_u16(uint16x8_t a, uint16x8_t b, uint16_t c); // VMLS.I16 q0, q0, d0[0] uint32x4_t vmlsq_n_u32(uint32x4_t a, uint32x4_t b, uint32_t c); // VMLS.I32 q0, q0, d0[0] float32x4_t vmlsq_n_f32(float32x4_t a, float32x4_t b, float32_t c); // VMLS.F32 q0, q0, d0[0]

스칼라가 있는 벡터 확장 곱하기 빼기

int32x4_t vmlsl_n_s16(int32x4_t a, int16x4_t b, int16_t c); // VMLSL.S16 q0, d0, d0[0] int64x2_t vmlsl_n_s32(int64x2_t a, int32x2_t b, int32_t c); // VMLSL.S32 q0, d0, d0[0] uint32x4_t vmlsl_n_u16(uint32x4_t a, uint16x4_t b, uint16_t c); // VMLSL.U16 q0, d0, d0[0] uint64x2_t vmlsl_n_u32(uint64x2_t a, uint32x2_t b, uint32_t c); // VMLSL.U32 q0, d0, d0[0]

스칼라가 있는 벡터 확장 포화 배수화 곱하기 빼기

int32x4_t vqdmlsl_n_s16(int32x4_t a, int16x4_t b, int16_t c); // VQDMLSL.S16 q0, d0, d0[0] int64x2_t vqdmlsl_n_s32(int64x2_t a, int32x2_t b, int32_t c); // VQDMLSL.S32 q0, d0, d0[0]

E.3.26 벡터 추출

int8x8_t vext_s8(int8x8_t a, int8x8_t b, __constrange(0,7) int c); // VEXT.8 d0,d0,d0,#0 uint8x8_t vext_u8(uint8x8_t a, uint8x8_t b, __constrange(0,7) int c); // VEXT.8 d0,d0,d0,#0 poly8x8_t vext_p8(poly8x8_t a, poly8x8_t b, __constrange(0,7) int c); // VEXT.8 d0,d0,d0,#0 int16x4_t vext_s16(int16x4_t a, int16x4_t b, __constrange(0,3) int c); // VEXT.16 d0,d0,d0,#0uint16x4_t vext_u16(uint16x4_t a, uint16x4_t b, __constrange(0,3) int c); // VEXT.16 d0,d0,d0,#0poly16x4_t vext_p16(poly16x4_t a, poly16x4_t b, __constrange(0,3) int c); // VEXT.16 d0,d0,d0,#0int32x2_t vext_s32(int32x2_t a, int32x2_t b, __constrange(0,1) int c); // VEXT.32 d0,d0,d0,#0uint32x2_t vext_u32(uint32x2_t a, uint32x2_t b, __constrange(0,1) int c); // VEXT.32 d0,d0,d0,#0int64x1_t vext_s64(int64x1_t a, int64x1_t b, __constrange(0,0) int c); // VEXT.64 d0,d0,d0,#0uint64x1_t vext_u64(uint64x1_t a, uint64x1_t b, __constrange(0,0) int c); // VEXT.64 d0,d0,d0,#0int8x16_t vextq_s8(int8x16_t a, int8x16_t b, __constrange(0,15) int c); // VEXT.8 q0,q0,q0,#0 uint8x16_t vextq_u8(uint8x16_t a, uint8x16_t b, __constrange(0,15) int c); // VEXT.8 q0,q0,q0,#0 poly8x16_t vextq_p8(poly8x16_t a, poly8x16_t b, __constrange(0,15) int c); // VEXT.8 q0,q0,q0,#0 int16x8_t vextq_s16(int16x8_t a, int16x8_t b, __constrange(0,7) int c); // VEXT.16 q0,q0,q0,#0uint16x8_t vextq_u16(uint16x8_t a, uint16x8_t b, __constrange(0,7) int c); // VEXT.16 q0,q0,q0,#0poly16x8_t vextq_p16(poly16x8_t a, poly16x8_t b, __constrange(0,7) int c); // VEXT.16 q0,q0,q0,#0int32x4_t vextq_s32(int32x4_t a, int32x4_t b, __constrange(0,3) int c); // VEXT.32 q0,q0,q0,#0uint32x4_t vextq_u32(uint32x4_t a, uint32x4_t b, __constrange(0,3) int c); // VEXT.32 q0,q0,q0,#0int64x2_t vextq_s64(int64x2_t a, int64x2_t b, __constrange(0,1) int c); // VEXT.64 q0,q0,q0,#0uint64x2_t vextq_u64(uint64x2_t a, uint64x2_t b, __constrange(0,1) int c); // VEXT.64 q0,q0,q0,#0


NEON 지원 사용

E.3.27 벡터 요소 반전(엔디안 스왑)

VREVn.m은 n비트 너비의 세트 내에서 m비트 레인의 순서를 반대로 바꿉니다.

int8x8_t vrev64_s8(int8x8_t vec); // VREV64.8 d0,d0 int16x4_t vrev64_s16(int16x4_t vec); // VREV64.16 d0,d0int32x2_t vrev64_s32(int32x2_t vec); // VREV64.32 d0,d0uint8x8_t vrev64_u8(uint8x8_t vec); // VREV64.8 d0,d0 uint16x4_t vrev64_u16(uint16x4_t vec); // VREV64.16 d0,d0uint32x2_t vrev64_u32(uint32x2_t vec); // VREV64.32 d0,d0poly8x8_t vrev64_p8(poly8x8_t vec); // VREV64.8 d0,d0poly16x4_t vrev64_p16(poly16x4_t vec); // VREV64.16 d0,d0 float32x2_t vrev64_f32(float32x2_t vec); // VREV64.32 d0,d0int8x16_t vrev64q_s8(int8x16_t vec); // VREV64.8 q0,q0 int16x8_t vrev64q_s16(int16x8_t vec); // VREV64.16 q0,q0int32x4_t vrev64q_s32(int32x4_t vec); // VREV64.32 q0,q0uint8x16_t vrev64q_u8(uint8x16_t vec); // VREV64.8 q0,q0 uint16x8_t vrev64q_u16(uint16x8_t vec); // VREV64.16 q0,q0uint32x4_t vrev64q_u32(uint32x4_t vec); // VREV64.32 q0,q0poly8x16_t vrev64q_p8(poly8x16_t vec); // VREV64.8 q0,q0poly16x8_t vrev64q_p16(poly16x8_t vec); // VREV64.16 q0,q0float32x4_t vrev64q_f32(float32x4_t vec); // VREV64.32 q0,q0int8x8_t vrev32_s8(int8x8_t vec); // VREV32.8 d0,d0 int16x4_t vrev32_s16(int16x4_t vec); // VREV32.16 d0,d0uint8x8_t vrev32_u8(uint8x8_t vec); // VREV32.8 d0,d0 uint16x4_t vrev32_u16(uint16x4_t vec); // VREV32.16 d0,d0poly8x8_t vrev32_p8(poly8x8_t vec); // VREV32.8 d0,d0 int8x16_t vrev32q_s8(int8x16_t vec); // VREV32.8 q0,q0 int16x8_t vrev32q_s16(int16x8_t vec); // VREV32.16 q0,q0uint8x16_t vrev32q_u8(uint8x16_t vec); // VREV32.8 q0,q0 uint16x8_t vrev32q_u16(uint16x8_t vec); // VREV32.16 q0,q0poly8x16_t vrev32q_p8(poly8x16_t vec); // VREV32.8 q0,q0 int8x8_t vrev16_s8(int8x8_t vec); // VREV16.8 d0,d0 uint8x8_t vrev16_u8(uint8x8_t vec); // VREV16.8 d0,d0 poly8x8_t vrev16_p8(poly8x8_t vec); // VREV16.8 d0,d0 int8x16_t vrev16q_s8(int8x16_t vec); // VREV16.8 q0,q0 uint8x16_t vrev16q_u8(uint8x16_t vec); // VREV16.8 q0,q0 poly8x16_t vrev16q_p8(poly8x16_t vec); // VREV16.8 q0,q0

E.3.28 기타 단일 피연산자 산술

다음 내장 함수는 기타 단일 피연산자 산술을 제공합니다.

절대: Vd[i] = |Va[i]|

int8x8_t vabs_s8(int8x8_t a); // VABS.S8 d0,d0 int16x4_t vabs_s16(int16x4_t a); // VABS.S16 d0,d0int32x2_t vabs_s32(int32x2_t a); // VABS.S32 d0,d0


NEON 지원 사용

float32x2_t vabs_f32(float32x2_t a); // VABS.F32 d0,d0int8x16_t vabsq_s8(int8x16_t a); // VABS.S8 q0,q0 int16x8_t vabsq_s16(int16x8_t a); // VABS.S16 q0,q0int32x4_t vabsq_s32(int32x4_t a); // VABS.S32 q0,q0float32x4_t vabsq_f32(float32x4_t a); // VABS.F32 q0,q0

포화 절대: Vd[i] = sat(|Va[i]|)

int8x8_t vqabs_s8(int8x8_t a); // VQABS.S8 d0,d0 int16x4_t vqabs_s16(int16x4_t a); // VQABS.S16 d0,d0int32x2_t vqabs_s32(int32x2_t a); // VQABS.S32 d0,d0int8x16_t vqabsq_s8(int8x16_t a); // VQABS.S8 q0,q0 int16x8_t vqabsq_s16(int16x8_t a); // VQABS.S16 q0,q0int32x4_t vqabsq_s32(int32x4_t a); // VQABS.S32 q0,q0

부정: Vd[i] = - Va[i]

int8x8_t vneg_s8(int8x8_t a); // VNEG.S8 d0,d0 int16x4_t vneg_s16(int16x4_t a); // VNEG.S16 d0,d0int32x2_t vneg_s32(int32x2_t a); // VNEG.S32 d0,d0float32x2_t vneg_f32(float32x2_t a); // VNEG.F32 d0,d0int8x16_t vnegq_s8(int8x16_t a); // VNEG.S8 q0,q0 int16x8_t vnegq_s16(int16x8_t a); // VNEG.S16 q0,q0int32x4_t vnegq_s32(int32x4_t a); // VNEG.S32 q0,q0float32x4_t vnegq_f32(float32x4_t a); // VNEG.F32 q0,q0

포화 부정: sat(Vd[i] = - Va[i])

int8x8_t vqneg_s8(int8x8_t a); // VQNEG.S8 d0,d0 int16x4_t vqneg_s16(int16x4_t a); // VQNEG.S16 d0,d0int32x2_t vqneg_s32(int32x2_t a); // VQNEG.S32 d0,d0int8x16_t vqnegq_s8(int8x16_t a); // VQNEG.S8 q0,q0 int16x8_t vqnegq_s16(int16x8_t a); // VQNEG.S16 q0,q0int32x4_t vqnegq_s32(int32x4_t a); // VQNEG.S32 q0,q0

선행 부호 비트 계산

int8x8_t vcls_s8(int8x8_t a); // VCLS.S8 d0,d0 int16x4_t vcls_s16(int16x4_t a); // VCLS.S16 d0,d0int32x2_t vcls_s32(int32x2_t a); // VCLS.S32 d0,d0int8x16_t vclsq_s8(int8x16_t a); // VCLS.S8 q0,q0 int16x8_t vclsq_s16(int16x8_t a); // VCLS.S16 q0,q0int32x4_t vclsq_s32(int32x4_t a); // VCLS.S32 q0,q0


NEON 지원 사용

선행 0 수 계산

int8x8_t vclz_s8(int8x8_t a); // VCLZ.I8 d0,d0 int16x4_t vclz_s16(int16x4_t a); // VCLZ.I16 d0,d0int32x2_t vclz_s32(int32x2_t a); // VCLZ.I32 d0,d0uint8x8_t vclz_u8(uint8x8_t a); // VCLZ.I8 d0,d0 uint16x4_t vclz_u16(uint16x4_t a); // VCLZ.I16 d0,d0uint32x2_t vclz_u32(uint32x2_t a); // VCLZ.I32 d0,d0int8x16_t vclzq_s8(int8x16_t a); // VCLZ.I8 q0,q0 int16x8_t vclzq_s16(int16x8_t a); // VCLZ.I16 q0,q0int32x4_t vclzq_s32(int32x4_t a); // VCLZ.I32 q0,q0uint8x16_t vclzq_u8(uint8x16_t a); // VCLZ.I8 q0,q0 uint16x8_t vclzq_u16(uint16x8_t a); // VCLZ.I16 q0,q0uint32x4_t vclzq_u32(uint32x4_t a); // VCLZ.I32 q0,q0

세트 비트 수 계산

uint8x8_t vcnt_u8(uint8x8_t a); // VCNT.8 d0,d0int8x8_t vcnt_s8(int8x8_t a); // VCNT.8 d0,d0poly8x8_t vcnt_p8(poly8x8_t a); // VCNT.8 d0,d0uint8x16_t vcntq_u8(uint8x16_t a); // VCNT.8 q0,q0int8x16_t vcntq_s8(int8x16_t a); // VCNT.8 q0,q0poly8x16_t vcntq_p8(poly8x16_t a); // VCNT.8 q0,q0

역수 추정

float32x2_t vrecpe_f32(float32x2_t a); // VRECPE.F32 d0,d0uint32x2_t vrecpe_u32(uint32x2_t a); // VRECPE.U32 d0,d0float32x4_t vrecpeq_f32(float32x4_t a); // VRECPE.F32 q0,q0uint32x4_t vrecpeq_u32(uint32x4_t a); // VRECPE.U32 q0,q0

역수 제곱근 추정

float32x2_t vrsqrte_f32(float32x2_t a); // VRSQRTE.F32 d0,d0uint32x2_t vrsqrte_u32(uint32x2_t a); // VRSQRTE.U32 d0,d0float32x4_t vrsqrteq_f32(float32x4_t a); // VRSQRTE.F32 q0,q0uint32x4_t vrsqrteq_u32(uint32x4_t a); // VRSQRTE.U32 q0,q0

E.3.29 논리 연산

다음 내장 함수는 비트 단위의 논리 연산을 제공합니다.


NEON 지원 사용

비트 단위 not

int8x8_t vmvn_s8(int8x8_t a); // VMVN d0,d0int16x4_t vmvn_s16(int16x4_t a); // VMVN d0,d0int32x2_t vmvn_s32(int32x2_t a); // VMVN d0,d0uint8x8_t vmvn_u8(uint8x8_t a); // VMVN d0,d0uint16x4_t vmvn_u16(uint16x4_t a); // VMVN d0,d0uint32x2_t vmvn_u32(uint32x2_t a); // VMVN d0,d0poly8x8_t vmvn_p8(poly8x8_t a); // VMVN d0,d0int8x16_t vmvnq_s8(int8x16_t a); // VMVN q0,q0int16x8_t vmvnq_s16(int16x8_t a); // VMVN q0,q0int32x4_t vmvnq_s32(int32x4_t a); // VMVN q0,q0uint8x16_t vmvnq_u8(uint8x16_t a); // VMVN q0,q0uint16x8_t vmvnq_u16(uint16x8_t a); // VMVN q0,q0uint32x4_t vmvnq_u32(uint32x4_t a); // VMVN q0,q0poly8x16_t vmvnq_p8(poly8x16_t a); // VMVN q0,q0

비트 단위 and

int8x8_t vand_s8(int8x8_t a, int8x8_t b); // VAND d0,d0,d0int16x4_t vand_s16(int16x4_t a, int16x4_t b); // VAND d0,d0,d0int32x2_t vand_s32(int32x2_t a, int32x2_t b); // VAND d0,d0,d0int64x1_t vand_s64(int64x1_t a, int64x1_t b); // VAND d0,d0,d0uint8x8_t vand_u8(uint8x8_t a, uint8x8_t b); // VAND d0,d0,d0uint16x4_t vand_u16(uint16x4_t a, uint16x4_t b); // VAND d0,d0,d0uint32x2_t vand_u32(uint32x2_t a, uint32x2_t b); // VAND d0,d0,d0uint64x1_t vand_u64(uint64x1_t a, uint64x1_t b); // VAND d0,d0,d0int8x16_t vandq_s8(int8x16_t a, int8x16_t b); // VAND q0,q0,q0int16x8_t vandq_s16(int16x8_t a, int16x8_t b); // VAND q0,q0,q0int32x4_t vandq_s32(int32x4_t a, int32x4_t b); // VAND q0,q0,q0int64x2_t vandq_s64(int64x2_t a, int64x2_t b); // VAND q0,q0,q0uint8x16_t vandq_u8(uint8x16_t a, uint8x16_t b); // VAND q0,q0,q0uint16x8_t vandq_u16(uint16x8_t a, uint16x8_t b); // VAND q0,q0,q0uint32x4_t vandq_u32(uint32x4_t a, uint32x4_t b); // VAND q0,q0,q0uint64x2_t vandq_u64(uint64x2_t a, uint64x2_t b); // VAND q0,q0,q0

비트 단위 or

int8x8_t vorr_s8(int8x8_t a, int8x8_t b); // VORR d0,d0,d0int16x4_t vorr_s16(int16x4_t a, int16x4_t b); // VORR d0,d0,d0int32x2_t vorr_s32(int32x2_t a, int32x2_t b); // VORR d0,d0,d0int64x1_t vorr_s64(int64x1_t a, int64x1_t b); // VORR d0,d0,d0uint8x8_t vorr_u8(uint8x8_t a, uint8x8_t b); // VORR d0,d0,d0uint16x4_t vorr_u16(uint16x4_t a, uint16x4_t b); // VORR d0,d0,d0uint32x2_t vorr_u32(uint32x2_t a, uint32x2_t b); // VORR d0,d0,d0uint64x1_t vorr_u64(uint64x1_t a, uint64x1_t b); // VORR d0,d0,d0int8x16_t vorrq_s8(int8x16_t a, int8x16_t b); // VORR q0,q0,q0int16x8_t vorrq_s16(int16x8_t a, int16x8_t b); // VORR q0,q0,q0


NEON 지원 사용

int32x4_t vorrq_s32(int32x4_t a, int32x4_t b); // VORR q0,q0,q0int64x2_t vorrq_s64(int64x2_t a, int64x2_t b); // VORR q0,q0,q0uint8x16_t vorrq_u8(uint8x16_t a, uint8x16_t b); // VORR q0,q0,q0uint16x8_t vorrq_u16(uint16x8_t a, uint16x8_t b); // VORR q0,q0,q0uint32x4_t vorrq_u32(uint32x4_t a, uint32x4_t b); // VORR q0,q0,q0uint64x2_t vorrq_u64(uint64x2_t a, uint64x2_t b); // VORR q0,q0,q0

비트 단위 배타적 or(EOR 또는 XOR)

int8x8_t veor_s8(int8x8_t a, int8x8_t b); // VEOR d0,d0,d0int16x4_t veor_s16(int16x4_t a, int16x4_t b); // VEOR d0,d0,d0int32x2_t veor_s32(int32x2_t a, int32x2_t b); // VEOR d0,d0,d0int64x1_t veor_s64(int64x1_t a, int64x1_t b); // VEOR d0,d0,d0uint8x8_t veor_u8(uint8x8_t a, uint8x8_t b); // VEOR d0,d0,d0uint16x4_t veor_u16(uint16x4_t a, uint16x4_t b); // VEOR d0,d0,d0uint32x2_t veor_u32(uint32x2_t a, uint32x2_t b); // VEOR d0,d0,d0uint64x1_t veor_u64(uint64x1_t a, uint64x1_t b); // VEOR d0,d0,d0int8x16_t veorq_s8(int8x16_t a, int8x16_t b); // VEOR q0,q0,q0int16x8_t veorq_s16(int16x8_t a, int16x8_t b); // VEOR q0,q0,q0int32x4_t veorq_s32(int32x4_t a, int32x4_t b); // VEOR q0,q0,q0int64x2_t veorq_s64(int64x2_t a, int64x2_t b); // VEOR q0,q0,q0uint8x16_t veorq_u8(uint8x16_t a, uint8x16_t b); // VEOR q0,q0,q0uint16x8_t veorq_u16(uint16x8_t a, uint16x8_t b); // VEOR q0,q0,q0uint32x4_t veorq_u32(uint32x4_t a, uint32x4_t b); // VEOR q0,q0,q0uint64x2_t veorq_u64(uint64x2_t a, uint64x2_t b); // VEOR q0,q0,q0

비트 지우기

int8x8_t vbic_s8(int8x8_t a, int8x8_t b); // VBIC d0,d0,d0int16x4_t vbic_s16(int16x4_t a, int16x4_t b); // VBIC d0,d0,d0int32x2_t vbic_s32(int32x2_t a, int32x2_t b); // VBIC d0,d0,d0int64x1_t vbic_s64(int64x1_t a, int64x1_t b); // VBIC d0,d0,d0uint8x8_t vbic_u8(uint8x8_t a, uint8x8_t b); // VBIC d0,d0,d0uint16x4_t vbic_u16(uint16x4_t a, uint16x4_t b); // VBIC d0,d0,d0uint32x2_t vbic_u32(uint32x2_t a, uint32x2_t b); // VBIC d0,d0,d0uint64x1_t vbic_u64(uint64x1_t a, uint64x1_t b); // VBIC d0,d0,d0int8x16_t vbicq_s8(int8x16_t a, int8x16_t b); // VBIC q0,q0,q0int16x8_t vbicq_s16(int16x8_t a, int16x8_t b); // VBIC q0,q0,q0int32x4_t vbicq_s32(int32x4_t a, int32x4_t b); // VBIC q0,q0,q0int64x2_t vbicq_s64(int64x2_t a, int64x2_t b); // VBIC q0,q0,q0uint8x16_t vbicq_u8(uint8x16_t a, uint8x16_t b); // VBIC q0,q0,q0uint16x8_t vbicq_u16(uint16x8_t a, uint16x8_t b); // VBIC q0,q0,q0uint32x4_t vbicq_u32(uint32x4_t a, uint32x4_t b); // VBIC q0,q0,q0uint64x2_t vbicq_u64(uint64x2_t a, uint64x2_t b); // VBIC q0,q0,q0


NEON 지원 사용

비트 단위 OR 보수

int8x8_t vorn_s8(int8x8_t a, int8x8_t b); // VORN d0,d0,d0int16x4_t vorn_s16(int16x4_t a, int16x4_t b); // VORN d0,d0,d0int32x2_t vorn_s32(int32x2_t a, int32x2_t b); // VORN d0,d0,d0int64x1_t vorn_s64(int64x1_t a, int64x1_t b); // VORN d0,d0,d0uint8x8_t vorn_u8(uint8x8_t a, uint8x8_t b); // VORN d0,d0,d0uint16x4_t vorn_u16(uint16x4_t a, uint16x4_t b); // VORN d0,d0,d0uint32x2_t vorn_u32(uint32x2_t a, uint32x2_t b); // VORN d0,d0,d0uint64x1_t vorn_u64(uint64x1_t a, uint64x1_t b); // VORN d0,d0,d0int8x16_t vornq_s8(int8x16_t a, int8x16_t b); // VORN q0,q0,q0int16x8_t vornq_s16(int16x8_t a, int16x8_t b); // VORN q0,q0,q0int32x4_t vornq_s32(int32x4_t a, int32x4_t b); // VORN q0,q0,q0int64x2_t vornq_s64(int64x2_t a, int64x2_t b); // VORN q0,q0,q0uint8x16_t vornq_u8(uint8x16_t a, uint8x16_t b); // VORN q0,q0,q0uint16x8_t vornq_u16(uint16x8_t a, uint16x8_t b); // VORN q0,q0,q0uint32x4_t vornq_u32(uint32x4_t a, uint32x4_t b); // VORN q0,q0,q0uint64x2_t vornq_u64(uint64x2_t a, uint64x2_t b); // VORN q0,q0,q0

비트 단위 선택

참고

이 내장 함수는 레지스터 할당에 따라 VBSL/VBIF/VBIT 중 하나로 컴파일될 수 있습니다.

int8x8_t vbsl_s8(uint8x8_t a, int8x8_t b, int8x8_t c); // VBSL d0,d0,d0int16x4_t vbsl_s16(uint16x4_t a, int16x4_t b, int16x4_t c); // VBSL d0,d0,d0int32x2_t vbsl_s32(uint32x2_t a, int32x2_t b, int32x2_t c); // VBSL d0,d0,d0int64x1_t vbsl_s64(uint64x1_t a, int64x1_t b, int64x1_t c); // VBSL d0,d0,d0uint8x8_t vbsl_u8(uint8x8_t a, uint8x8_t b, uint8x8_t c); // VBSL d0,d0,d0uint16x4_t vbsl_u16(uint16x4_t a, uint16x4_t b, uint16x4_t c); // VBSL d0,d0,d0uint32x2_t vbsl_u32(uint32x2_t a, uint32x2_t b, uint32x2_t c); // VBSL d0,d0,d0uint64x1_t vbsl_u64(uint64x1_t a, uint64x1_t b, uint64x1_t c); // VBSL d0,d0,d0float32x2_t vbsl_f32(uint32x2_t a, float32x2_t b, float32x2_t c); // VBSL d0,d0,d0poly8x8_t vbsl_p8(uint8x8_t a, poly8x8_t b, poly8x8_t c); // VBSL d0,d0,d0poly16x4_t vbsl_p16(uint16x4_t a, poly16x4_t b, poly16x4_t c); // VBSL d0,d0,d0int8x16_t vbslq_s8(uint8x16_t a, int8x16_t b, int8x16_t c); // VBSL q0,q0,q0int16x8_t vbslq_s16(uint16x8_t a, int16x8_t b, int16x8_t c); // VBSL q0,q0,q0int32x4_t vbslq_s32(uint32x4_t a, int32x4_t b, int32x4_t c); // VBSL q0,q0,q0int64x2_t vbslq_s64(uint64x2_t a, int64x2_t b, int64x2_t c); // VBSL q0,q0,q0uint8x16_t vbslq_u8(uint8x16_t a, uint8x16_t b, uint8x16_t c); // VBSL q0,q0,q0uint16x8_t vbslq_u16(uint16x8_t a, uint16x8_t b, uint16x8_t c); // VBSL q0,q0,q0uint32x4_t vbslq_u32(uint32x4_t a, uint32x4_t b, uint32x4_t c); // VBSL q0,q0,q0uint64x2_t vbslq_u64(uint64x2_t a, uint64x2_t b, uint64x2_t c); // VBSL q0,q0,q0float32x4_t vbslq_f32(uint32x4_t a, float32x4_t b, float32x4_t c); // VBSL q0,q0,q0


NEON 지원 사용

poly8x16_t vbslq_p8(uint8x16_t a, poly8x16_t b, poly8x16_t c); // VBSL q0,q0,q0poly16x8_t vbslq_p16(uint16x8_t a, poly16x8_t b, poly16x8_t c); // VBSL q0,q0,q0

E.3.30 이항 연산

이들 내장 함수는 이항 연산을 제공합니다.

이항 요소

int8x8x2_t vtrn_s8(int8x8_t a, int8x8_t b); // VTRN.8 d0,d0int16x4x2_t vtrn_s16(int16x4_t a, int16x4_t b); // VTRN.16 d0,d0int32x2x2_t vtrn_s32(int32x2_t a, int32x2_t b); // VTRN.32 d0,d0uint8x8x2_t vtrn_u8(uint8x8_t a, uint8x8_t b); // VTRN.8 d0,d0uint16x4x2_t vtrn_u16(uint16x4_t a, uint16x4_t b); // VTRN.16 d0,d0uint32x2x2_t vtrn_u32(uint32x2_t a, uint32x2_t b); // VTRN.32 d0,d0float32x2x2_t vtrn_f32(float32x2_t a, float32x2_t b); // VTRN.32 d0,d0poly8x8x2_t vtrn_p8(poly8x8_t a, poly8x8_t b); // VTRN.8 d0,d0poly16x4x2_t vtrn_p16(poly16x4_t a, poly16x4_t b); // VTRN.16 d0,d0int8x16x2_t vtrnq_s8(int8x16_t a, int8x16_t b); // VTRN.8 q0,q0int16x8x2_t vtrnq_s16(int16x8_t a, int16x8_t b); // VTRN.16 q0,q0int32x4x2_t vtrnq_s32(int32x4_t a, int32x4_t b); // VTRN.32 q0,q0uint8x16x2_t vtrnq_u8(uint8x16_t a, uint8x16_t b); // VTRN.8 q0,q0uint16x8x2_t vtrnq_u16(uint16x8_t a, uint16x8_t b); // VTRN.16 q0,q0uint32x4x2_t vtrnq_u32(uint32x4_t a, uint32x4_t b); // VTRN.32 q0,q0float32x4x2_t vtrnq_f32(float32x4_t a, float32x4_t b); // VTRN.32 q0,q0poly8x16x2_t vtrnq_p8(poly8x16_t a, poly8x16_t b); // VTRN.8 q0,q0poly16x8x2_t vtrnq_p16(poly16x8_t a, poly16x8_t b); // VTRN.16 q0,q0

인터리브 요소

int8x8x2_t vzip_s8(int8x8_t a, int8x8_t b); // VZIP.8 d0,d0 int16x4x2_t vzip_s16(int16x4_t a, int16x4_t b); // VZIP.16 d0,d0uint8x8x2_t vzip_u8(uint8x8_t a, uint8x8_t b); // VZIP.8 d0,d0 uint16x4x2_t vzip_u16(uint16x4_t a, uint16x4_t b); // VZIP.16 d0,d0float32x2x2_t vzip_f32(float32x2_t a, float32x2_t b); // VZIP.32 d0,d0poly8x8x2_t vzip_p8(poly8x8_t a, poly8x8_t b); // VZIP.8 d0,d0poly16x4x2_t vzip_p16(poly16x4_t a, poly16x4_t b); // VZIP.16 d0,d0int8x16x2_t vzipq_s8(int8x16_t a, int8x16_t b); // VZIP.8 q0,q0 int16x8x2_t vzipq_s16(int16x8_t a, int16x8_t b); // VZIP.16 q0,q0int32x4x2_t vzipq_s32(int32x4_t a, int32x4_t b); // VZIP.32 q0,q0uint8x16x2_t vzipq_u8(uint8x16_t a, uint8x16_t b); // VZIP.8 q0,q0 uint16x8x2_t vzipq_u16(uint16x8_t a, uint16x8_t b); // VZIP.16 q0,q0uint32x4x2_t vzipq_u32(uint32x4_t a, uint32x4_t b); // VZIP.32 q0,q0float32x4x2_t vzipq_f32(float32x4_t a, float32x4_t b); // VZIP.32 q0,q0poly8x16x2_t vzipq_p8(poly8x16_t a, poly8x16_t b); // VZIP.8 q0,q0poly16x8x2_t vzipq_p16(poly16x8_t a, poly16x8_t b); // VZIP.16 q0,q0


NEON 지원 사용

디인터리브 요소

int8x8x2_t vuzp_s8(int8x8_t a, int8x8_t b); // VUZP.8 d0,d0 int16x4x2_t vuzp_s16(int16x4_t a, int16x4_t b); // VUZP.16 d0,d0int32x2x2_t vuzp_s32(int32x2_t a, int32x2_t b); // VUZP.32 d0,d0uint8x8x2_t vuzp_u8(uint8x8_t a, uint8x8_t b); // VUZP.8 d0,d0 uint16x4x2_t vuzp_u16(uint16x4_t a, uint16x4_t b); // VUZP.16 d0,d0uint32x2x2_t vuzp_u32(uint32x2_t a, uint32x2_t b); // VUZP.32 d0,d0float32x2x2_t vuzp_f32(float32x2_t a, float32x2_t b); // VUZP.32 d0,d0poly8x8x2_t vuzp_p8(poly8x8_t a, poly8x8_t b); // VUZP.8 d0,d0poly16x4x2_t vuzp_p16(poly16x4_t a, poly16x4_t b); // VUZP.16 d0,d0int8x16x2_t vuzpq_s8(int8x16_t a, int8x16_t b); // VUZP.8 q0,q0 int16x8x2_t vuzpq_s16(int16x8_t a, int16x8_t b); // VUZP.16 q0,q0int32x4x2_t vuzpq_s32(int32x4_t a, int32x4_t b); // VUZP.32 q0,q0uint8x16x2_t vuzpq_u8(uint8x16_t a, uint8x16_t b); // VUZP.8 q0,q0 uint16x8x2_t vuzpq_u16(uint16x8_t a, uint16x8_t b); // VUZP.16 q0,q0uint32x4x2_t vuzpq_u32(uint32x4_t a, uint32x4_t b); // VUZP.32 q0,q0float32x4x2_t vuzpq_f32(float32x4_t a, float32x4_t b); // VUZP.32 q0,q0poly8x16x2_t vuzpq_p8(poly8x16_t a, poly8x16_t b); // VUZP.8 q0,q0poly16x8x2_t vuzpq_p16(poly16x8_t a, poly16x8_t b); // VUZP.16 q0,q0

E.3.31 벡터 재해석 캐스트 연산

경우에 따라 값을 변경하지 않은 채로 벡터를 다른 유형을 가진 것으로 처리할 수 있습니다. 이런 유형의 변환을 수행할 수 있도록 내장 함수 세트가 제공됩니다.

구문

vreinterpret{q}_dsttype_srctype

인수 설명:

q 변환이 128비트 벡터에서 작동하도록 지정합니다. 이 인수가 없으면 64비트 벡터에서 작동합니다.

dsttype 변환할 유형을 나타냅니다.

srctype 변환 중인 유형을 나타냅니다.

예제

다음 내장 함수는 부호 있는 4개의 16비트 정수의 벡터를 부호 없는 4개의 정수 벡터로 재해석합니다.

uint16x4_t vreinterpret_u16_s16(int16x4_t a);


NEON 지원 사용

다음 내장 함수는 4개의 32비트 부동 소수점 값 정수의 벡터를 부호 있는 4개의 정수 벡터로 재해석합니다.

int8x16_t vreinterpretq_s8_f32(float32x4_t a);

벡터가 나타내는 비트 패턴은 이러한 변환을 수행해도 변경되지 않습니다.


NEON 지원 사용


RealView Compilation Tools -...

Documents

Transcript of RealView Compilation Tools -...