Piscisos Development note _ 2 _ detailed description of development methods

The previous article briefly introduced the overview of piscisos. This article details the development methods of the entire system. Because the operating system involves programming close to the underlying hardware, I have not found a good ide for coding and debugging from start to end in my contact scope, therefore, you must select a suitable development method, including the selection of development languages, compilation software, and debugging tools, select the running environment and other tools and software.

First, list all the software used in piscisos development:

Development Platform: Windows 7

Development language: Assembly Language

Assembler: Flat aggreger (FASM)

Source code editing: notepad ++

Debugging tool: bochs 2.5

Running Environment: VMWare 8.1

Image tool: winimage

Other tools: winhex, total commander

Windows is used for the Development Platform. In the implementation of several micro operating systems I know, I have not seen windows as the development platform, but Linux is used. The selection of the Development Platform does not have a great impact on the entire development method, except that the selection of winimage is related to the development platform, you can find alternative or special Linux versions on Linux. The following sections detail the reasons for choosing these tools.

 

1. Development Language

All the source code of piscisos is completed in assembly language, and the application only supports assembly language development. There are several factors to consider when selecting a single assembly language.

First, because piscisos is not based on the existing operating system kernel, the binary program generated by the final encoding is required to be pure and does not contain redundant code added by the compiler or assembler for a specified file format.

Second, the piscios final architecture does not provide a module for memory management. If you want to develop applications for piscios, the programmer must be responsible for all the memory management work.

Third, the use of memory addresses in the programming of the operating system is very clear. In many cases, we need to precisely put some code or data in the specified memory address. The C language pointer can be completed, but relatively not intuitive.

Fourth, the initial design of piscisos did not consider supporting existing popular executable file formats, such as Elf and PE. To be precise, they were abandoned at the beginning, however, the ELF format will be supported in the future. As for PE, if it is supported, it is estimated that my test product system will reach the commercial level, so I will not consider it any more.

In view of the above reasons, the selection of advanced language development is excluded, because the advanced language compiler requires the kernel to support memory management, in addition, some redundant code, such as the PE Header, will be added to the generated target program image file. Therefore, piscios finally chose to use the assembly language to implement all development tasks.

2. assembly tools

The biggest headache for compiling operating system programs is that many compilers and assembler programs add redundant code to the generated target program image file, these codes are useless for a computer that does not load any operating system, so we should try to avoid introducing redundant code in the files generated by development.

At present, there are many popular assembler programs to choose from, but most assembler programs will still bring about redundant code problems, such as MASM, although it can be converted through later tools, however, this also brings about the development efficiency, so the use of the MASM assembler is excluded.

There is also NASM, which should be one of the most frequently used assembler programs in the operating system I have ever seen. It can generate pure binary files, however, since I compiled it from MASM and it was not applicable to at&t's Assembly syntax, I also ruled out the use of this assembly into a program.

To sum up, piscios chose to use flat javaser (FASM) for development. Flat worker er is a fast and efficient 80x86 Assembly tool that supports dos, windows, and Linux operating systems, including
8086-80486/Pentium instructions with MMX, SSE, sse2, sse3, and 3 dnow! Extensions and x86-64 (both amd64 and em64t)
Instruction set. The biggest advantage of flat worker er is that the compilation process is simple. You can use a command to generate target programs applicable to different systems, all controls are differentiated by simple pseudo commands in assembly code. For more information about FASM, see here: http://flatassembler.net

Piscios use flat worker er to generate a target program image file that does not contain any redundant code. In addition, the syntax of flat aggreger inherits from MASM and has been optimized a lot, improving development efficiency and code readability.

3. source code editing

Because flat javaser's own code editor function is weak, the notepad ++ program is used as the source code editor in the development process of piscios, And the nppexec plug-in can be used to build a simple and efficient IDE development environment, 1:

Figure 1 IDE development environment built by notepad ++

The setup method is to set an automatic macro Processing Command for nppexec. First, open the execute... Command, the dialog box appears, and then set the command in the format:

"FASM absolute program path" $ (full_current_path )"

For example, the path of fasm.exe in pisciosdevelopment is F: \ flat assembler \ FASM. EXE,

Set the command to "F: \ flat assembler \ FASM. EXE" "$ (full_current_path )".

Save the macro command and name it "FASM-build", as shown in Figure 2:

Figure 2 set nppexec

Then, adjust the basic settings of nppexec and select no internal messages and save all files on execute, so that nppexec does not output built-in messages and only displays FASM output during execution, and all files are automatically saved during execution, as shown in 3:

Figure 3 nppexec Basic settings

Open advance options of nppexec, set its advanced options, and add a menu item to the "macro" drop-down menu of notepad ++. Set 4:

Figure 4 nppexec advanced options

In order to accurately and quickly locate the source code error files and error lines when an assembly error occurs, you also need to set the console output filter option to enable "nppexec output filters ..." Tab:

Figure 5 nppexec console output Filtering

In this way, when an error occurs during compilation, you can double-click the error message output from the console to locate the error line of the error source file, as shown in 6:

Figure 6 error locating

After these settings, you can perform a convenient and quick development environment.

4. debugging tools

Piscios uses virtual machines for debugging and running, while bochs is used for debugging. because it provides timing simulation of the Virtual Machine CPU, you can adjust the clock frequency of the CPU as needed, A complete debugging interface is provided.

Common Debugging commands for bochs are shown in table 1:

 

Table 1 bochs Debugging commands

Set a breakpoint at a physical address	B ADDR	B 0x30400
Display All current breakpoint Information	Info break	Info break
Continue until a breakpoint occurs.	C	C
One-step execution	S	S
One-step execution (skip in case of a function)	N	N
View register information	Info CPU R Fp Sreg CREG	Info CPU R Fp Sreg CREG
View stacks	Print-Stack	Print-Stack
View memory physical address content	XP/nuf ADDR	XP/40bx 0x9013e
View linear address content	X/nuf ADDR	X/40bx 0x13e
Disassemble a piece of memory	U start end	U 0x30400 0x3040d
Every instruction executed by Disassembly	Trace-on	Trace-on
CPU information is printed every time a command is executed.	Trace-Reg	Trace-Reg on

However, the only drawback of bochs is that the maximum CPU frequency supported by bochs still cannot reach the actual CPU frequency, therefore, bochs will not be able to implement code that requires very strict CPU clock frequency. At this time, only manual review of the code is required. Figure 7 uses bochs for kernel debugging:

Figure 7 bochs debugging environment

5. Running Environment

VMware will be used as the runtime environment when piscios functions are verified and virtual machines are still used during the final run, because there is almost no difference between VMware and real physical machines, therefore, we can check whether the final operating system meets the requirements. Figure 8 run piscios with Vmware:

Figure 8 VMware Runtime Environment

6. Image tools

When the piscios module files are finally organized, use winimage to create a floppy disk image, and then write all the files into the image. Use winimage 9 is shown below:

Figure 9 create a disk image file using winimage

7. Other Tools

Other tools used include winhex and total Commander. The latter is not described too much, mainly for the convenience of file management. winhex needs to be explained.

The breakpoint is required during debugging. In the source code, we can clearly see where we want to place the breakpoint. However, after compilation, the address of some codes in the memory is uncertain, so we need to use winhex to calculate the linear address of our next breakpoint. The practice is to define several special characters in the source code, such as a series of strings "debugdebug", compile and generate binary files, then use winhex to open the file and search for the defined strings, find the offset address of the breakpoint, and add the offset address to the base address that the module is loaded into the memory, the result is the linear address of the breakpoint (because the memory paging ing of piscisos is one-to-one, that is, the physical address 0 corresponds to the linear address 0, so the physical address is equal to the linear address ). Then, you can easily break the breakpoint during bochs debugging. Even if you cannot find the precisely located byte address, you can also view the code loaded in the memory through the disassembly command, therefore, you can still precisely locate breakpoints. I have used the int3 command, but it cannot be executed after it is executed in bochs. Therefore, this complicated method is used.

 

The above is the selection of all tools used in development and the establishment of the environment. After the development environment is set up, you can start the development of the operating system. First, encode the modules according to the system's logical functions. Note that the modules mentioned here are only logical, because there is only one compilation unit during the final compilation, that is, pkernel. ASM, other modules are independent. INC source file, which is compiled by the compiler. the INC file is included in pkernel. in the ASM file, a pkernel is generated. bin binary file (the kernel module of the object ). Boot
Sector and other applications are also compiled to generate the corresponding binary files. Finally, these files are organized into a floppy disk image file using winimgae in the fat12 format, then, you can use bochs or VMware to load the disk image for debugging. If you encounter an error code and locate it through debugging, you can modify the corresponding source file, re-compile the code, write the disk image, and debug and run it.

 

This is the overall development method of piscisos. Within my knowledge, I try to automate and simplify the entire development process. I think the use of FASM is the core simplification method. FASM is a new assembly program with powerful functions! He can do everything MASM and NASM can do. for different target programs, he only needs to write one or two Macros in the source code, so he does not need to care about the parameters during compilation, because the only major parameter of FASM is the source file.

This article will introduce the compilation of Boot Sector and the entire Startup Process of piscsos.

Coming to the next article: piscisos Development note _ 3_boot sector implementation and piscisos Startup Process