Code Review (unintentional)
162 views
Skip to first unread message
Antony
Mar 27, 2019, 12:10:03 PM3/27/19
to Night DOS Kernel
All,
As I am going through the code to try and to see if I can get it to work with a linker, I'm noticing an interesting programming style that is slowing the process (for me). I looked at a few other projects that were coded in assembly (like MikeOS) and noticed the same layout.
What I am speaking of specifically are the paradigm of intermixed code and data and the include files. While it's not a bad thing from the current perspective of how you have developed the OS (and MikeOS does it that way), it has presented challenges for me since I am trying to make each portion of the kernel it's own separate code base.
Coming from a background (personally via work) of build/test/release, each section of code is typically designed to stand on its own so that unit tests can be built around it. The include files are used to introduce common values/data types and structures needed in the programs.
What I am attempting to do in my Linker branch is move the code to this type of model:
Things that need to accessed from a different module would be prefaced global and in the main kernel code (or other code), there would be an extrn section that would name the functions or procedures that are being called and the linker would fill in the missing addresses.
I've done some other research on the align, the linker script made for bigger files because I was aligning on a 32-bit boundary (align 4) so everything was lined up where the address modulo 4 is 0 (0x0, 0x4, 0x8...) in the code section, NASM drops in NOP and in data (which was never clearly defined in code, NULLs would be plae
You don't "necessarily" have to change your coding method, but I think you may find the more "structured" method easier overall.
Thoughts?
Antony
Mar 27, 2019, 12:11:30 PM3/27/19
to Night DOS Kernel
# Subprogram 1
.data
# Variables for subprogram 1
.text
# Subprogram body
ret
# Subprogram 2
.data
# Variables for subprogram 2
.text
# Subprogram body
ret
# Main program
.data
# Variables for main
.text
# Main body
ret
Looks like the message butchered the code when I applied the code formatting, so I re-added it here since I haven't figured out how to edit my messages.
-T
Maarten Vermeulen
Mar 27, 2019, 3:30:19 PM3/27/19
to Night DOS Kernel
Personally, I don't like doing it that way just because it's annoying but I will go with whatever is decided. Does it affect anything else other than the readability?
You should be able to edit your own messages by clicking on the drop-down arrow next to the 'reply arrows' (upper-right corner of a message).
{... Code syntax ...}
Mercury Thirteen
Mar 28, 2019, 3:21:50 AM3/28/19
to Night DOS Kernel
I like this approach. My only concern was the alignment issues but it sounds like those can be done away with, and if we can get the assembler to honor a .bss section, we may even end up shaving a little space off the overall size since we can remove all the instances of variables which are wasting space by being embedded in the code. Would simply adding section labels to the existing code be sufficient to implement this in the kernel? I think that's a minor and reasonable change.
I'm definitely looking forward to whatever results you achieve with this!
On Wednesday, March 27, 2019 at 12:10:03 PM UTC-4, Antony wrote:
Antony
Mar 28, 2019, 7:38:51 AM3/28/19
to Night DOS Kernel
What's annoying about that?
From a finished code perspective, all the data is loaded at the end of the file (since code comes first) and it makes everything easier rather than having data blocks dispersed among code blocks. It does also help from a readability perspective.
Oh, once I post, I can't edit the post.
Antony
Mar 28, 2019, 7:43:02 AM3/28/19
to Night DOS Kernel
As far as alignment goes, I think I would only align data, but once I can modularize the code and figure out what should be include vs module, we can play with align directives in the assembly source or in the linker script to determine what works best. If I remember correctly, having the instructions aligned on a word or dword boundary is supposed to benefit instruction loading and prefetch things. I've never delved too much into the inner workings of that kind of thing since most of my development has either been web or Java.
-T
Maarten Vermeulen
Mar 28, 2019, 7:45:36 AM3/28/19
to Night DOS Kernel
Oh okay. In that case it isn't annoying. :)
Do more people have the same problem with editing their posts once they're posted? If so, I will take a look if I can change that.
Maarten Vermeulen
Mar 28, 2019, 1:37:47 PM3/28/19
to Night DOS Kernel
Everyone should be able to edit their own posts now.
Mercury Thirteen
Mar 28, 2019, 7:04:14 PM3/28/19
to Night DOS Kernel
Makes sense. We'll eventually have to play with a few different alignments and compare to see what runs fastest.
Mercury Thirteen
Mar 29, 2019, 4:56:17 AM3/29/19
to Night DOS Kernel
Antony: I went through all the files for v0.19 and added proper section directives. I should be set to push by the end of this month; hopefully this will help!
Catharinus: You mentioned the kernel paused for several moments during boot on your one machine. I traced this down to faults in keyboard/mouse initialization, so I overhauled that code to eliminate unnecessary I/O timeout states on the PS/2 Controller for machines which have only a single PS/2 port active (as my own laptop does). Hopefully that'll resolve the issue!
Maarten: Thanks for fixing post editing!
Antony
Mar 31, 2019, 8:49:36 AM3/31/19
to Night DOS Kernel
Hi,
Missed this with all of the other threads but yes, adding sections would be the first step. Then in place of the include files, especially since most are code, the routines called externally should have global in front of them and then in the calling program, they should have an extrn statement to let the assembler know its in another file and the linker fixes it.
-T
Mercury Thirteen
Mar 31, 2019, 3:45:06 PM3/31/19
to Night DOS Kernel
That will be a little harder for me to do since that will basically break the current build procedure. Can I get another copy of your linker script? I'll see if I can migrate the project over to this build method.
Antony
Apr 4, 2019, 7:58:32 AM4/4/19
to Night DOS Kernel
Hey,
Yes, I will email it off list. This is why I started a local branch on my machine to try to work through everything. It's not easy to do at all, but I was starting by making the include files that are really full sections of code modular so that it stands on it's own.
-T
Mercury Thirteen
Apr 4, 2019, 8:19:38 AM4/4/19
to Night DOS Kernel
So, just to make sure I'm on the same page with you, in the end we would have a single kernel.asm file as we do now, but everything else would be renamed as .inc files, and the existing files would be split up into two; one containing code and the other data. Is that roughly correct?
Antony
Apr 4, 2019, 10:56:04 PM4/4/19
to Night DOS Kernel
Yes and no.
We would still end up with one kernel consisting of one binary file, but it would break down like this:
globals.inc would contain common constants and variables and be linked into each module (those variables are private)
kernel.asm would contain the entry point into the kernel
video.asm
hardware.asm
interrupt.asm
* all functions that are called would be marked global and in main referenced with an extrn statement
(as examples)
Or you can further modularize the kernel so that everything related to video is in one folder and then you can break out the 16-bit and 32-bit code and link as needed.
Also, building in this manner allows for more granular testing as you can, for example, test the memory manager code, initializing, freeing, and trapping memory errors, and once the bugs are worked out, the functions that need to be implemented are marked global and can be referenced by other programs via the extrn keyword.
The drivers can be compiled to flat binary with the option of either being built-in to the kernel or being loadable from disk.
Antony
Apr 5, 2019, 8:16:44 AM4/5/19
to Night DOS Kernel
Hi,
For an idea on what I mean by breaking up the kernel, look at the source for MS-DOS here https://github.com/Microsoft/MS-DOS or MMURTL at https://github.com/bproctor/MMURTL/tree/master/OSSOURCE (assuming you don't have the book, btw I do have an electronic version if anyone needs it).
Now in looking at this code, I am not suggesting using any of it, but merely looking at the structure of how it's built. I believe the MMURTL source may be more readable and easier to follow what I mean by a modular building of the kernel. Richard Burgess developed his own compilers for his OS.
-T
Mercury Thirteen
Apr 5, 2019, 6:09:59 PM4/5/19
to Night DOS Kernel
I actually do own his book! I'll have to check out the links you provided as well.
Antony
Apr 7, 2019, 5:41:24 PM4/7/19
to Night DOS Kernel
Hey,
I imported the Dev branch into my linker and did some edits, there is still a lot of work to be done to make this even try to work. I zipped up what I worked on and I can send it over so you can get an idea of what's needed.
-T
Mercury Thirteen
Apr 7, 2019, 9:00:06 PM4/7/19
to Night DOS Kernel
Sounds good, I'll check it out.
Antony
Apr 22, 2019, 10:43:55 PM4/22/19
to Night DOS Kernel
All,
I have completed the conversion of the kernel to a modular version using the linker. As I haven't compiled the current development version of the kernel to test, but based upon what is in GitHub (assuming a fresh build was pushed to the repository which is another addressible topic) the linker version of the kernel appears to be about 5k larger. It was larger than that until I removed the alignment on the .text section in the link file. There is is a 4K alignment on data and bss.
Before you get alarmed at the file size, remember size on disk does not exactly represent the usage in memory.
So I'm sure given this information, you're wondering what is the benefit of this method over one file with a bunch of includes?
This method provides for separate compilation, so now if someone makes a change to pci.asm for example, the entire source does not need to be rebuilt. The makefile (that you will all love) will notice that pci.asm needs to be rebuilt and just rebuild pci.asm to pci.o and then relink all the other .o files to build the kernel.
The second benefit is that as a developer, you can write a module and then include tests to verify that code is working correctly, before being linked into the kernel. These tests should be included in the repository as well.
-T
On Wednesday, March 27, 2019 at 12:10:03 PM UTC-4, Antony wrote:
Mercury Thirteen
Apr 25, 2019, 12:53:58 AM4/25/19
to Night DOS Kernel
Good deal! I probably won't be pushing 0.1B until the end of may, so you have plenty of time to push your changes lol
Mercury Thirteen
Apr 25, 2019, 1:48:23 AM4/25/19
to Night DOS Kernel
On second thought... it seems I typed that last reply before I remembered you already sent me the files. I'll incorporate them into the 0.1B release myself. Thanks!
Antony
Apr 26, 2019, 2:27:28 AM4/26/19
to Night DOS Kernel
Hey,
Confirm it runs successfully before moving up.
-T
Antony
Apr 27, 2019, 4:23:49 PM4/27/19
to Night DOS Kernel
All,
I have pushed the linker version up as a separate remote branch for everyone to try out
Mercury and I are having build issues, which he can speak to.
Aside from that issue, the linker version (as I mentioned in another post) does allow for separate compilation, so right now, we have an issue. If the issue is determined to be one of the source files, the kernel will only need to be re-linked with the errant module, but all of the .ASM code (unless all of it's touched or you run make clean) will not need to be re-compiled.
Mercury, I thought the issue was the script as well so I changed it and it seem to build a bit further than with the original script. I also removed the alignment on the code and left it on data and bss.
-T
On Wednesday, March 27, 2019 at 12:10:03 PM UTC-4, Antony wrote:
Antony
May 21, 2019, 5:30:41 PM5/21/19
to Night Kernel
All,
Notice the .fill sections to align the code/data on boundaries. Results in a larger file (on disk)
Here's the MAP file from the linker built version of the kernel (which crashes because I haven't had the time to redirect the driver calls)
Memory Configuration
Name Origin Length Attributes
*default* 0x0000000000000000 0xffffffffffffffff
Linker script and memory map
0x0000000000000600 phys = 0x600
.text 0x0000000000000600 0x64e0
0x0000000000000600 code = .
*(.text)
.text 0x0000000000000600 0x4c1 obj/kernel.o
0x0000000000000601 main
0x0000000000000ac1 DriverSpaceStart
0x0000000000000ac1 DriverSpaceEnd
*fill* 0x0000000000000ac1 0xf
.text 0x0000000000000ad0 0x5a7 obj/api/lists.o
0x0000000000000ad0 LMElementAddressGet
0x0000000000000b31 LMElementCountGet
0x0000000000000ba7 LMElementDelete
0x0000000000000c07 LMElementDuplicate
0x0000000000000c67 LMElementSizeGet
0x0000000000000cc5 LMItemAddAtSlot
0x0000000000000d3c LMListInit
0x0000000000000db5 LMSlotFindFirstFree
0x0000000000000e4b LM_Internal_ElementAddressGet
*fill* 0x0000000000001077 0x9
.text 0x0000000000001080 0x84 obj/api/misc.o
0x0000000000001080 SetSystemAPM
0x00000000000010a0 BCDToDecimal
0x00000000000010e9 TimerWait
*fill* 0x0000000000001104 0xc
.text 0x0000000000001110 0xaec obj/api/strings.o
0x0000000000001110 ConvertByteToHexString16
0x0000000000001144 ConvertWordToHexString16
0x0000000000001215 ConvertNumberHexToString
0x00000000000013e3 ConvertStringHexToNumber
0x0000000000001517 StringCharAppend
0x00000000000015ff StringLength
0x000000000000178c StringTokenBinary
0x0000000000001817 StringTokenDecimal
0x00000000000018a2 StringTokenHexadecimal
0x00000000000019b8 StringTokenString
0x0000000000001a40 StringTrimRight
0x0000000000001a70 StringTruncateLeft
0x0000000000001aa3 StringTruncateRight
*fill* 0x0000000000001bfc 0x4
.text 0x0000000000001c00 0xbfa obj/drivers/PS2Controller.o
0x0000000000001e45 KeyGet
0x0000000000001e80 KeyWait
*fill* 0x00000000000027fa 0x6
.text 0x0000000000002800 0xe5 obj/drivers/FAT12.o
*fill* 0x00000000000028e5 0xb
.text 0x00000000000028f0 0x6cc obj/drivers/ATAController.o
*fill* 0x0000000000002fbc 0x4
.text 0x0000000000002fc0 0x665 obj/io/serial.o
*fill* 0x0000000000003625 0xb
.text 0x0000000000003630 0xaa obj/system/hardware.o
0x0000000000003630 DriverLegacyLoad
0x000000000000367b PITInit
0x0000000000003690 Random
0x00000000000036c5 Reboot
*fill* 0x00000000000036da 0x6
.text 0x00000000000036e0 0xc1e obj/system/interrupts.o
0x0000000000003719 CriticalError
0x00000000000039a7 IDTInit
0x0000000000003a6a InterruptHandlerSet
0x0000000000003aae InterruptUnimplemented
0x0000000000003ac8 ISRInitAll
*fill* 0x00000000000042fe 0x2
.text 0x0000000000004300 0x1c2 obj/system/partitions.o
0x0000000000004300 PartitionEnumerate
*fill* 0x00000000000044c2 0xe
.text 0x00000000000044d0 0x5b6 obj/system/pci.o
0x00000000000044d0 PCIProbe
0x00000000000044ee PCICalculateNext
0x000000000000464f PCIGetNextFunction
0x00000000000046a3 PCIInitBus
0x0000000000004841 PCILoadDrivers
0x00000000000049e0 PCIReadAll
0x0000000000004a14 PCIReadDWord
*fill* 0x0000000000004a86 0xa
.text 0x0000000000004a90 0x34 obj/system/cmos.o
*fill* 0x0000000000004ac4 0xc
.text 0x0000000000004ad0 0x2f obj/system/power.o
0x0000000000004ad0 APMEnable
0x0000000000004ad1 APMDisable
*fill* 0x0000000000004aff 0x1
.text 0x0000000000004b00 0x8a obj/system/cpu.o
0x0000000000004b00 SetSystemCPUID
*fill* 0x0000000000004b8a 0x6
.text 0x0000000000004b90 0xe2 obj/system/pic.o
0x0000000000004b90 PICInit
0x0000000000004be7 PICIntComplete
0x0000000000004bfa PICIRQDisable
0x0000000000004c23 PICIRQDisableAll
0x0000000000004c36 PICIRQEnable
0x0000000000004c5f PICIRQEnableAll
*fill* 0x0000000000004c72 0xe
.text 0x0000000000004c80 0x9ca obj/system/memory.o
0x0000000000004cca A20Enable
0x0000000000004dca MemProbe
0x0000000000004f46 MemAllocate
0x0000000000004ff8 MemAllocateAligned
0x000000000000511b MemCopy
0x0000000000005198 MemFill
0x0000000000005233 MemInit
0x00000000000053c9 MemSearchString
0x00000000000055a5 MemSwapWordBytes
*fill* 0x000000000000564a 0x6
.text 0x0000000000005650 0xb74 obj/system/debug.o
0x0000000000005650 DebugInstacrash
0x0000000000005656 DebugMemoryDetails
0x000000000000572c DebugMenu
0x00000000000058b2 DebugPCIDevices
0x0000000000005dc4 DebugRAMBrowser
0x0000000000005f85 DebugStackTrace
0x0000000000005fdc DebugSystemInfo
0x00000000000061b7 DebugWaitForEscape
*fill* 0x00000000000061c4 0xc
.text 0x00000000000061d0 0x15e obj/system/tasks.o
0x00000000000061d0 TaskDetermineNext
0x00000000000061d7 TaskInit
0x0000000000006213 TaskKill
0x000000000000624a TaskNew
0x00000000000062e0 TaskSwitch
*fill* 0x000000000000632e 0x2
.text 0x0000000000006330 0x17a obj/system/rtc.o
0x0000000000006330 RTCAdjustBCD
0x00000000000063a2 RTCInit
0x00000000000063f0 RTCInterruptHandler
*fill* 0x00000000000064aa 0x6
.text 0x00000000000064b0 0x131 obj/system/gdt.o
*fill* 0x00000000000065e1 0xf
.text 0x00000000000065f0 0x4ef obj/video/screen.o
0x00000000000065f0 Print16
0x0000000000006682 PrintIfConfigBits16
0x000000000000669f PrintRegs16
0x0000000000006717 ScreenClear16
0x0000000000006748 ScreenScroll16
0x0000000000006796 CursorHome
0x00000000000067ab Print32
0x0000000000006876 PrintIfConfigBits32
0x00000000000068b5 PrintRAM32
0x0000000000006987 PrintRegs32
0x0000000000006a69 ScreenClear32
0x0000000000006a99 ScreenScroll32
*(.rodata)
0x0000000000006ae0 . = ALIGN (0x4)
*fill* 0x0000000000006adf 0x1
data: 0x0000000000006ae0 0x39
data: 0x0000000000006ae0 0x39 obj/system/hardware.o
.data 0x0000000000006b1c 0x2248
0x0000000000006b1c data = .
*(.data)
.data 0x0000000000006b1c 0x2d2 obj/kernel.o
*fill* 0x0000000000006dee 0x2
.data 0x0000000000006df0 0xba obj/api/lists.o
*fill* 0x0000000000006eaa 0x2
.data 0x0000000000006eac 0xba obj/api/misc.o
*fill* 0x0000000000006f66 0x2
.data 0x0000000000006f68 0x10 obj/api/strings.o
.data 0x0000000000006f78 0x280 obj/drivers/PS2Controller.o
.data 0x00000000000071f8 0xe7 obj/drivers/FAT12.o
*fill* 0x00000000000072df 0x1
.data 0x00000000000072e0 0x13b obj/drivers/ATAController.o
*fill* 0x000000000000741b 0x1
.data 0x000000000000741c 0xba obj/io/serial.o
*fill* 0x00000000000074d6 0x2
.data 0x00000000000074d8 0xba obj/system/hardware.o
*fill* 0x0000000000007592 0x2
.data 0x0000000000007594 0x565 obj/system/interrupts.o
*fill* 0x0000000000007af9 0x3
.data 0x0000000000007afc 0xe4 obj/system/partitions.o
.data 0x0000000000007be0 0x262 obj/system/pci.o
*fill* 0x0000000000007e42 0x2
.data 0x0000000000007e44 0xba obj/system/cpu.o
*fill* 0x0000000000007efe 0x2
.data 0x0000000000007f00 0xba obj/system/globals.o
*fill* 0x0000000000007fba 0x2
.data 0x0000000000007fbc 0x20c obj/system/memory.o
.data 0x00000000000081c8 0x7d6 obj/system/debug.o
*fill* 0x000000000000899e 0x2
.data 0x00000000000089a0 0xba obj/system/tasks.o
*fill* 0x0000000000008a5a 0x2
.data 0x0000000000008a5c 0x115 obj/system/rtc.o
*fill* 0x0000000000008b71 0x3
.data 0x0000000000008b74 0x30 obj/system/gdt.o
0x0000000000008b74 GDTStart
.data 0x0000000000008ba4 0x1bf obj/video/screen.o
0x0000000000008c5f gCursorY
0x0000000000008c60 gTextColor
0x0000000000008c61 gBackColor
0x0000000000008c62 kMaxLines
0x0000000000008c63 kBytesPerScreen
0x0000000000008d64 . = ALIGN (0x4)
*fill* 0x0000000000008d63 0x1
.bss 0x0000000000008d70 0x69d0
0x0000000000008d70 bss = .
*(.bss)
.bss 0x0000000000008d70 0x60b5 obj/kernel.o
*fill* 0x000000000000ee25 0x3
.bss 0x000000000000ee28 0x51 obj/api/lists.o
*fill* 0x000000000000ee79 0x3
.bss 0x000000000000ee7c 0x51 obj/api/misc.o
*fill* 0x000000000000eecd 0x3
.bss 0x000000000000eed0 0x55 obj/drivers/PS2Controller.o
*fill* 0x000000000000ef25 0x3
.bss 0x000000000000ef28 0xa1 obj/drivers/FAT12.o
*fill* 0x000000000000efc9 0x3
.bss 0x000000000000efcc 0xa1 obj/drivers/ATAController.o
*fill* 0x000000000000f06d 0x3
.bss 0x000000000000f070 0x51 obj/io/serial.o
*fill* 0x000000000000f0c1 0x3
.bss 0x000000000000f0c4 0x51 obj/system/hardware.o
*fill* 0x000000000000f115 0x3
.bss 0x000000000000f118 0xa1 obj/system/interrupts.o
*fill* 0x000000000000f1b9 0x3
.bss 0x000000000000f1bc 0xa1 obj/system/partitions.o
*fill* 0x000000000000f25d 0x3
.bss 0x000000000000f260 0xa1 obj/system/pci.o
*fill* 0x000000000000f301 0x3
.bss 0x000000000000f304 0x51 obj/system/cpu.o
*fill* 0x000000000000f355 0x3
.bss 0x000000000000f358 0x51 obj/system/globals.o
*fill* 0x000000000000f3a9 0x3
.bss 0x000000000000f3ac 0x51 obj/system/memory.o
*fill* 0x000000000000f3fd 0x3
.bss 0x000000000000f400 0x1e1 obj/system/debug.o
*fill* 0x000000000000f5e1 0x3
.bss 0x000000000000f5e4 0x51 obj/system/tasks.o
*fill* 0x000000000000f635 0x3
.bss 0x000000000000f638 0x51 obj/system/rtc.o
*fill* 0x000000000000f689 0x3
.bss 0x000000000000f68c 0xb2 obj/video/screen.o
0x000000000000f740 . = ALIGN (0x4)
*fill* 0x000000000000f73e 0x2
0x000000000000f740 end = .
LOAD obj/kernel.o
LOAD obj/api/lists.o
LOAD obj/api/misc.o
LOAD obj/api/strings.o
LOAD obj/drivers/PS2Controller.o
LOAD obj/drivers/FAT12.o
LOAD obj/drivers/ATAController.o
LOAD obj/io/serial.o
LOAD obj/system/hardware.o
LOAD obj/system/interrupts.o
LOAD obj/system/partitions.o
LOAD obj/system/pci.o
LOAD obj/system/cmos.o
LOAD obj/system/power.o
LOAD obj/system/cpu.o
LOAD obj/system/pic.o
LOAD obj/system/globals.o
LOAD obj/system/memory.o
LOAD obj/system/debug.o
LOAD obj/system/tasks.o
LOAD obj/system/rtc.o
LOAD obj/system/gdt.o
LOAD obj/video/screen.o
OUTPUT(output/kernel.sys binary)
Cross Reference Table
Symbol File
A20Enable obj/system/memory.o
obj/kernel.o
APMDisable obj/system/power.o
APMEnable obj/system/power.o
obj/kernel.o
BCDToDecimal obj/api/misc.o
obj/system/rtc.o
ConvertByteToHexString16 obj/api/strings.o
obj/system/memory.o
ConvertNumberHexToString obj/api/strings.o
obj/video/screen.o
ConvertStringHexToNumber obj/api/strings.o
obj/system/debug.o
ConvertWordToHexString16 obj/api/strings.o
obj/video/screen.o
CriticalError obj/system/interrupts.o
CursorHome obj/video/screen.o
DebugInstacrash obj/system/debug.o
DebugMemoryDetails obj/system/debug.o
DebugMenu obj/system/debug.o
obj/kernel.o
DebugPCIDevices obj/system/debug.o
DebugRAMBrowser obj/system/debug.o
DebugStackTrace obj/system/debug.o
DebugSystemInfo obj/system/debug.o
DebugWaitForEscape obj/system/debug.o
DriverLegacyLoad obj/system/hardware.o
obj/kernel.o
DriverSpaceEnd obj/kernel.o
obj/system/pci.o
obj/system/partitions.o
obj/system/hardware.o
DriverSpaceStart obj/kernel.o
obj/system/pci.o
obj/system/partitions.o
obj/system/hardware.o
GDTStart obj/system/gdt.o
obj/kernel.o
IDTInit obj/system/interrupts.o
obj/kernel.o
ISRInitAll obj/system/interrupts.o
obj/kernel.o
InterruptHandlerSet obj/system/interrupts.o
obj/drivers/ATAController.o
obj/drivers/PS2Controller.o
InterruptUnimplemented obj/system/interrupts.o
KeyGet obj/drivers/PS2Controller.o
obj/system/debug.o
KeyWait obj/drivers/PS2Controller.o
obj/system/debug.o
obj/system/interrupts.o
LMElementAddressGet obj/api/lists.o
obj/system/tasks.o
obj/system/debug.o
obj/system/memory.o
obj/system/pci.o
obj/system/partitions.o
obj/drivers/ATAController.o
obj/drivers/FAT12.o
LMElementCountGet obj/api/lists.o
obj/system/debug.o
obj/system/memory.o
obj/system/pci.o
obj/system/partitions.o
LMElementDelete obj/api/lists.o
obj/system/memory.o
LMElementDuplicate obj/api/lists.o
obj/system/memory.o
LMElementSizeGet obj/api/lists.o
obj/system/memory.o
LMItemAddAtSlot obj/api/lists.o
obj/system/debug.o
LMListInit obj/api/lists.o
obj/system/tasks.o
obj/system/debug.o
obj/system/memory.o
obj/system/pci.o
obj/kernel.o
LMSlotFindFirstFree obj/api/lists.o
obj/system/tasks.o
obj/system/partitions.o
obj/drivers/ATAController.o
LM_Internal_ElementAddressGet obj/api/lists.o
obj/system/tasks.o
MemAllocate obj/system/memory.o
obj/system/tasks.o
obj/system/debug.o
obj/system/pci.o
obj/system/partitions.o
obj/system/interrupts.o
obj/drivers/ATAController.o
obj/drivers/PS2Controller.o
obj/kernel.o
MemAllocateAligned obj/system/memory.o
obj/system/tasks.o
obj/kernel.o
MemCopy obj/system/memory.o
obj/video/screen.o
obj/system/debug.o
obj/system/pci.o
obj/system/interrupts.o
obj/drivers/ATAController.o
obj/drivers/FAT12.o
obj/api/strings.o
obj/api/lists.o
obj/kernel.o
MemFill obj/system/memory.o
obj/video/screen.o
obj/system/tasks.o
obj/api/strings.o
MemInit obj/system/memory.o
obj/kernel.o
MemProbe obj/system/memory.o
obj/kernel.o
MemSearchString obj/system/memory.o
obj/system/pci.o
obj/system/partitions.o
obj/system/hardware.o
MemSwapWordBytes obj/system/memory.o
obj/drivers/ATAController.o
PCICalculateNext obj/system/pci.o
obj/system/debug.o
PCIGetNextFunction obj/system/pci.o
obj/system/debug.o
PCIInitBus obj/system/pci.o
obj/kernel.o
PCILoadDrivers obj/system/pci.o
obj/kernel.o
PCIProbe obj/system/pci.o
obj/kernel.o
PCIReadAll obj/system/pci.o
obj/system/debug.o
PCIReadDWord obj/system/pci.o
obj/drivers/ATAController.o
PICIRQDisable obj/system/pic.o
obj/drivers/PS2Controller.o
PICIRQDisableAll obj/system/pic.o
obj/drivers/PS2Controller.o
obj/kernel.o
PICIRQEnable obj/system/pic.o
obj/drivers/PS2Controller.o
PICIRQEnableAll obj/system/pic.o
obj/drivers/PS2Controller.o
obj/kernel.o
PICInit obj/system/pic.o
obj/kernel.o
PICIntComplete obj/system/pic.o
obj/system/interrupts.o
obj/drivers/ATAController.o
obj/drivers/PS2Controller.o
PITInit obj/system/hardware.o
obj/kernel.o
PartitionEnumerate obj/system/partitions.o
obj/kernel.o
Print16 obj/video/screen.o
obj/system/memory.o
Print32 obj/video/screen.o
obj/system/debug.o
obj/system/interrupts.o
obj/kernel.o
PrintIfConfigBits16 obj/video/screen.o
obj/system/memory.o
obj/kernel.o
PrintIfConfigBits32 obj/video/screen.o
obj/system/rtc.o
obj/system/pci.o
obj/system/partitions.o
obj/drivers/ATAController.o
obj/drivers/FAT12.o
obj/drivers/PS2Controller.o
obj/kernel.o
PrintRAM32 obj/video/screen.o
obj/system/debug.o
obj/system/interrupts.o
PrintRegs16 obj/video/screen.o
PrintRegs32 obj/video/screen.o
obj/system/interrupts.o
obj/drivers/PS2Controller.o
obj/kernel.o
RTCAdjustBCD obj/system/rtc.o
RTCInit obj/system/rtc.o
obj/kernel.o
RTCInterruptHandler obj/system/rtc.o
obj/system/interrupts.o
Random obj/system/hardware.o
Reboot obj/system/hardware.o
obj/system/debug.o
ScreenClear16 obj/video/screen.o
ScreenClear32 obj/video/screen.o
obj/system/debug.o
obj/system/interrupts.o
obj/kernel.o
ScreenScroll16 obj/video/screen.o
ScreenScroll32 obj/video/screen.o
SetSystemAPM obj/api/misc.o
obj/kernel.o
SetSystemCPUID obj/system/cpu.o
obj/kernel.o
StringCharAppend obj/api/strings.o
obj/system/debug.o
StringLength obj/api/strings.o
obj/system/debug.o
obj/system/memory.o
StringTokenBinary obj/api/strings.o
obj/system/interrupts.o
obj/kernel.o
StringTokenDecimal obj/api/strings.o
obj/system/debug.o
obj/system/pci.o
obj/drivers/ATAController.o
obj/drivers/FAT12.o
obj/kernel.o
StringTokenHexadecimal obj/api/strings.o
obj/video/screen.o
obj/system/debug.o
obj/system/pci.o
obj/system/partitions.o
obj/system/interrupts.o
obj/drivers/ATAController.o
obj/kernel.o
StringTokenString obj/api/strings.o
obj/video/screen.o
obj/system/debug.o
obj/system/interrupts.o
obj/drivers/ATAController.o
obj/drivers/FAT12.o
StringTrimRight obj/api/strings.o
obj/drivers/ATAController.o
StringTruncateLeft obj/api/strings.o
obj/system/debug.o
StringTruncateRight obj/api/strings.o
TaskDetermineNext obj/system/tasks.o
TaskInit obj/system/tasks.o
obj/kernel.o
TaskKill obj/system/tasks.o
obj/system/interrupts.o
TaskNew obj/system/tasks.o
obj/kernel.o
TaskSwitch obj/system/tasks.o
obj/system/interrupts.o
TimerWait obj/api/misc.o
obj/drivers/PS2Controller.o
obj/kernel.o
backColor obj/system/memory.o
obj/kernel.o
gBackColor obj/video/screen.o
obj/system/memory.o
obj/kernel.o
gCursorY obj/video/screen.o
obj/system/pci.o
gTextColor obj/video/screen.o
obj/system/memory.o
obj/kernel.o
kBytesPerScreen obj/video/screen.o
obj/kernel.o
kMaxLines obj/video/screen.o
obj/system/debug.o
obj/system/interrupts.o
obj/kernel.o
main obj/kernel.o
textColor obj/system/memory.o
obj/kernel.o
-T
On Wednesday, March 27, 2019 at 12:10:03 PM UTC-4, Antony wrote:
Mercury Thirteen
May 22, 2019, 5:32:31 PM5/22/19
to Night Kernel
Looks good! I haven't had a chance to integrate the new files yet, but it's on my list. I just pushed the 0.1C update to catch the repo up with all the new changes to how functions are called before I get into the more in-depth paging changes.
Mercury Thirteen
Sep 17, 2019, 11:19:55 PM9/17/19
to Night Kernel
Hey Antony, I'm considering making the kernel a little more... "typical" in its layout, so far as having separate files for defines and code. I know in C one would have .h and .c files, but do you know what the Assembly equivalents would be? I think perhaps .asm for code (as we do now) and .inc for defines and such? Also, since some of the defines would be duplicated from file to file, would it make sense to have a "standard" include file which has all the basics in it (like true = 1, false = 0, null = 0, etc.) which would go at the top of every source file, and then additionally have a separate include file for the items specific to the routines in that file, like tTaskInfo for tasks.asm, tPartitionInfo for disks.asm, etc.? Or is there a different way it's done in mainstream programming projects?
Reply all
Reply to author
Forward
0 new messages