※ 引述《tester.bbs@bbs.csie.ncu.edu.tw (try or test)》之銘言：
> > 如果你主要是回應 gsj 的問題, 那麼在你提出不同 process 的情況時,
> > gsj 已經說這不是他認為 "OO非循序" 的情況了, 如下:
> > "我的循序是指 "行程內" 的循序"
> > "行程間也是有一個順序規則的"
> > "Process 的執行順序會由Scheduler 來排定"
> > "(這些東西已經算是OS的議題了，詳情去看看教科書吧)"
> > "至於Interrupt 有的是隨機發生(如網路卡、Keyboard)，有的是定時發生(如Timer)"
> > "但是ISR內部的執行也是循序"
> > "如果它有Task要註冊到Task Queue內執行，它也是循序的"
> > [恕刪]
> > 直接引用 Booch 在 Object-Oriented Analysis and Design 中的定義,
> > Object Model 的必要條件有:
> > 1. Abstraction
> > 2. Encapsulation
> > 3. Modularity
> > 4. Hierarchy
> > 非必要條件為:
> > 1. Typing
> > 2. Concurrency
> > 3. Persistence.
> > 既然 concurrency 是在非必要條件, 那麼就算 concurrency 確算真的
> > 會造成 gsj 所說的 "用非循序的程式設計方式不適合循序的CPU", 又
> 1. 不受 interrupt 影響的 CPU 執行是循序的, 但有 interrupt 機制的
> CPU 就不全然是循序做事的.
看了一連串的討論...實在是霧煞煞...
為何 MCU 一收到 interrupt signal 就不是"循序" 的?
interrupt controller 也不過是通知 MCU 有 hardware event 到了
至於這個 event 要不要處理，完全是由 MCP (CPU)控制的，不是嗎？
你不高興的話大可將該 interrupt 的 trigger bit mask 掉...這樣該 int 應該
就不會來煩你了
收到 interrupt 至少需要做的是把 ack bit 寫回 interrupt controller register
我想這是 ISRﾪ먠minimal critera 吧, return 後 MCU 可以從
Stack register 取回前一次的 PC...我實在是看不出來特別強調"循序"或"非尋序"的
意義
> 2. 把 interrupt 用 OS 掌管 ISR , 透過 Dispatcher , Process 隔開,
> 是在 OS 層之上提供分隔的虛擬執行環境, 這時候的各 process 是併行
> 的.
只是用起來像是 concurrent or parallel 吧...事實上還是是切成一段段的
quantum ，而這段 time slice 可能從幾個 ms 到幾百個 ms....看你高興要在那邊用吧
這應該是由 RTOS 的 Kernel 設計來決定要怎麼切 process/thread
processes 看起來同時執行要跟 interrupt controller/ISR handler
擺在一起講...實在是...
> 首先, 實體的 processor 有了 interrupt 機制, 其本質就不全然是循序的.
> OS 都被歸類有 Concurrent Operation 的成份, 而這種非循序特性還是因應
> interrupt 這機制而來的, 這特性並無 "不自然對應" 的現象.
> 其次, OOPL 在目前的實現形式是架在 OS 之上的 process , 使用者也只是
> 在個別的 single process 下, 執行其程式, 模組間依舊是同步的 call-
> return 或 Synchronous Remote Procedure Call 關係, 在這一點上跟目前
> 的傳統 PL 是相同的.
從 MCU/INT(ISR)/OS 的角度...至少不講繼承跟封裝或虛擬或多型...
RTOS 或是 OO-application 都是可以獨立存在的
找個比較簡單的 RTOS trace 一下(ex. 日系的 ITRON, nucleus, eLinux, WinCe...)
至少在 HAL/Kernel 層你是不太會看到啥 CPP 的東西的...有的話頂多是一些 3rd
party 給的 driver 會有 C++ 的結構
就這個部分看來...硬把 OO 跟 hardware/OS 綁這麼緊....實在是看不出來
其必要性在哪裡 (好吧...我必須承認我的資質弩頓...無法參透 orz)
> 但 OO 的 message passing 與 code+data encapsulation 就跨越出不必然
> 是在 shared memory 架構之上執行的限制, 至少在單機上透過 Virtual
> Memory 隔離的 multi process 間, 其記憶體就不能隨意來往. 假如 OOPL
> 子程式間(如某些不透過 interpreter 執行的 OOPL Compiler)是在不同
> process 或 thread 執行時, message passing 的機制(因為使用這個術語
> 就是有擺脫 synchronous call-return 的習慣涵義), 至少很容易可以透過
> 外部模組(通常是 OS)同時啟動兩個以上的 server process 併行運作. 因
> 此架在 OS 之上的 OOPL 有非循序的併行處理能力, 也不儘然是不對稱的.
> 再進一步, 假如 OS 的 ISR 與 Process Dispatcher 機制被用混合的語言
> 寫成可配合語言呼叫的模組, 送到 process 外的 message passing 也用
> communication ISR 來處理, 這種 "非循序現象" 就更自然了.
OS/OO-application 的 message passing 難道就不是循序執行的嗎？
那究竟是誰負責傳遞 event 進出 event queue 的呢？
還不是 system process, 這段程式用 OO 寫或是直接用 SDK 寫有很大的差異嗎？
> > 跟 OOP 有什麼關係.
> > 你在探討的似乎是 "到底要不要把 process model 從 OS 整合成為
> > OOPL 的語法",
> > 只是如果把 process model 歸類到 OS 中, 可以廣為大眾所接受,
> > 又可以讓 process model 有更大的發展空間,
> > 又何必一定要把所有的東西都放到 programming language 中?
> 想說的是合理又有效率的 "銜接" , 不是誰整合誰.
回歸主題...除非有多個各自獨立的 SOC 在同一個系統...否則單一處理器的系統中
指令的部分是循序執行的，有 OS 頂多是讓你看不到 context switch 的作業
用起來像是多工執行，實際上還是用一行行的指令讓 CPU 循序執行的
反過來想，難不成用了 goto 或是 long jump, CPU 就會只執行 line 1, 3, 5
的指令嗎, 將 instruction 跟 data 擺在一起，CPU 就會錯亂嗎？
看了老半天，還是不懂 CPU 要不要循序執行指令跟程式要不要用 OO 開發有啥關係
有效率的銜接? 這邊的效率指的是花多少 man-power 還是花多少 $$ 還是程式跑多快？
--
進來亂的
--
※ Origin: 交大資管心靈小站 <bbs.iim.nctu.edu.tw>
◆ From: mx.iim.nctu.edu.tw