Introduction

Until the last time, I explained the soft core CPU from the hardware side. From now on, I will explain the software side.

Software development steps

Figure 1 shows the general software development steps. We code based on design specifications, convert to binary (machine language) suitable for the target, and then debug (check operation). In general-purpose machines such as personal computers, it is possible to work on the actual machine that is the target, but in the case of embedded equipment, the development machine (called the host computer) performs up to binary conversion, and debugging is performed on the actual machine (called the target). ). Such development is called cross-environment. If you code in a high-level language such as C, even if the processor changes, you can reuse most of the original coding by replacing the tools in the dependent part. The proliferation of high-level languages and cross-development environments has made highly portable designs possible.

Fig. 1 Software development steps

It's an old story, but when microcomputers first came out, they were coded in assembly language and manually assembled and converted into machine language. When I was a poor student, I experienced a lot of things, including reverse conversion (disassembly), so I still remember the CPU mnemonics and machine language I used at that time (laughs).

Relationship between tools and files

Figure 2 shows the relationship between the software development tools and files used from the above-mentioned coding to binary conversion. Files are divided into three main parts: source, object, and executable binary. There are various names for each file, and the ones shown in the figure are not the main ones, so please replace them with the names you usually use. I will explain in order below.

·source file

高級言語やアセンブリ言語で記述されたファイルです。ソースは必ずしも全て新規設計する事はなく、既設計資産の流用や、OSやミドルウェアなどは購入したりして開発工数を抑えます。

・Compiler/Assembler

A tool that converts a source into an object. This tool requires a different tool for each language used, but the output object format is common. In other words, if the method of calling functions at the object level is the same, development using multiple languages is possible even in a single system.

Figure 2 Relationship between tools and files

・Object file

Although the object is machine language based, it is in a state independent of the hardware of the target and cannot be executed as is. In the past, there were cases where this object = executable binary, but recently there are many methods of generating executable binaries via linkers, which will be explained later. It also contains not only machine language but also symbol information required when called from other software.

・Librarian

From the point of view of design assets, it is easy to manage everything in source format, but if the target CPU does not change, it is inefficient to compile software that has already been debugged each time it is developed. Therefore, a librarian creates a library file that combines multiple objects into one and makes it easier to use in the later process. Standard functions that do not depend on applications or hardware are suitable for library creation.

·linker

Newly compiled objects and, if necessary, the aforementioned libraries and already compiled objects are input, building reference relationships between objects, and converting to real addresses according to the target memory map. and so on to generate an executable binary.