跟大家分享一個我做的單片機C語言編譯器。它的功能和keil軟件差不多，能把C語言
轉換成單片機的匯編程序。不過目前還不完善，只支持MCS51系列的單片機，等以后有時間
我會把這個編譯器移植到AVR和PIC系列的單片機上。雖然C語言很流行，但我個人感覺C的一些
細微地方并不適合單片機，因此在設計這個編譯器時，有些語法和標準C有區別。例如，
這個編譯器擴展了移位運算，移位時可以指定空出的位是用0還是1填充，也可以循環移位，
分別用 <<- <<+ <<< 等運算表示，還提供了一種擴展的控制語句： loop 。使用時
就像下面這樣：
loop( 8 )
{
語句a
}
表示執行8次語句a。實際是用djnz指令實現的，所以效率比for語句高。
對于變量類型則不再用標準C的char short long int 等名稱，而是int+數字或uint+數字形式,
分別表示相應長度的有符號數和無符號數。例如下面的定義：
uint8 a = 0b00001111；//定義8位（一個字節）的無符號數，可以用二進制
int16 b = 12345；//定義16位（兩個字節）有符號數
bit c = high；//定義位變量，賦值為1
bool 游戲結束 = true；//定義布爾類型變量
（標識符、文件名和文件夾等可以任意取名，這個編譯器非常支持中文 ^_^）
另外增加了一個特別的類型--“元件類型”，例如這樣定義一個元件類型：
box s24c256 [uint16*8]
{
interface void set( uint16 addr, uint8 data )
{
...
}
interface uint8 get( uint16 addr )
{
...
}
}
其中set函數用來把一個字節變量data通過IIC總線寫入24c256中，而get函數用來讀取
地址為addr的那個存儲單元的數據。只要定義了這個元件，就可以在外部的24c256中
定義變量和數組、結構體等，例如：
s24c256 uint8 data = 0b00001111;//在24c256中定義8位無符號數data并賦值15。
data可以像一般變量那樣參與運算。當運算中需要讀取data的值時，編譯器會自動調用
get函數獲取值，當運算中需要改變data的值時（如賦值運算data = 34 ）編譯器會
自動調用set函數把34寫入到24c256中，用法和普通的變量完全一致。非常方便。
實際上只要一個電子元件中可以存放數據，你就可以在那里定義數據，如把一個數組定義
到一個128*64液晶屏顯存中，那對這個數組操作時屏幕會有相應的變化，甚至可以在
另一個單片機中定義一個數組，只要用set和get封裝了串口通信程序，就可以在其他單片機
中讀取和修改這個數組的各元素，很有意思吧！
一個源程序由若干個這樣的元件類型組成，每個元件中都可以定義靜態變量、函數和接口等，
每個成員都可以帶有public或private修飾符，當為public類型時表明這個函數或靜態變量
可以在任意地方訪問，當為private類型時只能被同一元件中的函數訪問。
實際上這種新增的元件類型作用非常大，通過它還能實現位變量的數組定義等。目前
我正在想辦法把元件類型用于庫函數的配置，因為下一步我正在打算為這個編譯器添加
庫函數集合，這里的庫函數不是通常的編譯系統自帶的字符串操作、各種浮點運算等函數，
而是其他電子元件的驅動程序，如24c系列的讀寫函數、溫度檢測ds18b20的讀寫函數、
ds1302計時芯片的讀寫和液晶屏1602、128*64等接口函數。但現在有一個問題是這些函數
都不是用#include包含之后就可以直接使用的，都要先進行配置，如24c系列存儲器
函數需定義SCK和SDA對應單片機的哪兩個引腳，液晶1602的數據線怎樣和單片機連接等。
而這些配置應在用戶程序中實現，而不是進入庫函數文件夾修改庫函數。我打算這樣實現：
庫函數由若干個元件定義如液晶屏元件，ds18b20元件等組成，當需要使用哪個元件時
用#include包含進來，而每個元件的配置變量分別用一個“配置元件”定義，當然這個定義
是由用戶編寫的，也就是說庫函數會反向訪問用戶的程序和數據。完整方式如下：
文件 test.c:
#include "AT24C256.h";
box main
{
void main()
{
AT24c256 uint16 data = 34;//在24c256中定義一個16位無符號數
while( true ) {}
}
}
box AT24c256_port //配置元件名稱應為主元件名 + port
{
public bit SCK = &P1_0;
public bit SDA = &P1_1;
}
預計過年后給大家提供的下一個版本將會實現這種帶庫函數的編譯器，因為庫函數會反向訪問
用戶函數和數據，所以庫函數將會以源代碼的方式存放，而不像傳統編譯器那樣以obj形式存放。
這樣將會非常方便，代價僅僅是稍微增加了編譯時間而已。
到目前為止，這個編譯器還有些其他語法尚未實現，生成的hex代碼也沒有進行任何優化，
現在只是從“概念”上實現這種編程語言，至于優化則是以后的事情了。其他說明都在
編譯器文件夾中，大家可以下載了看看。注意這個編譯器是用C#設計的，本身不需要安裝，
隨便復制到哪個文件夾下都行，但運行需要微軟的.NET環境，需要在網上搜一個netframework
安裝之后編譯器才能用（估計vista和win7的已經內置.NET 就不需安裝了，不過沒試過）。
希望各位高手有時間可以幫我測試一下，另外在語法方面我都想的頭疼了，大家應該集思廣益嘛，有好的建議可以郵箱聯系：xbd2048@qq.com。讓我們共同設計一個單片機專用的編程語言.
順便再給大家拜個年 ^_^
網友評論：拍塊磚，C語言編譯器這東西，想做到很實用，難，做得差不多時，宜爭取商業贊助，方能做大做強。
網友評論：to 23樓 HWN: 我也知道這種語言其實很難得到大家的認可,但這個編譯器和相應的語法我會一直開發下去.
0xCC 發表于 2010-1-26 11:01
做C編譯器沒問題，隨著新的CPU的出現還會誕生很多針對某CPU的編譯器。你的問題是“創造新的C”，由于標準具有唯一性（否則就不是標準了），這就把你自己放在了一個非常不合時宜的位置。如果那玩意兒早誕生幾十年，也許標準就是你的了。
建議你改個名字，如C！什么的都行，至于那玩意兒能否成為標準，這就看你的造化了，不是沒那可能。
網友評論：終于看到了傳說中的牛，膜拜一下
我覺得樓主做的至少對自己來說很有意義，做一個編譯器可不是那么簡單，詞法分析，就這一條就夠搞的了。當然，這不是重點。
支持一個！
網友評論：TO computer00:在keil中是,不過我設計的這個編譯器控制語句中的表達式必須返回布爾類型, 所以目前還不能那樣寫.呵呵
0xCC 發表于 2010-1-26 10:27
那我改成
i=9;
while(--i!=0)
{
}
呢
網友評論：那我改成
i=9;
while(--i!=0)
{
}
呢
lxyppc 發表于 2010-1-26 12:40
呵呵,真是不好意思,我的語法中禁止改變操作數的運算有返回值,所以++i和--i還有賦值語句都只能單獨使用了,但這樣處理之后基本就杜絕了標準C語言的邊際效應,變量不會在運算中被莫名其妙的改變,提高了代碼的安全性.
網友評論：跟著標準好，能做51就能做別的，你按標準做，市場就大，換句話說，容易找到新MCU廠家來買你的代碼，
據說微軟從前就是這樣發家的
或者，可以考慮一下，自動生成代碼，也是一個好的發展方向
網友評論：23#
我建議你現在立馬停止寫了。
主要弄弄大方向！
看看你的非標準有沒有市場價值
如果你慎重考慮覺得你的非標準有市場價值 ，然后再繼續寫。
如果覺得沒有市場價值，就按照標準重新寫！
網友評論：肯定有用！
支持樓主，支持！支持！
網友評論：牛！
網友評論：樓主真牛！
網友評論： 23# HWM
我建議你現在立馬停止寫了。
主要弄弄大方向！
看看你的非標準有沒有市場價值
如果你慎重考慮覺得你的非標準有市場價值 ，然后再繼續寫。
如果覺得沒有市場價值，就按照標準重新寫！ ...
xlsbz 發表于 2010-1-26 13:14
把非標準改成標準的應該很容易了,直接修改語法樹部分就行.但現在問題是
一邊是標準語法,另一邊是實用語法,就比如補1移位,補0移位和循環移位,這在單片機
開發中非常有用吧,而且很容易實現,但為了標準就必須全用算術移位 >> << 實現,
感覺有點別扭. 至少目前來說,不想放棄這些非標準語法
網友評論：36#
現在感覺改起來容易！
蓋迪拜大廈，還沒有開始蓋，建筑圖紙 你想怎么改都行。
等住上人了，怎么改都不行！那就晚啦
現在你覺得 ...在開發中有用，等兩年可能就覺得自己考慮的太膚淺了。
盡管真理有時會掌握在少數人手里，但大多數情況并不如此。
網友評論：呵呵,真是不好意思,我的語法中禁止改變操作數的運算有返回值,所以++i和--i還有賦值語句都只能單獨使用了,但這樣處理之后基本就杜絕了標準C語言的邊際效應,變量不會在運算中被莫名其妙的改變,提高了代碼的安全性. ...
0xCC 發表于 2010-1-26 12:52
那我再改成
i=9;
while(i!=0)
{
i--;
}
呢
網友評論：樓主絕對牛人，贊一個，可是這不是標準呀，只能自己想玩的時候玩一下。。。
網友評論：強人，在21第一次看到這樣的強人。。。。
網友評論："標準"的寫法:
i=9;
while( i != 0 )
{
i--;
}
或是
loop(8)
{
}
延時一秒可以這樣寫:
loop( 250 ) loop( 250 ) {}
其實我主要不是為了爭論這個loop, 如果有時間不妨看看其中相對于C語言新增的"元件類型",我認為那才是這個編譯器的最重要功能.
網友評論："標準"的寫法:
其實我主要不是為了爭論這個loop, 如果有時間不妨看看其中相對于C語言新增的"元件類型",我認 ...
0xCC 發表于 2010-1-26 14:15
我也不是在爭這個loop的寫法
我只是想確認一下一些現有的代碼能不能用你的這個編譯器來編譯
因為我認為這才是這個編譯器重要的功能
網友評論：不能啊,只能修改代碼了. 不過我想,如果編譯器能移植到AVR和PIC上,那么代碼將不必進行任何改動(或僅修改端口)就能正常工作,這樣也不錯.
網友評論：不能啊,只能修改代碼了. 不過我想,如果編譯器能移植到AVR和PIC上,那么代碼將不必進行任何改動(或僅修改端口)就能正常工作,這樣也不錯.
0xCC 發表于 2010-1-26 14:30
呵呵，當年C++出來都不敢這么說啊
樓主可要想清楚了
網友評論：電腦和單片機編程是兩回事么. 對于移植性,我是這么考慮的, 即所有類型都有固定的長度,如uint8是8位無符號數,
int16是16位無符號數,通過編譯器不論在哪種單片機上都有相同的結果. 實際上編程時就好像在一個虛擬的單片機上運行一樣,換成另一種單片機時,只要編譯器提供了相同的變量類型和語法,源程序就不需改動了. 而標準C變量類型的長度不是確定的,就不太好移植.
網友評論：但是你的編譯器還是不能編譯現有代碼啊
像我比較懶，要寫什么程序的時候先去幾大芯片廠的網站看看有沒有現成的AppNote
有的話直接就拿過來用了，一般只需要改改配置什么的
網友評論：我會在下一版本中增加一個功能齊全的函數庫,其中包含24c256,ds18b20等常見芯片的驅動程序.
而且會提供一種專門的語法來處理庫函數的配置問題
網友評論：記住 不要玩！！
開發國產編譯器的大任就降落在樓主的身上了！！______同意17樓的意見。
網友評論：唉……
看來還是得繼續用keil
樓主努力啊！
網友評論：現在語言有那么多種.你還是看看發展史吧.
還有國外代碼的層次架構.
啥優勢都想占,往往是什么都占不到.
網友評論：還是先完成至少能編譯像UCOSII那樣的源碼，并且測試正常之后再考慮新的擴展功能。
網友評論：還是嚴格支持C的標準好，因為到后面會發覺，自定義的東西很難推廣開。
早幾年前我寫FinC就碰到了類似的問題，所以到了RT-Thread里的finsh shell，就嚴格使用C的方式。編譯器方面，前端語法實際上是非常小非常小的一方面，優化是功力所在，然后是各種各樣的后端支持。
網友評論：學習了
網友評論：樓主做的嘗試不錯。
只是，現在C語言編譯器不少呵，就算只玩C51，多數人也就算個大眾化的IDE直接弄了。
隨便提的建議：
要是整成這樣：圖形化編程，最好能和別的軟件做接口，比方Matlab/Simulink，弄個框圖，一編譯，直接下載到MCU運行。這種“
硬件在回路”的東西現在還是有些市場的，至少專門做控制算法的一些人能用得上。國外這東西現在賣得爆貴。。呵呵。
網友評論：樓主做的嘗試不錯。
只是，現在C語言編譯器不少呵，就算只玩C51，多數人也就算個大眾化的IDE直接弄了。
cauhorse 發表于 2010-1-26 18:31
呵呵,我的目標是設計一個和任何單片機無關的編譯器,也就是說編譯器的語法對于每種單片機都是完全一致的,這樣一種單片機上的程序有可能不做改動就能在另一種單片機上運行,例如在MCS51上編了個俄羅斯方塊,只要編譯器移植到AVR上,那么這個俄羅斯方塊程序不用修改就可以在AVR中運行.多好啊!以后就向著這個方向努力!
網友評論：
不錯，強人很多...
用什么打開呢？
網友評論：樓主做得很不錯。
網友評論：21里面確實藏龍臥虎，以后要多逛逛
網友評論：好樣的，我們也在做編譯器，我們聊聊。QQ563996855
網友評論：牛人啊,寫編譯器需要很高深的理論基礎吧
網友評論：呵呵,我的目標是設計一個和任何單片機無關的編譯器,也就是說編譯器的語法對于每種單片機都是完全一致的,這樣一種單片機上的程序有可能不做改動就能在另一種單片機上運行,例如在MCS51上編了個俄羅斯方塊,只要編譯器 ...
0xCC 發表于 2010-1-26 18:47
你說的這個和當年JAVA初衷是一樣的，所以后面多了個JAVA的虛擬機，你不會也來個虛擬機吧。
網友評論：絕對不會. 我是說同一個程序既可以編譯到MCS51上,也可以不做修改的編譯到AVR和PIC上. 所以我這里設計的語法是和任何單片機無關的語法,然后編譯器力爭在每種單片機中都實現這些語法,這樣就可以實現我的目標了.
網友評論：頂LZ
網友評論：LZ是出于興趣還是出于什么做這個編譯器呢？
坦率得說，如果是PIC，除非能嵌到MPLAB IDE，否則是沒幾個人會去用的。MLAB IDE的接口文檔，MCHP是不會隨便開放的。
HI-TECH的IDE，中國大陸區根本沒人用，悲劇啊，雖然C編譯器實際用戶很多。
在可以嵌入MPLAB IDE的前提下，C編譯器要懂得在DEBUG的時候規避掉ICD模塊占用的資源。麻煩事還是挺多的。
網友評論：看了這么多，感覺lz對單片機編程不很熟悉，編譯器要做到retargetable，是比較麻煩的，JAVA虛擬機的思路不適合嵌入式系統編譯器
網友評論：看了這么多，感覺lz對單片機編程不很熟悉，編譯器要做到retargetable，是比較麻煩的，JAVA虛擬機的思路不適合嵌入式系統編譯器
wwwq 發表于 2010-1-28 17:35
不是啊, 我不可能在單片機上搞個虛擬機出來. 我的意思相當于讓51系列的KEIL 和AVR的IAR 以及凌陽的SUNPLUSE IDE等有一個完全相同的語法,因為每個編譯器都有點自己的擴展語法. 但這是不可能的,所以才嘗試著做這個編譯器, 我希望它能實現真正的高級語言,能屏蔽不同類型單片機之間的差異, 雖然目前沒能實現. 但我正在努力的做.
MY QQ:910360201 不過經常不上線, 呵呵
網友評論：定LZ，，， 以前不是還有個哥們做了個海爾的C編譯器么？后面怎么沒消息了
網友評論：支持頂一下！
網友評論：牛人!頂一下！
網友評論：
LZ牛人
我在一家IC公司做單片機編譯器，LZ的想法固然好，也是廣大單片機用戶所希望的，但難度不小啊
51、PIC、AVR等單片機指令集都不一樣，且硬件資源也不一樣，Windows下編程我們很少關心CPU的硬件資源，但單片機就不一樣了
網友評論：niejinbo
這位是明白人，lz的勇氣可嘉，但路線不清，不過能有做這個東西的勇氣也比不少高校教授要強得多了，我曾經問過多個學校的
計算機專業的老師，一個最深刻的是說：我們專業的都不搞，你們是無知者無畏。不過我們搞出來了。這里路太長，lz還是別搞了，學生的精力有限。
網友評論：LZ有空可研究下LCC，LCC可以針對不同的目標機器產生不同的代碼，當然需要配置一下
網友評論：繼續關注中
網友評論：做個編譯器不容易,做得通用和用戶認可的更難!
網友評論：頂起
網友評論：不是啊, 我不可能在單片機上搞個虛擬機出來. 我的意思相當于讓51系列的KEIL 和AVR的IAR 以及凌陽的SUNPLUSE IDE等有一個完全相同的語法,因為每個編譯器都有點自己的擴展語法. 但這是不可能的,所以才嘗試著做這個編 ...
0xCC 發表于 2010-1-28 17:58
那你不是做了一個擴展語法而已嗎，和其他的編譯器有何區別，比如IAR,不過是添加自己的擴展語法而已。人家還支持標準C，你倒來了完全自己的語法，連標準C都不完全支持了，呵呵~~
網友評論：精神上支持;不過最好還是弄成與標準兼容的，方便移植；
樓主有這份精力，還不如把比較難的模塊；做成自動生成代碼的；這個可以參考飛思卡爾的processor expert;我覺得做得不錯，但就是生成的注釋太多了。文件本來可以整合成一個的它就要分兩個；造成文件太多，找起來不易。
如果樓主能把AVR PIC 51 等芯片也做成與飛思卡爾的一樣，相信比你這個仿keil的編譯器會成功得多。
網友評論：能寫編譯器，比較牛了
網友評論：支持樓主，加油！
網友評論：hao,非常的好。
http://www.minyantech.com
網友評論：不說好與壞，樓主鉆研的精神就值得小弟學習了~~
網友評論：我在linux下，沒裝rar解壓器，故對LZ的編程思路也不慎了解。
但是正統思路應該是 bison Yacc 之類，不要再自己做輪子了。
如果我記得沒錯，IBM上還有篇教你用yacc做簡單編譯器的小文章。建議LZ看看。
估計LZ是自己寫代碼分析的，做這種事，應該先查查資料
網友評論：又不了解又要教導別人。。
樂子大了
網友評論：頂一下樓主。我也做了一個編譯器，已經用到一個產品中，有時間交流一下。呵呵。我已經加你QQ了
網友評論：醬油打完了
網友評論：謝謝樓主！
