OSDev.org

TheGameMaker90 wrote: See? Was that so hard?

It was really easy. And this shows me that you wrote ". = _start + 512" in your bootloader code without understanding what it means. You didn't bother researching it or ask about it to understand your own code.

If you aren't curious enough to understand the code you are writing or are unable to do some research on your own, it might quickly become a problem for you.

TheGameMaker90 wrote: I recall Octocontrabass mentioning the direction flag [link to the page I came across: https://en.wikipedia.org/wiki/Direction_flag]

That link you posted literally tells you what the direction flag is and what it does. You can find more info in the Intel or AMD manuals.

TheGameMaker90 wrote: How does it work? This page is very limited as well. Where should it go? How does it help me to do what I want to do?

Intel or AMD manuals.

kzinti wrote:

TheGameMaker90 wrote: See? Was that so hard?

It was really easy. And this shows me that you wrote ". = _start + 512" in your bootloader code without understanding what it means. You didn't bother researching it or ask about it to understand your own code.

If you aren't curious enough to understand the code you are writing or are unable to do some research on your own, it might quickly become a problem for you.

TheGameMaker90 wrote: I recall Octocontrabass mentioning the direction flag [link to the page I came across: https://en.wikipedia.org/wiki/Direction_flag]

That link you posted literally tells you what the direction flag is and what it does. You can find more info in the Intel or AMD manuals.

TheGameMaker90 wrote: How does it work? This page is very limited as well. Where should it go? How does it help me to do what I want to do?

Intel or AMD manuals.

Actually, it worked up to this point and technically I'm more used to NASM assembly. It wasn't the first thing I thought about solving. My level of curiousity has got me to where I am today thank you. Besides, I forgot about that line. I was focused on why the top wasn't working.

And yes, a page about a paragraph long is supposed to be enough to tell me why this is needed to call a 16 bit C function into my assembly code. Right...
I defy you to tell me where in this stub I will find the reason I need to change the direction of bits for calling a C function into 16 bit real mode.

They both support x86, what's the difference? Will I need two separate bootloaders? I am currently using AMD, but I'm using VirtualBox to emulate Linux Mint and running QEMU in it. When I run my OS (The one I've almost finished the first part of) it detects the CPU as Intel. On Bare metal hardware (I've tested it) it recognizes the architecture and reports accordingly using CPUID.

Long story short, Intel?

At this point I can't tell if you are serious or not.

kzinti wrote:At this point I can't tell if you are serious or not.

Text on the screen cannot convey emotions, nor intentions behind words. I'm very serious. I'm going off f what he said in a previous post. I updated the post before you commented. Again I'll say it:
I defy you to tell me exactly where in this stub of an article how changing the direction of bits will allow me to call a 16 bit function defined in my C file.

If I'm mistaken, then tell me. You don't have to question my seriousness. I'm new to this. As I've mentioned before, my experience is in practically everything but os development. So forgive me if I have to start from somewhere.

P.S. I'll be looking into all of this, I'm just mentally exhausted. I pulled an all nighter and I can't quit. It's not in my DNA.

Hi,

Quick word of advice - never pull all nighters. I cant count the number of times stepping away and doing something else just for a resolution to manifest itself. You cant program or debug well if you are tired. It is also hard to read and follow technical documentation if you are tired: get some sleep. Your code will still be there in the morning.

Additionally - i always recommend using the toolchain you are most famailier with. I prefer intel syntax over at&t thus i use nasm (or nasm like). If your experience lies with nasm, id advise using it.

Wouldn't it be 5 based on your theory? 0-4 is 5 values. Again, I could be wrong. But that was meant as more of an example of what I'm talking about. The GDT tutorial shows us a 64 bit GDT, but not a 32 bit one too

Want to complete this example as well: What was posted given the example and code was not a theory: it is what it does. The selector is the index which is 4 in the provided example. It is important to note that segmentation never goes away: Its just that protected and long modes gives us more freedom to define our own segments with additional protection elements added in. However most operating systems overlap the segments when possible to create the illusion of a flat memory model when defining the GDT.

Perhaps as an exercise, define the structure in C using stdint types what you believe the GDT should be based on what is here. Also bookmark the Intel processor manuals here. Er, also, if you are using C, just in case, make sure to set structure member padding to 0.

TheGameMaker90 wrote:Without the ljmp it works finme, but yes, you are all right that I don't know enough about the registers to know what's in CS without the ljmp instruction.

What? No, we're saying you don't know what's in CS without the LJMP instruction because it's impossible to know. It's undefined.

TheGameMaker90 wrote:Now If I try to call that boot_main function, what is required? Will it work in the current state?

Your C code needs to all be in memory. The BIOS loads exactly one sector, and it's up to you to load the rest. With some linker trickery, you could fit your current code into one sector, but you'll run out of space pretty quickly. You really can't do much in 512 bytes.

TheGameMaker90 wrote:I recall Octocontrabass mentioning the direction flag [link to the page I came across: https://en.wikipedia.org/wiki/Direction_flag]

How does it work? This page is very limited as well. Where should it go? How does it help me to do what I want to do?

The direction flag must be clear before calling or returning to C. Why? Because the ABI says so.

TheGameMaker90 wrote:They both support x86, what's the difference? Will I need two separate bootloaders?

There are a handful of minor differences between the two, but you don't have to worry about that in a bootloader. You definitely don't have to write two of anything.

neon:
You make a good point. People keep telling me the same thing. It's just hard when passion forces sleepless nights. I have to work on that.
There are two main reasons I want to learn GAS Assembly:
1. Because I like the syntax. movl $0x0, %ax just makes more sense to me than mov ax, 0x0 even though they do the same thing. The order in which they're represented just seems more logical. I'm moving 0x0 into ax. Vs. I'm moving the thing on the right into the thing on the left.
2. Because I'm using GCC as my C compiler, inline assembly closely resembles GAS syntax. As a result it feels more consistent, like it's one big piece of coherent code that's supposed to be part of the same code base. I'm a bit of a perfectionist so it bothers me when I mix NASM assembly with it.

Thank you for the sources. I already had the GDT one bookmarked and downloaded the manual a while ago, but I still appreciate it.

And that makes sense. But with following that previously, my OS just triple faulted. I had to follow James Molloy's tutorial to get a decent GDT, then once I understood it I pulled it apart and build a similar, yet different way of using the same struct he provided.

Octocontrabass:
Well then that might be why I don't know what it is .
Based off of what you're telling me, trying to do this in 16-bits is not a very efficient way of doing things. I'm starting to wonder why I would even want to use C for this. I'm limited to 512 bytes for the bootloader. If I'm understanding this correctly, that limit will be quickly reached if I try to use C functions. Another thing I tried to do was just use inline assembly in my boot_main, but it still didn't work. I don't know enough about linkers yet to perform any trickery so perhaps that's not an option at the moment.

Ah yes, I found where you're referring to:
"The direction flag DF in the %EFLAGS register must be clear (set to “forward” direction) on function entry and return."
So does that mean I'd have to use CLD before calling the function and STD after? Also, do I need to read sectors to call C functions into memory at this level, or could I get away with holding off on that until later?

Okay that's a relief. I figured I wouldn't, but the way kzinti made it sound, I wasn't sure. In the meantime I will continue doing research and trying to figure this out.

Hi,

At least the first sector of the bootstrap code is always in assembly due to size limitations. If the bootstrap code spans more then one sector, it would need to load the rest of itself into memory. If using a file system, the bootstrap code is stored in reserved sectors. Typically the bootstrap code loads and executes a boot loader which in turn loads and executes the operating system. This design allows us to write the boot loader core once. Another way of looking at it is in stages: the bootstrap code is "stage 1", the boot loader core file is "stage 2". Sometimes there will be a "stage 1.5" to setup the system to run the boot loader core.

TheGameMaker90 wrote:Because I like the syntax.

Did AT&T pay you to say this? Most people dislike AT&T syntax because it uses different mnemonics than the CPU manuals and requires typing so many symbols.

TheGameMaker90 wrote:Because I'm using GCC as my C compiler, inline assembly closely resembles GAS syntax.

Well, of course it does. GCC passes that text directly to the assembler (after filling in operands, if necessary). It's also possible to use Intel syntax in inline assembly, or write inline assembly that supports both at once, but it's usually not worth the effort.

Intel syntax is similar to NASM syntax, but not the same.

TheGameMaker90 wrote:I'm limited to 512 bytes for the bootloader.

You're limited to 512 bytes for the first part of your bootloader. You can put the rest of your bootloader elsewhere, as long as you load it from the disk before you try to run it.

TheGameMaker90 wrote:So does that mean I'd have to use CLD before calling the function and STD after?

Why set the direction flag? If you're not going to use it, you can clear it once and leave it alone.

TheGameMaker90 wrote:Also, do I need to read sectors to call C functions into memory at this level, or could I get away with holding off on that until later?

You need linker trickery to fit any C code into your 512-byte boot sector. Since you said you don't want to do that, you'll need to load more sectors.

Octocontrabass wrote:Most people dislike AT&T syntax

Speak for yourself. I like the added clarity.

nullplan wrote:

Octocontrabass wrote:Most people dislike AT&T syntax

Speak for yourself. I like the added clarity.

I also think AT&T syntax is way better. Explicit wins over implicit here.

The order of operands is not what I would have done and it took me a while to get used to it after years of Intel syntax. But I wouldn't want to go back.

Octocontrabass wrote: Did AT&T pay you to say this? Most people dislike AT&T syntax because it uses different mnemonics than the CPU manuals and requires typing so many symbols.

+1. when I first saw that, I thought wtf is this? it looked like some hacker's cat took over a keyboard. as solar said here once, it looks like manure. nullplan, who would doubt, you'd like anything coming from that unix cave. jokes aside, sorry for offtopic, I have no idea what this thread about, but I wish the OP good luck with his challenge.