當(dāng)前位置:首頁 > 公眾號(hào)精選 > 嵌入式微處理器
[導(dǎo)讀]編輯整理:張巧龍,來源:大魚機(jī)器人 作者:invalid s 鏈接:https://www.zhihu.com/question/405701348/answer/1329114111 很表面很淺薄的問題。 簡單說愛怎么規(guī)定就怎么規(guī)定,甚至-1到254都行。無非是顯示時(shí)通過編碼表做個(gè)轉(zhuǎn)換的問題而已。 不過,當(dāng)初選擇


編輯整理:張巧龍,來源:大魚機(jī)器人

作者:invalid s
鏈接:https://www.zhihu.com/question/405701348/answer/1329114111

很表面很淺薄的問題。

簡單說愛怎么規(guī)定就怎么規(guī)定,甚至-1到254都行。無非是顯示時(shí)通過編碼表做個(gè)轉(zhuǎn)換的問題而已。

不過,當(dāng)初選擇“補(bǔ)碼”這種編碼形式,卻并不像表面看起來那么淺薄。背后的道道可多著呢。

01

碼點(diǎn)


首先,8位二進(jìn)制一共可以提供256個(gè)“碼點(diǎn)”;那么我們就總可以用這些“碼點(diǎn)”來編碼256種符號(hào)。

這種編碼方案有很多。最著名的大概就是ASCII碼方案了,這個(gè)方案規(guī)定了英文字符(區(qū)分大小寫)、0~9這10個(gè)數(shù)字、標(biāo)點(diǎn)符號(hào)以及一些控制字符如何編碼:


但ASCII碼用來編碼字符效果不錯(cuò);拿來存儲(chǔ)數(shù)字卻極為浪費(fèi)。比如它需要三個(gè)字節(jié)才能表示 123

為了編碼數(shù)字,我們需要一個(gè)更有效的方案。

一種很自然的想法是,我們就直接把二進(jìn)制對應(yīng)的數(shù)字值拿來用,這就是最好的編碼方案!

于是,8個(gè)二進(jìn)制位就可以表示 0~255 之間的所有數(shù)字——用ASCII碼三個(gè)字節(jié)才能表示的 123,直接用二進(jìn)制編碼就是 01111011,一個(gè)字節(jié)足夠了。

這個(gè)方案只能表示正數(shù);遇到負(fù)數(shù)怎么辦呢?

簡單,第一個(gè)二進(jìn)制位拿出來當(dāng)符號(hào)位,剩下七位仍然當(dāng)數(shù)字用,就能表示±127之間的任何數(shù)字了。

這個(gè)方案就叫“原碼”;其中不帶符號(hào)位的就是無符號(hào)數(shù)(unsigned)。

02

原碼



原碼是一種很初級(jí)的編碼方案,它僅僅解決了編碼問題——從此數(shù)字有辦法二進(jìn)制表示了。

但我們在計(jì)算機(jī)內(nèi)部表示數(shù)字是用來計(jì)算的;那么想用原碼計(jì)算的話,那可就麻煩了……

我們知道,最初CPU的內(nèi)部最重要的核心器件叫ALU(Arithmetic and Logic Unit算術(shù)邏輯單元),其中的A就是數(shù)學(xué)。

ALU的核心是加法器,這是個(gè)隨參與計(jì)算的數(shù)值的二進(jìn)制位數(shù)指數(shù)增長的數(shù)字電路。較早期的CPU里面絕大多數(shù)的邏輯門都被拿來做這個(gè)加法器了。

加法器顧名思義只能拿來做加法。

但是沒關(guān)系,如果你調(diào)過機(jī)械表,就知道從8點(diǎn)調(diào)到1點(diǎn)的方式有兩種:一種是往后撥7個(gè)小時(shí),一種是往前撥5個(gè)小時(shí)。


換句話說,在時(shí)鐘鐘面上,8-7 8+(12-7) 效果相同,最終得到的都是1.

類似的,1個(gè)字節(jié)的加減法,如果計(jì)算結(jié)果超過 255 就會(huì)造成溢出,溢出的高位二進(jìn)制數(shù)據(jù)無處存放自動(dòng)丟棄,計(jì)算結(jié)果就出錯(cuò)了——但反過來想,這不恰恰就是一個(gè)邏輯鐘面嗎?

顯然,我們也可以利用這個(gè)性質(zhì)做減法:減32完全可以當(dāng)成加 (256-32) 來算嘛;而由于二進(jìn)制的特點(diǎn),256-32 恰好又等于32這個(gè)數(shù)值取反。

類似的,有符號(hào)數(shù)其實(shí)是一個(gè)符號(hào)位和7個(gè)二進(jìn)制位,7個(gè)二進(jìn)制位能表示的最大數(shù)是 127;因此減 32 就可以用加 (128-32) 代替(和表盤上的12點(diǎn)/0點(diǎn)一樣)。

于是,減法器就可以不做,一個(gè)加法器就足夠用了——省了好大一坨門電路,CPU的制造成本一下子就去了一大塊。

既然最終減法一定要這樣做……那么從一開始就不應(yīng)該用原碼表示負(fù)數(shù),對吧。
不然每次計(jì)算都還得用一條指令判斷判斷符號(hào)位,然后該取反取反……這速度可就慢下去了。

如果從一開始,負(fù)數(shù)就取反表示,那么負(fù)數(shù)加法完全無需判斷,拎起來就加——圓滿。

這個(gè)編碼方案就是所謂的反碼。

03
反碼

反碼是一個(gè)充滿了工程師的惡臭味的優(yōu)秀方案。

說它優(yōu)秀,是因?yàn)樗拇_解決問題;說它惡臭,是因?yàn)樗闷饋韺?shí)在麻煩,需要很多“微妙”的調(diào)整才能得到正確結(jié)果。

比如,它的符號(hào)位相加后,如果產(chǎn)生了進(jìn)位,就要把進(jìn)位送回去加到最低位上——你得搞一大張真值表才能確定這個(gè)做法的正確性。

嗯……這就是最容易產(chǎn)生沒人看得懂但絕對不能動(dòng)不然就會(huì)出錯(cuò)的神奇代碼的重災(zāi)區(qū)——反正它就是能工作;剛開始我還知道為什么得這樣做,一段時(shí)間后就只有上帝知道了。

反碼行為奇特的根本原因在于,它有兩個(gè)零:+0 -0,分別對應(yīng)于 0000000010000000 ——還記得嗎?我們規(guī)定第一位是符號(hào)位。因此最前面的0/1是±號(hào),并不是數(shù)值。

+0 -0 都是 0. 它們是同一個(gè)數(shù)據(jù),卻得到了兩個(gè)碼點(diǎn)。

打個(gè)比方的話,這就好像夜里 12點(diǎn) 就是 0點(diǎn) 一樣;結(jié)果我們的鐘匠師傅沒想明白,偏偏要在鐘面上、12點(diǎn)1點(diǎn) 之間添加一個(gè)零點(diǎn)——然而邏輯上我們?nèi)匀恍枰?strong> 12小時(shí) 是一圈。

現(xiàn)在,你還想好好調(diào)表嗎?算的準(zhǔn)準(zhǔn)的,8點(diǎn) 前擰 5個(gè)小時(shí) 就是 1點(diǎn)了 ;結(jié)果擰完一看,0點(diǎn) ?

徹底亂套了,對吧。

而反碼的計(jì)算規(guī)則呢,無異于規(guī)定了過 12點(diǎn) 的方向——正著過正常去 1點(diǎn),反著過會(huì)先停在 -0點(diǎn) 上,所以必須推一把。

注意這個(gè)調(diào)整是計(jì)算過程的一部分,每次計(jì)算都必須即時(shí)調(diào)整。這是一個(gè)額外的負(fù)擔(dān)——和顯示時(shí)查表轉(zhuǎn)換到光學(xué)點(diǎn)陣/向量是不想干的兩個(gè)過程。

或者說,數(shù)據(jù)的內(nèi)部表示和外部顯示之間的轉(zhuǎn)換是另外一個(gè)必不可少的流程。這里只要不是太過復(fù)雜就不能算額外負(fù)擔(dān);而原碼/反碼這兩個(gè)編碼方案已經(jīng)影響了計(jì)算過程,造成了額外的性能消耗。

一言以蔽之:能解決問題,但是太難看、太復(fù)雜。

一個(gè)更好的方案叫補(bǔ)碼。

但是在介紹補(bǔ)碼之前,我先來講一個(gè)數(shù)學(xué)概念—群。

群大概來源于“算術(shù)運(yùn)算以及適用算法運(yùn)算的集合”的抽象,但又超脫于簡單的四則運(yùn)算,是一切計(jì)算/變換類似行為的總綱。

在群的觀念里,加減乘除都是一種“二元運(yùn)算”;二元運(yùn)算是一個(gè)集合G中任意兩個(gè)元素向群中另一個(gè)元素的映射。比如 1+1 就映射到了 2

注意群有“封閉性”,意思是群中任意兩個(gè)元素經(jīng)過二元運(yùn)算后,映射的那個(gè)元素都還要在群中。因此(自然數(shù),加減法)就不是一個(gè)群,因?yàn)闇p法會(huì)映射到負(fù)數(shù)。

此外,二元運(yùn)算需要滿足結(jié)合律,要有單位元(任何元素與之執(zhí)行二元運(yùn)算后都會(huì)映射到該元素自身),等等。

更復(fù)雜的東西我也還看不懂(對不起,俺數(shù)學(xué)水平太弱雞了);但了解這么多其實(shí)也已經(jīng)夠了:反碼存在兩個(gè)0,意味著對于加法運(yùn)算來說,它存在兩個(gè)不同的單位元;而根據(jù)群的定義,群里面有且只有一個(gè)單位元。

因此,在反碼這個(gè)基礎(chǔ)上無法定義一個(gè)群——用人話說就是,你不可能期望找到一種不需要判斷的算法,從而基于反碼模擬加減法運(yùn)算。

沒錯(cuò),反碼有兩個(gè)零這事并不像外行想象的那樣無關(guān)痛癢——它并不僅僅是浪費(fèi)了一個(gè)碼點(diǎn)的問題,而是破壞了相關(guān)結(jié)構(gòu)的性質(zhì)的問題。

04

本質(zhì)


如何解決這個(gè)問題呢?

不妨返璞歸真,看看這個(gè)問題的本質(zhì)。



很簡單,和上面等待寫入時(shí)間信息的無字鐘面一樣:這里有256個(gè)不同的二進(jìn)制編碼,我們需要給它們分別指定一個(gè)意義。

我們希望它們是連續(xù)的編碼,且基于二進(jìn)制的排序不能打亂——這樣我們才能使得基于這些碼點(diǎn)的、拋棄溢出位的加減法運(yùn)算構(gòu)成一個(gè)群。

只有它們是一個(gè)群,我們才能簡單明了的在加法器上支持加減法運(yùn)算——而不是先算一個(gè)瑕疵值然后想辦法彌補(bǔ)、把硬件/軟件變得復(fù)雜。

打個(gè)比方的話,就是把這些二進(jìn)制編碼按順序排于鐘面,我們要在上面填上帶±號(hào)的數(shù)字。

原碼的問題在于,它的編碼排列“不按固定順序”,使得因此必須把負(fù)數(shù)先“顛倒”一下(實(shí)際上取反)才能用;而反碼頭疼醫(yī)頭腳疼醫(yī)腳,大致保證了編碼順序,卻沒能消除額外的無效碼點(diǎn),造成在±0這個(gè)位置兩個(gè)碼點(diǎn)對應(yīng)一個(gè)編碼。

這兩個(gè)編碼都沒法自然構(gòu)造出加法群。

借用@任衛(wèi)同學(xué)的這張圖:


可以很清晰的看出補(bǔ)碼編碼的連續(xù)性。

(相比之下,原碼是0 1 2 3……127 -0 -1 -2……-127,順序上一會(huì)兒從小到大一會(huì)兒從大到??;補(bǔ)碼按照一定的順序編碼但是多了個(gè)-0;

只有補(bǔ)碼,嚴(yán)格按照統(tǒng)一的順序連續(xù)排列數(shù)字)。

既然連續(xù),那么通過加一個(gè)值(可能為負(fù))調(diào)整對稱中心(比如 0 的位置是00000000 還是 11111111)、然后再引入模運(yùn)算剔除高位溢出,這個(gè)群就建立起來了。

換句話說,隨便你如何編碼,只要?jiǎng)e改變底層的二進(jìn)制順序、不要有跳躍/重復(fù)碼點(diǎn),那么這個(gè)計(jì)算就仍然是一個(gè)群。

這個(gè)計(jì)算過程和最終的顯示是完全脫鉤的,你不需要在計(jì)算時(shí)做任何調(diào)整——溢出就隨它溢出,反正(在模運(yùn)算的層面上)算出來的值總是對的。這是群的性質(zhì)所保證的。

(注意是“模運(yùn)算的層面上”,換句話說算出來的實(shí)際意義是什么還是得你自己解釋;尤其是產(chǎn)生溢出之后。)

比如,哪怕你把它的編碼范圍改成 [-129, 126] 或者 [-1, 254],這也僅僅是一個(gè)加/減一個(gè)整數(shù)的映射操作而已;核心計(jì)算法則仍然會(huì)滿足你的需求)。

甚至,你規(guī)定 0代表1、1代表0,最終也不過是顯示時(shí)換一個(gè)不同的譯碼表而已,并不改變問題性質(zhì)。

這個(gè)性質(zhì)是普適的。

7位、8位或者32位、128位二進(jìn)制全都適用。

一旦明白了這個(gè)……再寫環(huán)形緩沖時(shí),你還要費(fèi)勁巴拉的檢查什么時(shí)候需要繞回嗎?求個(gè)余(或許還需要再視情況不同增減一個(gè)常數(shù)),完事。

你看,數(shù)學(xué)這種東西厲害吧?

哪怕群論門檻都摸不到的這么一點(diǎn)點(diǎn)皮毛知識(shí),帶來的就是眼界水平的差異。

一旦了解了這點(diǎn)皮毛,關(guān)于補(bǔ)碼的種種清規(guī)戒律神奇規(guī)則,也就平常。
但沒有這個(gè)眼界,就容易像反碼那樣動(dòng)輒得咎;反之,隨你怎么玩都不會(huì)出界。

沒錯(cuò)。別看這東西簡單;

但想要做第一個(gè)提出的人,你還是需要強(qiáng)悍的洞察力的。

站在群論的肩膀上、反向碾壓這個(gè)問題,這是伽羅瓦之后的現(xiàn)代人特有的福利。

-END-




推薦閱讀



【01】數(shù)學(xué)對于編程來說重要嗎?編程大佬現(xiàn)身說“線性代數(shù)”
【02】一個(gè)硬件工程師的叛逆?zhèn)髌?/a>
【03】C語言求解線性方程組
【04】嵌入式軟件測試的10條秘訣
【05】全面分析6大國產(chǎn)CPU處理器


免責(zé)聲明:整理文章為傳播相關(guān)技術(shù),版權(quán)歸原作者所有,如有侵權(quán),請聯(lián)系刪除

免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場,如有問題,請聯(lián)系我們,謝謝!

嵌入式ARM

掃描二維碼,關(guān)注更多精彩內(nèi)容

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時(shí)聯(lián)系本站刪除。
關(guān)閉
關(guān)閉