C語言字符串核對匹配居然還能這樣寫,真是萬能的指針

ID:688692 · 發(fā)表于 2022-6-30 10:20

if(SBUF==((unsigned char code *)"關閉投球")[j])

編譯得到的匯編代碼：
效率一點不受影響。

589:                if(SBUF==((unsigned char code *)"開啟投球")[ i])
C:0x16C8 E52B    MOV    A,0x2B
C:0x16CA 900208 MOV    DPTR,#0x0208
C:0x16CD 93    MOVC    A,@A+DPTR
C:0x16CE B59911 CJNE    A,SBUF(0x99),C:16E2
590:                {
591:                      i++;
C:0x16D1 052B    INC    0x2B

ID:378108 · 發(fā)表于 2022-6-30 18:04

所以,不要動不動就說C的效率比匯編低,
低是和高手的匯編比較,一般的意大利面條匯編,趕不上C的效率

ID:401564 · 發(fā)表于 2022-7-1 10:20

沒看出這里頭有什么文章來
匯編更多的優(yōu)點是占用空間小,這也得是高手來寫才行,有時候匯編寫出來的,占用空間比C還多

ID:624769 · 發(fā)表于 2022-7-1 15:42

看效率,不能斷章取義, 你既然直接引用 SBUF 這個代碼是在中斷里面的吧？你往前翻翻，看看是不是有PUSH DPH 和 PUSH DPL 往后翻翻，看看是不是有 POP DPH 和 POP DPL?

ID:624769 · 發(fā)表于 2022-7-1 15:49

一個明明只需要 MOVC A,@A+PC 就能搞定的事情，非要在 DPTR 里面走一圈。這已經(jīng)說明了效率的低下了。
C 的特點，就是不在乎效率，事無巨細，都用固定的套路。
如果親自動手打匯編代碼，也是全用固定的套路，不如直接用C。沒必要學匯編。
如果不能在不同情況選用最合適的方式，說明不適合學匯編。
真正能用好匯編的，這種編譯器編出來的匯編代碼，是看不上的。

ID:688692 · 發(fā)表于 2022-7-1 17:16

MOVC A,@A+PC 你這個如何指向字符串？改PC?

ID:624769 · 發(fā)表于 2022-7-1 17:44

cnos 發(fā)表于 2022-7-1 17:16
MOVC A,@A+PC 你這個如何指向字符串？改PC?

MOVC A,@A+PC
RET
DB 此處字符串

這種基本的查表格式，基本都知道吧？

ID:329625 · 發(fā)表于 2022-7-1 19:29

指針用得好，事半功倍

ID:883242 · 發(fā)表于 2022-7-2 02:13

本帖最后由 Hephaestus 于 2022-7-2 08:40 編輯

cnos 發(fā)表于 2022-7-1 17:16
MOVC A,@A+PC 你這個如何指向字符串？改PC?

DOS 5.0 (038-N) MCS-51 MACRO ASSEMBLER, V2.2
OBJECT MODULE PLACED IN DEMO.OBJ
ASSEMBLER INVOKED BY: C:\ASM51.EXE DEMO.ASM
LOC OBJ LINE SOURCE
1 ; ENTRY: ACC = ARRAY SUBSCRIPT
0000 2404 2 ADD A,#(LABLE2-LABLE1)
3 LABLE1:
0002 83 4 MOVC A,@A+PC
0003 B5990C 5 CJNE A,SBUF,LABLE3
6 LABLE2:
0006 57484154 7 DB 'WHAT A FUCK?'
000A 20412046
000E 55434B3F
8 LABLE3:
0012 04 9 INC A
10 END\

復制代碼

不算字符串，一共用了7個字節(jié)的代碼空間，你用了11個，不過無所謂，茴香豆的茴字有幾種寫法并不重要，4個字節(jié)空間無所謂的。

ID:688692 · 發(fā)表于 2022-7-2 08:27

如果是多個命令字符串的核對和匹配，這個MOVC A,@A+PC 就沒有編碼上的優(yōu)勢了，而且一般也不要去動用PC,SP這些敏感的寄存器。
當然匯編有匯編的玩法。
我只是說這樣寫出來的C代碼能很方便的進行命令字符串的核對匹配，而且代碼效率已經(jīng)非常高了。

ID:883242 · 發(fā)表于 2022-7-2 09:02

cnos 發(fā)表于 2022-7-2 08:27
如果是多個命令字符串的核對和匹配，這個MOVC A,@A+PC 就沒有編碼上的優(yōu)勢了，而且一般也不要去動用PC,SP這 ...

沒有動PC

ID:624769 · 發(fā)表于 2022-7-2 12:52

cnos 發(fā)表于 2022-7-2 08:27
如果是多個命令字符串的核對和匹配，這個MOVC A,@A+PC 就沒有編碼上的優(yōu)勢了，而且一般也不要去動用PC,SP這 ...

首先， PC指針，你還真動不了。其次，“SP 一般不要動”，和不能動是兩個概念，真的如果不能動，就像PC指針一樣，你壓根訪問不了，玩C的話，SP確實相當于不能動，那是類似于給自己挖坑埋自己，玩匯編的話，能玩好SP，是真的事半功倍的。
最后，在5樓的回復，主要是跟沙發(fā)說得，對于你的代碼，就C本身而言，代碼編譯后能成這樣，已經(jīng)算不錯了。畢竟你要C編譯器，在特定場合，能通過切換 DPTR1 / DPTR0 來提高效率，或者借用PC指針，這些本身就是奢望。

ID:61140 · 發(fā)表于 2022-7-3 11:41

188610329 發(fā)表于 2022-7-1 15:49
一個明明只需要 MOVC A,@A+PC 就能搞定的事情，非要在 DPTR 里面走一圈。這已經(jīng)說明了效率的低下了。
...

不懂匯編不要亂發(fā)言,等你學過匯編才知道匯編的強大遠不是C可比的.
你所指的只是C在KEIL里生成的匯編代碼,這個代碼還是跟據(jù)你寫的C生成的,這個代碼好不好全在于你的C寫的好不好,但并不說明如果用匯編語言也要這樣寫.

ID:401564 · 發(fā)表于 2022-7-3 16:50

xiaoyuxinke 發(fā)表于 2022-7-3 11:41
不懂匯編不要亂發(fā)言,等你學過匯編才知道匯編的強大遠不是C可比的.
你所指的只是C在KEIL里生成的匯編代碼 ...

有的人總是喜歡以自己的知識水平去評價他人的水平
你怎么就知道人家不懂匯編?
你怎么就知道人家沒學過匯編?
你說這話的依據(jù)是什么?
是不是以你自己的水平來分析別人所說的?
也許人家算不上高手,可匯編還是懂得的,至少匯編是學過的,至少不會像你說的這樣"等你學過匯編才知道匯編的強大"

ID:624769 · 發(fā)表于 2022-7-4 12:35

xiaoyuxinke 發(fā)表于 2022-7-3 11:41
不懂匯編不要亂發(fā)言,等你學過匯編才知道匯編的強大遠不是C可比的.
你所指的只是C在KEIL里生成的匯編代碼 ...

是你閱讀理解有問題，還是說你組詞造句不過關？

撇開我懂不懂匯編先不討論，你覺得我不懂，就當我不懂，這倒無所謂。

噴子也是需要有基礎素養(yǎng)的，就算要噴也要對著點子噴，就算亂扣帽子，也要表面上站得住腳吧？你不能把恐龍滅絕，怪在一個侏羅紀沒出生的人身上吧？

來，你給我解釋一下，哪個匯編代碼是我 “寫的C生成的” ？

ID:887371 · 發(fā)表于 2022-7-4 15:03

xiaoyuxinke 發(fā)表于 2022-7-3 11:41
不懂匯編不要亂發(fā)言,等你學過匯編才知道匯編的強大遠不是C可比的.
你所指的只是C在KEIL里生成的匯編代碼 ...

我學習mcu是從匯編開始的，我很多項目都是用匯編做的。
使用匯編十幾年后，我才開始用C做項目。
現(xiàn)在，假如這款mcu不支持C編譯，就不會被我用于實際項目。
我（使用匯編超過25年）應該有資格說：你的知識體系有問題，匯編沒你想象的那么強大。
1.直接用匯編和用C語言生成的機器語言相比，有可能是短小些，但這需要程序員花費大量的精力（精神狀態(tài)還要極好）。項目簡單點還好說，稍復雜些就沒法做到。
2.不同MCU的匯編指令是不同的，需要花費很多精力和時間適應。
3.現(xiàn)在mcu速度快、ROM大。匯編相比C的那點好處已經(jīng)沒有任何意義。

ID:1008383 · 發(fā)表于 2022-7-11 16:31

可以，指針還是很方便的

ID:130230 · 發(fā)表于 2022-7-11 19:07

C怎么可能比匯編效率高。

ID:401564 · 發(fā)表于 2022-7-11 21:34

jizhongbiao 發(fā)表于 2022-7-11 19:07
C怎么可能比匯編效率高。

C有時候效率是比匯編高的,并不是說匯編效率低,而是寫這個匯編的人技術不行,導致寫出一堆比C效率還低的代碼出來
并不是每個用匯編的都是高手,在這個時候,匯編效率就要比C低,而且更容易出問題
我當初剛開始學匯編的時候,經(jīng)常出現(xiàn)這種問題,現(xiàn)在也一樣,所以,我改用C了

ID:883242 · 發(fā)表于 2022-7-11 23:18

Y_G_G 發(fā)表于 2022-7-11 21:34
C有時候效率是比匯編高的,并不是說匯編效率低,而是寫這個匯編的人技術不行,導致寫出一堆比C效率還低的代 ...

看平臺，像ARM這種RISC結構的，很難寫出比c編譯器效率更高的代碼，很多人一看RISC不就是精簡指令集嗎？很簡單，但實際上精簡指令集的復雜組合是非常難于掌握的，我見過幾個試圖寫ARM匯編的，沒人能寫出比c編譯器效率更高的代碼。

8位單片機是另一個故事了，像STM8源自曾經(jīng)是高大上CPU的6502，寫出比c編譯器更高效的匯編也挺難，但是能做到。8051的結構要簡陋的多，寫出比c編譯器高的代碼相對容易。最蹩腳的是Microchip PIC16單片機，設計之初的目標是用最少的晶體管數(shù)量實現(xiàn)完整功能，就沒想過用高級語言，c編譯器出來的代碼怎么看怎么擰巴和不順眼，這種單片機只要智力正常，不可能寫出比c編譯器更垃圾的代碼。

帳號		自動登錄	找回密碼
密碼			立即注冊

欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

C語言字符串核對匹配居然還能這樣寫,真是萬能的指針

評分