0

I'm currently developing my own Operating System known as the ArkOS. Until now, I've been placing all of my assembly functions into my bootloader and just linking them using GCC. I've started on the interrupt handling which, needless to say, requires a lot of coding.

A general layout of the boot.S file:

    Multiboot Header
    Reserve Stack For Initial Thread
    Kernel Entry Point
    Page Setup
    Page Enable
    GDT Enable
    IDT Setup
    Interrupt Service Routines
         .global isr0-isr31
         isr0-isr31:
             cli; push 0-31; push 0-31; jmp isr_common_stub
    ISR Common Stub

Can I expect any sort of performance hit from appending functions to my bootloader? Also, what would be the proper/correct way of doing this? Would I want all of my assembly in one file as it is, or should I use inline asm, or separate asm files?

Thanks in advance.

edit: Basically if I have one file of asm containing a list of functions will it see a performance increase if I break up that file into other smaller asm files.

Community
  • 1
  • 1
Noah Wood
  • 1
  • 2
  • there is no one/real answer, inline is good when you want to tweak something and not have to call a function for it, but at the same time begs the question if why didnt you take a compiled function and tweak that and use it that way. If you want to wrap interrupts with something specific to your OS, etc then real asm is probably the answer, with the real asm calling the wrapped C/other function. But it is really all up to you... – old_timer Jan 03 '18 at 19:08
  • inline asm is very compiler dependent where real asm is still toolchain specific/dependent but you have much more control. be an operating system or some video game doesnt matter. should probably use as little asm as you can possibly get away with then well down the road profile and tweak as needed. – old_timer Jan 03 '18 at 19:10
  • Alright, IIRC the registers & stack need to be preserved between the statements; that could be an issue if the compiler is destroying-er... "Optimizing" code. – Noah Wood Jan 03 '18 at 19:27
  • Now, the real question is whether I'm going to see a performance loss if I continue placing all the necessary asm into a single file? – Noah Wood Jan 03 '18 at 19:28
  • @NoahWood - Assuming assembly source files, any performance gain would be related to function calls made to functions within a source file versus function calls where the address is filled in by the linker. I don't know the instruction set and how the linker handles calls, so I don't know what, if any, performance gain there would be. I have yet to see an embedded operating system that didn't use multiple source files, so the performance gain is likely to be minimal or non-existent. – rcgldr Jan 03 '18 at 19:35
  • 2
    Can I suggest step 1, get it working, step 2, worry about the little things like function call overhead. Keeping things in a higher level language for as long as possible will probably save more time than anything else. – Michael Dorgan Jan 03 '18 at 19:46
  • @MichaelDorgan I try not to get too hung up on the little things, but if I can fix something now why wait until later? – Noah Wood Jan 03 '18 at 19:56
  • My concern is that fixing this now will cause you to take a lot more time later working around various inline assembly routines that probably are just fine as C files and unless assembly is your native language of choice, switching to it will cost you development time for the rest of your project. Normally I would quote premature optimization, but since you are doing kernel stuff, it doesn't necessarily apply. I'm just trying to get you to the end of your project a bit faster and safer. I will say that unless you can profile, you are guessing anyway. – Michael Dorgan Jan 03 '18 at 20:06
  • @MichaelDorgan Oh, no I already have it written in assembly, tested and it works okay for exception handling; I'm just not sure if doing what I'm doing is the *best* method of structuring my code, so to speak. I think rcgldr answered it though: it depends on the linker. I was worried my code would iterate over the entire source file everytime a function was called, basically if putting it in one file was increasing the amount of 'fluff' in the way, – Noah Wood Jan 03 '18 at 20:19
  • There is no right answer taking a more complicated path up front might make it harder to undo later. Perhaps another way to say it is if you dont already know the answer (we cannot we are not intimately related to the design), then you are likely going to need to implement this more than once. The odds of hitting a home run first time at bat is very low, expect to re-write this several times. So start by just getting something working. then on the subsequent re-writes make improvements. – old_timer Jan 03 '18 at 21:41
  • another thought is the more asm the less portable, do as much as you can without asm... – old_timer Jan 03 '18 at 21:42
  • *I was worried my code would iterate over the entire source file every time a function was called*. Huh? You know assembly is assembled into binary machine code before it runs, not interpreted from the files, right? You can use a disassembler to see what the final binary looks like after linking, including both compiler output and your hand-written asm. See http://agner.org/optimize/ and other links in the [x86 tag wiki](https://stackoverflow.com/tags/x86/info) for more info on making efficient asm. (I can tell you're on x86 from the fact you have a GDT and IDT). – Peter Cordes Jan 04 '18 at 03:07
  • @PeterCordes This is my first real endeavor into a compiled language so I wasn't exactly sure of the specifics on how it actually finds a given instruction, how jumps work, etc. I've used ASM before, but preferred to stick with high level, interpreted languages – Noah Wood Jan 05 '18 at 20:06

0 Answers0