Machine language is the only language that a CPU understands true or false

This was last updated in February 2018

Continue Reading About machine code (machine language)

• Atari Archives explains machine language in more detail.

• Bright Hub compares machine code and high-level languages.

Related Terms

Telling a computer what to do

Imagine trying to instruct a visitor from another planet on how to boil an egg. To begin, a common language has to be learned. But even after that is accomplished, the visitor has to be given explicit, step-by-step directions, since he does not know an egg from an orange. For example: 1. Walk to the cupboard. 2. Open the doors. 3. Take out the big pot. 4. Go to the sink. 5. Turn on the cold water tap. 6. Fill the pot half-full of water. And so on. If he misses just one of the dozens of steps, the visitor will be confused and unable to complete his task.

That scenario is not unlike what a programmer goes through in writing the software, a set of instructions to perform a job on a computer. Writing a computer program is a most rigorous and exacting job that requires the utmost attention to detail. Even a misplaced comma can cause the computer to forget what it is doing and begin turning out garbage.

With the most basic computer languages—such as Assembler—programmers have to write one line of instruction, or computer code, for each tiny chore that the computer is to execute. The so-called higher-level languages such as Fortran and Cobol incorporate instruction subsets in the language so that one line of code can contain about six instructions. Even easier to write—because the language itself is more complex—are the software programs in the new query languages that understand English-like commands. Unlike Cobol or Fortran. however, which can be used to program the computer to do a wide variety of functions, query languages will instruct the computer only in how to file or retrieve information.

Shown below are portions of three programs—one in Assembler, one in Cobol, and one in a query language. Each is designed to generate the same report showing the account balances for a list of customers. But to do the job, the Assembler program takes more than 3,000 lines. The Cobol program runs more than 600 lines. But the one sentence in query language is all that is needed.

Assembler215LAR2, @ IDTWO(, R9)216LAR1, @ PTENDL+ @ PTNEXT(, R1)217BPTM1

COBOL330820IF PRIORBALNOT NUMERIC MOVE ‘Y’ TO VES-NON MOVE330822“PRIORBAL“TO MVLAB PERFORM NONNUM-1 THRU NONNUM-1 -EX330824MOVEZEROES TO PRIORBAL.

Query languageI WANT A REPORT FOR BUSINESS TYPE 17 IN ORDER BY BRANCH, SHOWING ACCOUNT NUMBER, NAME, AND BOTH CURRENT AND PRIOR BALANCES.

Assembly Language

Today programmers rarely write programs in machine language. Instead, they use the clearer assembly languages or high-level languages. These languages are partly responsible for the current widespread use of computers.

Programmers, burdened by machine language programming, began using English-like abbreviations for the various machine language instructions. Called mnemonics (memory aids), these abbreviations related to the action to be taken and made more sense to the programmer. For example, instead of writing “+ 20” to represent addition, a programmer might write the mnemonic “ADD”; “SUB” might be used for subtraction, “DIV” for division, and the like. Even the storage locations were given names. If location 92 contained a total, it might be referred to as “TOTAL” or “SUM” instead of 92. The resulting programs were much easier to understand and modify. For example, in a payroll program that subtracts total deductions from gross pay to calculate net pay, the following assembly language instructions might appear:

LOADGROSSPAYSUBDEDUCTSSTORENETPAY

Unfortunately, computers could not understand these programs, so the mnemonics still had to be translated into machine language for processing. An aristocracy arose in the programming profession. The “upper class” consisted of programmers who wrote programs using the English-like mnemonics. The “commoners,” called assemblers, then took these programs and manually translated them into machine language, a rather mechanical job. In the 1950s, programmers realized that this translation could be performed more quickly and accurately by computers than by people, and so the first assembler program, or translator program, was written (Figure 9-1). The program of instructions written in assembly language is known as the source program; an assembler program translates it into a machine language program, called an object program.

Programs could be written faster with assembly language than with machine language, although they still had to be translated into machine language before they could be executed (see Figure 9-2). The work involved in translation was more than justified by the resulting increased programming speed and fewer errors.

Assembly language programs are also machine dependent and not portable. Programmers must write large numbers of instructions to accomplish even simple chores, and the programs still appear to be in computerese (Figure 9-3).

Perhaps the major use of assembly languages today is in the writing of operating systems—the programs that control the hardware and make it more accessible to computer users (see Chapter 12).

High-Level Languages

Assembly language programming with macro instructions represented a big leap forward, allowing programs to be written faster and with fewer bugs than before. These programs were easier to understand and modify, but they still consisted mostly of individual assembly language instructions and had the appearance of computerese.

This led to the development of high-level languages in which programmers code programs that look almost like everyday English and use familiar mathematical notations. The assembly language instructions in the previous example can be written in high-level language as a single statement:

COMPUTE NETPAY=GROSSPAY−DEDUCTIONS.

Compared to machine and assembly languages, high-level languages are easier to learn and use. High-level language programs can be produced more quickly, are easier to debug, and are easier to maintain. This makes them popular with both beginning programmers and with experienced users who want to get their programs written and debugged as quickly as possible.

High-level language programs must also be translated to machine language before they can be executed. The translator programs that do this are called compilers (Figure 9-4). Compilers for a particular high-level language can be produced for various computers with different machine languages. This makes high-level language programs portable (Figure 9-5).

An alternative to a compiler is an interpreter, a translator program that actually runs a source program directly. An interpreter does not produce a machine language object program. Thus, every time a given statement is executed, the interpreter has to determine exactly what that statement means. This task is very much like compiling, but it is performed only for those statements that are actually executed on a given run of the program.

Interpreters are especially useful in program development. Each time a new bug is found, the programmer can correct it, try the program again, and almost immediately expose the next bug. There are no long delays for recompiling programs.

Once a program is functioning properly, it may be best to compile it into machine language and save the machine language version for future use. When that program is executed, the machine language version will run much faster than the interpreted program. As faster processors become more economical, interpreters will become more widely used.

Disassemblers

A disassembler is a program that reads a machine language program and attempts to reconstruct the assembly language source code that produced it. This task is especially difficult because there is no explicit difference between code and data in a binary program file: They are all just plain bytes.

Sophisticated disassemblers, such as V Communications' Sourcer, perform a complex analysis and simulation of the program to separate code and data. Using a disassembler is very useful in understanding how other programs operate, to learn skills and techniques to increase your knowledge, and to duplicate what a program does.

Disassembly is quite legal, but what you do with the resultant code can run afoul of copyright laws. In general, use of code from a product you own is acceptable for your own personal use or to gather understanding of program operation. You will violate a copyright if you include code from another copyrighted program and distribute the code in any form to others for money or for free. If you have any doubts, contact a lawyer versed in the current copyright laws.

22.2.3 Verifying the Behavioral Model

Now that we have developed our behavioral Gumnut model, we can verify it by writing a test bench model. Since the function performed by the processor is to execute a machine language program stored in memory, we can test the processor by loading the instruction memory with a test program and observing the values in registers and the I/O operations on the external interface. We will use an assembler called gasm (provided on the companion website for this book) to generate the machine language program from assembly language source code.

The entity declaration for the test bench model is:

entity test is

end test;

and the architecture body is:

library ieee;

use ieee.std_logic_1164.all, ieee.numeric_std.all;

use work.gumnut_defs.all;

use std.textio.all;

architecture gumnut of test is

  signal syscon_clk_o : std_ulogic;

  signal syscon_rst_o : std_ulogic;

  -- I/O port bus

  signal gumnut_port_cyc_o : std_ulogic;

  signal gumnut_port_stb_o : std_ulogic;

  signal gumnut_port_we_o : std_ulogic;

  signal gumnut_port_ack_i : std_ulogic;

  signal gumnut_port_adr_o : unsigned(7 downto 0);

  signal gumnut_port_dat_o : std_ulogic_vector(7 downto 0);

  signal gumnut_port_dat_i : std_ulogic_vector(7 downto 0);

  -- Interrupts

  signal gumnut_int_req : std_ulogic;

  signal gumnut_int_ack : std_ulogic;

  component gumnut_with_mem is

    port ( clk_i : in std_ulogic;

           rst_i : in std_ulogic;

           -- I/O port bus

           port_cyc_o : out std_ulogic;

           port_stb_o : out std_ulogic;

           port_we_o : out std_ulogic;

           port_ack_i : in std_ulogic;

           port_adr_o : out unsigned(7 downto 0);

           port_dat_o : out std_ulogic_vector(7 downto 0);

           port_dat_i : in std_ulogic_vector(7 downto 0);

           -- Interrupts

           int_req : in std_ulogic;

           int_ack : out std_ulogic );

  end component gumnut_with_mem;

begin

  reset_gen : syscon_rst_o <= ‘0’,

                    ‘1’ after   5 ns,

                    ‘0’ after  25 ns;

  clk_gen : process

  begin

    syscon_clk_o <= ‘0’;

    wait for 10 ns;

    loop

      syscon_clk_o <= ‘1’, ‘0’ after 5 ns;

      wait for 10 ns;

    end loop;

  end process clk_gen;

  int_gen : process

  begin

    gumnut_int_req <= ‘0’;

    for int_count in 1 to 10 loop

      for cycle_count in 1 to 25 loop

        wait until falling_edge(syscon_clk_o);

      end loop;

      gumnut_int_req <= ‘1’;

      wait until falling_edge(syscon_clk_o)

                 and gumnut_int_ack = ‘1’;

      gumnut_int_req <= ‘0’;

    end loop;

    wait;

  end process int_gen;

  io_control : process

    -- Hard-wired input stream

    constant input_data : unsigned_byte_array

      := ( X“00”, X“01”, X“02”, X“03”, X“04”, X“05”, X“06”, X“07”,

           X“08”, X“09”, X“0A”, X“0B”, X“0C”, X“0D”, X“0E”, X“0F”,

           X“10”, X“11”, X“12”, X“13”, X“14”, X“15”, X“16”, X“17”,

           X“18”, X“19”, X“1A”, X“1B”, X“1C”, X“1D”, X“1E”, X“1F” );

    variable next_input : integer := 0;

    variable debug_line : line;

    constant show_actions : boolean := true;

  begin

    gumnut_port_ack_i <= ‘0’;

    loop

      wait until falling_edge(syscon_clk_o);

      if gumnut_port_cyc_o and gumnut_port_stb_o then

        if to_X01(gumnut_port_we_o) = ‘0’ then

          if show_actions then

            swrite(debug_line, “IO: port read; address = ”);

            hwrite(debug_line, gumnut_port_adr_o);

            swrite(debug_line, “, data = ”);

            hwrite(debug_line, input_data(next_input) );

            writeline(output, debug_line);

          end if;

          gumnut_port_dat_i <=

            std_ulogic_vector(input_data(next_input));

          next_input := (next_input + 1) mod input_data‘length;

          gumnut_port_ack_i <= ‘1’;

        else

          if show_actions then

            swrite(debug_line, “IO: port write; address = ”);

            hwrite(debug_line, gumnut_port_adr_o );

            swrite(debug_line, “, data = ”);

            hwrite(debug_line, gumnut_port_dat_o );

            writeline(output, debug_line);

          end if;

          gumnut_port_ack_i <= ‘1’;

        end if;

      else

        gumnut_port_ack_i <= ‘0’;

      end if;

    end loop;

  end process io_control;

  dut : component gumnut_with_mem

    port map ( clk_i      => syscon_clk_o,

               rst_i      => syscon_rst_o,

               port_cyc_o => gumnut_port_cyc_o,

               port_stb_o => gumnut_port_stb_o,

               port_we_o  => gumnut_port_we_o,

               port_ack_i => gumnut_port_ack_i,

               port_adr_o => gumnut_port_adr_o,

               port_dat_o => gumnut_port_dat_o,

               port_dat_i => gumnut_port_dat_i,

               int_req    => gumnut_int_req,

               int_ack    => gumnut_int_ack );

end architecture gumnut;

The architecture includes a component declaration corresponding to the subsystem containing the Gumnut core and its memories. This component is instantiated as the design under test (dut). The architecture also includes an assignment to the reset signal and a clock-generator process, corresponding to a Wishbone system controller (“syscon”). The int_gen process generates a sequence of 10 interrupt requests at intervals of 25 clock cycles. The io_control process represents an I/O port controller that monitors the external interface of the processor. When the processor performs a read operation, the controller supplies the next in a sequence of input data values and displays a debug message showing the port address and the data value. When the processor performs a write operation, the controller likewise displays a debug message showing the address and data value.

In the test bench, we do not include the debug generic constant in the component declaration for the Gumnut. Instead, we use a separate configuration declaration, shown below, to bind the Gumnut entity to the component instance and to fill in values for the generic constant. We set the debug generic constant of the processor to true so that we can trace its operation.

configuration test_gumnut_behavior of test is

  for gumnut

    for dut : gumnut_with_mem

      use entity work.gumnut_with_mem(struct);

      for struct

        for core : gumnut

          use entity work.gumnut(behavior)

            generic map ( debug => true );

        end for;

      end for;

    end for;

  end for;

end configuration test_gumnut_behavior;

In order to execute the test bench, we need to prepare a test program to run on the processor core. The following is a small test program, written in the gasm assembly language:

; Counts from 10 downto 1, storing successive values to memory.

        text

        org     0               ; reset

        jmp     begin

        org     1               ; interrupt service

        reti

        org     16

begin:  enai

        add     r1, r0, 10      ; initialize count to 10

loop:   stm     r1, 0

        sub     r1, r1, 1       ; decrement count

        bnz     loop

stop:   disi

        stby

        data

        org     0

count:  bss     1

We assemble this program to produce the initialization files for the instruction and data memories. (Instructions on using the gasm assembler are provided on the companion website.) We also analyze each of the design units described so far and then invoke our simulator, specifying the configuration declaration as the unit to simulate. We then use the facilities of the simulator to step through the model, to examine the test bench signals to verify that the machine language program in the memory is correctly executed by the CPU. We do not describe the process in detail, as different simulators provide different commands and facilities for executing the model. The companion website provides a number of small test programs, including the one shown above, that can be executed using this test bench. The following is an example of the debugging messages, produced when the program above was run on the author's simulator.

#    0: jmp  16

#   16: enai

#   17: add  R1, R0, 10

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

# Interrupt acknowledged at PC =   18

#    1: reti

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   18: stm  R1, 0

#   19: sub  R1, R1, 1

#   20: bnz  -3

#   21: disi

#   22: stby

2.2.10 Registers

The 8088/6 CPU has 14 internal registers. All the registers are 16 bits. Registers are used to hold data temporarily while the CPU performs arithmetic and logical operations.

The data registers may be divided into two 8-bit registers depending on whether the CPU is working with 8-bit, or 16-bit data. Within the 16-bit X registers, the 8-bit registers are AL, BL, CL and DL, and AH, BH, CH, and DH. Each half of the X registers may be separately addressed using L and H labels.

•

AX is the accumulator and is used as a temporary storage space for data involved in arithmetic and string (character) operations.

BX is the base register and is often used to hold the offset part of a segmented address during memory transfer operations.

CX is the count register and is used as a counter for loop operations.

DX is the data register and is a general purpose 16-bit storage location used in arithmetic and string operations.

CS is the code segment and contains the base address of the segment of memory that holds the machine language program that is being executed.

DS is the data segment and contains the base address of the segment of memory where current data (such as program variables) are stored.

SS is the stack segment and contains the base address of the stack segment which is used to hold return addresses and register contents during the execution of subroutines within the main program.

ES is the extra segment and contains the base address of the extra segment which is used to supplement the functions of the data segment.

IP is the instruction pointer (or program counter) which provides the offset address into the code segment (CS) for the address of the next instruction to be executed in a machine language program.

SP is the stack pointer and together with the base pointer (BP) provide the offset into the stack segment (SS). This is the current location of the top of the stack.

BP, the base pointer, is used in conjunction with the stack pointer to provide an offset into the stack segment.

SI and DI are index registers and are used (usually in conjunction with a data register) to provide an offset into the data segment for the processing of long string characters.

Flags are individual bits which are used to report the results of various comparisons and processes done by the CPU. Program statements may then branch depending on the status of these flags. Although the flags themselves are individual bits, they are arranged together in the form of a 16-bit register so that their contents may be easily saved and restored whenever necessary (e.g. while a subroutine is being executed).

Flags

Carry flagarithmetic carry outParity flageven number of 1sAuxiliary carry flagused for BCD arithmetic operationsZero flagzero result or equal comparisonSign flagnegative result or not equal comparisonTrap flaggenerates single-step operationInterrupt enable faginterrupts enabledDirection flagdecrement/increment index registersOverflow flagarithmetic overflow

FlagSetResetCFCarryCYNCPFParityPEPOAFAuxiliary ACNAZFZeroZRNZSFSignNGPLIFInterruptEIDIDFDirection DNUPOFOverflow OVNV

When the status of flags is reported in diagnostic programs, a special notation is used. After executing an instruction, flags are either set (logic 1) or reset (logic 0). Instructions with the CPU's instruction set use these flags to jump to another section of the current program.

Other instructions exist which allow a program to set or reset some of the flags. The flag register as a whole is usually pushed onto the stack when a subroutine executes and is then popped off the stack when the main program resumes.

The stack is a block of memory used for temporary storage. Saving data to the stack is called pushing and retrieving the data is called popping. Data pushed onto the stack can be popped off the stack on a last-in, first-out (LIFO) basis. The offset which represents the top of the stack is held in a register – called a stack pointer. The base address is the contents of the stack segment register. Thus, the segmented address of the top of the stack is given by SS:SP. The stack fills from high memory to low. The bottom of the stack is thus: SS:FFFF.

When a subroutine is called within a program, the contents of CS and IP are pushed onto the stack. After the subroutine has finished, CS:IP are popped off the stack and thus execution of the main program resumes at the statement following the call to the subroutine. The subroutine itself can also save the contents of other registers by pushing them onto the stack and then popping them back before handing control back to the main program.

When data is pushed or popped from the stack, the stack pointer (SP) decrements or increments either by 2 or 4 depending on whether a word or a double word is being pushed or popped.

Software

Computer software consists of the instructions and data that the computer hardware manipulates to perform useful work. A sequence of instructions for a computer is called a program. The data manipulated by a program is called a data base, a file, input, or simply data, depending on its nature and extent.

The most primitive instructions that can be given to a computer are those interpreted directly by hardware, in the machine language of the computer. Machine-language instructions are encoded as strings of bits in the computer memory, often one instruction per memory location. The processor fetches machine instructions from memory and executes them one by one.

Since it is difficult for humans to read and recognize strings of bits, machine-language programs are written in assembly language and translated into bit strings by an assembler. Assembly language represents machine instructions by mnemonic names and allows memory addresses and other constants to be represented by symbols rather than bit strings.

Most programs are written in high-level languages that allow common operations such as expression evaluation, repetition, assignment, and conditional action to be invoked in a single high-level statement. Popular high-level languages include BASIC, FORTRAN, and Pascal.

Few computers execute a high-level language directly. Therefore, a compiler is needed to translate a high-level-language program into a sequence of machine instructions that performs the desired task.

Assemblers and compilers are not the only software tools that a programmer may encounter. Other useful tools related to program development are interpreters, simulators, and on-line debuggers. Like a compiler, an interpreter processes a high-level-language program. Unlike a compiler, an interpreter actually executes the high-level-language program one statement at a time, rather than translating each statement into a sequence of machine instructions to be run later. Most BASIC environments use an interpreter.

A simulator is a program that simulates individual machine instructions, usually on a machine other than the one being simulated. A typical use of a simulator is to test programs to be run on a processor before the processor hardware is available. An on-line debugger executes a program on a machine one or a few instructions at a time, allowing the programmer to see the effects of small pieces of the program and thereby isolate programming errors (bugs).

Text editors are used to enter and edit text in a general-purpose computer, whether the text is a letter, a report, or a computer program. Text formatters read text with imbedded formatting commands and produce formatted documents such as this book. Text editors and formatters belong to the area of computing known as word processing.

In a medium to large computer system, cooperating programs run under the control of an operating system. An operating system schedules programs for execution, controls the use of I/O devices, and provides utility functions for all of the programs that run on the computer. Programs and text stored on disks and other mass-storage devices are managed by a file system, a collection of programs for reading, writing, and structuring such information in “files.” The operating systems in most computers include file systems. Even a very small computer with no mass-storage or file system has a simple operating system, at least to monitor inputs and accept commands from the outside world.

AUTOSAR

The remaining chapters of this book contain multiple examples of the application of MPU. Each electronically controlled subsystem or system in a contemporary vehicle has a module or control device that, for convenience, is euphemistically referred to as an electronic control unit (ECU). Each ECU has one or more MPUs that have a fundamental hardware structure that has been explained earlier in this chapter. Moreover, it has been emphasized that an MPU performs its intended operation within the ECU under control of a stored program. The stored program consists of sequences of instructions in a binary format that can perform the operation in the MPU. A program in a format capable of causing the MPU to perform the necessary operations is termed “executable code” or “machine language program.” This executable code is stored in ROM-type memory.

During the development of a vehicular ECU, there are multiple steps taken by the individual or team that is (are) responsible for designing the given ECU. This development team that is responsible for designing the hardware also generates the algorithms related to the operation of the ECU. The algorithms must be used to create the executable code that constitutes the controlling program. In the early days of the application of MPUs to the equivalent of an ECU, the programming of the algorithms was accomplished by writing the program in the assembly language of the MPU. The executable code was created using a program (which ran on a development system) called an assembler. This assembler would create one or more lines of executable code for each assembly language instruction (as illustrated earlier in this chapter).

In addition to performing algorithms, ECU software provides a variety of other operations. For example, the ECU software must control the input of data as well as the output signals that operate the components that the ECU is controlling. In addition, the stored program must contain parameters that are specific to the overall system performance and that, for example, are part of the associated algorithms. As explained in Chapter 11, the programming any ECU can assist in the diagnosis of system and even overall vehicle diagnosis of problems.

It was not long in the evolution of vehicular electronics before the program to run an ECU was created with a high-level language (e.g., C). However, the rapid increase in the complexity of vehicular electronics inspired a significant jump in the efficiency of programming via the creation of Automotive Open System Architecture (AUTOSAR). AUTOSAR is essentially a consortium between automotive Original Equipment Manufacturers (OEMs) and various suppliers of electronic systems/components that began in 2003 that has permitted collusion free cooperation between the various members on software generation. It has the potential to improve the efficiency of ECU code generation by having standardized modules that can be adapted and employed in the software generation for a new ECU or for improvements in an existing ECU.

Although a given ECU for a vehicular electronically controlled subsystem can, in principle, be fabricated by a division of the OEM, it is typical for the production ready ECU to be provided by one or more top tier supplier(s). In the latter case, the OEM provides a sufficient description of the ECU functionality (which can include operating algorithms) and system configuration that programming by the supplier can be done via AUTOSAR.

The complete program for running a given ECU along with its interaction with other systems consists of software modules that, together, form the AUTOSAR architecture. Each module contains standardized basic software modules (BSW in AUTOSAR) that perform functions commonly found in digital systems. Any digital system working with analog inputs and/or outputs requires the function of analog/digital and vice versa conversion, as well a sampling and, often, multiplexing, bus communication, memory management, etc.

One of the elements of AUTOSAR architecture is called software components with AUTOSAR abbreviation SWCs. Each SWC has interfaces to the required BSW that are specified formally within the SWC. The control of connections between various SWCs and to/from BSW modules is an AUTOSAR element call the runtime environment (RTE). These connections are handled via an AUTOSAR element called the virtual function bus (VFB).

The description of software component is done via an XML file (AUTOSAR XML) that contains sufficient configuration information and data to create the programs for any given ECU (or for multiple ECUs and their interaction during vehicle operation). Among the necessary files are the BSW module descriptions. Normally, the necessary XML files come from the OEM.

In the contemporary versions of AUTOSAR, the functional software for the entire electronic systems of a given vehicle is described. This entire system is partitioned into individual SWCs. The connection/communication between SWCs (even in separate ECUs) is accomplished by the VFB. The VFB is implemented by the RTE, which is specific to any given ECU. The executable code for a given function can be implemented by the AUTOSAR as a C function that is ultimately done by the RTE.

In contemporary vehicles, the addition of a new ECU or the modification of a new ECU to a given or new version of an existing vehicle model, the AUTOSAR software developer requires description/modeling of the complete vehicle electronic system. As explained in Chapter 9 on vehicular communication, a given vehicle model will have one or (usually) more in-vehicle networks (IVNs) that support all digital communications between the various individual ECUs or subsystems. The interconnections between electronic systems via IVNs with all associated protocols (see Chapter 9), for example, bus data rates and data structure, must be specified in the documents provided to the AUTOSAR software developer. A description/model for the hardware and system topology is also necessary including sensors actuators (as explained in Chapter 5) and the individual microprocessors/microcontrollers. Once the vehicular electronic system description is adequately specified, for any ECU the BSW and RTE for that ECU is assembled and is specific to that particular ECU. From this assembly, the executable software code is produced by AUTOSAR. Eventually, the code required to run any given ECU can be stored in ROM as part of the final ECU configuration.

There are multiple benefits to programming vehicular ECUs or subsystems via AUTOSAR. The reuse of individual software or BSW elements increases the efficiency of programming any new digital electronic system. The reuse of portions of code and the automatic code generation can significantly reduce development time and costs compared with the traditional methods of programming for digital electronic systems. The full details of AUTOSAR are beyond the scope of this book. However, AUTOSAR provides documentation that is available online, for example, Autosar_ppt and AUTOSAR_EXP_LayeredSoftwareArchitecture.

Programming Languages

Before writing a program, one must know the code or language in which the program is to be written. Computer languages come in various levels, including high-level language such as C++. A program written in a high-level language such as C++ is essentially independent of the individual hardware on which it is to be run. However, to be useful on any given computer, it must be converted to a language that is specific to that hardware through use of a program known as a compiler. The compiler converts the high-level language to a so-called machine language. An assembly language is designed for a specific microprocessor. A typical assembly-language program consists of a sequence of instructions as explained below that are highly mnemonic to an English word. Machine language is the actual language in which a program is stored in memory in a binary or binary-coded format. For the present example, we choose the intermediate-level language (assembly language) to illustrate specific CPU operations.

Logic Functions

Microprocessors are capable of performing all of the basic logic functions such as AND, OR, NOT, and combinations of these. For instance, the NOT operation can affect the accumulator by changing all ones to zeros and zeros to ones. Other logic functions are performed by using the contents of the accumulator and some memory location. All eight bits of the accumulator are affected, and all are changed at the same time. As shown in Figure 4.13, the AND operation requires two inputs. One input is the contents of the accumulator and the other input is the contents of a memory location; thus, the eight accumulator bits are ANDed with the eight memory bits. The AND operation is performed on a bit-by-bit basis. For instance, bit 0 of the accumulator (the rightmost bit) is ANDed with bit 0 of the memory location, bit 1 with bit 1, bit 2 with bit 2, and so on. In other words, the AND operation is performed as if eight AND gates were connected with one input to a bit in the accumulator, and with the other input to a bit (in the same position) in the memory location. The resulting AND outputs are stored back into the accumulator in the corresponding bit positions. The OR logic function is performed in exactly the same way as the AND except that a 1 would be produced at the output if signal A or signal B were a 1, or if both were a 1 (i.e., using OR logic).

Figure 4.13. AND logic illustration.

Shift

Instead of the AND gate inputs being switched to each bit position as shown in Figure 4.13, the microcomputer uses a special type of sequential logic operation, the shift, to move the bits to the AND gate inputs. A type of register that is capable of such shift operations was discussed in Chapter 3 and is called a shift register. A shift operation causes every bit in the accumulator to be shifted one bit position either to the right or to the left. It can be what is called a logical shift or it can be a circulating shift. Figure 4.14 shows the four types of shifts (logical, circulating, right, and left) and their effects on the accumulator. In a left shift, bit 7 (the leftmost bit) is shifted into the carry bit of the CC register, bit 6 is shifted into bit 7, and so on until each bit has been shifted once to the left. Bit 0 (the rightmost bit) can be replaced either by the carry bit or by a zero, depending on the type of shift performed. Depending on the microprocessor, it is possible to shift other registers as well as the accumulator.

Figure 4.14. Shift register operations.

Programming the AND Function

It is the task of the programmer to choose instructions and organize them in such a way that the computer performs the desired tasks. To program the AND function, one of the instructions will be the AND, which stands for “AND accumulator with contents of a specific memory location,” as shown in Table 4.1c. Since the AND affects the accumulator and memory, values must be put into the accumulator to be ANDed. This requires the load accumulator instruction, LDA.

The assembly-language program of Figure 4.15 performs the required AND function. The programmer must first know which memory location the digital buffer interface (Figure 4.12) occupies. This location is identified, and the programmer writes instructions in the assembler program so that the buffer memory location will be referred to by the label or name SEAT. The mnemonic SEAT is easier for the programmer to remember and write than the address of the buffer.

Figure 4.15. Assembly language AND subroutine.

The operation of the program is as follows. The accumulator is loaded with the contents of the memory location SEAT. Note in Figure 4.12 that the two digital logic input signals, A and B, have been gated into bits 0 and 1, respectively, of the buffer that occupies the memory location labeled SEAT. Bit 0 is high when someone is sitting in the driver's seat. Bit 1 is high when the driver's seat belt is fastened. Only these two bits are to be ANDed together; the other six are to be ignored. But there is a problem because both bits are in the same 8-bit byte and there is no single instruction to AND bits in the same byte. However, the two bits can be effectively separated by using a mask.

Use of Subroutines

The previous example program has been written as a subroutine named CHECK so that it can be used at many different places in a larger program. For instance, if the computer is controlling the speed of the automobile, it might be desirable to be able to detect whether a driver is properly fastened in the seat before it sets the speed at 55 miles per hour.

Since the driver's seat information is very important, the main program must wait until the driver is ready before allowing anything else to happen. A program such as that shown in Figure 4.15b can be used to do this. The main program calls the subroutine WAIT, which in turn immediately calls the subroutine CHECK. CHECK returns to WAIT with the condition codes set as they were after the last AND instruction. The Z bit (see Figure 4.5a) is set if A and B are not both high (the accumulator is zero). The BEQ instruction (see Table 4.1) in line 2 of WAIT branches back because the accumulator is zero and causes the computer to re-execute the JSR instruction in line 1 of WAIT. This effectively holds the computer in a loop, rechecking signals A and B until the accumulator has a nonzero value (A and B are high).

In automotive electronic systems for control or instrumentation, there are many subroutines that are called repeatedly. Among those is the routine for multiplication (as well as for division). The algorithm on which the subroutine is based is derived from the fundamental multiplication of a pair of bits:

0 × 0 = 01 × 0 = 00 × 1 = 01 × 1 = 1

The product of a binary multiplicand A by a binary multiplier B yields binary result C. It is perhaps instructive to illustrate with an example in which A = 13 (decimal) and B = 2 (decimal):

In obtaining this result for each bit in the multiplier, the multiplicand is either copied (i.e., multiplied by 1) if the multiplier bit is a 1 or replaced by all 0's (i.e., multiplication by 0) and shifted to the left by the position of the bit in the multiplier. After performing this operation for each multiplier bit, the results are summed according to the rules of binary addition.

1.9 Problem-solving: Stages and error

Created (by human beings) from the material universe are the physical problems (models). To solve each of these problems, a mathematical model (problem) — imulation/nonsimulation — is derived imposing assumptions and hence errors5 on the physical model. We translate the mathematical model into an appropriate algorithm (method of solution) and subsequently into a computer program (e.g., MATLAB, high-level Fortran, C, C++, or Java program). Then the digital computer which is always a finite-precision (finite word-length) machine and which can represent only a very small fraction of rational numbers translates this program into its machine language. Finally the computation, i.e., the execution of the machine program takes place and the results are produced.

We like to stress here that the terms physical problem (model), mathematical model (problem), algorithm, high-level computer program, internal machine representation of this program, and machine program are equivalent in the sense that each one of these terms is just a set of imperative sentences along with certain given data/inputs/information. These inputs are usually assertive sentences (information).

Consider, for example, the following physical problem. 5 liters of milk, 3 liters of sunflower oil, and 12 eggs cost Rs.182. 2 liters of milk, 4 liters of sunflower oil, and 10 eggs cost Rs.190. 7 liters of milk, 5 liters of sunflower oil, and 30 eggs cost Rs. 300. Find the cost of 1 liter of milk, 1 liter of sunflower oil, and 1 egg, where “Rs.” denotes “Indian currecncy Rupees”.

In this physical model the first three assertive sentences are given data/inputs (information) while the fourth (last) sentence is an imperative one.

The equivalent mathematical model is as follows. Given the linear system (i.e., the system of linear equations)

(1.1)5x1+3x2+12x3=1822x1+4x2+10x3=1907x1+5x2+30x3=300or(531224107530)Ax=(182190300)b

where x=[x1x2x3]tis the solution (column) vector, X1 = cost of one liter of milk, X2 = cost of one liter of sunflower oil, and X3 = cost of one egg, compute X1, X2, and X3.

An equivalent algorithm is as follows. Given Ax = b, where A is the coefficient matrix of the vector X in Equation (1.1), b is the right-hand side column vector inEquation (1.1). Compute x = A− 1b.

An equivalent computer program (high-level) is a set of input (read) statements/instructions along with an ordered set of instructions (imperative sentences). In a MATLAB program it could be

A=[5 3 12;2 4 10;7 5 30]: Input statement

b= [182 190 300]t: Input statement

x = inv(A)∗b: Instruction i.e., compute the inverse of the matrix A, post-multiply it by the column vector b, and store the result in the column vector x.

The solution

x=[x1x2x3]t=[10401]t.

This MATLAB program is translated into a physically larger (in terms of number of instructions) internal machine representation, say, reverse polish notation — a lower level program — and then this intemal machine representation is translated into the still physically larger machine language program (or simply machine program) of the specified computer. The hardware computer understands only its machine program/instructions which are an ordered set of elementary add, subtract, multiply, shift, comparison, test, jump operations and can execute only these machine instructions. There could be several levels of translation/conversion — each is successively physically larger. All of these translated/converted programs in addition to the physical problem, mathematical model, high-level computer program are imperative sentences (simple/compound) with specified data/inputs (assertive sentences). The problem, algorithm, and programs are thus equivalent. However, error, i.e., inaccuracy, is usually injected in each of these stages — problems/programs, in general. In one or more stages in some context, error may not get introduced.

In the execution/computation stage, further error is introduced. Thus the final required solution/result involves the cumulative error. How good this result is has to be established by actually knowing/computing the cumulative error. Diagrammatically, we have (figure 1.4), where MU = material universe, PP = physical problem, M = mathematical model, A = algorithm, CP1 = computer program1 (usually a high-level language program, say, MATLAB or Fortran program), CP2 = computer program2 (could be an internal machine representation, say reverse polish notation — a translated version of CP1), CPn = computer programn, (always a machine program of the particular real/physical computer). Result is the exact solution (usually numerical) plus the cumulative error — none of these two is ever known in practice. Thus the result obtained out of a computer, though is certainly not the most desired exact solution, is a solution reasonably close to the exact solution, i.e., the error is reasonably low (non-dominant) compared to the magnitude of the solution. It is, therefore, necessary to validate how good the result is. We will discuss this important issue in subsequent sections

However, it is worth mentioning that for several continuous simulation problems, we may have immediately after the physical problem PP either a mathematical model M or a bond graph model (Cellier 1998) or both in place of M. Bond graphs are a unique way of describing dynamic models. A bond graph is a drawing in which the physical structure as well as the nature of subsystems are shown and can be directly derived from the ideal physical model. When the ideal physical model is partially changed, only the corresponding part of a bond graph has to be changed. For flow problems such as passive and active electric circuits current flow problems, bond graph modelling is a convenient tool. There are softwares that take, as inputs, the bond graphs and produce the required solutions. The physical laws are made use of to derive a bond graph model for a given physical problem. For a bond graph compendium the reader may refer the websites

http://www.eng.gla.ac.uk/bg/

http://www.ece. arizona.edu/~cellier/bg.html

The universe has always an order in it. We have to unearth all the laws governing it (the order). We have unearthed some but many are yet to be unearthed. There is no inconsistency in this order. Observe that the material universe is absolutely error-free. Any thing/event that happens in it must follow the laws of nature exactly and, of course, sometimes some of these laws could be beyond our comprehension.

Is it true that machine language is the only language that a CPU understands?

What language does a CPU understand quizlet?

Is machine language is universally understood on any computer?

Which language is used in machine?