Binary vs. Hex in in source - Page 1
Forum section: electronics / general

author: robotix3
author_rank: Regular Contributor
timestamp: January 21, 2021, 05:32:39 pm
content: I've been wondering for a while why most programmers use hexadecimal in their source code when representing a register mapping or something similar where you need to convert back to binary to have any idea of what the line of code is doing (or have to re-convert when making a modification), such as when an IC uses each bit for a different function. I tend to just type out the binary representation instead (0b00101000 vs. 0x40).Is there an advantage in using hexadecimal or is this just a learned habit?

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 21, 2021, 05:49:32 pm
content: Quote from: robotix3 on January 21, 2021, 05:32:39 pmAn obvious one: the probability of mistyping a binary-coded constant is MUCH higher than mistyping a hexadecimal one.Another one is readability. Yes, actually, hex constants are much more readable than binary ones. Try and convince me that you can spot a given bit (by its index) in a longish binary constant. Whereas figuring that out with a hex constant, if you half know your hexadecimal, is much easier.

author: Ian.M
author_rank: Super Contributor
timestamp: January 21, 2021, 05:54:15 pm
content: Also, because the C standard committee rejected binary constants: "A proposal to add binary constants was rejected due to lack of precedent and insufficient utility." (line 30,page 51 (58 in PDF)), so they are a proprietary extension to the standard (although widely implemented), the use of which may be prohibited by corporate and/or industry C coding standards.

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2021, 06:15:35 pm
content: C standard committee is hopeless. What lack of precedent? All modern languages support binary constants.But yes, hex is much easier to read and interpret mentally, especially on constants larger than 8 bits.

author: brucehoult
author_rank: Super Contributor
timestamp: January 21, 2021, 06:24:54 pm
content: Quote from: robotix3 on January 21, 2021, 05:32:39 pmIt's very hard to understand exactly which bit numbers are set in a long binary number without laboriously counting them. You might get away with it for an 8 bit number, but it's brutal for a 16 or 32 bit value.0b01001010010100000100010101000111 -- what the heck is that?0x4a504547 -- most experienced programmers will immediately recognize this is 4 uppercase ASCII charactersAt least with C++14 you can write the binary literal as 0b0100'1010'0101'0000'0100'0101'0100'0111 which helps a little, but this isn't accepted by C, even with gnu extensions.

author: jpanhalt
author_rank: Super Contributor
timestamp: January 21, 2021, 06:26:21 pm
content: I don't write C, but aren't the shift operations inherently binary?Code: (C)// The result is 00000010printf("a>>1 = %d\n", a >> 1);// The result is 00000100printf("b>>1 = %d\n", b >> 1);return 0;The decision not to allow binary in C seems oxymoronic, if such shifts are allowed. Surely, they are not shifting hexadecimal characters.In Assembly, I use hex when convenient and obvious, e.g., when using byte instructions such as IORLW 0xB0 when setting a new page command for some GLCD. When setting bits in certain registers, e.g., some of the set-up registers, I use binary as the result is more obvious. The TS didn't say which language he was using; although, I agree it is probably C.

author: m k
author_rank: Super Contributor
timestamp: January 21, 2021, 06:29:53 pm
content: Quote from: robotix3 on January 21, 2021, 05:32:39 pmI see it in binary.How many bit you had in mind, 16?

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2021, 06:31:01 pm
content: For delimiters I personally would prefer underscores (and groupings of 8 ): 0b01001010_01010000_01000101_01000111.But again, I would not use binary for actual arbitrary constants, just something that is naturally has one or few bits set.But in practice, I use GCC extensions all the time, so standards compatibility is not an issue for me. Yet, I don't think I've ever used binary. Hex works fine.

author: Syntax Error
author_rank: Frequent Contributor
timestamp: January 21, 2021, 06:44:03 pm
content: @robotix3 It's habbit. I often use decimals, which is really annoying for the hex nerds. Yep, that's 255 not 0xFF. Binary is great for seeing which bits are set. You can mix and match!When it comes to setting registers etc, programmers should use any predefined symbols:Code:#define PORTB #0e#define DDR3 1// set portb pin 3 to outputPORTB = ( 1 < DDR3 )#define LEDRED 0b00000100...// set pin 3 to high/onPORTB &= ( 1 << LEDRED )+I should add when it comes to address ranges (which can be in gigabytes) hex is always used. For example UBI_SPACE=0xa00000100000-0xa00007f80000Remember the default network MAC address of 0xDE:AD:BE:EF:FE:ED

author: PlainName
author_rank: Super Contributor
timestamp: January 21, 2021, 07:55:39 pm
content: Hex is easier to read and successfully write. Strings of 0s and 1s mean nothing.But it depends on context. If I'm defining, say, a character bitmap then using binary shows the actual character there on the paper whereas hex would just be indecipherable. There are other similar situations, so the proper answer to this question is a bit like 'should I use gotos': generally not, but where it's appropriate, sure.

author: brucehoult
author_rank: Super Contributor
timestamp: January 21, 2021, 11:34:24 pm
content: Quote from: ataradov on January 21, 2021, 06:31:01 pmSadly we don't get that option, as the C++ people consciously decided not to follow Ada. The problem, as I understand it, is that _ starts a new identifier.QuoteAnd yet hex constants such as 0x00040000 are super-easy to understand.QuoteAs far as I could quickly establish, GNU doesn't have an extension for this.

author: ejeffrey
author_rank: Super Contributor
timestamp: January 22, 2021, 12:06:38 am
content: Quote from: brucehoult on January 21, 2021, 11:34:24 pmUgh. I first read that and was like "no way, _ isn't anything special, this would only be an issue if you tried to use _ at the beginning of a literal." In C, _ would be a fine choice and not create any ambiguity. In C++ it doesn't conflict with identifiers (which can't start with a digit) but with user defined literals which were added in C++11 or 14 and use the underscore syntax. Basically this means:Sometype t = 0x1234_abcis transformed into a call toSometype::operator""_abc(0x1234).It looks like it is supposed to mimic the type tags such as 1LL. I'm sure that is useful, although I for one would prefer legible separator characters.

author: sleemanj
author_rank: Super Contributor
timestamp: January 22, 2021, 12:39:25 am
content: Quote from: dunkemhigh on January 21, 2021, 07:55:39 pm"I want to set bits 1, 2 and 5", 0b00010011 or 0x13, for me it's the binary that's faster and clearer both to read and write. But I've never been good at hex conversion in my head.Equally "which bits are set by 0x44", requires either considerable brain cycles (or finding the calculator), while "which bits are set by 0b01000100" requires zero brain cycles because that's the answer already.As others say though once you get past 8 bits then binary representation can get very unwieldy, humans are good with groups of between 7 to 10 things maximum, bits in this case, more than that and we lose track easily.

author: MIS42N
author_rank: Frequent Contributor
timestamp: January 22, 2021, 01:26:34 am
content: Surely it's whatever is appropriate for the use. Here's some code I wrote to set up a DAC. I used binary and decimal constants:; --- DAC ---; Analog input on RC2 - all RCx inputs are analog at reset, only; RC2 is used as input so no need to change ANSEL. Get the comparator; +ve input from the DAC - set to approx 1.9V; V = (DACCON0/32)*5BANKSEL DACCON0MOVLW D'12' ; set the voltageMOVWF DACCON1MOVLW B'10000000' ; enable DAC, source Vdd; 1 x 0 0 0 0 x x; | | | -+-; | | | +----- 00 = DAC Positive Source Vdd; | | +-------- 0 = DAC not connected to the DACOUT2 pin; | +---------- 0 = DAC not connected to the DACOUT1 pin; +-------------- 1 = DAC is enabledMOVWF DACCON0But in the code where masks were used, hex made senseMOVF PWM,W ; Add the least significantADDWF Dithr,F ; 14 bits of PWM to DithrMOVF PWM+1,WANDLW 0x3F ; truncate to top 6 of 14 bitsBTFSC STATUS,CADDLW 0x01 ; add in carryADDWF Dithr+1,W ; add to the current DithrBTFSC WREG,6 ; was there 14 bit overflowBSF STATUS,CANDLW 0x3F ; truncate to top 6 of 14 bitsMOVWF Dithr+1MOVF PWM+1,W ; now work out the top 10 bitsANDLW 0xC0 ; get least significant two bits of 10BTFSC STATUS,CADDLW 0x40 ; yes, increase duty cycle 1 bitI just use whatever base makes the most sense when I come back to read it later.

author: Berni
author_rank: Super Contributor
timestamp: January 22, 2021, 07:30:42 am
content: It sort of makes sense at 8bit but when you get to 32bit the binary representation is just one huge snake of 1s and 0s. C was sort of designed for machines larger than 8bit.But i don't see why modern C standards would not include binary number literals. It can be pretty useful given that C is the de-facto standard for low level MCU development.Heck even C# has it! Even allows you to put the underscore delimiters anywhere you like. Yet it's high level interpreted language that is so far from the hardware that it doesn't even care what instruction set the CPU is running. If anything C# shouldn't have this, yet it has (probably because it was so easy to do and doesn't get in the way if you don't use it)Code:int myValue = 0b0010_0110_0000_0011;Still HEX is not that hard to read once you get used to it. A great way to assist you in mentally converting between hex and binary is printing out a table similar to this (but hopefully in a bit more readable form, this one is not that great) and leaving it somewhere near your monitor. You will quickly memorize the common ones, and if you forget a more twisty one like 0xD you can just glance at the table.

author: m k
author_rank: Super Contributor
timestamp: January 22, 2021, 09:09:05 am
content: D is clearly C + 1, like B is A + 1.Here over a byte is generally hex but least 8 bits can differ, like setting as 64 + 32.Notation is also important.Those whitespaces must be there and adding -1 must also be visible.(capital mnemonics, bad rap)

author: ledtester
author_rank: Super Contributor
timestamp: January 22, 2021, 09:50:41 am
content: In some cases it makes sense to represent constants in octal.

author: Ian.M
author_rank: Super Contributor
timestamp: January 22, 2021, 12:20:03 pm
content: Quote from: ledtester on January 22, 2021, 09:50:41 amIf you aren't coding for a processor with 3*N bits per word, and your code uses octal constants *KILL* *IT* *WITH* *FIRE* !!!

author: David Hess
author_rank: Super Contributor
timestamp: January 22, 2021, 04:55:05 pm
content: I freely switch between binary and hexadecimal constants depending on which is more applicable in each case. Sometimes I will use multiple binary constants added together to better show what is going on.

author: PlainName
author_rank: Super Contributor
timestamp: January 22, 2021, 05:26:39 pm
content: Quote from: sleemanj on January 22, 2021, 12:39:25 amAs I said, where appropriate it's appropriateHowever, that example is using magic bits and I think you would be better in that instance to go something like:Code:some_reg = BIT_1 | BIT_2 | BIT_5;Not least because then you can go:Code:some_reg = BIT_1 //!< Invert display| BIT_2 //!< 0,0 is top left| BIT_5; //!< Interrupt on refreshBut then you'd probably be better going:Code:some_reg = DISP_INVERT| DISP_ORIG_TOPLEFT| DISP_REFR_INT_EN;Just as examples - you particular circumstance would dictate, of course, but it illustrates that binary isn't necessarily what you want despite it being what you're thinking.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 22, 2021, 05:49:39 pm
content: Quote from: dunkemhigh on January 22, 2021, 05:26:39 pmFully agree. This makes the overall debate about numeric constants pointless, as they are, as you pointed out, the worst possible way of expressing set bits.Writing constants the way you show above is the right way of approaching it IMO. Some languages have have better support for this than others, but through simple macros, as you showed, this is still very easy to do in C.Sure it takes more "typing" than a single numeric constant. But, as we can see over and over again in discussions about programming languages, this is a moot point IMHO. I'll take readability and maintainability over saving a few keystrokes (while taking much more time to figure out the required constant in binary or hex...) You don't even save time by willing to save keystrokes here, it's usually even the contrary. Not to talk of course, about readability when you have to figure out later on what these bits are actually meaning.Although I don't mind using macros in C, some languages do have better support for this. Two that come to mind are Oberon (and probably a couple of other Pascal derivatives), and Ada.In Oberon, there is a SET type that allows to express "bit maps" easily. For instance, the above example with bits 1, 2 and 5 set would be: { 1..2, 5 }. Neat.In Ada, you can "map" records to bit fields, but, contrary to C, with a guaranteed mapping with no ambiguity or implementation-dependant behavior.That said, if you don't care about portability and know how bit fields are implemented on your particular platform/compiler, using bit fields in C is also an option.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 22, 2021, 06:37:57 pm
content: I think the #1 reason is the original lack in C standard.Universal compiler support for 0b literals is relatively new.Many C programmers have been writing C in 1990's, if not earlier! With no binary literals available and a lot of low-level bit manipulation to do, they/we have learned to convert between hex and binary quickly and intuitively in our heads. Meaning when you see 'a', you immediately think about 1010. And conversely, if you think about 1010, you can just write down 'a', no need to think about it.Optional delimiters would help with readability.

author: brucehoult
author_rank: Super Contributor
timestamp: January 22, 2021, 08:15:08 pm
content: Quote from: Ian.M on January 22, 2021, 12:20:03 pmOctal makes sense for the encoding of instructions on CPUs with 8 registers and 8 addressing modes, such as the PDP-11, M68000, and x86 (the MOD-REG-R/M for example).Octal was actually traditional on the PDP-11. I seem to recall octal digits didn't line up with the 3 bit fields in 68000 instructions, and Motorola used hex anyway. But octal would have made sense for x86 (and I think 8080/z80 too)

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 22, 2021, 11:09:26 pm
content: Quote from: Ian.M on January 21, 2021, 05:54:15 pmThey must have changed their minds, because binary constants are back on the cards for C2x.

author: newbrain
author_rank: Super Contributor
timestamp: January 23, 2021, 01:28:29 pm
content: Quote from: ledtester on January 22, 2021, 09:50:41 amAnd, in fact, you are using octal every time you type the literal 0 in C

author: ledtester
author_rank: Super Contributor
timestamp: January 23, 2021, 06:54:48 pm
content: Quote from: newbrain on January 23, 2021, 01:28:29 pmAnd 1 through 7

author: ataradov
author_rank: Super Contributor
timestamp: January 23, 2021, 06:56:23 pm
content: Quote from: ledtester on January 23, 2021, 06:54:48 pmOnly if you type 01-07.The point of that "fun fact" is that octal constants start with 0, which 0 itself does.

author: gnuarm
author_rank: Super Contributor
timestamp: January 23, 2021, 08:41:48 pm
content: Quote from: brucehoult on January 21, 2021, 06:24:54 pmYou have to wonder who thought apostrophes were a good idea for digit separators??? I code in Forth and VHDL. VHDL uses underscores for this which is much more clear 0100_1101. I have to tame Forth into working with underscores, but Forth will do anything you ask it to do. You don't even need to ask nicely, you just need to let it know you mean business.It's very hard to understand exactly which bit numbers are set in a long binary number without laboriously counting them. You might get away with it for an 8 bit number, but it's brutal for a 16 or 32 bit value.

author: gnuarm
author_rank: Super Contributor
timestamp: January 23, 2021, 08:54:58 pm
content: Quote from: sleemanj on January 22, 2021, 12:39:25 amMaybe I'm unusual, but I do all manner of math in my head. I don't have any trouble deciphering 0x44 as bits 6 and 2 set (0 based). I can see it clearly. It's the naming the bits as 6 and 2 I might have a bit of trouble with immediately. Octal is also easy.Most of this discussion has been about C which I don't use. In most languages hex works fine because the variable sizes are all multiples of 4 bits. In VHDL you can't assign a 12 bit literal to a 10 bit signal or variable. So you need to either use binary, or they did recently (2008) extend the language to have variable length literals, 10x"11A", but not all tools support every 2008 feature... yes, even 12 years later.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 24, 2021, 03:23:12 pm
content: Quote from: gnuarm on January 23, 2021, 08:54:58 pmBut VHDL, like ADA, supports underscores in numeric literals, and has for a long time, so as we said above, that helps. But underscores are not supported in ALL types of lterals, so that can be confusing.For instance, they are for integer literals. For instance (for your example):2#01_0001_1010#They also are for bit vectors:B"01_0001_1010"Oddly, underscores are not supported for std_logic_vector, and that's probably why it's rarely seen in VHDL code, as many people tend to use std_logic_vector everywhere even when using other types would make more sense.Note that the "&" operator in VHDL alleviates all this, if you don't have access to tools that support recent enough versions of VHDL. You can absolutely use it in literals.That would be here:"01" & "0001" & "1010", which is easier to read.You can then combine bases too:"01" & x"1A" works too.Finally, if your constants are really decimal integers but you need to set std_logic_vector, using conversion functions is a lot easier to write, maintain and read (it's unfortunate IMHO that we still see engineers manually converting decimal to binary whereas the compiler can do it for you):std_logic_vector(to_unsigned(282, 10))You can always define a function for this if you find it cumbersome to type:Code:function Dec2SLV10(n : integer) return std_logic_vector isbeginreturn std_logic_vector(to_unsigned(n, 10));end Dec2SLV10;Many ways to skin a cat.

author: Simon
author_rank: Unknown
timestamp: January 31, 2021, 10:34:55 am
content: Baring in mind that I only write in C in Atmel studio. I always get the urge to write in binary when setting up a register so that you can look back at the datasheet and see quickly what it does. But now that I look to ARM 32 binary bits is fraught with trouble and you generally only want to set a few bits so then it makes sense to bit shift the few bit's required and binary can work well. I have never made any effort though to memorize hex.I have often wanted a way of showing bit's in groups but the only way is to create a ton of macro's and even at 32 bit's it still get's hard. I suppose a space every 4 with a double space on every 8? ever 8 bits in a row is hard to read but if you do 4 bit splits it gets hard.

author: PlainName
author_rank: Super Contributor
timestamp: January 31, 2021, 03:21:16 pm
content: QuoteThat's one of the problems with using magic bits - the code is meaningless without the datasheet, and often even with the datasheet you're looking at several pages to resolve what a register's bits do.With macros you sure can fill up a header with them, yes. But the thing is you only need to check them once - after that youknowwhat they are meant to do, and that they are the right ones. The only reason to look at the datasheet is to check that what it does is the function you want, not to keep reminding yourself of which bits to flip every time you come across an operation in your code.

author: Simon
author_rank: Unknown
timestamp: January 31, 2021, 03:27:00 pm
content: This is why I spend several hours creating macro code full of comments that tell the future me how to set stuff up and give bits and register addresses meaningful names.

author: PlainName
author_rank: Super Contributor
timestamp: January 31, 2021, 03:33:58 pm
content: The annoying thing is having done that for some new chip you find you only actually write to a couple of registers in the end. But good typing practice, anyway

author: Simon
author_rank: Unknown
timestamp: January 31, 2021, 03:39:12 pm
content: Well it's work through the peripherals as you need them. Write the code for the configurations you need.

author: PlainName
author_rank: Super Contributor
timestamp: January 31, 2021, 06:17:58 pm
content: I used to do 'em as I needed them, but found that some time later I would need something that wasn't there and the temptation to do a quick hack was very high. Plus it would mean getting the datasheets out and trying to remember what the naming scheme was the first time round, etc. Just less aggro later on to do it all in one go. And, after all, practice makes perfect

author: Simon
author_rank: Unknown
timestamp: January 31, 2021, 08:35:22 pm
content: well as I am writing the macros for getting the whole thing to work in one mode I generally cover most of it and it's quicker to add what is missing as there is so much work already done.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 02, 2021, 09:34:48 am
content: Quote from: dunkemhigh on January 31, 2021, 03:21:16 pmAs I have explained inhttps://www.eevblog.com/forum/microcontrollers/migrating-from-avr-to-stm32/msg3441132/#msg3441132, I have basically "given up" the idea that you could write, read and understand peripheral configuration register accesses just from the code alone. Definitely neither magic bit values, nor MACROS_WITH_THE_DATASHEET_ACRONYM do the job. You can come up with better macro names but then you have added another layer of naming to keep track of, and does it solve the problem, can you describe the bits and all their effects in just A_FEW_WORDS?A long comment explaining what is done and why is the best (how? is trivial: by setting the bits as explained in the manual). In any case, whoever works with that code will need to work together with the manual, with the page(s) containing the register description open at very least, likely they need to look at the peripheral functional description as well.

author: Simon
author_rank: Unknown
timestamp: February 02, 2021, 12:41:05 pm
content: Yea, I often copy datasheet text to the comments and reference the datasheet sections. The pain with writing to registers without renaming is finding the relevant bit in the datasheet but if you include the datasheet paragraph number you can navigate to it very quickly and re-educate yourself.

author: Ian.M
author_rank: Super Contributor
timestamp: February 02, 2021, 12:49:40 pm
content: ... as long as you also know the datasheet *VERSION*. Page and paragraph numbers can move around when the IC manufacturer revises the datasheet.Does anyone know of an IDE that's capable of hotlinking a specific location in a document (not a source filetype) from a human readable reference in a source comment?

author: Berni
author_rank: Super Contributor
timestamp: February 02, 2021, 01:12:27 pm
content: Yeah that is sort of an unsolved problem.But i think as long as you use the same name of the C macro as the datasheet names the register it is good enough. You can just Ctrl+F the register in the datasheet, or most datasheets have register descriptions in a certain section in the table of contents. The names in there are also typically short enough to use. In case of overly short names that basically tell you nothing, then i like to add comments next to the macro definition with the full long name.If you are doing any serious work on hardware driver code then you most likely have the datasheet already open anyway. So i don't see it as much of an inconvenience to look up the register documentation in there.But i do admit that i love the help system in VisualStudio where i can just leave my cursor on the name of a function, press F1 and have the browser pop up with documentation on that function. If pressing F1 inside a hardware register name would open a datasheet on the right page that would be awesome (but i have never seen that one yet).

author: Siwastaja
author_rank: Super Contributor
timestamp: February 02, 2021, 02:19:59 pm
content: Quote from: Ian.M on February 02, 2021, 12:49:40 pmST does never update documentation. The only exception is when they decide to deprecate a brand-new product without warning without having to keep up with the promises of selling the part for 10 years, then they just erase all hints of the parts ever existing and reuse thecompletepart number for the new, incompatible part. Only in this case, documentation is changed. But this doesn't happen too often, thank god, so usually it's the same old documentation for the whole product life cycle.The downside is, the documentation does not match the device behavior. It's written based on original pre-implementation planning, not how the device actually turned out, so mistakes are common and sometimes very significant. No matter how wrong, it's just never corrected. If you are lucky, they add an update to a separate "errata" sheet.But you just found out an upside to all this: you can refer to it easily! That's definitely a bright side, you can explain in your documentation how the thing described on page 1234 is completely wrong and actually works in way xyz, and anyone can easily find page 1234.

author: PlainName
author_rank: Super Contributor
timestamp: February 02, 2021, 03:38:31 pm
content: QuoteAs I noted earlier, your specific circumstances my dictate otherwise. However, in principal I think the macro approach is being a scapegoat in your comments there.For example, you say that you don't like the long and barely different names that produce walls of characters, and you're not alone! This is why I tend not to have such long or unwieldy macro (or function!) names. However, you do realise that if you have a number of macros being used like that you can combine them?Code:#define PERIPH_X_SETTING (PERIPHERAL_X_CONFIG_REG_ASDFG | PERIPHERAL_X_CONFIG_REG_QWER | PERIPHERAL_X_CONFIG_REG_XYZ);...PERIPHERAL_X_CONFIG_REG = PERIPH_X_SETTING;And, of course, using macros doesn't in any way prevent your fromalsodropping in appropriate comments. In fact, in this example you might have the comments with the macro definition so they don't break up the code later on.Next, and I am not sure if this is a joke or not, you say that "a small one-letter mistake easily sneaks in and is hard to find". Actually, it might be very easy to find when the compiler throws a wobbly, but consider that a 1 or 0 mistake will likely not be found until your actual hardware doesn't do what it's meant to, which could be a looooong way down the line. Clearly, the answer here is not to junk macros completely but to choose names appropriately.

author: BitsnBytes
author_rank: Contributor
timestamp: February 07, 2021, 07:33:45 am
content: It's not just a habit it has obvious benefits. It is easy to type, less prone to human errors.Biggest advantage that I think is, if two developers are talking it is much convenient to talk in HEX rather than binary

author: Simon
author_rank: Unknown
timestamp: February 07, 2021, 10:34:49 am
content: But a 32 bit value in hex is still a mind boggling quantity unless it's something easy like all "F"'s in certain locations or "0"'s