不負責任猜測,有錯還請多指正!!

system call 有涉及到hardware control 部份,我想這一部份一定是組合語言來完成的!!
或者 GUI畫面呈現程式,為了做到流暢,GUI的function call 也是組合語言來完成!!

至於多工部份,應該就是C語言為主了!!

這個黃大仙出口

就是表示他們家的硬體

有問題




看看他之前的喊的

都是這個樣子

你也太迷信組合語言了吧

真的要做, 頂多是使用量大(瓶頸)的地方用組合語言改善.

大量使用組合語言, 會很難維護.

個人認為, 演算法與程式寫法才是重點.

沒錯 軟體架構跟如何用硬體來加速才是重點, Quartz, Core Animation 等 都透過 GPU 來最佳化... 這部份Apple其實很早就開始導入(2003), 之後 Vista Window compositing, 到 Linux 的 compiz.

Android 部份的話, 2.0 才有基本的GPU compositing / 一直到 3.0, Skia opengl backend / Animation framework 才開始追齊iOS

軟體架構 Apple 在設計iOS就有考慮到 手機裝置的限制(CPU RAM 相對不強), 所以很多元件設計都會用 Lazy initialization / Tile base rendering. 這點在Android 就比較少看到...

至於組語蠻多部份都是用在畫面處理(Software renderer), 多媒體運算的部份(DSP library), 會直接用 NEON assembly 來最佳化, 畢竟 Compiler 說笨也很笨, 另外有些C library, memory 處理的部份 也會用組語.

Kernel 幾乎很少用 組語, 除了最開始載入 跟 處理器相關會用到組語, 大部份都是用 C 做掉... 最近比較先進的部份的話 大概就是Linux kernel 在 有人在 netfilter 部份用JIT來最佳化..

所以我才說,以前的我....

因為當時剛學Assembly Language ,小有心得, 不知天高地厚
又對遊戲設計有興趣,所以才會這麼說的...

請多見諒!!

現在知道, 組語加上C語言 才是王道!! :shy:

GUI的部分要流暢應該是要借助像GPU這類的硬體處理單元,我想如何善用GPU這類的裝置跟是否用組語或C語言沒有太大的關係,關鍵是有如何有效率的利用GPU的架構管理像頂點和貼圖這類很吃頻寬的資源..

而且現在手機平台都可以支援到OpenGL ES 2.0的標準了,反而都是用shader language來撰寫跟影像處理相關的程式,才會快

我覺得Apple最成功的地方在於,它把一些電腦常用到的功能帶入手機,但關鍵是阿公阿罵都會用....

以前我不會用電腦的親戚,在IPhone流行後,每天都在用手指滑來滑去玩game

最失敗的例子就是以前搭配Windows系統的PDA,根本就是把桌上型電腦的介面塞到小小的PDA螢幕中,有夠白吃的~

這一點對於反蘋果的人來說，
永遠不會是他們能夠理解的部分

一個東西要做得好，
還要做到大家都會用，
難上加難

原來是以前... :ase

我以前也做過類似的傻事... 想自己寫繪圖函數庫, 還鑽研如何畫基礎元件最快 :flash:

直到真正入門才發現, 以前真蠢, 做出來的東西慢到爆 :jolin:

老實說
玩Game不是問題
跟掌上型差不多簡單
但是其他應用還是...
隨便一個東西點開
要幹嘛還是一問三不知