How can the same sequence of bytes might represent an integer, floating-point number, character string, or machine instruction?

Question

I have just started to study about computer systems and I came across this line. How can the difference in the contexts in which we view data objects make this happen?

Bytes store numbers, now that number represents something, a symbol or a character or something else so how can the same sequence of bytes represent different things in different contexts?

Answer 1

The 8-bit binary pattern 10000000 (aka 0x80), can represent:

• in Windows Code Page 1252: the EURO symbol
• in Latin-1: a control character
• in UTF-8: a continuation byte contributing 6 bits of zero to a code point

Even getting the value as a number requires an interpretation:

• as an unsigned byte: 128
• as a signed byte in two's complement form: -128
• as a signed byte in one's complement: -127
• in Binary Coded Decimal: 80

Some early computers even strung the bits backward, as in the Manchester Baby experimental computer system (of the late 1940's).

So, a given bit string can have many different interpretations. Whenever we retrieve or operate on information we consider the size (number of bits/bytes), the actual bit pattern (the value), and the type, which describes the interpretation of that bit pattern. That way we know how to manipulate the information such as being able to use arithmetic on a number, or display a representation of the value (as a symbol or number) on the screen.

Floating point values generally use either 4 (float) or 8 bytes (double), though there are others. The interpretation of those bits uses fields, dividing the bits into (1) an overall sign bit, (2) mantissa bits, (3) an exponent sign bit and exponent value.

Since 4 and 8 bytes are also popular sizes for integer values, the same 4 byte value can be interpreted as integer or float.

There is no way to examine a bit pattern or value to know what type is intended, that is, whether the value is meant to be an integer, a float, or a code point or symbol, or something else. The value alone is insufficient; we need something extra for differentiation.

We generally do this the other way around: rather than looking at the bits to guess what it might be, we, as programmers, tell the computer how to interpret information. Thus, it is by design that we know how to interpret the value.

Another approach is to tag a value by using (some additional) memory for a tag or descriptor; this allows for dynamic interpretation.

It is generally considered a logic error or flaw in program design or a flaw in programming to interpret the same value using a one interpretation at one point and switching interpretations to another at some other point.

Programs generally decide in advance how a given 4 byte value is going to be interpreted, as we cannot tell by the value. This is part of the type system of programming languages, and in turn of computer instruction sets.

Good type systems prevent illegal and undesired program states and logic errors by preventing the accidental mixing of interpretations, and broadly speaking, this is a very serious issue in programming, with a lot of active and ongoing research. Many type systems use a combination of design-time, fixed determination of type, together with some form of tagging for more dynamic capabilities. Some type systems also work at preventing other logic errors beyond accidental misinterpretation, such as array reference out of bounds, null pointer dereferencing, memory leaks, ownership of memory, race conditions, etc..

A computer instruction set typically provides different instructions for manipulating different sized items with a variety of interpretations (e.g. as signed integers, as unsigned bits, as float or double, etc..). A high-level programming language makes use of these varied instructions to accomplish the intent of the program.

Answer 2

As you said, the meaning of a specific bit pattern is context dependent. To understand what data is encoded in a particular bit pattern, you not only need to know the bit pattern, but also what's done to it.

If the memory location containing that binary data is passed as an address of an object, then that data is probably some kind of pointer.

If the memory is given to an add instruction, then it's probably a number.

If the memory location is pointed to by the program counter, then it's probably an instruction OP code that meant to be executed by the CPU.

Answer 3

Most programming languages have a concept known as "type," implemented via a "type system."

When a programmer writes a program, he will generally declare a set of variables and then write some source code that tells the computer to do something with the variables. Each variable, when declared, is associated with a type, such as integer, byte, or string. The type determines how the compiler will interpret the source code that works with the variables, which will determine what sort of machine code to emit during compilation.

For example, in c#, if I want to add or subtract two numbers I might write:

int a = 2;
int b = 2;
int c = a + b;
int d = a - b;

In this code, I have told c# that I want four memory locations, and I want them treated as integers. On the third line, I can use the + operator on a and b because addition is allowed for integers. And on the fourth line I can use -.

If I wanted to work with strings, I might write this instead:

string a = "2";
string b = "2";
string c = a + b;
string d = a - b;  //Error

In this example, I have told c# to set up four memory locations and treat them like strings. On line 3 I can add them together because addition is valid for strings (it will concatenate them). But on the fourth line the compiler will tell me I have made a mistake, because subtraction is not allowed for strings, since it is not exactly clear what it would do if it were allowed.

Similarly there are data types for dates, times, floating point numbers, and complex structures. In addition, a programmer can often define his own types, such as objects, which can be programmed to represent business concepts, database connections, or other more advanced structures, all of which require a memory location for storage, but have different rules for how to read those memory locations.

In some rare cases you can copy data of one type to a variable of another type. This is generally not allowed in "type safe" languages because the data could be misinterpreted. But in languages like assembly and c, you can do it, and you will usually need to be very careful not to cause problems.

Now what about code? Well, code is just another memory location, and it too gets a name ("symbol"), known as the entry point:

static void main()
{
    int a = 2;
    int b = 2;
    int c = a + b;
    int d = a - b;
}

In the above example, I declare a memory location with an entry point named "main." This memory location will contain the instructions to reserve memory for a, b, c, and d, and it will contain instructions to set them to 2 and to do the math. When I write source code that calls main, the compiler will emit machine-readable code that points the instruction pointer at the entry point main, where it will execute the instructions. Thus there is never any mixing between code and data, and the computer (hopefully) will never try to execute a number or try to do math on code.

Answer 4

Ben Eater has a nice series of videos on YouTube in which he builds an 8-bit computer using breadboards. The result is drastically simplified from what today's computers look like, and lacks a lot of stuff that's standard nowadays, but the underlying concepts are the same. In the videos, he explains machine instructions, memory addresses, storing simple data, etc - and these values are all just stored as bits in various registers and EEPROMs.

The same bits represent different things based on the context in which they live. So, a value of 0b0001 means instruction LDA ("Load A", meaning load a value into the A register) when that value is stored in the instruction register, but it means the number 1 when stored in memory, for example. There is some bit of circuity to decode the LDA instruction into a series of control logic that the computer executes - move a value onto the bus, move a value off the bus, etc.

The key to understanding this, IMO, is realizing that at some point you (as the designer / builder of the computer) get to decide all that. There is nothing intrinsic about the value 0b0001 meaning LDA - it's a decision that Ben Eater made in his videos. He could have just as easily decided that 0b0101 would be LDA, or that 0b0001 would be the ADD instruction. Even the set of instructions that are available need to be decided, as well as the arguments for the instruction, how many microinstructions it will have, etc.

And, as @ErikEidt mentioned in his answer, you have to decide in what format you store your values - unsigned, signed, twos-complement, ones-complement, etc. You may use different formats for different registers or types of memory (instructions probably don't need to be signed, for instance, but you probably want to perform computations involving negative numbers elsewhere in your computer). Again, though, this is a decision you make when you're building the computer.

Once you have all that, you can start to build on top of it with operating systems, programs, programming languages, etc.

Answer 5

At the lowest level (memory and processor) bytes does not intrinsically represent anything (not even numbers!), they are just patterns of bits. Bytes only get "meaning" in how programs operate on these bytes.

Processors take sets of bytes as input to instructions, and each instruction interprets the bytes a specific way, eg.

• the ADD instruction interprets the bytes as integer numbers (where the bits are interpreted as binary digits), and adds them using integer arithmetic.
• the FADD instruction interprets the bytes as floating-point numbers and adds them using floating point arithmetic (see this for how floating point numbers are represented as bits.)
• the AND instruction treats the bytes as booleans or bit-flags (not numbers!) and performs bit-wise logical operations.
• the MOV instruction copies bytes from one place to another, and doesn't interpret them at all.
• the JMP instruction interpret the bytes as a memory address. But the bytes located at that memory address will be interpreted as instructions.

So in short the program code specifies how bits are as interpreted as different kinds of values.