Number Literals, Sizing, and Signed Versus Unsigned

A literal is a constant value you write directly in your code. You can write it plainly, like the number five, or you can write it as a sized and based literal that states exactly how many bits it occupies and in which base. The sized form names a width, then a base such as decimal, hexadecimal, or binary, then the value. Writing literals this way is how you say precisely which bits you mean, instead of leaving it to the tool to guess.

When you write a number plainly with no size, it still has a width and a signedness under the hood; you just did not state them. A plain integer is treated as a signed value of a standard width. That is convenient, but it means a plain literal and a sized literal that look like the same number can behave differently in an expression. This is the first place constants quietly surprise people.

Every value is read in one of two ways. Read as unsigned, every bit adds to a positive total. Read as signed, the top bit carries a negative weight. The crucial idea: the very same bit pattern can mean two completely different numbers depending on which reading applies. A pattern of all ones is the largest positive value when read unsigned, and it is negative one when read signed. The bits do not change. Only the reading does.

Here is the trap, and it is one of the most quietly damaging bugs in real code. When you mix signed and unsigned values in one expression, the rules silently convert things, and a value you believed was negative can become a large positive. The arithmetic does not error. It computes a confident, wrong answer, and the simulation runs perfectly clean. A comparison that is obviously true can come back false. The only defence is to write every literal with the size and signedness you actually intend, and never leave signedness to chance. This lab shows you exactly how a clean looking expression lies.