Pascal.CodeCompared.To/Assembly

WriteLn is the whole difference: it knows the argument is a string, finds its length, writes it, appends the newline, and flushes through a buffered text file variable. The assembly version spells the newline as the byte 10 and the length as a number computed by the assembler. Note also that Pascal's end. returns to a runtime that then exits; here nothing runs after _start unless you write it.

There is no way to fall off the end of an assembly program safely: without that final syscall the processor keeps executing whatever bytes follow in .text and the process dies on an illegal instruction. Pascal's end. is a return into runtime code that calls exit for you, which is why forgetting Halt is harmless and forgetting the syscall is not.

Sixteen instructions and one division per digit. WriteLn(value) dispatches on the argument's type at compile time, picks the integer-writing routine out of the runtime, and that routine performs this same loop — written once by the FPC authors and shared by every Pascal program. Notice also that nothing here reports failure: a buffer too small would simply write past it.

The instructions are identical; only the operand names differ. Writing mov eax, first works because the compiler substitutes the variable's actual location — a register or a stack slot — which is exactly the bookkeeping the right-hand column does in your head. And the reason this column cannot run on an Apple Silicon machine is the sharpest possible statement of what an asm block costs: it is the one Pascal construct that is not portable at all, because it names a specific processor's instructions. The rest of the program would have compiled anywhere.

Pascal's insistence on a declaration block ahead of the code is often called ceremony, and this is the argument for it: the compiler needs to know every variable's type and size before it can assign storage, and having them in one place is how it does the job the right-hand column does by hand. Run out of registers and you must choose, yourself, which value gets pushed to memory.

A truncating cast is free for the same reason in both columns: the bits were already there and the narrower name simply stops looking at the rest. The direction that costs an instruction is widening a signed value, where the sign bit has to be smeared across the new high bits — that is movsx, and it exists because reading al into rax would otherwise leave the top 56 bits stale.

Writing 17 div 5 and 17 mod 5 as separate expressions asks for the same division twice unless the compiler notices they are identical — which FPC does. The instruction was always going to produce both halves; Pascal simply has no syntax for asking for them together, so the optimizer has to infer it.

Pascal's if smaller < larger compiles to a compare and a jump reading exactly this flag. The flag itself is invisible, unnamed, and overwritten by the very next arithmetic instruction, which is why the jump must come immediately after the sub — inserting an unrelated add between them silently breaks the test with nothing to warn you.

The condition is inverted, which is the commonest confusion when reading compiler output: the source says "if this is true, do the block" and the machine says "if this is false, skip the block". Note too that the two arms had to be arranged so control rejoins at print — Pascal's if/else has one exit, and here you build that out of a jump.

The rule that you may not assign to a Pascal for variable inside the loop exists so the compiler is free to keep it in a register and to strength-reduce the loop — the guarantee is what buys the optimization. The choice of rbx over rcx here is the same kind of decision, made by hand: a counter in rcx would be destroyed by the syscall in the middle of the body.

A parameter list is a promise about registers that nothing enforces down here — calling combine having set only rdi is not an error, and the function reads whatever rsi and rdx happened to hold. Note also the old Pascal convention on display: assigning to the function's own name is how you set the result, which is why Combine := … is an assignment rather than a return.

Pascal's var block inside a procedure is precisely this sub rsp, 24: the compiler adds up the declared sizes and reserves that many bytes in one instruction. Note that mov rsp, rbp erases nothing — it moves a number, and the locals sit in memory until the next call overwrites them, which is why a pointer to a dead local gives plausible garbage rather than an immediate crash.

Removing the word var from the Pascal signature changes lea rdi, [total] into mov rdi, [total] — the address becomes the value — and the caller's variable stops changing. That one-instruction difference is the entire semantics of var, and it is also why a var parameter cannot accept a literal: there is no address to take.

The hidden argument is why a nested procedure cannot be called from outside its parent — there would be no frame to link to — and why taking a procedure variable pointing at a nested procedure is restricted. Nesting is genuinely useful and genuinely not free: every call to Inner carries one more register than its written parameter list suggests.

This layout is Pascal's oldest and best-known design decision, and it is the direct opposite of C's: a stored count rather than a terminator. The cost is the 255-byte ceiling and a fixed 256-byte footprint; the benefits are that length is free, a string may contain any byte including zero, and no operation can run off the end looking for something that is not there. Modern AnsiString keeps the stored length and moves it to a header before the characters, which is why the character pointer still looks like a C string.

The dec rcx is free in practice — the compiler folds the subtraction into the addressing mode's displacement, so array[1..3] and array[0..2] generate identical code. That is the answer to the old complaint that 1-based indexing must be slower: the lower bound is a compile-time constant, and constants cost nothing. What it does buy is that the declared range is checkable, which {$rangechecks on} turns into a real test.

Field access is free — it is part of the addressing mode, not an extra instruction. What is not free is assuming you know the offsets: Free Pascal inserts padding so each field lands on its natural alignment, and packed record is the directive that suppresses it. Writing the 8 by hand, as the right-hand column does, is only correct because both fields happen to be eight bytes wide.

Pascal puts the dereference after the name, which reads more naturally in a chain — node^.next^.value goes left to right — while C's prefix * needs parentheses for the same idea. Down here neither notation exists: a bare label is a number and brackets are a memory access, and forgetting the brackets gives you an address where you wanted a value, with no type to object.

The %1010 notation is Pascal's binary literal and 0b1010 is NASM's — the same bits with different spelling. Note that Pascal uses the same words for boolean and bitwise operations and decides which you meant from the operand types, which is why and on two integers is this instruction while and on two booleans is a branch.

One instruction, jae, does the work of both halves of Pascal's (index < 1) or (index > 3): after subtracting the lower bound, an index below the range wraps to an enormous unsigned value and fails the same upper test. That trick is exactly what {$rangechecks on} emits, which is why range checking costs two instructions rather than four.

Reading rcx after the syscall would print whatever the kernel left behind — no crash, no complaint, just a wrong answer that changes with the kernel version. This is the concrete hazard behind the earlier asm ... end; row: an inline block that clobbers a callee-saved register without restoring it corrupts the function around it, and the compiler will not notice.