1樓：網友
這個看個人習慣，有的用r0~r7，有的用累加器。還有的用其他暫存器。
組合語言中的子程式呼叫引數的傳送方式有哪些
2樓：網友
這個看個人習慣，有的用r0~r7，有的用累加器。還有的用其他暫存器。
3樓：網友
子程式引數傳遞的方法一般有三種：
1)暫存器傳遞法：適用於引數少時。
2)變數傳遞法：適用於同一原始檔(程式模組)中。
3)堆疊傳遞法：只適用於傳遞入口引數。
子程式呼叫時，有哪幾種常用的引數傳遞方法
4樓：動起凱來
子程式引數傳遞的方法一般有三種： 1)暫存器傳遞法：適用於引數少時。 2)變數傳遞法：適用於同一原始檔(程式模組)中。 3)堆疊傳遞法：只適用於傳遞入口引數。
在組合語言程式設計中，主程式與子程式之間進行引數傳遞的方法有哪些
5樓：網友
組合語言中主程式與子程式引數傳遞的方法有以下幾種：
1.暫存器法。
暫存器法就是將入口引數和出口引數存放在約定的暫存器中。
優點：資料傳遞書讀快、程式設計較方便、節省記憶體單元。
缺點：當傳遞引數過多時候，由於暫存器個數有限，及暫存器的頻繁使用，將導致暫存器不足。
適用：引數較少的子程式。
2。約定單元法：
約定單元法顧名思義是吧入口引數和出口引數都放在事先約定好的單元中。
優點：不佔用暫存器、引數個數任意、每個子程式要處理的資料和送出的結構都有獨立的儲存單元。
缺點：但用一定數量的儲存單元，增加程式設計中對變數定義的難度。
3.堆疊法。
堆疊法是利用堆疊來傳遞引數的。
優點：引數不佔用暫存器，和儲存單元。引數存放在公共堆疊區，處理完後客恢復。引數個數一般不限。
缺點：由於引數和子程式混雜在一起，存取引數時候必須小心計算它在堆疊中的位置。要注意斷點的儲存和恢復。
4.位址表法。
這種方法是把引數組成的一張參數列放在某個儲存區中，然後只要主程式和子程式約定好這個儲存區的首位址和存放的內容，在主程式中將引數傳遞給位址表，在子程式中根據位址表給定的引數就可以完成操作。
6樓：網友
1、通過暫存器傳遞；
2、棧中開闢空間傳遞；
3、通過記憶體單元傳遞；
4、通過磁碟檔案傳遞。
組合語言(用子程式呼叫來程式設計的問題!)
7樓：沙崖思
只跟你說一下大體思想吧。其他的還是你自己作比較好。
1.用指標si和di分別指向資料區和儲存區首位元組，則a2首位址為[si+leng]，同樣sub1首位址為[di+leng]
然後用mov ax，[si];mov bx，ax;add ax，[si+leng];mov [di]，ax;mov ax，bx;
sub [si+leng];mov [di+leng]，ax然後指標後移add si，2（如果是位元組變數則為1）
2.十進位轉二進位就是用除2的辦法。用div指令，對於字變數，商在ax中，餘數在dx中。
dx中的值只可能為1或0。再用shr和ror指令將dx的值移入暫存器bx中，注意所移動的位數。當ax中的值為1或0時，將其移入bx即結束。
顯示的話，需將結果每一位轉成ascii碼即可。
轉八進位只需將轉好的二進位從低到高三位一組轉成ascii碼即可。還是使用移位指令，每次移三位即可。
8樓：網友
以往這陣具體的程式設計題是不會有人真正去做到具體步驟給你的，我建議你還是自己去查資料，自己解決，記住，這個世界只有自己才是最可靠的！！
9樓：網友
你給個郵箱吧，我會發給你。
我曾經寫過乙個帶四位數加減乘除運算的小程式。
不知道是否適合你要的。
******c語言中呼叫匯編的方法…*****
10樓：網友
page5開始講的是c語言和彙編的混合程式設計這是arm彙編。
不知道你用的彙編是什麼彙編？
巨集程式與子程式呼叫與區別,巨集程式與子程式呼叫與區別
1.在彙編後產bai生的.obj檔案中,子程式du定義依然存在,zhi而巨集dao定義卻不復存在。專 2.子程式呼叫是在執行時通屬過call指令完成的,而巨集呼叫是在彙編時進行巨集,被相應巨集體所取代。3.將多次呼叫的一段 定義為巨集指令,與使用子程式相比,其執行速度要快 因為過程需要呼叫和返回 但...
51微控制器中組合語言如何呼叫c的子程式
我的程式是keil編譯的，如下 先申明extrn code send crc send crc是c中的函式，彙編中加了 呼叫的時候 lcall send crc 如果要專 使用c中的變數，那麼code變成 屬相應的data,xdata等 我的程bai序keil編譯器，extrn code du se...
請問大家組合語言中子程式呼叫指令和跳轉指令有什麼區別？謝
簡單點說，call指令在跳轉前儲存當前指令地址，而jmp一類的指令不儲存當前指令的地址。詳細點說 call指令在跳轉前會在棧中儲存當前的程式計數器 ip 的值 有必要的話還要儲存cs 儲存完ip的值後，再去執行跳轉指令。即相當於 push cs 沒有這種指令,有沒有這一句還要看呼叫的型別 far n...