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

1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13803정성태11/7/20246568닷넷: 2309. C# - .NET Core에서 바뀐 DateTime.Ticks의 정밀도
13802정성태11/6/20247019Windows: 269. GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점파일 다운로드1
13801정성태11/5/20246840Linux: 100. eBPF의 2가지 방식 - libbcc와 libbpf(CO-RE)
13800정성태11/3/20247814닷넷: 2308. C# - ICU 라이브러리를 활용한 문자열의 대소문자 변환 [2]파일 다운로드1
13799정성태11/2/20245596개발 환경 구성: 732. 모바일 웹 브라우저에서 유니코드 문자가 표시되지 않는 경우
13798정성태11/2/20247251개발 환경 구성: 731. 유니코드 - 출력 예시 및 폰트 찾기
13797정성태11/1/20247216C/C++: 185. C++ - 문자열의 대소문자를 변환하는 transform + std::tolower/toupper 방식의 문제점파일 다운로드1
13796정성태10/31/20246725C/C++: 184. C++ - ICU dll을 이용하는 예제 코드 (Windows)파일 다운로드1
13795정성태10/31/20245941Windows: 268. Windows - 리눅스 환경처럼 공백으로 끝나는 프롬프트 만들기
13794정성태10/30/20246029닷넷: 2307. C# - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
13793정성태10/28/20245980C/C++: 183. C++ - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
13792정성태10/27/20245388Linux: 99. Linux - 프로세스의 실행 파일 경로 확인
13791정성태10/27/20245842Windows: 267. Win32 API의 A(ANSI) 버전은 DBCS를 사용할까요?파일 다운로드1
13790정성태10/27/20245338Linux: 98. Ubuntu 22.04 - 리눅스 커널 빌드 및 업그레이드
13789정성태10/27/20246306Linux: 97. menuconfig에 CONFIG_DEBUG_INFO_BTF, CONFIG_DEBUG_INFO_BTF_MODULES 옵션이 없는 경우
13788정성태10/26/20245100Linux: 96. eBPF (bpf2go) - fentry, fexit를 이용한 트레이스
13787정성태10/26/20246449개발 환경 구성: 730. github - Linux 커널 repo를 윈도우 환경에서 git clone하는 방법 [1]
13786정성태10/26/20246254Windows: 266. Windows - 대소문자 구분이 가능한 파일 시스템
13785정성태10/23/20245599C/C++: 182. 윈도우가 운영하는 2개의 Code Page파일 다운로드1
13784정성태10/23/20246170Linux: 95. eBPF - kprobe를 이용한 트레이스
13783정성태10/23/20245702Linux: 94. eBPF - vmlinux.h 헤더 포함하는 방법 (bpf2go에서 사용)
13782정성태10/23/20245404Linux: 93. Ubuntu 22.04 - 커널 이미지로부터 커널 함수 역어셈블
13781정성태10/22/20245935오류 유형: 930. WSL + eBPF: modprobe: FATAL: Module kheaders not found in directory
13780정성태10/22/20246999Linux: 92. WSL 2 - 커널 이미지로부터 커널 함수 역어셈블
13779정성태10/22/20245576개발 환경 구성: 729. WSL 2 - Mariner VM 커널 이미지 업데이트 방법
13778정성태10/21/20247111C/C++: 181. C/C++ - 소스코드 파일의 인코딩, 바이너리 모듈 상태의 인코딩
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...