Binary

Started by
7 comments, last by Exellon2000 22 years, 3 months ago
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.
[small]:P I'll lick it if you lick it first :P[small]
Advertisement
Are you asking how to read binary?
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.
[small]:P I'll lick it if you lick it first :P[small]
   0 = 0   1 = 1  10 = 2  11 = 3 100 = 4 101 = 5 110 = 6 111 = 71000 = 81001 = 91010 = 101011 = 111100 = 121101 = 131110 = 141111 = 15 

... and so on...
--- krez ([email="krez_AT_optonline_DOT_net"]krez_AT_optonline_DOT_net[/email])
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:

S EEEEEEEE MMMMMMM MMMMMMMM MMMMMMMM

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
S EEEEEEEE MMMMMMM MMMMMMM MMMMMMM

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

1010000...

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 -
01000000
--------
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.
Trying is the first step towards failure.
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
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.
[small]:P I'll lick it if you lick it first :P[small]
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
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.

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

This topic is closed to new replies.

Advertisement