OKL4 uses address space to manage sharing of memory-mapped resources, such as physical memory, device registers and I/O ports.
(OKL4는 물리적 메모리, 디바이스 레지스터, I/O ports와 같은 memory-mapped resource 공유하는 것을 관리하기 위해서 address space를 사용한다.)
An address space can be viewed as a mathematical function, containing a set of mappings of virtual addresss to memory-mapped resources together with a class of permitted memory access operations and a caching policy for each mapping.
(address space는 허용된 메모리 엑세스 클래스와 함께 memory-mapped 리소스에 맵핑되는 가상주소 집합과 각 mapping의 캐쉬정책을 포함하는 수학 함수(수학적기능)로 보여진다.)
Note that the term "address space" is used to refer to the entire address-mapping function.
("address space" 말은 address-mapping function 전체를 참조하는데 사용된다는 것을 주의하라.)
Each address space covers the entire range of virtually addressable memory supported by the underlying architecture.
(각 address space는 기반되는 아키텍처에 의해서 지원되는 모든 가상적으로 주소화 영역을 커버한다.)
Similarly, each address space mapping can reference any memory-mapped resource in the system and is limited only by hardware constraints.
(유사하게, 각 address space 매핑은 시스템상의 어떤 메모리맵드 리소스를 참조할 수 있고, 하드웨어 제한에 의해서만 제한된다.)
The adress space mappings are constructed using the MapControl system call.
OKL4 divides both the virtual addresses of the system into discrete regions called flexible pages.
(OKL4는 시스템의 가상주소들을 flexible page들이라고 하는 개별영역으로 나눈다.)
*diviede 목 + into + 명 (분류하다.)
A flexible page has a size of 2의 K승 where K>=10 and aligned to its own page size, that is they are not restricted to the set of page supported by the hardware architecture.
(flexible page는 2의 K승(K는 10보다 큰) 크기를 가지고,page 크기에 정렬된다. 이것은 flexible page는 하드웨어 아키텍처에 의해서 제공되는 페이지 집합에 제한되지 않는다.)
Flexible pages map on to pages provided by the hardware architecture where each page covers a unique region of 2의MinPageWidth승 consecutive virtual addresses.
(Flexible pages map은 )
Address spaces are required by OKL4 threads in order to execute code and access memory.
(OKL4 thread는 코드를 실행하거나 메모리를 접근하기 위해서 address space를 요구한다.)
Thus, all threads are associated with an address space. Each address space may have zero or more threads associated with it at given point in time.
(따라서, 모든 쓰레드는 address space와 결합된다. 각 address space는 주어진 시점에서 결합된 0또는 그 이상의 thread를 가질 것이다.)
It should be noted that an address space cannot be deleted while it has threads associated with it.
(address space는 thread와 결합되어 있는 동안에는 삭제되어질 수 없다는 것을 주의해야 한다.)
Address space serve two main purposes.
Firstly, they implement the memory protection facilities that permit operating system personalities to manage secure distribution and sharing of memory-mapped system resources.
(첫번째로, address space는 안전배포와 메모리 맵드 시스템 리소스 공유를 관리하는 것을 OS특성에게 허락하는 메모리 보호 편의(?ㅋㅋ)를 구현한다. 크크.. 직역 개판)
This is achieved by controlling the visibility of these resources to particular system threads.
(이것은 특정 시스템 쓰레드에게 이런 리소스들의 가시성을 제어함으로써 이루어진다.)
Secondly, address spaces provide user programs with a address translation facility.
(두번째로, address space는 주소변화의 용이함과 함께 사용자 프로그램들을 제공한다.)
Parts of the address space may be left unused by the user, allowing for sparse data arrays, demand loading,
dynamic memory allocation and virtual memory paging
(address space의 부분들은 사용자, 드문 데이터 배열 허용, demand loading, 다이나믹 메모리 할당, 그리고 가상메모리 페이징에 의해서 사용되지 않는 상태로 놓여있을 것 이다.)
1. Address Space Identifiers.
An OKL4 system consists of a fixed set of space identifiers, each of which may be used or available at a given time.
(OKL4 System은 주어진 시점에 사용되거나 또는 사용할 수 있는 고정된 space identifiers의 집합으로 구성된다.)
A unique space identifier is allocated to each address space and is used to reference a particular address space when using OKL4 system calls.
(유일한 space identifier는 각 adress space에 위치하고 OKL4 system call을 사용할 때 특정 address space를 참조하는데 사용되어 진다.)
The space identifier of an address space is determined by the user at the time of its creation and cannot be subsequently modified.
(address space의 space identifier는 user에 의해서 생성될 때 결정된다. 그리고, 그 후에는 수정할 수 없다.)
OKL4 allows the space identifier of an address space to be recycled once the space has been deleted.
(OKL4는 address space가 제거되면 address space의 space identifier를 재사용하는 것을 허용한다.)
2. Access permission and page faults
Each address mapping is associated with zero or more access permissions from the set {read, write, execute}.
(각 address mapping은 {읽기, 쓰기, 실행} 집합중에서 0또는 그 이상의 access permission과 결합된다.)
* read = load, write = store, execute = fetch
A mapping with an empty set of access permissions is effectively excluded from corresponding address space function(deleted)
(access permission이 없는 매핑은 실제적으로 corresponding address space function에서 제외된다.(삭제된다.))
Since no operations are permitted on such a mapping, the corresponding physical address and caching policy is effectively ignored by the microkernel
(이러한 매핑(empty set)상에서는 아무런 Operation도 허용되지 않기 때문에 corresponding physical address와 캐시정책은 실제적으로 마이크로커널에 의해서 무시된다.)
The access permissions for a particular virtual address page are specified by the user when establishing the mapping using the MapControl function.
(특정 가상 주소 페이지의 access permission은 MapControl 함수를 사용하여 맵핑을 수립할 때(만들어진다고 보자) 사용자에 의해서 상세화된다.)
Note that access permissions are associated with virtual pages rather than physical pages, so a single physical page may be simultaneously mapped at different locations within an address space using a different set of access permission.
(access permission은 물리 페이지보다는 가상 페이지와 결합된다. 그래서, 단일 물리 페이지는 다른 access permission set을 사용하는 address space내에서 다른 위치들에 동시에 연결될 수 있다. )
To facilitate restrictions imposed by individual architectures, the set of permissions specified by the user is adjusted using the PMask parameter.
(일개의 아키텍처에 의해서 가해진 제한을 쉽게하는 하는 것, 사용자에 의해서 명세된 permission 세트는 PMask parameter를 사용하여 조정된다.)
This adjustment does not remove permissions from the set requested by the user, but may add additional permissions to the set as dictated by the requirements of the underlying architecture.
(이 조정은 user의 의해서 요청된 set에서 permission을 제거하지 않는다. 그러나, 추가적인 permission들을 기반 아키텍처의 요구사항에 의해서 기술된 set에 추가할 것이다.)
In addition, the permission adjustment does not add permissions to a set specified as empty by the user.
(추가적으로, permission 조정은 사용자에 의해서 empty로 명세된 set에는 추가하지 않는다.)
The adjusted set of access permission is called the set of the effective access permissions for the virtual address.
(access permission의 조정된 ste은 virtual address를 위한 유효한 access permission의 set으로 부른다.)
An attempt by a user thread to read, write or execute from memory without the effective read, write or execute permissions is detected by the microkernel as a page fault.
(user 쓰레드가 읽기, 쓰기 또는 실행 권한이 없이 메모리로 부터 읽기, 쓰기 또는 실행하는 시도는 마이크로커널에 의해서 page fault로 발견된다. - page fault가 발생한다.)
The microkernel generates a page fault message on behalf of the user thread and delivers it to the thread’s page fault handler
(마이크로커널은 user 쓰레드 대신에 page fault 메세지를 생성하고 이것을 쓰레드의 page fault 핸들러로 전달한다.)
After performing any recovery actions, the page fault handler replies to the message using ordinary IPC mechanism which is also handled by the microkernel on behalf of the faulting thread.
(어떠한 복구 액션을 수행한 후에 page fault handler는 정규의 IPC 메카니즘을 사용하여 메세지를 회신한다. 이것 역시 fault가 발생한 쓰레드 대신에 마이크로커널에 의해서 처리된다.)
A page fault event is not necessarily an indication of a programming error.
(page fault 이벤트는 반드시 프로그래밍 에러를 표시하는 것은 아니다.)
Page fault messages may be used to facilitate daynamic and incremental construction of the address space function by selectively mapping resource to the virtual addresses referenced by the faulting memory access instruction.
(페이지 폴트 메세지는 fault가 생기는 메모리 access 명령에 의해서 참조되는 가상 주소들에 선택적으로 연결되는 리소스에 의해서 address space기능의 동적이고 증가적인 address space function(기능)의 생성를 쉽게 하기 위해서 사용되어질지 모른다.)
Page faults may also be used to implement operating system features such as demand-loading, copy-on-write and virtual memory paging.
(페이지 폴트는 디맨드로딩, copy-on-write(cow) 그리고 가상메모리페이징과 같은 OS 기능을 구현하는데 사용된다.)
3. Caching Policies
The OKL4 microkernel recognizes the importance of caching on memory-mapped resources and annotates each page of virtual memory in the system with a caching policies.
(OKL4 마이크로커널은 캐싱된 memory-mapped resurce의 중요성을 인정하고(?), 각 캐싱정책을 가진 시스템의 가상페이지마다 주석을 단다.)
These annotations dictate the behaviour of memory system for all memory accesses referencing the corresponding virtual address.
(이러한 상응하는(?) 가상주소를 참조하는 모든 메모리 주석들은 행동을 알려준다.)
The choice of caching page may affect the semantics of access to physical memory resources.
(캐싱된 페이지의 선택은 물리적 메모리 리소스에 접근한다는 의미에 영향을 줄지 모른다.)
In particular, accesses to memory mapped devices often require uncached mappings. This is to ensure that writes propagate to the device immediately and reads always get the current state of the device. Also of importance is preserving the strict ordering of operations on the device.
(특히, 디바이스에 맵핑된 메모리에 접근하는 것은 종종 캐싱되지 않은 맵핑을 요구한다. 이것은 쓰기에 디바이스에 즉각적으로 전달되는 것과 읽기가 항상 디바이스 현재 상태를 얻는 것을 보장하는 것이다. 또한 중요한 것은 디바이스상에서 동작의 엄격한 순서를 지키는 것이다.)
In addition, on systems with multiple processing units that do not share a portion of the cache hierarchy, the hardware must ensure that results of a memory operation performed on one processing unit are visible on the remaining units in the system.
(추가로, 캐시 계층 구조의 일부를 공유하지 않는 멀티 프로세싱 유닛을 가진 시스템상에서, 하드웨어는 반드시 하나의 프로세스 유닛상에서 실행한 메모리 동작의 결과를 시스템상의 다른 프로세스 유닛상에 보여지는 것을 보장해야 한다.)
This is known as cache coherency.
(이것은 캐쉬 일관성으로 알려진 것 이다.)
A particular architecture may choose to provide caching policies without cache coherency in order to improve system performance.
(특정 아키텍처는 시스템 성능향상을 위해서 캐시 일관성 없이 캐시정책을 제공하는 것을 선택할 수도 있다.)
On such system, the software must insert explicit memory barriers to ensure that modifications to memory performed on one processing units are visible to the rest of the system.
(이런 시스템상에서, 소프트웨어는 하나의 프로세싱 유닛상에서 수행되는 메모리 수정을 시스템의 다른 프로세서에 보여지는 것을 보장하기 위해서 명백한(명시적인) 메모리 베리어를 반드시 삽입해야 한다.)
The specific mechanism by which memory barriers are inserted on a particular architecture is defined by the corresponding instruction set.
(특정 아키텍처에 삽입된 메모리 베리어에 의해서 명세된 메카니즘은 적합한 명령어 집합에 의해서 정의된다.)
However, in all cases OKL4 provides the CacheControl system call that may be used to maintain cache coherency without use of architecture-specific memory barrier instructions.
(그러나, 모든 경우에 OKL4는 아키텍처 특유의 메모리 베리어 명령어의 사용없이 캐시일관성을 유지하는데 사용되어지는 the CacheControl 시스템 호출을 제공한다.)
In summary, the design space for caching policies can be described by considering caching of memory read and
write operations separately as described.
(요약하면, 캐싱 정책들의 design space는 메모리 읽기와 쓰기 OP를 따로 고려함으로 설명될 수 있다.)
Irrespective of the capabilities of a particular architecture, the OKL4 microkernel recognizes a set of caching policies represented by the CACHINGPOLICY type.
(특정 아키텍처의 기능을 불문하고(기능과 상관없이), OKL4 마이크로커널은 CACHINGPOLICY를 통해서 캐싱정책들을 인지한다.)
The policy desired for a particular region of the address space is configured using the MapControl system call.
(address space의 특정 영역을 위해 요구되는 정책은 MapControl 시스템 호출을 사용하여 구성된다.)
Few architectures support the full design space of caching policies described in this chapter. Therefore, OKL4 implementations adjust the caching policy requested by the user to any policy that provides equal or higher predictability.
(소수의 아키텍처는 이 장에서 설명하는 모든 캐싱정책의 디자인을 지원한다. 그러므로, OKL4 구현들은 사용자에 의해서 조절요구된 캐싱정책을 같거나 더 높은 예측가능성을 제공하는 다른 정책으로 맞춘다.)
* adjust 목1 to 목2 : 목1을 목2에 맞추다.
Any request for a particular caching policy may be "satisfied" by an OKL4 implementation executing on an architecture without a user-controlled caching hardware by disabling caching of the corresponding memory resources, although it is expected that such drastic means of implementation will not necessary in practices.
(특정 캐싱정책에 대한 모든 요구는 아키텍처상에서 사용자 제어 캐싱 하드웨어 없이 해당 메모리 리소스 캐싱을 해제하여 실행하는 OKL4 실행(구현)에 의해서 만족될지 모른다. 비록 관행에서는 구현과 같은 과감한 수단은 필요하지 않는 것이 예상될지라도 )
4. Caching operations
An explaination of all possible caching operations is beyond the scope of this document.
모든 가능한 캐싱 동작의 설명은 이 문서의 범위를 넘어선다.
As caching of operations significantly affect system performance, choosing the correct policy for your system may require analysis and testing
(캐싱동작이 실제적으로 시스템 수행속도에 영향을 주기 때문에, 너의 시스템에 적합한 정책을 고르는데 분석과 테스트가 요구될 수도 있다.)
There are a large number of caching policies implemented by a variety of different hardware architectures.
(여러 종료의 다른 하드웨어 아키텍처에 의해서 구현된 많은 캐싱정책이 있다.)
A few commom points and issues are discussed blow.
(몇몇 공통점과 이슈는 아래에 기술되어 있다.)
a. cacheable memory generally refers to memory for which the processor may consult the caches first to find a cached copy, before accessing physical memory. In addition, the processor may update the cached copy when performing a write operation.
(cacheable 메모리는 물리 메모리를 접근하기 전에, 프로세스가 프로세스가 참조 메모리를 조사한다
와... 진짜 해석 못 하겠다. 대충 의역하면, cacheable 메모리는 물리적 메모리를 접근하기 전에 캐시된 복사를 찾기위해서 프로세서가 먼저 캐시를 참고했을지 모를 메모리를 참조한다. 추가적으로 프로세서는 쓰기 동작을 할 때, 캐시된 복사를 업데이트한다.)
b. line-allocation refers to the policy the processor uses to insert entries into the cache when a cache-miss occurs. Typically, either read operations or write operations are chosen, sometimes both. In caches where a cache-miss occurs and the line-allocation policy is not satisfied, the operation is performed on physical memory without accessing the cache.
(line-allocation은 캐시미스가 일어났을 때 프로세스가 엔트리들을 캐시에 넣기 위해서 사용하는 정책을 참조한다. 전형적으로, 읽기 동작이거나 쓰기 동작중 하나가 선택되어진다. 때로 양쪽다 되기도 한다. 캐시미스가 발생하거나 line-allocation 정책이 만족되지 않는 캐시들 안에서의 Operation은 캐시에 접근없이 물리적 메모리 위에서 수행되어진다.)
* either ~ or ** : ~나 **중 하나,
<-> neither ~ nor ** : ~ 나 ** 모두 아닌,
c. write-back refers to a policy where updates to the cache mark an entry as “dirty” for later write-back to physical memory (typically an explicit flush or cache-line eviction). If write-back is disabled, the processor may update the cache as well as physical memory
(write-back은 나중에 물리메모리에 저장하기 위해서 캐시가 dirty를 엔트리에 마킹하는 것을 정책을 참조한다. - 해석안됨. 이해는 됨. ㅠㅠ; 딸리는 영어실력, 명사절인지 형용사절인지.. 젠장.. ㅠㅠ- 만약 write-back이 비활성화되어 있으면 프로세서는 물리메모리와 동시에 캐시를 업데이트할 것 이다.)
d. write-buffers are small caches which are used to collect data from multiple consecutive write operations to adjacent memory locations into a single write operation which may subsequently be presented to the caches or physical memory.
(해석 못 하겠음 : write-buffer의 역활로 이해함)
e. cache-coherency refers to hardware-supported mechanisms for keeping two or more separate caches coherent. Typically this allows other processing units to see changes to memory without software support.
(캐쉬-일관성은 두개 또는 그이상의 분리된 캐시 일관성으로 지키기 위한 하드웨어 지원 매카니즘과 관련된다. 일반적으로 이것은 다른 프로세싱 유닛에게 SW 지원없이 메모리 변화를 참조하는 것을 허용한다.)
A particular type of cache-coherency issue faced by OKL4 implementations is the consistency between instruction and data caches. Unless stated otherwise in the corresponding chapter in Part C, programs should always assume a lack of hardware-enforced coherency between instruction and data caches. Programs should therefore
flush all instruction caches after each modification to an executable region in memory. Note that this is rarely a cause of portability problems, as manipulation of executable memory is architecture-specific by nature.
(OKL4 implementations에 의해 직면한 특별한 형태의 캐시 일관성 이슈는 명령어와 데이터캐시간의 일관성이다.... imb 관련된 내용이네...)
5. Address space regions
The address space function is partitioned into address space regions. The OKL4 API defines the following region type:
( address space는 address space region으로 분할된다. OKL4 API는 아래 region type을 정의한다.)
a. User regions are accessible to all threads executing in the corresponding address space.
(사용자영역은 해당 주소 공간에서 실행되고 있는 모든 쓰레드에서 접근이 가능하다.)
b. System regions of an address space are reserved for internal use by the OKL4 microkernel. An attempt by a user thread to access an memory within such a region is detected by the microkernel as a page fault.
(주소공간의 시스템 영역은 OKL4 마이크로커널의 내부사용을 위해 예약되어 있다. 사용자 쓰레드의 이 영역의 메모리의 접근 시도는 페이지 폴터로 마이크로커널에 의해서 감지되어 진다.)
c. the UTCB region described in next section is used by the OKL4 to store the thread control blocks of the threads associated with the corresponding address space.
(다음 섹션에 기술된 UTCB 영역은 해당 주소공간과 결합된 쓰레드의 컨트롤 블럭들을 저장하기 위해서 OKL4에 의해서 사용된다.)
d. Global regions are automatically mapped into each address space and shared between all address space. The generic OKL4 API does not require any such regions to be provided by an implementation. However, these regions may be present on some OKL4 implementations.
(전역공간은 각 주소공간에 자동적으로 연결되고, 모든 address space간에 공유한다. 일반적인 OKL4 API는 구현에 의해 제공되어지기 위해서 이와같은 어떠한 영역을 요구하지 않는다. 그러나, 이 영역들은 몇몇 OKL4 구현들을에서 나타날 수 있다.)
e. Lastly, some architectures define one or more special region.
The UTCB and system regions are known as reserved regions. An OKL4 application should not attempt to access these regions except by using facilities provided by the OKL4 API.
(UTCB와 시스템 영역은 예약된 영역으로 알려져 있다. OKL4 어플리케이션은 OKL4 API가 제공하는 기능들을 사용하여 접근하는 것을 제외하고 이 영역에 접근을 시도해서는 안된다.)
However, such an access does not violate the integrity of other address space in the system. Page fault handlers should always detect attempts to access reserved regions and treat them an unrecoverable programming error.
(그러나, 이런 접근이 시스템상의 다른 주소영역의 보전을 위반하는 것은 아니다. 페이지 폴터 핸들러는 항상 예약된 영역의 접근 시도를 감지하고 그것을 복구할 수 없는 프로그래밍 에러로 처리해야한다.)
5. The UTCB region
Each address space contains a User Thread Control Block(UTCB) region, used by OKL4 to store some of the virtual registers for threads executing in the address space.
(각 주소공간은 주소공간에서 실행되고 있는 쓰레드들의 몇몇 가상 레지스터를 저장하기 위해서 OKL4가 사용하는 사용자 쓰레드 제어 블럭(UTCB)를 포함한다.)
The current OKL4 API does not provide a facility for a user thread to obtain the location of the UTCB region within its address space. The operating system personality must establish its own protocol for user threads to determine the location of the UTCB region.
(현재 OKL4 API는 사용자 쓰레드를 위한 주소공간안의 UTCB 영역의 위치를 얻기 위한 기능을 제공하지 않는다. OS 성격은 반드시 사용자 쓰레드용의 UTCB region의 위치를 결정하기 위한 자신의 규약(프로토콜)을 구축해야 한다.)
The size and location of the UTCB region is fixed in some OKL4 implementations.
(UTCB 영역의 크기와 위치는 몇몇 OKL4 구현안에서 고정된다.)
This allows the operating system personality to treat it as another system region. Such implementation are distinguished by the UtcbRegionWidth parameter which is set to a zero value, and place no restrictions on the number of threads associated with an address space at any given time.
(이것은 OS personality에게 다른 주소공간과 같이 다루는 것을 허용한다. 이런 구현은 0으로 설정된 UtcbRegionWidth parameter에 의해서 구분되고, 어떤 주어진 시간에 주소공간과 결합된 쓰레드의 개수에 아무런 제한을 두지 않는다.)
In OKL4 implemetations with a UtcbRegionWidth parameter set to a non-zero value, the size and location of the UTCB region must be configured by the user, using the SpaceControl system call.
(UtcbRegionWidth 매개변수가 0이 아닌 값으로 설정된 상태의 OKL4 구현에서 UTCB의 크기와 위치는 SpaceControl system call를 사용하여 사용자가 받드시 설정해야 한다.)
Note that the address space must be in the new state, the requested size of the UTCB region must be greater than 2nUtcbRegionWidth, and the selected location must reside within what would otherwise constitute a part of a user region of the address space.
(주소공안은 반드시 new state에 있어야 한것을 주의하라, UTCB영역이 요구하는 크기는 반드시 2의 UtcbRegionWidth승보다 크야 하고, 선택된 위치는 주소공간의 사용자영역의 한 부분을 구성하는 것안에 존재해야 한다.)
Under such implementations the number of threads n associated with an address space at any given time is restricted by the following equation.
(이런 구현 아래에서 주어진 시점에 주소공간과 결합된 쓰레드의 수 N은 아래 방적식으로 제한된다.)
0 <= n <= (2의 RegionSize승/UtcbSize)
Where UtcbSize is defined as 2nUtcbAlignment*UtcbMultiplier and RegionSize is the size of the particular UTCB region configured using the SpaceControl system call.
The effective access permissions for the UTCB region are implementation-defined and cannot be changed by the user. The content of this region is also implementation-defined and described in Part C of this manual. User threads should use the facilities provided by the OKL4 API to access the content of the UTCB region and not attempt to access it directly. On implementations with a user-configurable UTCB region location, OKL4 relies
on the operating system personality to manage allocation of user thread control block entries (UTCB entries) within the UTCB region of an address space. On such implementations, the UTCB region is considered to be an array of UTCB entries, each of which occupies UtcbSize bytes of the UTCB region. The content of individual UTCB entries is implementation-defined. The operating system personality is responsible for ensuring that no two threads within an address space share the same UTCB entry. The location of the UTCB entry of a new thread is configured using the ThreadControl system call.
(UTCB영역을 위한 효과적인 접근 허가는 implementation-defined이다(구현에 따라 달라진다는 뜻임). 이 영역의 내용 또한 implementation-defined이다. 사용자 쓰레드들은 UTCB 내용에 접근하기 위해서 OKL4 API가 제공하는 기능을 사용해야 하고, 이것에 접근을 시도해서는 안된다. 사용자 설정 UTCB 영역 location과 함께 구현한 경우, OKL4는 주소공간의 UTCB영역안의 UTCB 내용들의 할당을 제어하는 것을 OS personality에 의지한다. 이러한 구현상, UTCB 영역은 UTCB 엔트리들은 배열이 되는 것으로 간주된다. 개인적인 UTCB 엔트리의 컨텐츠는 implementation-defined이다. OS personality는 주소공간안의 두개의 쓰레드가 같은 UTCB를 공유지 않도록 안전하게 하는 의무가 있다. 새로운 Thread의 UTCB 영역 위치는 ThreadControl 시스템콜을 사용하여 설정된다.)
*참고 : 이제야 찾음.
- undefined: 잘못된 프로그램으로 인하여 발생하는 결과. (예: null pointer를 dereference 하는 것)
- implementation-defined: 프로그램의 잘못이 아니라 각 구현에 따라 달라질 수 있는 사항.
각 구현체의 제작자는 이러한 사항을 문서화할 의무가 있음. (예: 1바이트를 구성하는 비트 수)
- unspecified: implementation-defined와 같은 성격을 가지지만 이를 문서화할 의무는 없음.
(예: 함수 인자의 평가 순서)
댓글 없음:
댓글 쓰기