g++ compile issue

[tsdnz]

Hi Guys, I am running in long mode nicely.
But I have an issue with g++ compiling code incorrectly.
I have a smallish amout of code, but the exact cause is here.

All this does is show my title 3 characters in from the top left and should pad 7 P characters after the title.
This works fine, as below in the disassembly

Code: Select all

inline void _ShowTitle()
	{
		unsigned short* pScreen = (unsigned short*)(0xB8000 + (3 * 2));
		const char* ch = CurrentDisplayWindow->Title;
		int i = 1;
		for (i = 1; i <= TitleWidth; i++)
		{
			if (*ch == 0)
				break;

			*pScreen++ = MakeCharAndColor((char)*ch++, TitleForeground, TitleBackground);
		}

		i = 1;
		while (i <= 7)
		{
			*pScreen++ = MakeCharAndColor('P', TitleForeground, TitleBackground);
			i++;
		}
	}

7 P's disassembly

Code: Select all

 135:   84 c9                   test   cl,cl
 137:   75 df                   jne    118 <_Z11StartKernelv+0x118>
 139:   b8 50 2f 00 00          mov    eax,0x2f50
 13e:   b9 50 2f 00 00          mov    ecx,0x2f50
 143:   be 50 2f 00 00          mov    esi,0x2f50
 148:   bf 50 2f 00 00          mov    edi,0x2f50
 14d:   41 b8 50 2f 00 00       mov    r8d,0x2f50
 153:   41 b9 50 2f 00 00       mov    r9d,0x2f50
 159:   41 ba 50 2f 00 00       mov    r10d,0x2f50
 15f:   66 89 02                mov    WORD PTR [rdx],ax
 162:   66 89 4a 02             mov    WORD PTR [rdx+0x2],cx
 166:   66 89 72 04             mov    WORD PTR [rdx+0x4],si
 16a:   66 89 7a 06             mov    WORD PTR [rdx+0x6],di
 16e:   66 44 89 42 08          mov    WORD PTR [rdx+0x8],r8w
 173:   66 44 89 4a 0a          mov    WORD PTR [rdx+0xa],r9w
 178:   66 44 89 52 0c          mov    WORD PTR [rdx+0xc],r10w
 17d:   f4                      hlt

But ??? When I change while (i <= 7) to while (i <=8) I get this dissassembly.

Code: Select all

 135:   84 c9                   test   cl,cl
 137:   75 df                   jne    118 <_Z11StartKernelv+0x118>
 139:   66 0f 6f 05 00 00 00    movdqa xmm0,XMMWORD PTR [rip+0x0]        # 141 <_Z11StartKernelv+0x141>
 140:   00
 141:   f3 0f 7f 02             movdqu XMMWORD PTR [rdx],xmm0
 145:   f4                      hlt

Any idea why?

In case this is needed here are my command lines.

Code: Select all

$ x86_64-elf-g++ -c kernel.c -o kernel.o -ffreestanding -O3 -Wall -Wextra -nostdlib -nostartfiles -nodefaultlibs -m64 -std=c++11

Code: Select all

$ objdump -d kernel.o -M intel

[jnc100]

G++ is optimizing your writes with SSE instructions, and I presume you haven't set up SSE yet. The simplest way is sort this is probably to disable sse in g++: add -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow to your compiler options.

Regards,
John.

[tsdnz]

Cheers, now I am interested in settings these up.

Do you have a link on what is required to setup optimisation for SSE instructions?

[dozniak]

Yep: Intel Manuals.

[tsdnz]

Righty, will do.

[sortie]

Code: Select all

$ x86_64-elf-g++ -c kernel.c -o kernel.o -ffreestanding -O3 -Wall -Wextra -nostdlib -nostartfiles -nodefaultlibs -m64 -std=c++11

Please note that -O3 tries to generate fast code with all the tricks possible, even if it makes the generated code considerably larger, but sometimes the larger code even makes things slower. -O2 is meant as the general purpose optimization level that doesn't produce bloated code. You may wish to put some thought into which level you use. For instance, -O3 likes the SSE tricks you just encountered.

Note that -nostdlib is equal to passing -nostartfiles and -nodefaultlibs. If you pass -nostdlib you should completely remove -nostartfiles and -nodefaultlibs because they are redundant. Additionally, these options only make sense when you link the kernel, so you shouldn't pass them when compiling individual kernel files. Note that -m64 means "Hey, use a 64-bit compiler mode" but you are compiling with x86_64-elf-g++ which already defaults to a 64-bit compiler mode (what else did you expect x86_64-elf to mean?), so you should just delete that as well.

You seem a bit confused about for loops. If you want to loop 8 iterations over 0, 1, 2, 3, 4, 5, 6, 7 you can just do:

Code: Select all

 for ( int i = 0; i < 8; i++ ) 

(Note that you don't always want to use an int, but rather an unsigned int, or a size_t, or something completely different. Pay attention to data types.)

[jnc100]

As a side note I'd probably discourage using SSE in the kernel as you'd have to save the user programs SSE state when running these instructions. Its not impossible to do, either with a naive implementation that always saves the SSE state upon entering the kernel and restores it on exit, or making use of the TS flag in CR0 and the #NM exception, its just probably something that's more likely to introduce difficult to debug errors when you're still in the printing characters to screen stage.

Regards,
John.

[tsdnz]

Thanks John, good points.

This solution, and the other 2 I need to get this project running are only a single task machines.
I am planning to add user programs in my next project, thanks for your inputs.

Currently I have 512GB mapped, possible 64 ethernet cards, possible 256 CPU's, just one SATA.
Everything was written in assembly, but the next stage requires a lot of code so I thought I would convert everything to C++
I am using VS 2012 C++ for my IDE.
I find this very easy to program in.
Pressing F5 to compile and run runs my VS Windows Application.
My C++ files are just included and not compiled.
My Win App creates batch files to compile my BootLoader and my SeconaryLoader from asm to binary.
My Win App opens cygwin (if not already open) and sends keys to do the commands I want.
g++ etc...
If the programs are compiled ok then my Win App joins all the bins together into an image file and runs qemu-img to convert this to virtual hard disk.
It then automates setting up Virtual Box to use this, setting up ethernet, storage, cpu's etc...
It then runs Virtual Box and opens the VM.

My next step is to add more functionalilty to my Win App so I can create additional projects and solutions within projects.

All good fun.

[tsdnz]

SSE is going now, thanks.

[Nessphoro]

Thanks John, good points.

This solution, and the other 2 I need to get this project running are only a single task machines.
I am planning to add user programs in my next project, thanks for your inputs.

Currently I have 512GB mapped, possible 64 ethernet cards, possible 256 CPU's, just one SATA.
Everything was written in assembly, but the next stage requires a lot of code so I thought I would convert everything to C++
I am using VS 2012 C++ for my IDE.
I find this very easy to program in.
Pressing F5 to compile and run runs my VS Windows Application.
My C++ files are just included and not compiled.
My Win App creates batch files to compile my BootLoader and my SeconaryLoader from asm to binary.
My Win App opens cygwin (if not already open) and sends keys to do the commands I want.
g++ etc...
If the programs are compiled ok then my Win App joins all the bins together into an image file and runs qemu-img to convert this to virtual hard disk.
It then automates setting up Virtual Box to use this, setting up ethernet, storage, cpu's etc...
It then runs Virtual Box and opens the VM.

My next step is to add more functionalilty to my Win App so I can create additional projects and solutions within projects.

All good fun.

I think this might be relevant:
http://forum.osdev.org/viewtopic.php?f= ... 6&start=39
Also
http://forum.osdev.org/viewtopic.php?f=2&t=26138

[tsdnz]

Interesting....

I choose VS as I know VS and what windows can / cannot do, or atleast I think I do.

I have no experience with linux.

All I wanted was a compiler to compile to 64 bit binary.
The rest I can take care of, for now???????

For example:
In my origional asm files if I was in debug it would insert into the asm file the procedure, line and file that each instruction was on.
Only for procedures with Proc (Proc is a macro, but I parsed the asm files for it)
I also added other utils for myself, like comments, ins and outs for procedures etc.
When multiple CPU's were running it would trap exceptions for that CPU's and report the line, file, proc etc for my.
Very nice, but it did take time to assembly.
I will do the same for the c files shortly.

Thanks for all the comments.