Microsoft MVP성태의 닷넷 이야기
닷넷: 2259. C# - decimal 저장소의 비트 구조 [링크 복사], [링크+제목 복사],
조회: 10265
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 8개 있습니다.)
.NET Framework: 539. C# - 부동 소수 계산 왜 이렇게 나오죠? (1)
; https://www.sysnet.pe.kr/2/0/10872

.NET Framework: 540. C# - 부동 소수 계산 왜 이렇게 나오죠? (2)
; https://www.sysnet.pe.kr/2/0/10873

.NET Framework: 608. double 값을 구할 때는 반드시 피연산자를 double로 형변환!
; https://www.sysnet.pe.kr/2/0/11055

개발 환경 구성: 440. C#, C++ - double의 Infinity, NaN 표현 방식
; https://www.sysnet.pe.kr/2/0/11896

기타: 85. 단정도/배정도 부동 소수점의 정밀도(Precision)에 따른 형변환 손실
; https://www.sysnet.pe.kr/2/0/13212

닷넷: 2257. C# - float (단정도 실수) 저장소의 비트 구조
; https://www.sysnet.pe.kr/2/0/13617

닷넷: 2258. C# - double (배정도 실수) 저장소의 비트 구조
; https://www.sysnet.pe.kr/2/0/13618

닷넷: 2259. C# - decimal 저장소의 비트 구조
; https://www.sysnet.pe.kr/2/0/13619




C# - decimal 저장소의 비트 구조

decimal의 경우 float/double과 내부적인 처리는 유사하지만,

C# - float (단정도 실수) 저장소의 비트 구조
; https://www.sysnet.pe.kr/2/0/13617

C# - double (배정도 실수) 저장소의 비트 구조
; https://www.sysnet.pe.kr/2/0/13618

그것들의 관계처럼 단순히 지수부와 가수부에 대한 비트 수만 확장한 것이 아니라, 지수부의 진법을 2가 아니라 10으로 취급한다는 점이 다릅니다. 마이크로소프트의 공식 문서는 (어딘가 있을 듯한데) 찾을 수 없었지만 아래의 글에 이에 대한 내용이 나옵니다.

Decimal floating point in .NET
; https://csharpindepth.com/articles/Decimal

결국, decimal은 16바이트이고 8바이트씩 나눠 다룰 수 있는데 이것을 bit mask로 표현하면 이렇게 구분할 수 있습니다.

[하위 8바이트(64비트)]
가수부 64비트: 1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111

[상위 8바이트(64비트)]
상위 가수부 32비트: 1111_1111_1111_1111_1111_1111_1111_1111_0000_0000_0000_0000_0000_0000_0000_0000
지수부 5비트:       0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0001_1111_0000_0000_0000_0000
Sign 1비트:        0000_0000_0000_0000_0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_0000_0000

따라서, 가수부는 총 96비트, 즉 2의 96승을 다룰 수 있고, 지수부는 5비트로 32까지 다룰 수 있지만 실제로 사용하는 범위는 0~28까지라고 합니다. 그래서 지수부의 경우 1_1111 비트 마스크 중 사실상 0_1111로 처리해도 무방합니다.

예를 하나 들어볼까요? ^^

18_446_744_073_709_551_616m 숫자에 대해 각각의 부호 비트, 지수부, 가수부를 다음과 같은 코드로 구할 수 있습니다.

decimal m = 18_446_744_073_709_551_615m + 1m;

Console.WriteLine($"decimal value: {m}");
byte* pDecimal = (byte*)&m;
ParseDecimalFormat(pDecimal);

private static unsafe void ParseDecimalFormat(byte* pDecimal)
{
    // 1bit - signbit
    // 5bits - exponent (only valid 0~28), 10의 n 승
    // 96bits - mantissa

    // 하위 - 64bits mantissa
    // 1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111;
    // 0111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111;

    // 상위 - 64bits
    // 1111_1111_1111_1111_1111_1111_1111_1111_0000_0000_0000_0000_0000_0000_0000_0000; // 상위 32bits - 추가 mantissa
    // 0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0001_1111_0000_0000_0000_0000; // 5bits - exponent
    // 0000_0000_0000_0000_0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_0000_0000; // 1bit - sign

    byte* hiPart = pDecimal;
    byte* loPart = pDecimal + 8;

    bool signBit = GetDecimalSignBit(hiPart);
    Console.WriteLine($"sign bit: {signBit}");

    ulong exponentBits = GetDecimalExponents(hiPart);
    Console.WriteLine($"10-exponent: {exponentBits}");

    BigInteger mantissaBits = GetMantissa(hiPart, loPart);
    Console.WriteLine($"Mantissa: {mantissaBits}");
}

private static unsafe bool GetDecimalSignBit(byte* hiPart)
{
    ulong hi = *(ulong*)hiPart;
    ulong signBit = hi & 0b_0000_0000_0000_0000_0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_0000_0000;

    return signBit != 0;
}

private static unsafe ulong GetDecimalExponents(byte* hiPart)
{
    ulong hi = *(ulong*)hiPart;
    ulong exponentBits = hi & 0b_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0001_1111_0000_0000_0000_0000;
    return exponentBits >> 16;
}

private static unsafe BigInteger GetMantissa(byte* hiPart, byte* loPart)
{
    ulong lo = *(ulong*)loPart;
    BigInteger lower = new BigInteger(lo);

    ulong hi = *(ulong*)hiPart;
    ulong hiMantissa = hi & 0b_1111_1111_1111_1111_1111_1111_1111_1111_0000_0000_0000_0000_0000_0000_0000_0000;
    hiMantissa = (hiMantissa >> 32);

    BigInteger large = hiMantissa;
    large = large << 64;

    Console.WriteLine($"Low mantissa: {lo}");
    Console.WriteLine($"Hig mantissa: {large}");

    return large + lower;
}

실행 결과는 다음과 같습니다.

decimal value: 18446744073709551616
sign bit: False
10-exponent: 0
Low mantissa: 0
Hig mantissa: 18446744073709551616
Mantissa: 18446744073709551616

숫자에 소수점이 없어서 말 그대로 96비트의 숫자를 다루는 형태입니다. 반면 -0.01m으로 하면,

decimal m = -0.01m;

Console.WriteLine($"decimal value: {m}");
byte* pDecimal = (byte*)&m;
ParseDecimalFormat(pDecimal);

이런 출력 결과가 나옵니다.

decimal value: -0.01
sign bit: True
10-exponent: 2
Low mantissa: 1
Hig mantissa: 0
Mantissa: 1

보는 바와 같이 지수부의 숫자가 2인데요, float/double이 각각 127, 1023을 bias로 잡아 음의 지수, 양의 지수를 표현했던 것과는 달리 decimal은 무조건 음의 지수로 10의 -n 승을 의미합니다.

즉, 위의 경우에는 10의 -2승이 돼 원래의 숫자를 다음과 같은 공식으로 복원할 수 있습니다.

sign * mantissa / 10exponent

위의 공식에 분해한 숫자를 각각 대입하면 원래의 값이 나옵니다.

sign bit: True ==> -1
mantissa = 1
exponent = 2

-1 * 1 / 102 == -0.01

다시 말해, float/double이 2진수를 지수승으로 표기해 0.1 숫자를 제대로 표현할 수 없었던 한계를 decimal은 10의 n 승으로 지수를 계산하기 때문에 0.1에 대한 표현의 제약이 없어진 것입니다. (물론, 그만큼 연산 속도는 느립니다.)

자, 그럼 분해한 숫자를 기반으로 원래의 숫자를 복원하는 코드도 이렇게 간결하게 만들 수 있습니다. ^^

decimal m = -0.01m;

byte* pDecimal = (byte*)&m;
byte* hiPart = pDecimal;
byte* loPart = pDecimal + 8;

bool signBit = GetDecimalSignBit(hiPart);
ulong exponentBits = GetDecimalExponents(hiPart);
BigInteger mantissaBits = GetMantissa(hiPart, loPart);

{
    decimal orignalValue = (decimal)mantissaBits;
    decimal exponent = (decimal)Pow10(exponentBits);

    orignalValue = orignalValue / exponent;
    orignalValue = orignalValue * (signBit ? -1 : 1);

    Console.WriteLine(orignalValue); // 출력 결과: -0.01
}




한 가지 재미있는 점은, decimal의 경우 (float/double과는 다르게) 4바이트 int 배열로 그 구조를 반환하는 GetBits 메서드를 별도로 제공한다는 점입니다.

GetBits(Decimal)
; https://learn.microsoft.com/en-us/dotnet/api/system.decimal.getbits#System_Decimal_GetBits_System_Decimal_

이전에 설명했듯이 96비트가 int의 3개에 해당한다는 점, 그리고 부호/지수 비트의 영역이 남은 32비트에 있다는 점에서 GetBits는 가수부와 지수부/부호부를 어느 정도 분해해서 반환하는 효과를 갖습니다.

참고로, 검색하던 중에 아래와 같은 질문을 봤는데요,

How do check if a decimal has a fractional part in C#
; https://www.reddit.com/r/learnprogramming/comments/1g1f31/how_do_check_if_a_decimal_has_a_fractional_part/

즉, decimal의 값이 소수점을 포함하고 있는지를 확인하고 싶다는 건데, 이런 경우 GetBits를 이용하면 다음과 같이 구할 수 있고,

int[] bits = Decimal.GetBits(m);
bool hasFraction = (bits[3] & 0x7FFF_FFFF) != 0;

혹은 직접 포인터를 구해 저 영역의 값을 확인해도 됩니다.

decimal m = -0.01m;
byte* pDecimal = (byte*)&m;
ulong upper = *(ulong*)(pDecimal + 8);
bool checkFraction = (upper & 0x7FFF_FFFF) != 0;

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 5/10/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2025-05-17 10시36분
본문에서 상위 8바이트의 16비트가 사용되지 않는 것을 볼 수 있습니다. 이유가 뭘까요? 이에 대해 C/C++의 DECIMAL에서 흔적을 찾을 수가 있군요. ^^

What’s with the weird wReserved value at the start of the DECIMAL structure?
; https://devblogs.microsoft.com/oldnewthing/20250516-00/?p=111185

Win32 C/C++에서도 "wReserved"라는 필드로 16비트를 점유하고 있는데요,

typedef struct tagDEC {
  USHORT wReserved;
  union {
    struct {
      BYTE scale;
      BYTE sign;
    };
    USHORT signscale;
  };
  ULONG Hi32;
  union {
    struct {
      ULONG Lo32;
      ULONG Mid32;
    };
    ULONGLONG Lo64;
  };
} DECIMAL;

VARIANT의 vt 필드로 구조를 맞추기 위해서였다고 합니다. 즉, 마이크로소프트는 Windows 환경에 C/C++에서 정의한 VARIANT와 DECIMAL 구조체를 그대로 C#에 도입한 것입니다.

----------------------------------------

눈치채셨겠지만 ^^ 당연히 이러한 정의는 표준이 될 수 없습니다. 찾아보니까, IEEE 754 표준이 있긴 하지만,

Decimal data type - Standard formats
; https://en.wikipedia.org/wiki/Decimal_data_type#Standard_formats

(C#뿐만 아니라) 제각각 언어마다 구현을 달리하는 것 같습니다.

Decimal data type - Language support
; https://en.wikipedia.org/wiki/Decimal_data_type#Language_support
정성태

... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
12069정성태12/2/201921210디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201929654디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201921192디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201920752디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201918642디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201922068오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201920984디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201920069디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201920261Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201922619디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201921844디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201922471디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/201917682오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/201923965개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/201917944개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/201919597.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201920694Windows: 166. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201919577오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태11/14/201923802개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/201921205Windows: 165. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/201921768.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/201921602Windows: 164. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/201924050Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
12046정성태10/29/201918157오류 유형: 577. windbg - The call to LoadLibrary(...\sos.dll) failed, Win32 error 0n193
12045정성태10/27/201918585오류 유형: 576. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 - 두 번째 이야기
12044정성태10/27/201917729오류 유형: 575. mstest.exe - System.Resources.MissingSatelliteAssemblyException: The satellite assembly named "Microsoft.VisualStudio.ProductKeyDialog.resources.dll, ..."
... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...