LEA是x86中唯一一條內存操作數無法訪問內存的指令嗎？

我使用libdis，來自the bastard的x86反彙編程序庫，我試圖找出哪條指令訪問內存。LEA是x86中唯一一條內存操作數無法訪問內存的指令嗎？

參照這兩個指令：

mov eax, [ebx + 10] 
lea eax, [ebx + 10]

在libdis，兩者都列出了指令類型insn_mov，和地址操作數具有在兩種情況下相同的標誌。所以我可以判斷內存是否被訪問的唯一方法是查看指令助記符。

因此，我的問題是：LEA是唯一使用內存操作數的指令，實際上並不訪問內存？任何鏈接到引用將是很好的。

來源

2013-12-16 QuasarDonkey

我這麼認爲...不知道。 – Mehrdad

prefetchprefetch指令系列（prefetcht1，prefetcht2，prefetcht3，prefetchnta）要求處理器將這些內存行拖入緩存中，因爲這些內存行將很快需要使用。但是，英特爾的文檔清楚地表明，傳遞給預取的錯誤地址不會導致錯誤。這樣軟件就可以傳遞可能出界的地址來進行預取，而不必先檢查它們，以便數據可以在執行這些檢查時進行。

預取也沒有'輸出'，不像LEA。

來源

2013-12-16 23:51:55 SoapBox

Intel有一組採用內存尋址操作數的「NOP」指令。

我不認爲他們碰內存;實際上，我不確定他們是否真的形成了地址並通過內存映射運行並檢查保護。我不這麼認爲;我構建了一個編譯器，它可以用各種尋址模式生成各種不同大小的空間填充NOP，並且永遠不會陷入陷阱。

來源

2013-12-17 00:24:48

看來他們確實可以訪問memoty [根據Peter Ferrie]（http://pferrie.host22.com/misc/lowlevel2.htm）：「有趣的是，儘管它的名字，如果Mod/RM字節告訴它，它也會訪問內存所以這個「無操作」會導致頁面錯誤，畢竟不是NOP。「 –

真的嗎？嗯。我將不得不回頭重新訪問該代碼;如果不在緩存中，內存接觸可能會變慢。 –

我似乎得到了一個不同的故事：http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-September/003881.html我的代碼生成器生成建議的代碼，涉及EAX，在上下文中其中EAX可以是任意值。如果這些確實能夠讀取記憶，我會得到陷阱，但是我沒有遇到這個問題。 Ferrie或Dabbs之一是錯誤的。 –

LEA是x86中唯一一條內存操作數無法訪問內存的指令嗎？

回答

相關問題