This topic is now archived and is closed to further replies.


This topic is 5816 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anyone have any idea how to read binary? I don''t plan on making a compiler or anything. I''m just wondering where the people who know how to make compilers get their knowledge of binary stuff for.
Please excuse me now while I get the kick the sh*t out of this f**kin monitor.

Share this post

Link to post
Share on other sites
I know it''s probably a huge topic so I''d best state right now that all''s I want is a pointer or two to some resources on the subject.

Please excuse me now while I get the kick the sh*t out of this f**kin monitor.

Share this post

Link to post
Share on other sites

0 = 0
1 = 1
10 = 2
11 = 3
100 = 4
101 = 5
110 = 6
111 = 7
1000 = 8
1001 = 9
1010 = 10
1011 = 11
1100 = 12
1101 = 13
1110 = 14
1111 = 15

... and so on...

Share this post

Link to post
Share on other sites
For computer representations of numbers, there are a few extra things. Since each bit in the memory is either 0 or 1, it means that you can''t store a radix point (eg 1.0101) or a negative sign.

The two main things used to counter that on PCs is 2''s complement and floating point numbers.

2''s complement is used for storing signed numbers, and it works like this:

The number you want to store: a = -5
The absolute value of the number you want to store: b = 5
b in binary: c = 00000101 (assuming an 8 bit datatype)
Add 1 to c: d = 00000110
Inverse d: e = 11111001 = 2''s complement of 5

So, if the computer was to interpret that number, firstly, it does a check to see if it is positive or negative. This is done by checking the first bit of the number, if it is 0, then the number is positive, and nothing needs to be done to the number. If it is 1, then the number is negative.

So, given a negative number, say: 11010100, to work out what the actual number is you do the same thing, add 1 and inverse:

a = 11010100
b = a + 1 = 11010101
c = Not b = 00101010
d = decimal c = 2 + 8 + 32 = 42

but, since we know that the number is negative, then it is actually representing the number -42.... negative the meaning of life.

Ok, crash course number 2, this one is a bit more complicated, it is floating point numbers. It is very similar to scientific notation we use in decimal, like: 2.57 * 10^5

For a 32 bit floating point number, it is stored like this:


Where: S is the sign bit (1 for negative number. 0 for positive)
E is the exponent (more on this)
M is the mantissa (more on this)

The way the number is interpretted is:

(-1)^Sign * Mantissa * 2^Exponent

Example floating point number:

0 01111111 1010000 0000000 0000000

To work out Mantissa, you take the MMMMMMs in the representation, example:


Now, in scientific notation, the whole part of the first number (the 2 in 2.57) is always in between 1 and 9. But, since this is binary, the whole part is always between 1 and 1, which means that the first digit is always 1. So, instead of storing that 1, they just assume that it is there, this is called normalising. So, the mantissa in the example would be interpretted as:

1.1010000 00000...

whichi is decimal:
1 + 1/2 + 1/8 = 1.625

Next step is to look at the exponent, this is stored using a format called excess 127. Where the actual number being represented is how much the number exceeds 127, so, we subtract 127 from the number:

01111111 -
00111111 = decimal 1 + 2 + 4 + 8 + 16 + 32 + 64 = 127

This means that the example number is:
1 * 1.625 * 2^127 = 2.76 * 10^38... a big number.

By using a smaller exponent, it is possible to store fractions, and by using a large exponent like in the example, big numbers can be stored.

But, there is one thing I forgot to mention. Using floating point as I just described, there is no way to store the number 0, you could try:

0 00000000 0000000 00000000 00000000

but, I said before that the mantissa would be normalised, so it would be:

1 * 1.0000 * 2^-127

which is a very small number, but it still isn''t 0.

But fortunately, 0 is an exception to the rule, and to store it, you just use all 0s as I just did, and it is interpretted as 0. Also, you can have negative 0 by changing the sign bit.

The other exceptions come with special numbers:

0 11111111 xxxxxxx...

are all NaN (not a number), there are special values stored in the xxxxxxx''s which indicate errors and stuff, like overflows, division by zero, infinity, Sqr(-1)... that kind of thing.

Trying is the first step towards failure.

Share this post

Link to post
Share on other sites
I'm assuming you're trying to understand how to read binary (base 2) numbers?

You can think of a number as the sum of the products of each of its digits and the base times the place of the digit. In other words, 18273 = 3 * 100 + 7 * 101 + 2 * 102 + 8 * 103 + 1 * 104. For binary numbers, you just use a 2 instead of a ten.

Lets take the binary number 1001101:

1001101 = 1 * 20 + 0 * 21 + 1 * 22 + 1 * 23 + 0 * 24 + 0 * 25 + 1 * 26

If you're asking not how to read base 2 numbers but how to interpret the numbers in a hex editor when you open an exe file in it, then I know there are resources online. You can run searches under topics like "x86 opcodes" and I'm sure you'll find information.

Edited by - TerranFury on January 8, 2002 9:27:17 PM

Share this post

Link to post
Share on other sites
Well, actually, I''m really trying to read the letters/numbers in executables. Well really, just trying to read numbers and letters in binary. Not specifically exes. I got a disassembler I use for that once I learn ASM.

Please excuse me now while I get the kick the sh*t out of this f**kin monitor.

Share this post

Link to post
Share on other sites
What you want to research into is assembly - assembly being basically a coding language that translates directly into the binary values you''re seeing in the executable files. I believe you can open the executables in Visual studio (and probably other compilers) and view them in asembly form rather than purely binary.

You know, I never wanted to be a programmer...

Alexandre Moura

Share this post

Link to post
Share on other sites
If you want to read "files", then you want t0 know about hexidecimal (base 16).

0x0 - 0x9 in hex = 0 - 9 ind ecimal
0xA = 10
0xB = 11
0xC = 12
0xD = 13
0xE = 14
0xF = 15
0x10 = 16

Just search google if you want more info. You might want to know about the ascii equivalent of the hex numbers also.

Share this post

Link to post
Share on other sites