s/w development tools for es design->https://www.youtube.com/watch?

v=PcDWm7J19Vo
Can loaded
1. Mixing Assembly Language with High level language like ‘C’ (Assembly Language with ‘C’)

Assembly routines are mixed with ‘C’ in situations where the entire program is written in ‘C’ and
the cross compiler in use do not have built in support for implementing certain features like ISR.

If the programmer wants to take advantage of the speed and optimized code offered by the
machine code generated by hand written assembly rather than cross compiler generated
machine code.

For accessing certain low level hardware, the timing specifications may be very critical and cross
compiler generated machine code may not be able to offer the required time specifications
accurately.

Writing the hardware/peripheral access routine in processor/controller specific assembly

language and invoking it from ‘C’ is the most advised method.

Mixing ‘C’ and assembly is little complicated.

The programmer must be aware of how to pass parameters from the ‘C’ routine to assembly and
values returned from assembly routine to ‘C’ and how Assembly routine is invoked from the ‘C’
code.

Passing parameter to the assembly routine and returning values from the assembly routine to
the caller ‘C’ function and the method of invoking the assembly routine from ‘C’ code is cross
compiler dependent.

There is no universal written rule for purpose.

We can get this information from documentation of the cross compiler.

 Different cross compilers implement these features in different ways depending on GPRs and
memory supported by target processor/controller.

2. Mixing High level language like ‘C’ with Assembly Language (‘C’ with Assembly Language)

The source code is already available in assembly language and routine written in a high level
language needs to be included to the existing code.

The entire source code is planned in Assembly code for various reasons like optimized code,
optimal performance, efficient code memory utilization and proven expertise in handling the
assembly.

The functions written in ‘C’ use parameter passing to the function and returns values to the
calling functions.

The programmer must be aware of how parameters are passed to the function and how
values returned from the function and how function is invoked from the assembly language
environment.

Passing parameter to the function and returning values from the function using CPU registers
, stack memory and fixed memory.

Its implementation is cross compiler dependent and varies across compilers.

C – Run time environment

In programming, the term "run-time environment" (RTE) refers to the environment in

which a program runs and operates during its execution. It includes all the resources
and services required for a program to execute properly. The run-time environment
provides support for tasks such as memory management, input/output operations,
and hardware interaction.

For the C programming language specifically, the run-time environment includes:

1. Operating System: The operating system provides essential services to the C

program, such as process management, file system access, and device
interaction.
2. Compiler/Runtime Libraries: C programs often rely on standard libraries
provided by the compiler, such as the C Standard Library (libc). These libraries
contain pre-written code for common tasks like string manipulation, memory
allocation, and input/output operations.
3. Memory Management: The run-time environment manages memory
allocation and deallocation during program execution. This includes stack
memory for function calls and local variables, as well as heap memory for
dynamic memory allocation.
 4. Input/Output (I/O): The run-time environment facilitates communication
between the program and external devices, such as keyboards, displays, files,
and network sockets. This involves functions provided by the standard I/O
library (stdio.h) for reading from and writing to these devices.
5. Execution Context: The run-time environment maintains the execution
context of the program, including the state of variables, the program counter,
and other processor registers.
6. Error Handling and Exception Mechanisms: C programs can handle errors
and exceptions at runtime using mechanisms such as error codes, return
values, and exception handling (e.g., using setjmp/longjmp or C++-style
exception handling).

Cross compiler->https://medium.com/@harsh.bihani20/cross-compiler-and-its-
applications-37b6b7c76d36
https://www.quora.com/What-is-meant-by-cross-compilation-in-an-embedded-system

https://allthingsembedded.com/2018/12/29/cross-compiling-for-embedded-devices/

How do cross-compilers work?

Well, they work just like any other compiler. The main difference is that the generated
binaries and elf files cannot be run on the local architecture. For an example about a
compiler we will examine the GCC toolchain:

GCC is an acronym for GNU Compiler Collection. It is not just a compiler, but also some
other assorted tools that let you manipulate executable files and generate binaries in
multiple formats. The C compiler in GCC is also called gcc (GNU C Compiler), whilst the C+
+ compiler is a binary named g++.

The job of the compiler is to take source code and transform it into some object code that
is able to run on the target platform. This is done in a few separate steps:

 Preprocessing:
o The first step is running the C Preprocessor on each of the source files. This
will replace all preprocessor directives such as #define and #include,
creating a final file that can be parsed by the compiler itself. It substitutes
all define directives and includes all header files in the source file, as well as
handling some compile time conditional statements such as #ifdef.
o GCC can run this phase using the cpp command.
 Compilation:
o This stage takes care of translating all the source code to the assembly
language required for the target processor. The compiler usually translates
the source code first into an intermediate representation that can be
interpreted by the optimizer and with which it can decide to make
optimizations on the code to reduce the size of it and increase
 performance. Later, this intermediate representation is translated into the
ASM language used for the target language. Function names and variable
names are translated into symbols that are exported whenever it is
necessary. Unresolved symbols will be taken care of later in the build
process.
o GCC can run this phase using the gcc -S or g++ -S commands
 Assembly:
o Once the code for each source file has been transformed into ASM files, the
assembler can run and convert each of the instructions into machine code
or object code that can be run directly on the target. In addition to the
machine code, the object file also includes information about the symbols
required and contained within the code.
o GCC uses the as command to assemble the ASM sources.
 Linkage:
o The last step in this process is the running the linker. This step takes care of
resolving missing symbols and can perform optimizations such as removing
unused code and data. It basically merges all object files into a single
executable. The linker can also link other code contained in libraries (static
or shared).

The build process can be summarized in the following image:

 use of tools sets in Embedded Linux->https://thenewstack.io/compiler-tools-for-
embedded-linux-systems/

Q)explain cross compilation. Discuss its need and importance for embedded and real time system
design

ans. Cross-compilation is the process of compiling code on one platform (the host)
for execution on a different platform (the target). In embedded and real-time system
design, cross-compilation is crucial due to several reasons:

1. Targeting Different Architectures: Embedded systems often utilize

microcontrollers or processors with architectures different from the
development machine. Cross-compilation allows developers to write code on
a host system (e.g., x86-based PC) and compile it for the target architecture
(e.g., ARM, MIPS, or PowerPC). This enables efficient utilization of the
resources of the target hardware and takes advantage of its specific features
and capabilities.
 2. Resource Efficiency: Cross-compilation leverages the processing power and
memory resources of the host development machine for compilation, rather
than relying on the typically limited resources of the target hardware. This
results in faster compilation times and allows developers to compile complex
codebases more efficiently.
3. Isolation from Target Environment: Cross-compilation provides isolation
from the target environment, enabling developers to avoid potential conflicts
with libraries, headers, or tools installed on the target system. This ensures
that the compiled code is strictly targeted for the embedded platform and
minimizes the risk of compatibility issues.
4. Development Workflow Streamlining: Cross-compilation streamlines the
development workflow by enabling developers to compile, test, and debug
code on their development machine before deploying it to the target
platform. This reduces iteration times and accelerates the development
process, as developers can quickly identify and fix issues without the overhead
of transferring code to the target device for compilation.
5. Support for Cross-Platform Development: Cross-compilation facilitates
cross-platform development by allowing developers to write code on one
operating system (e.g., Windows, macOS, or Linux) and compile it for
execution on embedded devices running different operating systems (e.g.,
Linux, FreeRTOS, or bare metal).
6. Optimization for Target Hardware: Cross-compilers provide optimization
options tailored to the target hardware architecture, enabling developers to
generate efficient code that takes advantage of the specific features and
capabilities of the embedded platform. This can lead to improved
performance, reduced memory usage, and extended battery life in battery-
powered devices.
7. Integration with Build Systems: Cross-compilers are often integrated into
build systems like Buildroot, Yocto Project, or custom build scripts to
automate the compilation process and generate complete firmware images
for deployment on embedded devices. This ensures consistency and
repeatability in the build process across different projects and environments.

GNU tool chain->

Toolchain is a set of software tools and components used in the

development of C programming language applications. These tools
are essential for writing, compiling, linking, and debugging C code.

After employing the Compiler Toolchain, we gained a level of

abstraction that allowed us to write our software in human-readable
languages such as C/C++, without the need to concern ourselves
with the intricate hardware details or invest significant time in
understanding machine instructions specific to each machine's
unique instruction set architecture.

So, we have two types of toolchains.

1 - Native Toolchain:

Native toolchains are designed and optimized for a particular hardware or software
platform. They are intended to run on the same platform for which they generate
code.

We use these toolchains to in many examples like desktop applications or design

games that will run in computer.

Examples: Compilers like GCC (GNU Compiler Collection) or Microsoft Visual C++
are native toolchains. They compile code to run specifically on the host system where
the compiler is installed.

2 - Cross-Platform Toolchain:

Targeted for Multiple Platforms: Cross-platform toolchains are designed to work

on one platform (the host) but generate code that can run on different target
platforms. They are used when you need to develop software that can be deployed
on various hardware or software environments like microcontroller based on ARM
Cortex-M we widely use this type of toolchain in embedded system applications, and
cross compiler toolchain aware of memory map and details of platform architecture
relevant to their target execution.
Examples: GCC Compiler for ARM the output will run in (ARM Based
microcontrollers).

Native compiler and cross compiler form

https://www.linkedin.com/pulse/buildingcompilation-process-using-gnu-arm-toolchain-
mohamed-ali/

different files generated during cross compilation-

Types of Files Generated on Cross- Compilation

• Cross-compilation is the process of converting a source code written in high level language to a
target processor/controller understandable machine code.

• The various files generated during the cross-compilation process are:

• List file(.lst)

• Hex file(.hex)

• Pre-processor output file

• Map file(.MAP)

• Object file(.obj)

List file(.LST File)

• Contains information about the cross-compilation process.

• Cross compiler details

• Formatted source text

• Assembly code generated from the source file

• Symbol tables

•Errors and warnings detected during cross-compilation

Pre-processor Output File

• Contains the pre-processor output for the pre-processor instructions used in the source file.

• The pre-processor output file is a valid C source file.

Object File(.OBJ File)

• List of some of the details stored in an object file

• Reserved memory for global variables

• Public symbol names

• External symbol references

• Library files with which to link

• Debugging information to help synchronise source lines with object code

Map File(.MAP)

• Linking and locating of relocatable object files generate a list file called ‘linker list file’

or ‘map file’.

• Map file contains information about the link/locate process.

•Page header

• Command line

• CPU details

• Input modules

• Memory map
• Program size

• Warnings and errors

HEX File(.HEX)

• Hex file is the binary executable file created from the source code.

• The format of hex file varies across the family of processors/controllers.

• Intel HEX and Motorola HEX are the two commonly used hex file formats in embedded
applications.

Disassembler/Decompiler

• Disassembler is a utility program which converts machine code into target processor specific
assembly codes/instructions.

• Decompiler is the utility program for translating machine codes into corresponding high level
language instructions.

• Disassemblers/decompilers are deployed in reverse engineering.