以下出自–《cortex-M3權威指南》

程序狀態(tài)寄存器組（PSRs 或曰xPSR）

中斷屏蔽寄存器組（PRIMASK, FAULTMASK,以及BASEPRI）

控制寄存器（CONTROL）
xPSR：
記錄ALU算數邏輯單元(Arithmetic Logic Unit) 標志（0 標志，進位標志，負數標志，溢出標志），執(zhí)行狀態(tài)，以及當前正服務的中斷號。

應用程序 PSR（APSR）

中斷號 PSR（IPSR）

執(zhí)行 PSR（EPSR）
這里嘮叨下，只因不熟悉。。。。
通過MRS/MSR 指令，這3 個PSRs 即可以單獨訪問，也可以組合訪問（2 個組合，3 個組合都可以）。當使用三合一的方式訪問時，應使用名字“xPSR”或者“PSR”。
關于ICI/IT、T：
ICI：在中斷延遲中有提到，與LDM/STM的處理機制有關。LDM/STM是一串LDR/STR的速度優(yōu)化版。于是，為了加速中斷的響應，CM3支持LDM/STM指令的中止和繼續(xù)，就好像它們只是普通的一串LDR/STR一樣。為了實現“指令撕裂與粘合”的目的，需要記錄中斷時數據傳送的進程。為此，CM3在xPSR中開出若干個“ICI位”，記錄下一個即將傳送的寄存器是哪一個（LDM/STM在匯編時，都把寄存器號升序排序）。在服務例程返回后，xPSR被彈出，CM3再從ICI bits中獲取當時LDM/STM執(zhí)行的進度，從而可以繼續(xù)傳送。
這個辦法聽起來是個好主意，只是在個別情況下還有一點限制：IF‐THEN(IT)指令的執(zhí)行也需要在xPSR中使用幾個位，可它需要的位剛好與ICI位重合（類似C中的union）——both ICI bits和IT條件都記錄在EPSR中。所以，如果在IF‐THEN中使用了LDM/STM，則不再記錄LDM/STM
的執(zhí)行進度。但盡管如此，及時響應中斷依然是首要任務。此時只好把LDM/STM取消，待中斷返回后繼續(xù)執(zhí)行。–這里待續(xù)++

中斷屏蔽寄存器組：

PRIMASK：除能所有的中斷——當然了，不可屏蔽中斷（NMI）才不甩它呢。

FAULTMASK：除能所有的fault——NMI 依然不受影響，而且被除能的faults 會“上訪”。

BASEPRI：除能所有優(yōu)先級不高于某個具體數值的中斷。

控制寄存器：

CONTROL：定義特權狀態(tài)（見后續(xù)章節(jié)對特權的敘述），并且決定使用哪一個堆棧指針

只有在特權級下，才允許訪問這3 個寄存器。

一個指定PSP 進行更新的例子：

LDRR0,=0x20008000MSRPSP,R0BXLR;如果是從異常返回到線程狀態(tài)，則使用新的PSP的值作為棧頂指針123123

cortex-M3權威指南，有這樣一段：

為了快速地開關中斷，CM3 還專門設置了一條CPS 指令，有4 種用法

CPSIDI;PRIMASK=1;關中斷CPSIEI;PRIMASK=0;開中斷CPSIDF;FAULTMASK=1;關異常CPSIEF;FAULTMASK=0;開異常12341234

？CPS指令是？==改變處理器狀態(tài)==change processor state
這款內核也許就這兩個CPS指令

SVC（系統服務調用，亦簡稱系統調用）和PendSV（可懸起系統調用），它們多用于在操作系統之上的軟件開發(fā)中。SVC 用于產生系統函數的調用請求。例如，操作系統不讓用戶程序直接訪問硬件，而是通過提供一些系統服務函數，用戶程序使用SVC 發(fā)出對系統服務函數的呼叫請求，以這種方法調用它們來間接訪問硬件。因此，當用戶程序想要控制特定的硬件時，它就會產生一個SVC 異常，然后操作系統提供的SVC 異常服務例程得到執(zhí)行，它再調用相關的操作系統函數，后者完成用戶程序請求的服務。
這種“提出要求——得到滿足”的方式，很好、很強大、很方便、很靈活、很能可持續(xù)發(fā)展。首先，它使用戶程序從控制硬件的繁文縟節(jié)中解脫出來，而是由OS 負責控制具體的硬件。第二，OS 的代碼可以經過充分的測試，從而能使系統更加健壯和可靠。第三，它使用戶程序無需在特權級下執(zhí)行，用戶程序無需承擔因誤操作而癱瘓整個系統的風險。第四，通過SVC 的機制，還讓用戶程序變得與硬件無關，因此在開發(fā)應用程序時無需了解硬件的操作細節(jié)，從而簡化了開發(fā)的難度和繁瑣度，并且使應用程序跨硬件平臺移植成為可能。開發(fā)應用程序唯一需要知道的就是操作系統提供的應用編程接口（API），并且了解各個請求代號和參數表，然后就可以使用SVC 來提出要求了（事實上，為使用方便，操作系統往往會提供
一層封皮，以使系統調用的形式看起來和普通的函數調用一致。各封皮函數會正確使用SVC指令來執(zhí)行系統調用——譯者注）。其實，嚴格地講，操作硬件的工作是由設備驅動程序完成的，只是對應用程序來說，它們也是操作系統的一部分。如圖7.14 所示

SVC 異常通過執(zhí)行”SVC”指令來產生。該指令需要一個立即數，充當系統調用代號。SVC異常服務例程稍后會提取出此代號，從而解釋本次調用的具體要求，再調用相應的服務函數。例如，

SVC0x3;調用3號系統服務11

在SVC 服務例程執(zhí)行后，上次執(zhí)行的SVC 指令地址可以根據自動入棧的返回地址計算出。找到了SVC 指令后，就可以讀取該SVC 指令的機器碼，從機器碼中萃取出立即數，就獲知了請求執(zhí)行的功能代號。如果用戶程序使用的是PSP，服務例程還需要先執(zhí)行

MRSRn,PSP11

指令來獲取應用程序的堆棧指針。通過分析LR 的值，可以獲知在SVC 指令執(zhí)行時，正在使用哪個堆棧。
由CM3 的中斷優(yōu)先級模型可知，你不能在SVC 服務例程中嵌套使用SVC 指令（事實上這樣做也沒意義），因為同優(yōu)先級的異常不能搶占自身。這種作法會產生一個用法fault。同理，在NMI 服務例程中也不得使用SVC，否則將觸發(fā)硬fault。

PendSV：
另一個相關的異常是PendSV（可懸起的系統調用），它和SVC 協同使用。一方面，SVC異常是必須立即得到響應的（若因優(yōu)先級不比當前正處理的高，或是其它原因使之無法立即響應，將上訪成硬fault——譯者注），應用程序執(zhí)行SVC 時都是希望所需的請求立即得到響應。另一方面，PendSV 則不同，它是可以像普通的中斷一樣被懸起的（不像SVC 那樣會上訪）。OS 可以利用它“緩期執(zhí)行”一個異?！钡狡渌匾娜蝿胀瓿珊蟛艌?zhí)行動作。懸起PendSV 的方法是：手工往NVIC 的PendSV 懸起寄存器中寫1。懸起后，如果優(yōu)先級不夠高，則將緩期等待執(zhí)行。
PendSV 的典型使用場合是在上下文切換時（在不同任務之間切換）。例如，一個系統中有兩個就緒的任務，上下文切換被觸發(fā)的場合可以是：

執(zhí)行一個系統調用

系統滴答定時器（SYSTICK）中斷，（輪轉調度中需要）
舉個簡單的例子來輔助理解。假設有這么一個系統，里面有兩個就緒的任務，并且通過SysTick 異常啟動上下文切換。如圖7.15 所示。

上圖是兩個任務輪轉調度的示意圖。但若在產生SysTick 異常時正在響應一個中斷，則SysTick 異常會搶占其ISR。在這種情況下，OS 不得執(zhí)行上下文切換，否則將使中斷請求被延遲，而且在真實系統中延遲時間還往往不可預知——任何有一丁點實時要求的系統都決不能容忍這種事。因此，在CM3 中也是嚴禁沒商量——如果OS 在某中斷活躍時嘗試切入線程模式，將觸犯用法fault 異常。

為解決此問題，早期的OS 大多會檢測當前是否有中斷在活躍中，只有沒有任何中斷需要響應時，才執(zhí)行上下文切換（切換期間無法響應中斷）。然而，這種方法的弊端在于，它可以把任務切換動作拖延很久（因為如果搶占了IRQ，則本次SysTick 在執(zhí)行后不得作上下文切換，只能等待下一次SysTick 異常），尤其是當某中斷源的頻率和SysTick 異常的頻率比較接近時，會發(fā)生“共振”。
現在好了，PendSV 來完美解決這個問題了。PendSV 異常會自動延遲上下文切換的請求，直到其它的ISR 都完成了處理后才放行。為實現這個機制，需要把PendSV 編程為最低優(yōu)先級的異常。如果OS 檢測到某IRQ 正在活動并且被SysTick 搶占，它將懸起一個PendSV 異常，以便緩期執(zhí)行上下文切換。如圖7.17 所示

個中事件的流水賬記錄如下：

任務 A 呼叫SVC 來請求任務切換（例如，等待某些工作完成）

OS 接收到請求，做好上下文切換的準備，并且pend 一個PendSV 異常。

當 CPU 退出SVC 后，它立即進入PendSV，從而執(zhí)行上下文切換。

當 PendSV 執(zhí)行完畢后，將返回到任務B，同時進入線程模式。

發(fā)生了一個中斷，并且中斷服務程序開始執(zhí)行

在 ISR 執(zhí)行過程中，發(fā)生SysTick 異常，并且搶占了該ISR。

OS 執(zhí)行必要的操作，然后pend 起PendSV 異常以作好上下文切換的準備。

當 SysTick 退出后，回到先前被搶占的ISR 中，ISR 繼續(xù)執(zhí)行

ISR 執(zhí)行完畢并退出后，PendSV 服務例程開始執(zhí)行，并且在里面執(zhí)行上下文切換

當 PendSV 執(zhí)行完畢后，回到任務A，同時系統再次進入線程模式。