Oktal

A register mask operation, input to all four bases

Last winter a colleague spent two hours chasing a peripheral that refused to ack. The interrupt status register read 0xFF00 on the logic analyzer, the driver expected the low byte, and the mask in the C source was written 0x0F0F instead of 0x00FF. Three nibbles off, and the AND came back as 0x0F00 instead of the zero he wanted. Reading the result in only one base hid the problem. Reading it in hex, decimal, octal, and binary at the same time would have made the stray bit at position 8 impossible to miss.

That scenario is the whole point of Oktal. Type FF00 into Value A, pick AND, type 0F0F into Value B, and the result panel shows four numbers stacked: 0x0F00, decimal 3840, octal 7400, binary 0000 1111 0000 0000. The binary view catches the mistake. Position 8 should be zero. It isn't. The mask is wrong.

Why four bases at once, and not a mode switch?

Every base lies about something different. Hex hides bit boundaries: 0xF0 looks tidy and is actually 1111 0000. Decimal hides power-of-two structure: 256 reads as a round number and 255 reads as junk, but the binary tells you 255 is the interesting one. Octal hides the upper bits in any value wider than 24 bits, which is why C uses it for permission masks and nobody trusts it for register layouts. Stacking all four is the point: a four-base output panel that reads 0xFF00 AND 0x0F0F = 0x0F00 / 3840 / 0o7400 / 0000 1111 0000 0000 without making you pick a representation first.

Input    Hex      Decimal   Octal      Binary
0xFF00   0xFF00   65280     0o177400   0b1111111100000000
0x0F0F   0x0F0F   3855      0o007417   0b0000111100001111

How BigInt precision changes the arithmetic ceiling

The arithmetic side has a trap the four-base view makes obvious. JavaScript's regular Number type goes wrong above 2^53 because it stores everything as a 64-bit float with a 52-bit mantissa. So 0x1FFFFFFFFFFFFF + 0x1 in a naive calculator returns 0x20000000000000 and quietly drops the low bit if you push one more digit. Oktal uses BigInt end to end in the parser, the multiplier, and the renderer, so a 24-character hex value still adds and multiplies losslessly. We picked BigInt over a fixed 64-bit type because the embedded work that motivated the tool involves 128-bit UUIDs, address arithmetic on 64-bit systems with sign extension, and the odd cryptographic nonce. None of those fit in a double.

So arithmetic has no ceiling. Bitwise NOT does. NOT on a BigInt produces a negative number with infinitely-many leading ones in two's complement, which is mathematically correct and useless on a microcontroller. We mask the NOT output to the bit width of the input value, rounded up to the nearest byte. NOT 0x00FF returns 0xFF00 in 16 bits, not -0x100. It's the one place Oktal trades strict math for what an embedded reader actually wants.

Shift arithmetic versus logical shift: what SHL and SHR do to high-bit hex values

Shifts are logical, not arithmetic. 0xFFFF SHL 4 returns 0xFFFF0 and not 0xFFFFF because the low bit is filled with zero, not a sign bit. 0x8000 SHR 1 returns 0x4000 and not 0xC000, because we shift in a zero on the left.

0xFFFF SHL 4  →  0xFFFF0   (low nibble filled with 0, not sign)
0x8000 SHR 1  →  0x4000    (zero shifted in from left, not 1)

The Shift Amount input is decimal, capped at 64. We've lost too many minutes to typos where a hex 1A in a shift field silently became 26 places of shift.

Can I shift by more than the value's bit width?

Yes. Oktal doesn't truncate. 0x1 SHL 80 returns 0x100000000000000000000 and the binary view shows you exactly that, which is what you want when building a wide mask for a 128-bit register.

Reading octal output: where the leading zero matters in C and Python literals

Octal is the base everyone forgets about until they hit a chmod 0755 or a Python 2 file mode. Oktal renders octal without a prefix in the result grid. If you copy a value out as a literal, prepend 0o in Python 3 and most modern shells, and a bare leading zero in C. The bare leading zero is the trap: int x = 010 is 8, not 10. The JSON spec forbids leading zeros in numeric literals for exactly this reason. The four-base panel keeps the decimal next to the octal so you can sanity-check before you paste.

One note on inputs. The parser accepts 0xFF, 0XFF, #FF, and bare FF. It rejects mixed case at the digit level only when it would be ambiguous, which in practice means never. The display uppercase toggle defaults on because uppercase hex is what every datasheet on this side of 1990 prints.

Frequently Asked Questions