Norsk Data Assembler

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Norsk Data Assembler" – news · newspapers · books · scholar · JSTOR (December 2025) (Learn how and when to remove this message)

The assembler had several snags which today would be considered exotic or strange.

Like many assemblers MAC placed a limit on the length of variable names, however, rather than simply disallowing names greater than the maximum length it only kept the last five letters of an identifier, ignoring the first part of the name. The reason for keeping the last 5 was so that variables such as MY_ARRAY1 and MY_ARRAY2 would be distinguishable. The result was that the internal storage of some names was very strange and some times hard to understand as the names would be identical to names such as RRAY1 and RRAY2 respectively. This behavior caused some programmers to adopt the practice of writing only the last five letters of a name in their program code as the assembler would ignore the rest anyway. Because of the difficulty faced by a human reader in understanding what was meant by the name, the code became much more difficult to understand. This resulted in less code reuse on the system.

Another peculiarity was that the assembler worked by adding together the "values" of all the symbols in an instruction to form the actual machine code. For example to copy the contents of the X register to the A register you would write:

COPY SX DA

Internally the assembler had a numerical value for "COPY", another value for "SX", and a third value for "DA". Adding them together yielded the actual machine instruction.^[3] However, if the programmer made a mistake and typed in (notice that both registers are "source" registers):

COPY SX SA

the machine would not do what was really intended by the programmer, nor would it throw an error. Instead the assembler would accept the program but it would not be translated into a COPY instruction. The SX + SA part would most likely result in either the value of some third register or would overflow so that the operation part of the instruction was modified changing it from copy to some other unintended operation.

Another issue for assembler programmers in general is the list of so-called monitor (MON) calls. The MON instruction is equivalent to the INT instruction found in Intel CPUs. However, while they originally had a nice set of functions to write to a file, read from a file, etc.; it quickly devolved into an ad hoc set of functions. An example being a function originally designed to output 8 bytes stored in 4 of the registers (A, D, T and X). Soon someone, having the bytes in some other registers, made a new function to output from those registers. This left the programmer with a veritable forest of output functions all doing almost the same thing. In the latter days of SINTRAN the problem then was to find available codes for these system calls as all 256 of them had already been taken by several such near identical functions. Thus, the extended multi-function monitor calls entered the scene where one monitor call could do a number of functions with a function code specified in a register designating which of its subroutines would be executed.