Microsoft MVP성태의 닷넷 이야기
닷넷: 2259. C# - decimal 저장소의 비트 구조 [링크 복사], [링크+제목 복사],
조회: 10098
글쓴 사람
정성태 (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
정성태

... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13576정성태3/8/202411755닷넷: 2228. .NET Profiler - IMetaDataEmit2::DefineMethodSpec 사용법
13575정성태3/7/202412460닷넷: 2227. 최신 C# 문법을 .NET Framework 프로젝트에 쓸 수 있을까요?
13574정성태3/6/202411894닷넷: 2226. C# - "Docker Desktop for Windows" Container 환경에서의 IPv6 DualMode 소켓
13573정성태3/5/202410470닷넷: 2225. Windbg - dumasync로 분석하는 async/await 호출
13572정성태3/4/202410364닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/202410329닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/202411580닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/202411316닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/202411150닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/202411074오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/202411047오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20249503닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/202411584Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/202410972디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/202410203오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/202411337닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/202411378디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/202412499오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/202411601닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20249758Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/202410868Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/202411006닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/202410320VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20249430닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20249622닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/202411063닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...