nansama님 처럼 어셈블리 코드를 살펴보면..
좀 더 세세하게 확인이 가능하겠네요..(한번도 해본적은 없지만.. -0-)

참고해서 다음부터는 좀 더 자세히 확인해보도록 해야겠습니다.
고맙습니다. 답변 많이 도움이 되었네요

nansama 님이 쓰신 글 :
: 조금 버그인듯 합니다.
: 어셈블리 소스를 살펴본 결과 nTmp2   = (int)(log(128) / log(2)); 이 줄에서는 FPU의 결과를 int형 자료로
: 변환할때 _ftol() 내부 함수를 사용 하는데 그 함수에서 약간 버그가 있다고 생각 됩니다.
: FPU의 연산 결과는 7 이었지만 _ftol()을 거치면서 6으로 변경 되었습니다.
:
: 하지만 항상 부동소수를 사용 하실때는 정확한 값이 아니라는것을 염두 하셔야 합니다.
: PC에서 부동 소수를 표현할때 지수 형태로 저장 하므로 7을 float형으로 저장 했을때
: 6.99999999 와 같은 값을 가지는 지수로 변환 될수 있습니다. 6.99999999 를 int로 케스팅 하면
: 무조건 내림 하기 때문에 6으로 표현 되는 것이죠..
: PC에서 float 형의 데이타 기록방법을 공부 하신다면 이런 어처구니 없는 현상도 이해 하게 되실 겁니다.
:
: 이성진 님이 쓰신 글 :
: : {
: :     String  strTmp;
: :     double  dbTmp;
: :     int     nTmp1;
: :     int     nTmp2;
: :     dbTmp   = log(128) / log(2);
: :     nTmp1   = (int)(dbTmp);
: :     nTmp2   = (int)(log(128) / log(2));
: :     strTmp.sprintf("TmpDb[%f] Tmp1[%d], Tmp2[%d]",dbTmp, nTmp1, nTmp2);
: :     ShowMessage(strTmp);
: : }
: : 결과 "TmpDb[7.000] Tmp1[7] Tmp2[6]"
: :
: : 나누기 연산중 값이 Tmp1[7] Tmp2[6]가 달라지는 현상이 발생하네요..
: : 같은코드를 MFC로 컴파일 했더니 Tmp1[7] Tmp2[7] 컴파일러 버그인 걸까요?
: :
: : xxx.ini에서 읽은 각 BIT POS를 가지고 있다 저장해도 될터인데..
: : for문을 돌린다거나 해서 현재 BIT POS를 찾아내도 될터인데..
: :  그래도 조금 더 간단한 방법은 없을까요 ?
: :
: : 일단 하는 일은
: : 1. xxx.ini 에서 비트 설정을 읽어서
: :   [IN]
: :   START=x
: :   END=x
: : 2. m_maskIn구조체에 저장을 하고..
: :   m_maskIn.nStart = pow(2, START_BIT_POS);
: : 3. 프로그램 내부에서 m_maskIn을 사용하다 UI조작으로
: :   m_maskIn의 값들을 log(m_maskIn.nStart) / log(2.0)연산으로 저장하는 구조 입니다.