47

I can only quote from the manual of a rather primitive CPU, a 68020 processor from around 1986: "Calculating the exact runtime of a sequence of instructions is difficult, even if you have precise knowledge of the processor implementation". Which we don't have. And compared to a modern processor, that CPU was primitive. I can't predict the runtime of that ...


33

The "assembly writer" in that book is a human software developer who writes code in assembler language.


30

You cannot do this in general, but in some senses, you very much can, and there have been a few historical cases in which you indeed had to. The Atari 2600 (or Atari Video Computer System) was one of the earliest home video game systems and was first released in 1978. Unlike later systems of the era, Atari could not afford to give the device a frame buffer, ...


21

Other reason for compilers to produce assembly rather than proper machine code are: The symbolic addresses used by assemblers instead of hard-coding machine addresses make code relocation much easier. Linking code may involve safety checks such as type-checking, and that's easier to do with symbolic names. Small changes in machine code are easier to ...


16

A compiler does usually convert high-level code directly to machine language, but it can be built in a modular way so that one back-end emits machine code and the other assembly code (like GCC). The code generation phase produces "code" which is some internal representation of machine code, which then has to be converted to a usable format like machine ...


15

There are two aspects at play here As @gnasher729 points out, if we know the exact instructions to execute, it's still difficult to estimate the exact runtime because of things like caching, branch prediction, scaling, etc. However, the situation is even worse. Given a chunk of assembly, it's impossible to know which instructions will run, or even to know ...


11

Historically a number of notable compilers did output machine code directly. There are some difficulties with doing so, however. Generally someone who's trying to confirm that a compiler is working correctly will find it easier to examine assembly-code output than machine code. Further, it's possible (and was historically common) to use a one-pass C or ...


10

In VLIW architecture, the compiler/and or assembly writer chooses instructions that can be executed in parallel The meaning of this sentence is that in VLIW architecture, assembler (machine) code defines which instruction will be executed in parallel, so it's fixed at the time assembly code is written by a human or generated by a compiler. This differs ...


10

The two most obvious characteristics of an assembly language are: It is specific to a particular CPU architecture. There is a one-to-one correspondence between assembly language commands and machine code instructions (once you strip out labels, assembler directives and code comments). By contrast, a high-level language will have the following ...


5

The essential difference between assembly language and every other programming language is that assembly language specifies the sequence of instructions directly, whereas in any other language, the code has to be converted into a sequence of instructions, a process known as compilation or code generation. As a consequence, assembly language is architecture-...


5

Assembler code describes instructions for one particular architecture. It is slightly helpful by allowing you to use human-readable names for instructions, names for memory addresses, doing some simple calculations etc. but it is totally useless to produce instructions for any other processor. With heroic effort you could create a translator that produces ...


4

(Warning, this historical account of increasing abstraction and declarative programming may annoy, confuse, or upset you:) Hello, world! By far and large, programing languages happen on a continuum, with "pure" instances of languages being ideals. This is because there are a variety of platforms, architectures, and goals when writing software. Of course, ...


4

I've seen compilers that compile directly to object code. I've seen compilers that compile to assembler code. I've seen compilers that compile to byte code for a virtual machine. I've seen compilers that compile to bit code which is intended to be further compiled to code for slightly different processors. I've seen compilers that compile to a ...


3

Assembly language is normally untyped, in the sense that there is no type-checking. Adding type-checking is a non-trivial research challenge (hence the papers you see). Papers on typed assembly language should explain the motivation. One application is that they can be used to support proof-carrying code, which can be used to securely execute untrusted ...


3

Can we say that assembly is generally untyped? If you mean "assembly" as, e.g. x86 assembly language, then I think yes, to some degree. Types are some constraints that we can statically checked/proved, then there is so little (but not nothing) we can do given an x86 assembly program, e.g. add rcx, [@addr] jmp rcx so it's possible to infer that [@addr] is ...


2

Usually compilers work internally with sequences of instructions. Each instruction will be represented by a data structure representing it's operation name, operands and so-on. When the operands are addresses those addresses will usually be symbolic references, not concrete values. Outputting assembler is relatively simple. It's pretty much a matter of ...


2

Even platforms that use the same instruction set may have different relocatable object file formats. I can think of "a.out" (early UNIX), OMF, MZ (MS-DOS EXE), NE (16-bit Windows), COFF (UNIX System V), Mach-O (OS X and iOS), and ELF (Linux and others), as well as variants of those, such as XCOFF (AIX), ECOFF (SGI), and COFF-based Portable Executable (PE) on ...


2

There are dozens and dozens of stack machines out there in the wild, and they all have different instruction sets. So there's no single correct answer. Some people might consider using CALL like that cheating: after all, it relies on things like ADD and CMP and JMP and DUP and such all being implemented in the machine, so why don't you call them ...


2

Back in the era of 8-bit computers, some games did something like that. Programmers would use the exact amount of time it took to execute instructions, based on the amount of time they took and the known clock speed of the CPU, to synchronize with the exact timings of the video and audio hardware. Back in those days, the display was a cathode-ray-tube ...


2

That translation isn’t done by the CPU when it executed the instructions. It is done a lot earlier, when a program called “assembler” translates the assembler instructions into sequences of bits that the CPU can execute. You say “it’s stored in binary”. Yes, it is translated from assembler to binary, and the binary code is stored.


2

An assembler is a program that reads assembly language commands and translates then into a sequence of binary instructions, addresses and data values that is called machine code. The machine code is stored in the computer's memory and can be executed by the computer at some later time. Machine code is read and "understood" directly by the CPU. So a command ...


2

Would the choice of "computer system" happen to include microcontrollers? Some microcontrollers have very predictable execution times, for example the 8 bit PIC series have four clock cycles per instruction unless the instruction branches to a different address, reads from flash or is a special two-word instruction. Interrupts will obvously disrupt this ...


2

It makes sense to pay attention to formal grammars when talking about programming languages. Typical program in assembly language has very simple grammar, consisting mainly of following productions (I'm assuming maximum two operands here): Program = Instruction | Program Instruction Instruction = [Label ":"] Operation Operand [Operand] The grammar for ...


2

In an assembly language, you specify the sequence of instructions of your code. In other languages that are compiled, you specify the effect of these instructions, not the instructions themselves. The compiler is free to use any instructions that seem useful, as long as they lead to the desired effect.


2

Many assembly languages do have certain features that could be considered static typing. Most often this is for making programming easier, rather than type checking. In many assembly languages you can define the equivalent of C's structs and unions. Many assembly languages also allow the usage of arrays, where the type (in the sense of byte-count) of the ...


2

The CPU has direct access to registers. If A and B are already in the registers then the CPU can perform the addition directly (via the Arithmetic Logic Unit) and store the output in one of the registers. No access to memory is needed. However, you may want to move your data A and B from memory or the stack into the registers and vice-versa. These are ...


1

You can think of a bitvector as a set, by giving names to the various bits. For example, if we name the bits in an 8-bit integer using the numbers $0,\ldots,7$ (where $0$ is the LSB and $7$ is the MSB), then $00010010$ is the same as $\{1,4\}$. Your first function asks whether the set has size $1$. If we name the bits using numbers as above, the second ...


1

OP suggested me to this here as an answer. If you are writing assembly code, you need to know what CPU it is for and its characteristics※. That is, you need to be aware of hardware details. Your could write code that works on many similar CPUs… Yet, in general, it is not portable code. That kind of code is low level code. ※: Such as available instructions, ...


1

In essence I would say that assembly languages are a set of instructions that are translated into opcodes; while any higher language is transformed (i.e. compiled) into a set of assembly instructions which in turn are translated.


1

There are at least three different models for translating portable source code written in a high level language into machine code instructions that can be run on a particular type of computer and operating system(the "target platform"). Confusingly, the terms "compiler" and "compilation" are used in all of these models. The output of the compiler can be a ...


Only top voted, non community-wiki answers of a minimum length are eligible