In my childhood I used to program on an MK-61 Soviet calculator. It had four operating registers (X, Y, Z, T) and 15 storage registers. A program could have 105 steps.

As I recall it, it had commands like:

  • Swap X and Y registers
  • Shift registers (Z to T, Y to Z, X to Y)
  • Copy from storage register (1..15) to X
  • Copy from X to storage register (1..15)
  • If X < 0 then go to program step ##
  • Perform operation (+, -, *, /) using X and Y values and put result to X

Is this command set an assembly language? Did I have a basic idea of assembly languages by using this device?


It turns out it is something called "keystroke programming".

Funny fact: a similar calculator (like this one, but with energy independent memory) was used as a back-up hardware for space mission trajectory calculations in 1988. :-)

  • Nice! - that picture brings back memories. I still got my MK-52 in the basement somewhere :)
    – DXM
    Dec 13, 2013 at 21:40
  • This looks like a Soviet clone of the HP 65. It may be programmed in Reverse Polish Notation with operations that push and pull on a stack. The RPN operators are simply recorded in memory, and interpreted by a what is probably equivalent to a 4004 CPU. The code in the 4004 ROM was probably compiled from 4004 assembler, but the keystrokes are really more like spreadsheet macros. Dec 14, 2013 at 5:38

7 Answers 7


This is not an assembly language, this is a machine language.

Machine language is anything that physically means something to the machine. In the case of pocket computers, it's key presses, encoded into numbers in the machine. You don't give more information about this Electronika MK61 machine, so I'll give the example of the TI-57: the machine language used the number of the key given as column in the tens and line in the units. So for example, a program that would increment the memory 8 would be:

33 8  57 1 58 23

This is machine language: it's what's directly interpreted by the machine.

Assembly language would be the human readable text:

RCL 8 

To transform this text into the sequence of machine codes, you would need an assembler, which may be a program, or a human who would translate that text into the sequence of numbers.

The confusion is often done, because there's often a quite direct translation from the assembly language to the machine language, but this is not always an entirely direct translation: macro assemblers have powerful macros that may do a lot of work in the assembler and generate a lot of machine language instructions from a single assembly instruction. The mere translation of symbolic addresses may involve changing the op-code of the branch instructions (for example, when switching from short relative addressing to long relative or absolute addressing), so it's not always as direct as you'd think.


I would say that the answer to both parts of your question is no: this calculator's commands aren't like assembly language, and programming this calculator is different from programming in assembly language.

The "language" this calculator is programmed in is fairly low level, but it still represents an abstraction on top of lower-level constructs that aren't visible to you as the programmer. I'm guessing a bit, but from your description, and from looking at the keyboard (and comparing it to similar-looking calculators from Hewlett Packard or Texas Instruments from the late 1970s and early 1980s) I'd say that each program "step" not only could be a simple operation like "add" or "swap X & Y" but also more complex operations like trigonometry, exponentiation, logarithms, etc. Each of these steps is probably implemented as a internal microcoded routine. That microcode probably is programmed in assembly language, but I don't think it's visible to ordinary calculator programming at the level you've described.

As others have described, assembly language usually is in very close (if not 1:1) correspondence with the facilities of the underlying machine. I'd say that assembly language programming includes the following characteristics that are probably not present in programming this calculator.

  • Operations include lower level level operations such as bitwise AND, OR, XOR, shifting; integer and (maybe) floating point arithmetic, on a variety of data sizes (e.g. single or double precision); load/store of a variety of sizes (byte, halfword, word, etc.).

  • Higher level operations (trig, logarithms) are usually subroutine calls, not instructions. There are some exceptions, such as the DEC VAX which had a polynomial-evaluation instruction. [Edit: OP pointed out that x87 also has trig functions.]

  • The addressing scheme of the machine is exposed. If the address space is segmented, you have to load a base address into a register and then address code or data relative to that register. Even with a flat address space, you're aware of addresses and address arithmetic. Usually assemblers will allow programmers to use labels to denote addresses. But if an address is in a different segment you may have to load a segment register before you can get to it.

  • Memory alignment is exposed. For example, on many machines a 4-byte word can only be loaded from or stored to addresses that are multiples of 4 bytes.

  • Data representation is exposed. Usually assemblers provide some way to specify numeric data in hex, octal, decimal, floating point, and occasionally character data.

  • Specialization of registers is exposed. Some architectures allow integer and address operations in some registers, but floating point only in others, or allow addressing only relative to certain registers. Sometimes there are specialized registers such as those with condition or status bits that cannot be used for addressing or arithmetic.

  • Subroutine calling conventions are exposed. Arguments and return values may be passed in registers, or pushed to and popped from a stack. (This stack is usually a region of memory addressed by a special stack pointer register, not a fixed set like X Y Z and T.)

  • You may need to be conscious of how to interact with the OS, or if there isn't one, how to deal with low-level hardware facilities. With an OS you have to load arguments into registers (or the stack) and trap into the kernel. Without an OS you probably have to deal with interrupts and timers.

My recollection of assembly programming is that it is very, very painful. I think that programming this calculator is easy and fun by comparison. (Sorry.)

  • 1
    1) Well, it has some bitwise operation AND, OR, XOR, NOT - blue symbols , , and ИНВ (which means INV) on keyboard. 2) I thought that sine, cosine etc. are instructions according to this reference ref.x86asm.net/coder32.html for x86 processors. But of course I do agree with you that assembler is a lot more complicated.
    – defhlt
    Jul 13, 2012 at 6:01
  • If you want the refrence for that VMS instruction set operation - deathrow.vistech.net/… . Some other fun bits can be found in esolangs.org/wiki/…
    – user40980
    Jul 13, 2012 at 16:04

Yes, that definitely sounds like an assembly language to me.

It's hard to say whether or not that actually is assembly just from the description, because the definition--a language whose commands map 1:1 with its target platform's machine code--is hard to determine without a knowledge of the machine code itself, but that does sound like the way ASM works on other platforms.


It certainly has some close similarities to an assembly language, but I'm going to argue that that's not what it really is.

In an assembly language, the operations mostly map 1-to-1 to CPU instructions. There are some exceptions, such as macros and pseudo-ops (like, say, a CLEAR instruction that really XORs a register with itself); the real point is that an assembly program exactly determines the CPU instructions to be generated. (That's the fundamental difference between an assembly language and a higher-level language like C; in the latter, programs specify behavior).

The calculator undoubtedly has a CPU in it, but I doubt that individual CPU instructions refer to the X, Y, Z, and T "registers", or perform high-level operations like xy or sin (or ПРГ, whatever that means!).

Instead, I'm sure that many or most of the visible operations are done as subroutine calls. And for each operation executed, there must be a significant amount of extra work done to display the result.

You can think of the visible operations as an assembly language for a high-level virtual machine, but that virtual machine is implemented via something like an interpreter running on the real CPU.

Still, I'd say that the answer to the second part of your question:

Did I have a basic idea of assembly languages using this device?

is yes.

  • 1
    Our boxes don't have AX, BX, CX & DX, either--assembly languages are permitted symbolic translation. I do agree that the high level functions most certainly aren't assembly but note that what he listed didn't include them. While I think it's unlikely it really was an assembly language (everything would have to be of fixed length for the addressing mode to work) none of the commands listed are beyond what assembler on a PC has. Jul 13, 2012 at 1:46
  • 2
    "if X < 0 then go to program step ##" is a simple BMI (branch if minus) assembly instruction.
    – mouviciel
    Jul 13, 2012 at 7:36
  • 1
    @mouviciel And even if the platform doesn't directly support something like the BMI example, IF ... THEN ... are generally read as two instructions: first a comparison (x < 0 in this case), then an action based on the result of that comparison (most likely a jump when working in assembly language). In Intel 8086, something like (assuming x is in AX) CMP AX, 0 JNL After_IfThen_Block. (JNL being Jump if Not Less; in a higher-level language, this would read as something like if not (x < 0) then goto After_IfThen_Block, which is the same as if (x >= 0) then {code until there}.)
    – user
    Jul 13, 2012 at 8:43
  • 1
    ПРГ (PRG - programming) is just a meta key to switch to programming mode, not some function. Jul 13, 2012 at 12:27
  • 1
    @mouviciel: I'm skeptical that "if X < 0 then go to program step ##" is actually implemented as a single hardware CPU instruction. I speculate that a program entered on the calculator is not stored as a sequence of CPU instructions; rather, it's stored as a sequence of higher-level instructions that are interpreted by a firmware program. I've never worked with this particular calculator, but I have used the HP-48; the user-visible instruction set is very different from that of the Saturn CPU that it uses. Jul 13, 2012 at 18:06

That is right, posted code fragment does look like assembly language. The proper conversion of this code would define the version.

Edit: it has some specific language for this device, but it is not assembly.

It is also look like a USSR made calculator. Does it run on rounded batteries/cord?

  • 3
    Correct, it was produced in soviet Ukraine from mid-80s. I have one made in 1991. It has both slots for 3 AA batteries and for 220v adapter.
    – defhlt
    Jul 12, 2012 at 23:08
  • 1
    This is really a nostalgic for me. I do remember this brand name "Elektronika" :)
    – Yusubov
    Jul 12, 2012 at 23:11

I would argue you're closer to a BASIC assembly language hybrid but it really depends on the underlying CPU and architecture. There doesn't need to be direct memory access if you have no true RAM to speak of. Floating point operations also not need be present without a FPU.

I think a simple test would be an addition operation on a floating point number and an integer. Most higher level programming languages would accept ADD 2.5, 7 and return 9.5. Assembly languages however would differ the output based upon the called instruction and depending on the underlying number representation in binary. Most assembly languages require a different instruction to be used based on using floating point vs integer operations. An exception to this might be some kind of fixed point format.

  • It could simply treat all numbers as floats and consider one of arguments 7.0. Jul 13, 2012 at 12:26
  • @OlegV.Volkov maybe, however then you only need pick two floating point numbers whose sum has no true representation. Also you could hunt for cancellation errors in subtraction. Jul 13, 2012 at 13:35

Reverse Polish notation (RPN) calculators were classic. No, although the register designations seem like assembly language it was not. Calculations were performed by translating from algebraic format onto the stack. The numbers used were pushed into the stack and operations were performed on last stacked against next to last stacked values.

You could "rotate" the stack to move the values since the displayed value was a stack member. The results could be swapped or stacked as necessary to perform nearly complex calculation. If you do understand stack hardware and assembly language this calculator was trivial to learn since its paradigm was most similar.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.