Sixth day of the 30-day homemade operating system

Split compilation focuses on these two graphs:

Then there is the content of makefile:

Objs_bootpack =bootpack.obj naskfunc.obj hankaku.obj graphic.obj dsctbl.objtoolpath= .. /z_tools/Incpath= .. /z_tools/haribote/ Make= $ (toolpath) Make.exe-Rnask=$ (toolpath) nask.execc1= $ (Toolpath) cc1.exe-i$ (incpath)-os-wall-Quietgas2nask= $ (toolpath) Gas2nask.exe-Aobj2bim=$ (toolpath) Obj2bim.exemakefont=$ (toolpath) Makefont.exebin2obj=$ (toolpath) BIN2OBJ.EXEBIM2HRB=$ (toolpath) Bim2hrb.exerulefile= $ (Toolpath) haribote/haribote.ruledimg=$ (toolpath) Edimg.exeimgtol=$ (toolpath) imgtol.comcopy=Copydel=deldefault: $ (make) Imgipl10.bin:ipl10.nas Makefile $ (nask) Ipl10.nas Ipl10.bin Ipl10.lstasmhead.bin:asmhead.nas make File $ (nask) Asmhead.nas asmhead.bin asmhead.lsthankaku.bin:hankaku.txt Makefile $ (makefont) Hankaku.txt hankaku.b Inhankaku.obj:hankaku.bin Makefile $ (bin2obj) Hankaku.bin hankaku.obj _hankakubootpack.bim: $ (objs_bootpack) Makefil E $ (Obj2bim) @$ (rulefile) out: Bootpack.bim stack:3136k map:bootpack.map $ (objs_bootpack) # 3MB+64kb=3136kbbootpack.hrb:bootpack.bim Makefile $ (BIM2HRB) Bootpack.bim BOOTPACK.HRB0haribote.sys:asmhead.bin bootpack.hrb Makefile copy/b asmhead.bin+BOOTPACK.HRB haribote.sysharibote.img:ipl10.bin haribote.sys Makefile $ (edimg) Imgin:../z_tools/Fdimg0at.tek wbinimg src:ipl10.bin len: +  from:0To:0Copy from: Haribote.sys to:@: Imgout:haribote.img%.gas:%. C Makefile $ (CC1)-O $*.gas $*. C%.nas:%. Gas Makefile $ (gas2nask) $*.gas $*. NAS%.obj:%. NAS Makefile $ (nask) $*.nas $*.obj $*. Lstimg: $ (make) Haribote.imgrun: $ (Make) img $ (COPY) haribote.img. \z_tools\qemu\fdimage0.bin $ (make)-C. /z_tools/Qemuinstall: $ (Make) img $ (imgtol) W A:haribote.imgclean:-$ (DEL) *. Bin-$ (DEL) *. LST-$ (DEL) *. obj-$ (DEL) Bootpack.map-$ (DEL) Bootpack.bim-$ (DEL) BOOTPACK.HRB-$ (DEL) Haribote.syssrc_only: $ (make) clean-$ (DEL) haribote.img

About the loaded code for GDTR:

_LOAD_GDTR:        ; void load_gdtr (int limit, int addr);        MOV        ax,[esp+4]        ; Limit        MOV        [esp+6],ax         LGDT    [esp+6]         RET

It says in the book:

This function is used to assign the upper and address values of the specified segment to a 48-bit register named GDTR. This is a very special 48-bit register, and can not be used with our usual MOV instructions to assign value. When assigning a value to it, the only way to do this is to specify a memory address, read 6 bytes (i.e. 48 bits) from the specified address, and assign the value to the GDTR register. The command to complete this task is LGDT.

The lower 16 bits of the register (that is, the first 2 bytes of memory), is the upper limit of the segment, which equals "the number of valid bytes of GDT-1". In the future, we will occasionally use the term "limit", meaning the size of the volume, generally "bytes-1". The remaining high 32 bits (that is, the remaining 4 bytes) represent the starting position of the GDT.

At the time of the initial execution of this function, Dword[esp+4] holds the upper limit of the segment, and the address is stored in dword[esp+8]. Specific to the actual value, is 0x0000ffff and 0x00270000. If you write them in bytes, it will be [FF FF 00 00 00 00 27 00] (Note that the low bits are stored in a small memory address). In order to execute the LGDT, I want to arrange them as [FF FF 00 00 27 00], so we first use "MOV ax,[esp+4]" to read the original 0XFFFFF, and then write to [Esp+6]. Thus, the result is [FF FF 00 00 27 00], which is exactly what we want if we start reading 6 bytes from [ESP + 6]. “

If you do not understand the protection mode of the principle of addressing, is to read these words, http://www.techbulo.com/708.html read this article and then control the text, you can understand.

Sixth day of the 30-day homemade operating system