簡單的編譯系統好寫嗎

A. 怎樣去寫一個編譯器（用C語言寫C語言編譯器），需要哪些知識做鋪墊，可以給一下相關網站和書籍的推薦嗎

寫編譯器重點就是設計並實現一些數據結構和演算法，語言特點太多的話，代碼寫起來不容易，建議你找一個小語言嘗試下，不要一開始就去嘗試成熟語言。否則你會在寫完語法分析程序以後，遭遇到很大的困難。多數人都是在寫語義分析程序的時候，突然發現自己設計的數據結構很爛，後邊越寫越要命。
如果你想入門編譯器的話，那麼可以看《編譯原理與實踐》，整本書先將編譯器理論，然後後邊教你一步步實現c-miuns（c的子集）的編譯器，包括lex，yacc，都在幾千行代碼左右。這本書講的比較簡單易懂一點
也可以學學斯坦福大學的編譯器設計公開課（aiken設計了一個叫cool的語言，專門用來教人寫編譯器），課程地址上面有人給了：Compilers。這門課以前有個實驗環境（據說已經給了，我以前寫的時候還是用的網上一個不完整的實驗環境），把和編譯器知識無關的內容都給你寫好了，你只需要在固定的地方填上你的內容就可以寫出你的編譯器（不要覺得很簡單哦，人家的代碼寫的很精巧的，讀完就發現寫個好編譯器還是很費腦子的），另外，這個實驗環境有個特點，就是在每一步都提供標准程序做對比，你可以在寫完一部分以後就同標准程序對比，及時發現錯誤。這種方式為寫編譯器又提供了很多幫助
先找個小的，慢慢研究，弄懂了整體的結構再說

B. 寫一個編譯器大概多長時間

寫一個簡單的編譯器，很簡單，一個星期夠了，但是，它肯定沒有實用價值。
你懂的，編譯器要把源程序編譯為目標機器語言的，不熟悉機器指令，可以用匯編作為目標代碼。

C. java語言好學么

1、 java好學嗎?

從某些方面來說，java比較容易學，如果是大學畢業，大學計算機專業里大多開設了java基礎課程，或者學過一點編程，學起java來也會輕松不少。即使是零基礎也不用擔心，java可以零基礎授課，入門比較簡單，難的是學深入，這不是一件容易的事。學習java是一個循序漸進的過程，要想完全憑自學是很難精通這一技能的。

2、java是不是最難學的語言?

Java是一種面向對象的語言，因而在程序設計思路上要比C類的語言簡單得多，但是Java最重要的基礎，起步越踏實，後期的學習越簡單。但問題在於Java的涉及面很廣，並不是單單的知識語言，而是一個知識體系，Java基礎，高級。Java Web，Jave Script，JSP，各種框架知識等等都是需要你去學習的，只有掌握的知識足夠全面踏實，才能成為一個Java工程師。單單靠Java編程語言是無法完成工作的。

java編程語言難度大於PHP Python Golang 小於C++

3、java和c++學哪個找工作范圍比較廣一些，以後的發展能好一些？

前提是兩種語言都是一種熟練度，都需要精通，兩種語言都很熱門，有能力工作都好找，C++更底層，較復雜，應用廣。JAVA通過調用API介面來完成工作(注:JAVA底層實現用C++，C完成的)適合做應用，流行，相對C++簡單

D. 如何編譯一個精簡的Android系統

本次試驗使用的android源碼是4.2，編譯的架構是mini-mips。

一、所做的工作
1、修改build/target/proct/mini.mk，去掉一些不必要的模塊（例如Phone、DownloadManager等）
2、修改SystemServer.java，屏蔽一些service，讓系統能夠啟動起來（例如，Location Manager、Telephony Registry）
3、修改dalvik/vm/native/dalvik_system_Zygote.cpp，注釋掉因為檢查不到外部存儲而導致dalvik abort的地方 （這是googel的一個bug，在2013年1月份已解決，如果用這以後的代碼不用修改此處）
4、修改WindowManagerService.java，把發送BOOT_TIMEOUT消息的時間改為0（之前為30秒）

二、系統優化後的效果（驗證工作均在mips模擬器上進行）
1、節省運行內存，下面是全編譯與mini編譯的內存使用狀態的對比
1）full build
MemTotal: 499360 kB
MemFree: 242064 kB
2）mini build
MemTotal: 499360 kB
MemFree: 395192 kB

2、縮短開機啟動時間
在虛擬機上的啟動時間
1）full build－29秒
2）mini build－14秒

3、只啟動home程序，其餘的應用程序均被移除

三、保留android的開發環境
1、adb，ddms，apkinstall等，都能正常工作
2、在eclipse中編寫的android應用程序能夠運行在該mini-android之上

四、開機自動啟動指定應用程序
本次測試使用Gallery.apk應用程序，修改其源碼後可以實現隨系統的啟動而自動啟動的功能。

E. 開發一個 C++ 編譯器的難度有多大，難點又在哪裡

C++的前端是出了名的復雜度和可靠性要求並駕齊驅的軟體。

（這兩點都比它高一個數量級的大概就只有OS了）

對於這種系統，唯一的辦法就是燒錢。

燒錢的作用主要包括：
1.留人；
2.填坑；
3.買買買。

先說留人：復雜度一般是「細節」的代名詞。現實中的編譯器大多數以遞歸下降為主，自底向上的歸納推導為輔。這兩樣在教科書上也就是幾頁紙的事情。但是現實總是很殘酷的，人們總想讓語言更加「易用」，這就意味著各種上下文相關的情況都會出現。

對於C++來說，你要判斷一個符號是類型或者變數（比如這個符號被用在模板參數中），要看前面的聲明/定義。這就是一個上下文相關的推導。然後你就會寫大量的if else switch case之類的代碼來解決各種各樣的可能分支。寫它的人當然知道它是做什麼的，但是如果這個人離職了，新來一個人，就呆掉了，這寫的都是什麼煞筆玩意兒。因為它不知道現實中怎樣的需求會導致奇形怪狀的邏輯。所以人員的穩定，對於這種長周期迭代、邏輯復雜的項目是很重要的。但是人的水平要求高嗎？不算高也不算低。總結來說就是：有邏輯，知好歹。技術什麼都可以培養，但是態度和基本智商是比較難培養起來的。

至於怎麼保證人員穩定？很簡單：加薪。

再說填坑：編譯器是對正確性要求很高的基礎軟體。這里的正確性既包括產生的代碼的正確性，也包括編譯器自身對於各種問題的容忍度和足夠豐富的錯誤提示。容錯和錯誤提示本身也是代碼，也有很大的出錯幾率。所以這些軟體，bug少不了。但是作為基礎軟體，你又不能隨便就2+3搞成了2*3，這樣還怎麼讓別人相信愛情。所以要燒很多錢來養一幫debugger。

再說買買買：古人日：我們不用很麻煩很辛苦也可以成佛。既然這么費神我們自己做干什麼，不如買別人的吧。於是MS就乾脆不自己做了，直接去EDG整了個前端，這樣就可以少了不少人年。這就是傳統土豪和水果這種新暴發戶想的不一樣的地方。

傳統土豪想的是：我們有這么多錢為什麼還要自己解決問題呢？買買買！
水果新貴則是：啊呀，不小心有了這么多錢，我們要不要給自己製造點問題好把這些錢花出去？