編譯後程序塊過大不適合

㈠ 本科獨立用C語言完成沒有優化的C語言編譯器屬於什麼水平

我覺得水平還是很高的，但意義恐怕不大。編譯器技術是非常成熟的領域，而且由於應用場景的限
制實時，復雜的演算法已經自動出局了，你可選的東西是有限的。編譯器可能有很多實現的形
式，虛擬機/解釋器/靜態編譯器 等，也有成熟的開源實現。作為本科生，而非專門研究該分支的學生，應該合理分配自己學習的時間，如果做這個編譯器就干
掉了大半年，那計網和OS這些課程該咋辦？ 

我知道很多人會認為沒有做編譯器優化特指中段優化，不考慮機器碼上的優化比較劃水。但編
譯器優化是一個很復雜的東西：首先它和你用的IR表示有關而且是強烈耦合，SSA IR基本還
好，有開源代碼和文獻記載，你想要的都能在網上挖到但這怎麼體現你的水平是吧。你
要考慮編譯器的性能，盡管編譯器的後端優化基本上可以納入到某種PEabstract interpretation的
范疇中。

要不然你可以通過編寫插件的方式白嫖例如visual studio code這類軟
件的強大編輯功能,如果你寫的不是c compiler,你也可以盡量把語法設計得很像c,這樣你又能進一步
白嫖其強大的intellisense code,當然仍然有不少人或者應該說團隊達到了這一步,到這里,應該卷死
了99.99%的同行應該毫無問題。

㈡ keil編譯後code的大小問題

這個很簡單，首先先說最後一條，你涉及到了小數，也就是浮點數的計算，在所有的單片機中，有的帶有浮點數計算，比如高級的ARM，有些不帶，凡是不帶浮點數硬體計算模塊的，都要通過語言來處理，浮點數的計算是非常復雜的，所以，最後一個代碼最大，當然，結果也最精確。
再說第一個，為什麼會最小，因為單片機會先計算 625/10000，你認為結果是多少？0.0625？
錯，如果你的res是浮點型的，那麼，計算的結果可能是 0.0625，如果你的res是整形的，那麼，計算的結果是0，而這里，我敢肯定，你的res是整形的，相當於再計算 tem = res*0，結果是0，也就是說，你第一條是個錯誤的，得到的結果恆0
而第2條語句，先是計算 res*625，再去計算除法，這樣，不會出現常數結果，所以耗時比第一條語句大。
如果你的結果要求比較准確，我建議你用第三條語句，雖然費時間。
另外，你完全可以用查表法來完成，而不必要用浮點數計算，畢竟51單片機的能力比較差。

㈢ 用keil編譯51程序時,下面的Program Size: data=47.0 xdata=0 code=3092,是什麼意思各個值允許最大是多少

data=47.0 編譯器編譯後，程序總共需要佔用47位元組的片內RAM空間。注意這個大小僅僅是累加而已，並未考慮各個塊之間的空隙，也就是說實際佔用的RAM空間可能多於此數值。
xdata=0 程序未使用片外RAM（映射）空間
code=3092 編譯器編譯出的各個代碼塊總共大小為3092位元組。與前面的data一樣，由於各個塊之間可能存在空隙，因此實際生成的代碼大小可能多於此數值。