Microsoft MVP성태의 닷넷 이야기
닷넷: 2259. C# - decimal 저장소의 비트 구조 [링크 복사], [링크+제목 복사],
조회: 11422
글쓴 사람
정성태 (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
정성태
2025-08-01 10시42분
위의 덧글에서, DECIMAL 타입의 크기가 16바이트이고 그중 16비트가 VARIANT와의 호환으로 인해 사용되지 않는다고 했습니다. 비록 VARIANT를 고려해 16비트를 예약한 것이지만 그렇다고 해서 VARIANT의 vt 필드까지 대응하도록 decimal을 정의하지는 않아서 DECIMAL을 VARIANT에 대입할 때 순서가 중요하게 되었습니다.

A consequence of the weird wReserved value at the start of the DECIMAL structure
; https://devblogs.microsoft.com/oldnewthing/20250731-00/?p=111423

가령, 다음과 같이 vt 필드를 먼저 대입하면,

// Wrong
var.vt = VT_DECIMAL;
var.decVal = value;

16바이트 DECIMAL이 그대로 (decVal은 union이므로) var 16바이트를 덮어쓰게 돼 vt 필드도 초기화되므로 오동작을 하게 됩니다. 따라서 반드시 vt 필드를 나중에 설정하도록 주의를 기울여야 합니다.

// Better
var.decVal = value; // the wReserved overwrites var.vt
var.vt = VT_DECIMAL; // but we fix it up immediately

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

위의 원문 덧글에 나온 내용도 재미있는데요, gcc 컴파일러의 경우 최적화 과정에서 vt 필드를 설정하는 코드를 없앨 수도 있다고 합니다. 분명히 소스 코드에서는 설정했는데, 실행하면 설정이 되지 않았으니... 정말 힘든 버그를 만날 수도 있겠군요. ^^;
정성태

... 16  [17]  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13580정성태3/15/202411031닷넷: 2231. C# - ReceiveTimeout, SendTimeout이 적용되지 않는 Socket await 비동기 호출파일 다운로드1
13579정성태3/13/202412572오류 유형: 899. HTTP Error 500.32 - ANCM Failed to Load dll
13578정성태3/11/202414355닷넷: 2230. C# - 덮어쓰기 가능한 환형 큐 (Circular queue)파일 다운로드1
13577정성태3/9/202412877닷넷: 2229. C# - 닷넷을 위한 난독화 도구 소개 (예: ConfuserEx)
13576정성태3/8/202412917닷넷: 2228. .NET Profiler - IMetaDataEmit2::DefineMethodSpec 사용법
13575정성태3/7/202413976닷넷: 2227. 최신 C# 문법을 .NET Framework 프로젝트에 쓸 수 있을까요?
13574정성태3/6/202413372닷넷: 2226. C# - "Docker Desktop for Windows" Container 환경에서의 IPv6 DualMode 소켓
13573정성태3/5/202411395닷넷: 2225. Windbg - dumasync로 분석하는 async/await 호출
13572정성태3/4/202411276닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/202411220닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/202412952닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/202412359닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/202412884닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/202413018오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/202412514오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/202410325닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/202413144Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/202412269디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/202411154오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/202412500닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/202412679디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/202414250오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/202413103닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/202410361Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/202412500Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/202412617닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
... 16  [17]  18  19  20  21  22  23  24  25  26  27  28  29  30  ...