어셈블러의 분기 테이블 (Nasm)

분기 테이블에 대한 질문이 있습니다. 데이터 부문 (DS)에서어셈블러의 분기 테이블 (Nasm)

코드 부문 (CS)

무슨 이득이 방법의 다른 지역 : 이러한 테이블을 선언하는 방법은 두 가지가 있습니다

나는이 다음 예 배운 : 사례 1 :

SECTION .data 
i   dd  2; 
stab   dd  m1,m2,m3 ; branchtable for switch 

SECTION .text 
global  start 
start: 
mov ebx , [ i ]   ;  switch (i) 
cmp ebx , 1 ; 
jl end 
cmp ebx , 3 
jg end 
shl ebx , 2 ;  /∗ stab 4 Bytes ∗/
jmp [ stab+ebx −4];  
m1: ;do something..... 
....

사례 2 : 우리 교수가 우리에게 말했다

SECTION .data 
i   dd  2; 

SECTION .text 
global  start 
start: 
mov ebx , [ i ]   ;  switch (i) 
cmp ebx , 1 ; 
jl end 
cmp ebx , 3 
jg end 
shl ebx , 2 ;  /∗ stab 4 Bytes ∗/
jmp [ cs : ebx+stab −4]; branchtable in codesegment 
ALIGN 4 ;  
stab   dd  m1,m2,m3 
m1: ; do something 
....

, 그 방법이가 더 effectiv하지만 왜 ? 분기 테이블에 짧은 점프가있어서 DS에 표시 할 필요가 없기 때문에?

방법은하지만, 내가 CS 사용하여 교수와 다르다고, 더 효과적입니다 당신이 다루고있는 프로세서에 따라

출처

2012-02-14 destiny

아마도 두 번째 경우에 캐시가 이미 stab이라는 테이블을 포함하는 메모리 위치를 프리 페치했기 때문에? –

피터와 마찬가지로, 캐시 영역과 관련이 있다고 생각하지만, 어려운 사실은 없습니다. 하지만 필자가 보았던 모든 컴파일러 생성 코드 (항상)는 항상 코드 세그먼트에 점프 테이블을 가지고 있다고 말할 수 있습니다. –

아아, 찌르다는 내용을 캐시 한'align'을 실행하기 때문에 더 효과적일까요? – destiny

이 세그먼트 접두사 재정을 필요로 greetz 운명에 따라서 이상, 코드가 더 큰 만들기 프로세스 및 캐시가 적다. 하지만 x86 윈도우 (userland)에서는 CS과 DS이 동일한 선형 주소 공간으로 평탄 해져서 부적절한 최적화를합니다. 세그먼트 기반이 제로가 아닌 경우 따로 FS 및 GS의 모든 세그먼트가 무시됩니다으로 64에서이 멀리 떨어지면하지만

특정 프로세서 (인텔 아톰)도, CS에 느린 액세스 할 수 있습니다, 때문에 (자신의 기지 implicity 0) x64의 플랫 주소 지정 모델. 또한 인텔은 최대한 적은 세그먼트 레지스터 사용을 권고합니다 (레지스터 리 네이머의 부담을 덜어줍니다).

출처

2012-02-14 22:13:22 Necrolis

좋은 의견에 감사드립니다 – destiny

어셈블러의 분기 테이블 (Nasm)

답변

관련 문제